форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Увидел свет OpenVPN 2.4.0"	+/–
Сообщение от opennews (??) on 28-Дек-16, 10:51
После почти четырёх лет с момента публикации ветки 2.3 выпущен (https://sourceforge.net/p/openvpn/mailman/message/35571939/) релиз OpenVPN 2.4.0 (http://openvpn.net/index.php/open-source/downloads.html), пакета для создания виртуальных частных сетей, позволяющего организовать шифрованное соединение между двумя клиентскими машинами или обеспечить работу централизованного VPN-сервера для одновременной работы нескольких клиентов. Код OpenVPN распространяется под лицензией GPLv2, готовые бинарные пакеты подготовлены (https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos) для Debian, Ubuntu, CentOS, RHEL и Windows. Из добавленных в новой версии улучшений (https://github.com/OpenVPN/openvpn/blob/master/Changes.rst) можно отметить: -  Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN. В новой версии представлен новый протокол  P_DATA_V2, в котором для идентификации клиента используется универсальный Peer-ID. При изменении IP-адреса/порта, но сохранении Peer-ID, серевер считает соединение мигрировавшим, проверяет HMAC и обновляет сетевые параметры клиента в своих внутренних структурах без повторного согласования соединения; -  Реализована возможность использования режима блочного шифрования AEAD (https://ru.wikipedia.org/wiki/AEAD-%D1%80%D0&...) GCM, при котором шифруется лишь важная часть данных (IP-адреса, номера протоколов и прочие метаданные остаются открыты), но всё сообщение, включая  AEAD]открытые метаданные, аутентифицировано. По сравнению с CBC пакеты в формате AEAD привносят небольшие накладные расходы - при схеме AES-128-GCM дополнительно добавляется 20 байт на пакет вместо 30 байт для AES-128-CBC + HMAC-SHA1; -  Добавлена поддержка протокола согласования ключей на основе эллиптических кривых ECDH (https://ru.wikipedia.org/wiki/%D0%9F%D1%...) (Elliptic Curve Diffie-Hellmann), позволяющего имея незащищённый канал связи получить двум сторонам общий секретный ключ для дальнейшего шифрования; -  Включен по умолчанию механизм согласования шифров ("--cipher"), используемых для защиты канала передачи данных. Если клиент объявит о поддержке согласуемых параметров шифрования (NCP, Negotiable Crypto Parameters), то сервер выберет оптимальный шифр (по умолчанию AES-256-GCM) и предложит его клиенту. Управлять доступными для согласования шифрами можно через опции "--ncp-ciphers" и "--ncp-disable". В случае если на клиенте или сервере используется старая версия OpenVPN, то возможно ограниченное согласование, при котором система с OpenVPN 2.4 может выбрать шифр, используемый на стороне с более ранее версией OpenVPN. Например, клиент 2.4 с "--cipher BF-CBC" и  "ncp-ciphers AES-256-GCM:AES-256-CBC" может подсоединиться  как к серверу 2.3 с выбранным шифром BF-CBC в файле конфигурации, так и с AES-256-CBC; -  Добавлена поддержка сжатия при помощи алгоритма LZ4 (ранее поддерживался только LZO) и возможность передачи параметров сжатия со стороны сервера; -  Добавлена опция "--tls-crypt" для увеличения защиты конфеденциальных данных о соединении пользователя. Опция позволяет использовать заранее предопределённые статические ключи для шифрования  пакетов с управляющей информацией; -  Улучшена работа в окружениях, одновременно использующих  IPv4 и IPv6. Например, при соединении с внешним хостом OpenVPN пытается соединиться перебирая все привязанные в DNS  адреса IPv6 и IPv4. В настройки добавлена новая опция DNS6 для явного задания DNS-резолвера для IPv6; -  Добавлена опция pull-filter, позволяющая явно разрешить или запретить приём опций отправляемых сервером. Также добавлена опция push-remove для выборочного удаления опций из списка "push"; -  Добавлена опция "--auth-gen-token", при указании которой сервер сгенерирует случайный токен  и предаст его клиенту без изменения модулей аутентификации. Режим полезен для реализации схем с одноразовыми паролями, позволяя организовать периодическое обновление ключей без необходимости ввода новых кодов OTP; -  Значительно расширен графический интерфейс, встроенный в установочный пакет для Windows. В том числе обеспечена возможность запуска OpenVPN GUI в Windows без наличия привилегий администратора. Полностью переписана прослойка для запуска сервиса OpenVPN в Windows.   В установщике OpenVPN 2.4 прекращена поддержка Windows XP; -  Добавлена поддержка платформ Android (через VPNService API) и AIX (через устройство tap). Для macOS реализована возможность использования встроенного хранилища ключей. URL: https://sourceforge.net/p/openvpn/mailman/message/35571939/ Новость: http://www.opennet.dev/opennews/art.shtml?num=45777
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

3. "Увидел свет OpenVPN 2.4.0"	–2 +/–
Сообщение от Аноним (??) on 28-Дек-16, 11:13
интересно, производительность по сравнению с open any connect как? Кто-нибудь замерял?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Увидел свет OpenVPN 2.4.0"	+3 +/–
	Сообщение от cmp (ok) on 28-Дек-16, 13:25
	А это что такое, впрочем, мне не интересно, линуха-линуха и через ssh нормально туннелится, а роутеры умеют gre, ipip и openvpn. gre у каждого свой, ipip бесполезен, так что выбор не велик.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	45. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от qwerty123 (??) on 28-Дек-16, 15:53
	>gre у каждого свой неправда, прекрасно стандартизован.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	81. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от cmp (ok) on 29-Дек-16, 04:38
	> неправда, прекрасно стандартизован. А я утверждал обратное? Нет. Я говорил о том, что сервер под разных клиентов gre поднять заморочно, а может и невозможно, так как стандартов много, а на софт-vpn легко, тока копии процесса по разным портам расскидать с разными настройками.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	87. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer on 29-Дек-16, 12:46
	Можете чуть подробнее рассказать, что вы имеете ввиду под GRE у каждого свой? Не считая первое RFC, их всего два вида заголовков стандартизировали. Один причём исклюзиано для PPTP, а второй общепринятый, его все и используют.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	93. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от cmp (ok) on 29-Дек-16, 15:46
	> Можете чуть подробнее рассказать, что вы имеете ввиду под GRE у каждого > свой? Не считая первое RFC, их всего два вида заголовков стандартизировали. > Один причём исклюзиано для PPTP, а второй общепринятый, его все и > используют. GRE, OSPF, BGP, STP, LLDP и наверняка еще столько же не вспомнил, протоколы и стандарты, которые у каждого вендора, со своими "плюшками" из-за которых частенько оно в кроссвендорных связках не работает или работает, но криво. Полгода назад, ковырял этот gre, уж не помню откуда куда, но на одном конце пакеры tcpdump показывает in-out, на другом показывает только out.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	94. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer on 29-Дек-16, 15:53
	Если честно, исключая LLDP, с ним плотно не работал, у названных протоколов проблем в реализации между вендорами не встречал. Под вендорами я имею ввиду, Cisco, Juniper и тд., D-Link, TP-Link и прочие ломают что угодно и когда угодно.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	118. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 30-Дек-16, 10:00
	> Если честно, исключая LLDP, с ним плотно не работал, у названных протоколов > проблем в реализации между вендорами не встречал. Под вендорами я имею > ввиду, Cisco, Juniper и тд., D-Link, TP-Link и прочие ломают что > угодно и когда угодно. Повезло вам, а нам на циски денег не дают, лучшее из того, что есть - это хуавей, хотя однажды и он заставил понервничать, когда порт в даун не уронил, а трафик дропнул
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	120. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от zanswer CCNA RS on 30-Дек-16, 10:39
	Я слышал много хорошего о Huawei, по отношению к другим Китайским брендам.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	124. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 30-Дек-16, 12:23
	> Я слышал много хорошего о Huawei, по отношению к другим Китайским брендам. В целом железо прекрасное, в 2 раза дешевле и в 2 раза производительнее циски.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	127. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Нечестивый (ok) on 31-Дек-16, 13:15
	> Под вендорами я имею ввиду, Cisco, Juniper и тд. Со стороны Juniper проблем тоже ни видел и вряд ли будут, но вот Cisco очень любят скупать и ребрандировать под себя все что сумеют. Правда с GRE проблем пока не видел, но вот с невозможностью запустить BGP или скажем IPSEC из за экзотичности диалекта сталкивался не раз. Самое интересное что если обоих стран - Cisco шансы на такой конфуз увеличиваются.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	95. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer on 29-Дек-16, 15:57
	Если пакеты на одной из сторон не возвращаются, значит имеет место быть их потеря в транзите, например по причине асимметричной маршрутизации, при которой обратные пакеты уходят не туда. Возможно я вас не правильно понял, но не вижу тут причин винить GRE, если пакеты вообще не пришли на интерфейс.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	117. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 30-Дек-16, 09:54
	> Если пакеты на одной из сторон не возвращаются, значит имеет место быть > их потеря в транзите, например по причине асимметричной маршрутизации, при которой > обратные пакеты уходят не туда. > Возможно я вас не правильно понял, но не вижу тут причин винить > GRE, если пакеты вообще не пришли на интерфейс. НА Интерфейс туннеля нет, а на интерфейс физический gre трафик сыпется.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	121. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от zanswer CCNA RS on 30-Дек-16, 10:42
	С удовольствием бы сделал TSHOOT по данной теме, если трафик дошёл до физического интерфейса, значит debug или имеющийся аналог функции на устройстве, мог бы пролить свет на то, что происходит далее с пакетом.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	49. "Увидел свет OpenVPN 2.4.0"	+3 +/–
	Сообщение от ram_scan on 28-Дек-16, 16:34
	Было время когда GRE грустно ходил через NAT на сохо железках. Лично я с той поры как-то в UDP верую больше.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	74. "Увидел свет OpenVPN 2.4.0"	+1 +/–
	Сообщение от Аноно on 29-Дек-16, 00:52
	с тех пор что-то изменилось? GRE и сейчас грустно ходит через NAT
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	80. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 29-Дек-16, 04:26
	> Было время когда GRE грустно ходил через NAT на сохо железках. Лично > я с той поры как-то в UDP верую больше. Даже сейчас есть железо через которое gre не натится, причем операторское.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	86. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer on 29-Дек-16, 12:42
	Тому есть вполне простое объяснение, вытекающие из формата заголовка GRE, а делать ALG в масштабах операторских решений не всегда рентабельно вестимо.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	96. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 29-Дек-16, 16:01
	> Тому есть вполне простое объяснение, вытекающие из формата заголовка GRE, а делать > ALG в масштабах операторских решений не всегда рентабельно вестимо. Дело в том, что железка которая не умеет стоила 3 миллиона дервянных в 13-14 годах, сейчас она толи 5, толи 6 стоит, при этом вендор для решения проблемы предлагает поставить циску и ацлками завернуть на нее gre трафик, хотя проще было бы купить циску и использовать ее, в стойке их стоит 4 штуки, а для 20 миллионой покупки формат заголовка не оправдание, к счастью или сожалению это не единственная проблема железки, поэтому, аллилуя, их скоро заменят хуавеями, но тем не менее.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	98. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer on 29-Дек-16, 16:17
	>> Тому есть вполне простое объяснение, вытекающие из формата заголовка GRE, а делать >> ALG в масштабах операторских решений не всегда рентабельно вестимо. > Дело в том, что железка которая не умеет стоила 3 миллиона дервянных > в 13-14 годах, сейчас она толи 5, толи 6 стоит, при > этом вендор для решения проблемы предлагает поставить циску и ацлками завернуть > на нее gre трафик, хотя проще было бы купить циску и > использовать ее, в стойке их стоит 4 штуки, а для 20 > миллионой покупки формат заголовка не оправдание, к счастью или сожалению это > не единственная проблема железки, поэтому, аллилуя, их скоро заменят хуавеями, но > тем не менее. Cisco тоже не умеет делать ASIC accelerated NAT для GRE, насколько я знаю, поскольку заголовок GRE просто не обладает полем с уникальным значением для идентификации отдельных пакетов.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	85. "Увидел свет OpenVPN 2.4.0"	+1 +/–
	Сообщение от zanswer on 29-Дек-16, 12:25
	GRE без IPSec бесполезен, если же вы про PPTP GRE вариант, то он не актуален совершенно уже.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	91. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer on 29-Дек-16, 13:37
	Кстати, насчёт UDP, есть вот такой draft, GRE-in-UDP: https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-enca... Но я бы всё равно GRE без IPSec использовать в рамках сети Internet в жизни бы не стал.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	133. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 00:20
	> Но я бы всё равно GRE без IPSec использовать в рамках сети > Internet в жизни бы не стал. Не в обиду, но все эти ваши ipsec и gre очень геморны в настройке, застревают на первом же фаере или нате, через прокси не жильцы в принципе и еще и безопасность достаточно хилая. В результате долботни много а толку мало. Вот народ и предпочел дружно сабжа. Он сделан для реального интернета и его неидеальностей. Так что это можно быстренько настроить и потом еще и работать будет. Без секаса с ипсеками и прочих gre.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

5. "Увидел свет OpenVPN 2.4.0"	+/–
Сообщение от Аноним (??) on 28-Дек-16, 11:27
Есть хорошая статья по установке и настройке OpenVPN?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Увидел свет OpenVPN 2.4.0"	+84 +/–
	Сообщение от Andrey Mitrofanov on 28-Дек-16, 11:28
	> Есть хорошая статья по установке и настройке OpenVPN? "Измена Родине" подойдёт?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	12. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 28-Дек-16, 12:04
	спасибо, поржал :) хотя на сегодня более актуальна ст. 280
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	58. "Увидел свет OpenVPN 2.4.0"	+1 +/–
	Сообщение от ZloySergant (ok) on 28-Дек-16, 17:54
	>спасибо, поржал :) хотя на сегодня более актуальна ст. 280 282-я же, для опеннета, по крайней мере. После 130-й. :) P.S. Притянуто за уши, но и верхние - тоже не ангелы, а йумаристы. :)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	8. "Увидел свет OpenVPN 2.4.0"	+1 +/–
	Сообщение от Аноним (??) on 28-Дек-16, 11:30
	Есть, а что?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	11. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 28-Дек-16, 11:39
	да и книги есть https://openvpn.net/index.php/open-source/books.html эта гуляет в нете ebook качества Beginning OpenVPN 2.0.9 by Markus Feilner and Norbert Graf Publisher: Packt Publishing (December 2, 2009) а так вот неплохая статья http://bfy.tw/9A5u
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	26. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 28-Дек-16, 13:34
	косвенно  https://bettercrypto.org/
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	34. "Увидел свет OpenVPN 2.4.0"	+4 +/–
	Сообщение от dep on 28-Дек-16, 14:21
	На Digitalocean все есть. https://www.digitalocean.com/community/tutorials/how-to-set-...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	64. "Увидел свет OpenVPN 2.4.0"	+2 +/–
	Сообщение от Аноним (??) on 28-Дек-16, 20:08
	Нижняя палата РФ уже работает над этим. ))
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "Увидел свет OpenVPN 2.4.0"	+1 +/–
Сообщение от Аноним (??) on 28-Дек-16, 11:33
>Please note that OpenVPN 2.4 installers will not work on Windows XP. Плак-плак :(
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Увидел свет OpenVPN 2.4.0"	+1 +/–
	Сообщение от Аноним (??) on 28-Дек-16, 12:11
	это диверсия !
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	79. "Увидел свет OpenVPN 2.4.0"	+1 +/–
	Сообщение от 404 not found on 29-Дек-16, 04:24
	с этим надо что-то делать
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

14. "Увидел свет OpenVPN 2.4.0"	+12 +/–
Сообщение от VPN это сила on 28-Дек-16, 12:32
Я слышал, что есть какие-то системы, определяющие OpenVPN, вроде как провайдет может определить OpenVPN и порвать соединение. В том же Китае он не работает, и некоторые VPN-провайдеры предлагают проприетарные решения для обхода таких блокировок. Я слышал, что OpenVPN вроде-бы хочет предпринять что-то в этом направлении, чтобы была маскировка от таких "детекторов". Что известно об этом?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Увидел свет OpenVPN 2.4.0"	+4 +/–
	Сообщение от Andrey Mitrofanov on 28-Дек-16, 12:36
	> Я слышал, что есть какие-то системы, >Я слышал, что OpenVPN вроде-бы хочет предпринять что-то в этом > направлении, чтобы была маскировка от таких "детекторов". Что известно об этом? https://duckduckgo.com/?q=openvpn+traffic+obfuscation
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	17. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от VPN это сила on 28-Дек-16, 12:40
	Спасибо, очень интересно.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	134. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 03-Янв-17, 00:23
	> https://duckduckgo.com/?q=openvpn+traffic+obfuscation Посадят тебя по твоей же статье. Хоть и за утку вместо спутника.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	62. "Увидел свет OpenVPN 2.4.0"	+1 +/–
	Сообщение от sage (??) on 28-Дек-16, 19:29
	Для этого как раз сделали опцию tls-crypt в новой версии.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

15. "Увидел свет OpenVPN 2.4.0"	+8 +/–
Сообщение от VPN это сила on 28-Дек-16, 12:33
> Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN. Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть, или где-то еще?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от Меломан1 on 28-Дек-16, 13:32
	Не совсем понимаю в каких случаях это может пригодиться?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	35. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 28-Дек-16, 14:23
	GPRS
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	37. "Увидел свет OpenVPN 2.4.0"	–2 +/–
	Сообщение от Меломан1 on 28-Дек-16, 14:51
	Не актуально. Прокачиваться будет не более 33.6кбит/c. даже заголовки сообщений будут с трудом просачиваться на таком соединении.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	43. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Клыкастый (ok) on 28-Дек-16, 15:51
	> Прокачиваться будет не более 33.6кбит/c на IRC хватит
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	47. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 28-Дек-16, 16:29
	Например, чтобы не палиться перед ISP, постоянно переподключая VPN-соединение для смены IP.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	106. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 30-Дек-16, 02:58
	Multi-Wan вариации(всех типов) и Multipath-TCP использование. в Ad-Hoc/Mesh сетях тоже обычное дело(а там и оборонные и помышленные среди них есть а не только меш потато и вские гипербореи).
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	115. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer CCNA RS on 30-Дек-16, 08:52
	Вот авторы RFC4555 Mobility and Multihoming Protocol (MOBIKE), дают исчерпывающий ответ, зачем это может понадобиться. There are scenarios where these IP addresses might change. One example is mobility: a host changes its point of network attachment and receives a new IP address. Another example is a multihoming host that would like to change to a different interface if, for instance, the currently used interface stops working for some reason. The main scenario for MOBIKE is enabling a remote access VPN user to move from one address to another without re-establishing all security associations with the VPN gateway.  For instance, a user could start from fixed Ethernet in the office and then disconnect the laptop and move to the office's wireless LAN.  When the user leaves the office, the laptop could start using General Packet Radio Service (GPRS); when the user arrives home, the laptop could switch to the home wireless LAN. MOBIKE updates only the outer (tunnel header) addresses of IPsec SAs, and the addresses and other traffic selectors used inside the tunnel stay unchanged. Thus, mobility can be (mostly) invisible to applications and their connections using the VPN. Протоколы разные, но принцип схожий, что IPsec, что OpenVPN, должны сначала выполнить согласование ряда параметров, как то алгоритмы шифрования, хеширования, выполнить аутентификацию, согласовать общий ключ для симметричных алгоритмов шифрования и HMAC функций и тд. Всё это требует времени, вычислительных ресурсов и может привести к потерям сегментов/датаграм, что в зависимости от типа приложений может быть, как критично для QoE, так и нет. То есть посторонние шумы или обрыв VoIP звонка, это плохо, снижение скорости закачки файла на короткий промежуток времени нет.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	135. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 00:30
	> Не совсем понимаю в каких случаях это может пригодиться? В любых когда соединение нестабильное. Например беспроводка. Не круто, понимаешь, если все дружно отлипает только на том основании что реконект случился.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	29. "Увидел свет OpenVPN 2.4.0"	–3 +/–
	Сообщение от cmp (ok) on 28-Дек-16, 13:38
	> Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть, > или где-то еще? Чет не очень понимаю зачем, давеча поставил фалег лится на ноут с хранилища, смотрю скорость бе, воткнул провод, 1 строкой в shell перевесил ip на ethernet и ни ssh не порвалось, ни закачка. Хотя чисто из академического интереса можно запихивать vpn-интерфейсы в мост с stp, но  при сходимость кольца все равно потеряет данные, IP всегда теряет данные, он байдизайн ширину канала по потерям расчитывает, так-то.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	31. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от Меломан1 on 28-Дек-16, 14:03
	Ни хера не понял в твоих манипуляциях. Подробности, пожалуйста.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	36. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 28-Дек-16, 14:48
	Это явно юный админ локалхоста говорит фразы продолжения которых не знает.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	77. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 29-Дек-16, 03:30
	brctl addif br0 tun0 че непонятного
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	42. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от Аноним (??) on 28-Дек-16, 15:18
	>> Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN. > перевесил ip на ethernet и ни ssh не порвалось, ни закачка. В новости говорится что можно сменить IP или/и порт и соединение не прервётся. Я правильно понял что ты не менял ни IP ни порт и говоришь "У меня и так работает"?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	44. "Увидел свет OpenVPN 2.4.0"	+1 +/–
	Сообщение от Клыкастый (ok) on 28-Дек-16, 15:53
	> Я правильно понял что ты не менял ни IP ни порт и говоришь "У меня и так работает"? ты всё правильно понял, а гражданин суммирует часы и устриц.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	78. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 29-Дек-16, 04:18
	> ты всё правильно понял, а гражданин суммирует часы и устриц. Устрицы в голове у тебя. ядро шлет пакеты на хост до которого нет маршрута, между удалением ip с одного интерфейса и навешиванием на другой, и должно бы возвращать - но_роут_ту_хост, но не возвращает же, покрайней мере сразу, значит переустановить соединение-туннель есть время, а уж ip и порт нового значения не имеют, при правильно отстроенных буфферах и таймаутах соединения в туннеле даже не поймут, что что-то произошло.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	88. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer on 29-Дек-16, 13:05
	IP рассчитывает ширину канала по потерям? Можете подробнее изложить свою мысль, что вы имеете ввиду? Для каких целей IP протоколу, который является stetaless протоколом, потребовалось рассчитывать ширину канала, да ещё и по потерям. Может быть вы имели ввиду TCP?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	97. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 29-Дек-16, 16:10
	>  Может быть вы имели ввиду TCP? Определенно, но хотел включить UDP в множество, хотя зря, так как особенности реализации отдельного кое-чего на udp к делу отношения не имеют.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	89. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer on 29-Дек-16, 13:10
	Речь я так понимаю идёт о том, что OpenVPN теперь может динамически в рамках одной сессии, менять tunnel source, что в прошлом приводило к разрыву сессии. Вы же я так понимаю tunnel source не меняли, а изменили только его положение (перенесли на другой интерфейс). Поэтому да, tunnel destiantion не заметил подмены, как вы сами правильно заметили при правильных размерах буфера и dead interval, сессия не будет потеряна.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	99. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 29-Дек-16, 16:17
	>  сессия не будет потеряна. А какая ценность у этой сессии? я хотел обратить внимание на то, что при ее разрыве и скорой установки новой, соединения внутри туннеля при надлежащих параметрах не разорвуться.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	100. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от J.L. on 29-Дек-16, 16:50
	>>  сессия не будет потеряна. > А какая ценность у этой сессии? я хотел обратить внимание на то, > что при ее разрыве и скорой установки новой, соединения внутри туннеля > при надлежащих параметрах не разорвуться. а какие надлежащие параметры и требуют ли они установки с обоих сторон соединения внутри туннеля - и на клиенте (подконтрольном) и на сервере (неподконтрольном) (частенько рвётся впн и приходится клиентскую подтуннельную программу переподключать) и стоит ли мне задуматься над схемой "виртуальноеEth -> впнEth1+впнEth2(на разные сервера целевой подсети) -> целевой_сервер" ? (и как такое вообще делать?)
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	104. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 30-Дек-16, 00:38
	Как любил говорить один не_товарищь - открытия требую экспериментов. > виртуальноеEth -> впнEth1+впнEth2(на разные сервера целевой подсети) -> целевой_сервер Вообще не понял ничего, не благодарное дело гадать, но в большенстве случаев на сервера ходят или за сервисами или для управления, сервисы лучше предоставлять через единую точку входа, где их можно будет прикрыть фаерволом ежели чего, управления на серверах, вроде и так не плохо защищено, смысла его туннелировать нет, это я о ssh говорю, как там оно в виндах и макосях беспонятия.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	109. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer CCNA RS on 30-Дек-16, 06:27
	macOS не чем принципиально от любого другого Unix в этом отличаться не будет, такой же SSH и TLS. Windows, по крайней мере в свежих реинкарнациях охотно использует TLS (WS-Management Protocol), возможно и SSH можно использовать, поинтересуюсь у коллег.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	101. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer on 29-Дек-16, 17:29
	У меня конечно же нет ответа, который устроит всех, но давайте представим следующий кейс, у нас есть стандартная, я бы сказал обыденная топология Hub-and-Spoke. В центральном офисе у нас CallManager, в филиалах IP телефон. Руководство ставит задачу, чтобы не пре каких обстоятельствах аудио конференции не прерывались. Не знаю, как дела обстоят с процедурой установления туннеля у OpenVPN, не изучал данный протокол, но в случае GRE over IPSec, в классическом DMVPN к примеру, важно помнить, что при разрыве сессии, нужно будет пройти IPSec Phase 1, IPSec Phase 2, затем создание GRE туннеля, регистрацию на NHRP NHS сервере, иначе наш Hub не будет знать о том, какое соотношение у нас между VPN IP и tunnel IP. Затем нужно установить отношения соседства в OSPF/EIGRP и только после этого можно будет обмениваться пакетами! То есть иными словами, для чувствительного к задержкам и потерям трафика это может быть определённой проблемой. Само-собой, что вы можете резонно заметить, что при таких вводных, можно построить два туннеля, через разные аплинки с Hub, поднять внутри EIGRP и указать, что один из туннелей у нас имеет большую метрику чем другой, при этом же ничто не мешает ему быть feasible successor. В таком случае время переключения будет равно в худшем случае hold time, которое можно всегда изменить на нужное нам. Но топологии и конфигурации бывают разные, да и учесть все детали каждого кейса сложно в абстрактном сообщении. P/S/ Я не претендую этим сообщением на всеобъемлющее исследование или истину в последней инстанции, просто изложил свои мысли.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	105. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 30-Дек-16, 01:19
	> Руководство ставит задачу Это какбы его работа, которая выполняется ровно на столько, на сколько выделятся ресурсов. Всегда конечно можно чего-то сколхозить и часто это даже работает, но самопал есть самопал. > GRE over IPSec, в классическом Ну для кого как. Последнее время "модно" филиалы подключать через микротики, там опенвпн и гре, и много всякого, и по сути обеспечивается л2 с резервом или без, в зависимости от готовности платить. У цисок есть решения для такой задачи. У операторов есть решение, л2 из москвы на чутотку легко, но стоить будет много. > учесть все детали каждого кейса сложно в абстрактном сообщении Подключение филиалов вполне типовая задача. > установить отношения соседства в OSPF/EIGRP А вот это уже задача транспортного подразделения, которое либо организовывает и поддерживает л2 для вашего ip, либо выгоняется на мороз, а на эти деньги покупается л2 у провайдера с резервированием, допустимыми потерями и прочим, что оговоренно в договоре, на клинтских концах ставятся деморкаторы и наступает счастье.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	107. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от zanswer CCNA RS on 30-Дек-16, 05:42
	MPLS L2 VPN через всю страну, это очень дорогое удовольствие в каждый филиал, его ещё нужно чем-то обосновать. Нечего против Mikrotik не имею, они дёшевы, умеют достаточно много, пусть и с оговорками во многих аспектах. Что касается поддержания L2, то я снова не совсем вас понимаю, что вы имеете ввиду? 2 Data-Link Layer, исключая решения MPLS L2 VPN, поддерживать в рамках всего канала между Hub и Spoke, совершенно не возможно, поскольку он закончится на точке демаркации оператора. Объясните, как вы видите работу транспортного отдела? Что он должен обеспечить мне, как сетевому инженеру, чтобы отношения соседства EIGRP/OSPF между Hub и Spoke не нарушались? P/S/ Вообще не вижу причин, для того, чтобы строить именно L2 VPN между филиалами всегда, кроме нескольких специальных кейсов.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	110. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 30-Дек-16, 07:11
	> кроме нескольких специальных кейсов. Согласен, но в большенстве случаев перед ИТ клиентов л2впн стоят другие задачи, и связность филиалов отдается на "аутсорсинг оператору", если клиентскому специалисту интересно, то он занимается и хотябы между соседними точками, которые в прямой видимости находятся вайфайки вешает, если нет, то нет. > Объясните, как вы видите работу транспортного отдела? Транспортники обеспечивают транспорт, резервирование каналов и надлежащую ширину, все остальные подстраиваются под них, если у транспортников канал спутниковый, и узкий и дорогой, то настрайка приоритезации трафика в нем уже не их головная боль. А ОСПФ их, и дать вам подсеть и шлюз в федеральную корп сеть их задача. > Что он должен обеспечить мне, как сетевому инженеру, чтобы отношения соседства EIGRP/OSPF между Hub и Spoke не нарушались Обеспечить транспорт, л3 как минимум который не рвется при разрыве магистральных каналов отдельных операторов или последней мили, то есть его зона ответственности от его железки в филиале до его железки в другом филиале, ваша от кресла директора до железки транспортника, и вашего коллеги от кресла его директора до железки траспортника в другом филиале, если разные города, если один, то вы и ваш коллега можете быть одним лицом, если филиалов много и во многих городах, то транспортники соответственно тоже делять на местных и федеральных. > что вы имеете ввиду? 2 Data-Link Layer Хотелось бы ответить ethernet, но далеко не всегда он чист, периодиски приходится сталкиваться с проблемами, когда ethernet оказывается не ethernet и вланы через него ходят и даже q-in-q ходит, а какой-нибудь bpdu уже нет.  И если на каких-нибудь хуавеях уровня backhaul это решается легко, то всякие релейки сляпаны кто как, там с вланами траблы, а о плюшках и речи нет. Поэтому л2 это траспорт для л3, чтобы там можно было использовать любую адресацию ip4, или ip6 или, прости господи ipx. Так, что в большенстве случаев это просто влан, а вот если клиент хочет, то отдельно в договоре пишет свои хотелки. Кстате, отрганизовать л2 оператору проще, чем л3, так как не надо вбивать ip шлюзов и городить л3 инстанции, чтобы изолироваться, влан прописал и забыл.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	111. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer CCNA RS on 30-Дек-16, 07:31
	Вы всё время замыкаетесь на L2 VPN, к тому же операторский, что не всегда возможно по разным причинам. Представьте, что у вас нет возможности получить MPLS L2 VPN через вашего оператора. Но, у вас есть два оператора, в каждом филиале и центральном офисе, филиалы представлены не только офисами в вашей стране, но и за её пределами или же, внутри страны но с трудно доступных точках. Поэтому мы вынуждены самостоятельно строить нашу VPN сеть, без прямого участия оператора, он просто продаёт нам услуга доступа к сети Internet, всё. Я понял, почему мы долго с вами так уже ведём беседу и ещё не пришли к одному знаменателю, я смотрю с позиции инженера транспортной службы по вашей классификации, а вы инженера внутренней службы отвечающей за сеть внутри. Что касается 2 Data-Link Layer, то в случае L2 VPN он само-собой легко различим, как пример QinQ конфигурация. Но, что если у нас OpenVPN TUN или GRE over IPsec? Канальный уровень у нас закончится на точке демаркации, дальше мы уже не можем не влиять на его работу, не тем более отвечать за него. С точки зрения оператора, конфигурация MPLS PE узла выглядит одинаково на мой взгляд, что же касается в принципе MPLS VPN, то L2 сложнее, чем L3 VPN с точки зрения теории.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	116. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 30-Дек-16, 09:38
	> Что касается 2 Data-Link Layer, то в случае L2 VPN он само-собой > легко различим, как пример QinQ конфигурация. Но, что если у нас > OpenVPN TUN или GRE over IPsec? Канальный уровень у нас закончится > на точке демаркации, дальше мы уже не можем не влиять на > его работу, не тем более отвечать за него. OpenVPN TUN этот который p2p , путаю их все время с TAP, если да, то почему не сделать TAP? Собственно VPN, ИМХО, это и есть способ уйти от точек демаркации, но GRE, ИМХО, не лучшее решение. > Я понял, почему мы долго с вами так уже ведём беседу и > ещё не пришли к одному знаменателю, я смотрю с позиции инженера > транспортной службы по вашей классификации, а вы инженера внутренней службы отвечающей > за сеть внутри. Внутри чего? А вообще, наверное, следовало бы определить смысл букв - VPN. У вас вся сеть как будто это цепочка шифрованных каналов через вражеские физические сети, я же полагаю, что у любой нормальной организации есть центральный офис или несколько, где подключение происходит проводами, которые связаны друг с другом либо своими волсами, либо л2 купленным у провайдера. И уже к той сети подключаются филиалы, по волсам, или через провайдеров, но это уже другой уровень сети, зачем там (в филиале) оспф и бгп, там должен быть мальчик эникейщик , чтобы мышку поменять, и какая-нибудь циска или микротик, чтобы раздавать интернетик и корп сеть, причем у мальчика эникейщика от циски той не должно быть ни пароля ни пачкорда с управлением, а выдаваться она дожна настроенная директору филиала под роспись. > С точки зрения оператора, конфигурация MPLS PE узла выглядит одинаково на мой > взгляд, что же касается в принципе MPLS VPN, то L2 сложнее, > чем L3 VPN с точки зрения теории. Вот не правда, с л3 в свое время голову сломали куда эти ip вешать, умники рекомендовали на ядро сети, но это во-первых, уникальные вланы на каждую точку, через все опорное кольцо волс, во-вторых, клиентские ip на ядре сети - полнейший бред. А с л2 проблем никаких, 5 строк на порт с указанием точки выхода - любой город.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	119. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer CCNA RS on 30-Дек-16, 10:30
	Выбор типа VPN, L2/L3 лежит в плоскости требований вашей сети, обычно L2 VPN используют с целью передачи не IP трафика, в иных случаях использование L2 VPN лишь увеличивает накладные расходы и не даёт не каких преимуществ. Я не знаю, где вы работаете, поэтому я отталкиваюсь от вашей терминологии. Вот смотрите, давайте лучше отталкиваться от какой-то архитектуры сети, например Cisco Enterprise Architecture. У нас есть функциональные блоки, у которых чётко определены роли в сети, Enterprise Campus, включает классическую трёх уровневую иерархическую сеть. Enterprise Edge включает в себя модули обеспечивающие связь между Enterprise Campus и другими блоками корпоративной сети. Далее, идёт Service Provider Edge, он может быть представлен чем угодно, FrameRelay, ATM, MetroEthernet, PSTN, MPLS. Через данный блок подключен блок Remote. Куда входят уже наши филиалы, удалённые сотрудники, мобильные сотрудники и так далее. Внутри блока Enterprise Campus у нас могут быть свои волокна к примеру, почему бы и нет. Но филлилы подключаются к Enterprise Campus через Enterprise Edge, который в свою очередь связан с Service Provider Edge по не контролируемым каналам. И именно от Enterprise Edge до Remote мы и строим нашу Virtual Private Network, которая использует в качестве основы имеющиеся сети операторов. Поскольку количество филиалов может быть не детерминированным, а обмен между информацией между ними по каким либо причинам требуется, при этом прохождение трафика через Enterprise Edge нам не выгодно, по причине высоких задержек, дорогой аренды PVC, 802.1Q Vlan и тд. Возникает резонная задача, обеспечить динамический обмен маршрутной информацией, чтобы филиалы могли выполнять обмен напрямую, минуя центральный офис. Выбор протокола динамической маршрутизации для построения таких VPN сетей, зависит от выбранной технологии и налагаемых ею требований. Находится сетевому инженеру в каждом филиале нет не какой нужды, NOC находится в центральном офисе. Мне сложно судить о том, какая у вас архитектура опорной сети, поэтому, ещё сложнее судить о предложения которые делали какие-то _умнники_. :)
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	125. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 30-Дек-16, 13:06
	Если у вас так, то я за вас рад. А у нас все сильно по-другому, и у остальных тоже. Мелкие и средние компании имеют большое преимущество перед крупными в этом плане.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	122. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от zanswer on 30-Дек-16, 11:09
	Что касается GRE, то у него компактный заголовок, он без каких либо проблем позволяет передавать мультикаст пакеты, исключая трудности с NAT, не каких проблем у него не вижу других. А уж multipoint GRE, так вообще счастье, для любого сетевого инженера. Если вы имеете ввиду, что лучше, то это тема для долгих споров, интернет ими и так полон. :)
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	123. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от zanswer CCNA RS on 30-Дек-16, 11:23
	Странно, при размещении сообщения куда-то OpenVPN потерялся. Я имел ввиду, что OpenVPN vs L2TP vs GRE vs SSTP и так далее, это длинный спор с множеством возможных ситуаций, где лучше один, а где другой ИМХО. :)
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	108. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от zanswer on 30-Дек-16, 06:19
	Поясню насчёт кейсов, что я имел ввиду. Первый кейс, классическая топология Hub-and-Spoke, 1 Hub, 10 Spoke, статические point-to-point линки между Hub и Spoke, весь трафик течёт через Hub между Spoke. Второй кейс, классическая топология Hub-and-Spoke, 1 Hub, 100 Spoke, динамические point-to-multipoint линки между Hub и Spoke, весь трафик течёт через Hub между Spoke. Третий кейс, классическая топология Hub-and-Spoke, 1 Hub, 100 Spoke, динамические point-to-multipoint линки между Hub и Spoke, Spoke и Spoke, трафик течёт согласно маршрутам в RIB, получаемых в объявлениях маршрутизации от Hub. Четвёртый кейс, классическая топология Hub-and-Spoke, 4 Hub, 1000 Spoke, динамические point-to-multipoint линки между Hub и Hub, Hub и Spoke, Spoke и Spoke, трафик течёт согласно маршрутам в RIB, получаемых в объявлениях маршрутизации от Hubs. И это я в рамках L3 VPN только четыре достаточно очевидных кейса описал, которые очень красиво решаются через DMVPN = IPsec + mGRE + NHRP + EIGRP/OSPF/BGP. Поэтому я выше и написал, что учесть в абстрактном сообщение все возможные кейсы просто не возможно, у всех разные задачи, бюджеты, технические возможности, требования безопасности и тд. P/S/ Не претендую на полноту изложения всех возможных сценариев построения VPN сетей в этом сообщении, открыт для любых обсуждений.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	112. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 30-Дек-16, 07:55
	> у всех разные задачи, бюджеты, технические возможности, требования безопасности не такие уж и разные, о безопасности вообще спорно, нормальные безопасники сами все что надо зашуфруют, а похЕРистам оно и не надо, а иначе ходить каждые полгода с инспекцией к провайдеру, а он прям так взял и пустил вас ага))).
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	113. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от zanswer CCNA RS on 30-Дек-16, 08:04
	Под требованиями безопасности я понимаю, не только обеспечение конфиденциальности, целостности и аутентичности передаваемых данных через VPN линк. А такие аспекты, как противодействие утечкам конфиденциальных данных, например путём анализа всего трафика филиалов на Intrusion Prevention System устройствах, для выявления заданных паттернов, свидетельствующих об утечках определённых данных к примеру. К провайдеру ходить совершенно не зачем, IPsec, OpenVPN или любой другой не объявленный устаревшим протокол, обеспечивает все три базовых элемента, конфиденциальность, целостность, аутентичность передаваемой информации, при должном внимание при их настройке конечно. Информационная безопасность же, распространяется не только на такие аспекты, есть ещё масса других организационно правовых норм, которые могут налагать определённые требования на построение сети.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	114. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от zanswer CCNA RS on 30-Дек-16, 08:07
	В общем и целом, проблема защиты от утечек конфиденциальной информации или атак совершаемых изнутри компании, является не менее актуальной, чем защита передаваемых данных через не подконтрольные каналы передачи данных, как например предоставляемый оператором нам 802.1Q Vlan или целый 802.1ad QinQ trunk.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	59. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от бугага on 28-Дек-16, 18:10
	> Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть, или где-то еще? ipsec mobike https://tools.ietf.org/html/rfc4555
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

18. "Увидел свет OpenVPN 2.4.0"	+/–
Сообщение от Аноним (??) on 28-Дек-16, 12:54
Жаль что многопоточность так и не завезли.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	30. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 28-Дек-16, 13:46
	> Жаль что многопоточность так и не завезли. А на кой, если надо из in-буффера скопировать в out-buffer, у вас копирование файлов тоже многопоточное? дефрагментировать не надоело?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	32. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 28-Дек-16, 14:04
	> дефрагментировать не надоело что делают виндопользователи на опеннете?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	40. "Увидел свет OpenVPN 2.4.0"	–2 +/–
	Сообщение от Аноним (??) on 28-Дек-16, 15:11
	>> дефрагментировать не надоело > что делают виндопользователи на опеннете? Ламерить не надоело?
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	76. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok) on 29-Дек-16, 03:28
	ext3? С разморозкой!
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

27. "Увидел свет OpenVPN 2.4.0"	–1 +/–
Сообщение от Ilya Indigo (ok) on 28-Дек-16, 13:37
Не ed25519, не chacha20-poly1305. Как-то не очень секьюрно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	136. "Увидел свет OpenVPN 2.4.0"	+1 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 14:45
	> Не ed25519, не chacha20-poly1305. Ну тогда во: https://www.phoronix.com/scan.php?page=news_item&px=WireGuar... > Как-то не очень секьюрно. Это OpenSSL, детка. Секурно его настроить не сможет даже вон тот CCNA, судя по его постам. Туда же и ipsec'ов всяких.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

33. "Увидел свет OpenVPN 2.4.0"	+/–
Сообщение от arrnorets (ok) on 28-Дек-16, 14:07
Многопоточности все еще не хватает :(
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

38. "Доступен релиз OpenVPN 2.4.0"	–1 +/–
Сообщение от Аноним (??) on 28-Дек-16, 15:04
>В том числе обеспечена возможность запуска OpenVPN GUI в Windows без наличия привилегий администратора. маршруты как будут добавляться? У них и раньше можно было запускать, только без маршрутов оказываешься после этого
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	61. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от K.O. on 28-Дек-16, 18:32
	Возможно они допилили OpenVPN Service под виндой. Теперь OpenVPN GUI просто просит этот сервис запускать OpenVPN, а сервис работает с правами админа, а OpenVPN статусы читаются через management interface. Ваш K.O.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	68. "Доступен релиз OpenVPN 2.4.0"	+1 +/–
	Сообщение от Led (ok) on 28-Дек-16, 22:28
	> У них и раньше можно было запускать, только без маршрутов оказываешься после этого Вендузятники должны страдать.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

39. "Доступен релиз OpenVPN 2.4.0"	+/–
Сообщение от анан on 28-Дек-16, 15:09
Многопоточности все еще не хватает :(
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

46. "Доступен релиз OpenVPN 2.4.0"	–1 +/–
Сообщение от h31 (ok) on 28-Дек-16, 16:26
> Добавлена возможность бесшовной смены IP-адреса > Реализована возможность использования режима блочного шифрования AEAD GCM > Добавлена поддержка протокола согласования ключей на основе эллиптических кривых ECDH Уже сто лет как есть в IPsec. Приятно, что OpenVPN догоняет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	52. "Доступен релиз OpenVPN 2.4.0"	+2 +/–
	Сообщение от Аноним (??) on 28-Дек-16, 17:19
	Скажите честно вы ipsec вообще использовали ?
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	69. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от Ктулху on 28-Дек-16, 23:19
	Я использую уже несколько лет (Linux—[Linux|Android], если важно). Прекрасно работает. А что, должны быть какие-то сложности?
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	82. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 29-Дек-16, 11:15
	Админов локалхоста просят проходить мимо.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	73. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от h31 (ok) on 29-Дек-16, 00:01
	Да, постоянно пользуюсь. Настроил pcrypt (многопоточное шифрование) - вообще красота.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	83. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 29-Дек-16, 11:16
	Авторизация конечно же psk ?
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	71. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от obl (ok) on 28-Дек-16, 23:43
	>> Добавлена возможность бесшовной смены IP-адреса >> Реализована возможность использования режима блочного шифрования AEAD GCM >> Добавлена поддержка протокола согласования ключей на основе эллиптических кривых ECDH > Уже сто лет как есть в IPsec. Приятно, что OpenVPN догоняет. Тут и можно поспорить кто догоняет. Ipsec если бы был прост в настройке так же как опенвпн.. Но увы.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	84. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 29-Дек-16, 11:18
	А уж как прекрасно у ipsec c межвендорной совместимостью, это просто праздник какой-то.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	103. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от zanswer on 29-Дек-16, 18:42
	Всё относительно, Cisco EasyVPN Server (IPsec) + Cisco AnyConnect Client (IPsec), будет не сложнее OpenVPN, по крайней мере на клиентах, настройка сервера, тут повод сравнивать детально уже.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	90. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от zanswer on 29-Дек-16, 13:28
	Разве IPSec поддерживает динамические изменение IP адреса? IKE при этом сохранит имеющиеся SA? Можете дать ссылку на RFC, где описан данный механизм?
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	137. "Доступен релиз OpenVPN 2.4.0"	–1 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 14:58
	> Уже сто лет как есть в IPsec. Приятно, что OpenVPN догоняет. Догоняет что? Нормальная кривая это 25519. А нистовские кривые возможно с бэкдорами. И если вы поюзаете nist-овский ECDH завтра над вашей перепиской будет плакать все АНБ. А ipsec не надо догонять. Это встревает на ближайшем NAT. А сабж даже через прокси можно запустить, если это за каким-то надо.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

67. "Доступен релиз OpenVPN 2.4.0"	–1 +/–
Сообщение от Аноним (??) on 28-Дек-16, 22:13
Интересно, а почему это --no-iv объявлена устаревшей?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	132. "Доступен релиз OpenVPN 2.4.0"	–1 +/–
	Сообщение от Аноним (??) on 02-Янв-17, 09:12
	> Интересно, а почему это --no-iv объявлена устаревшей? ну и за что минус? по существу вопроса сказать нечего?
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

126. "Доступен релиз OpenVPN 2.4.0"	–1 +/–
Сообщение от ALex_hha (ok) on 31-Дек-16, 00:18
А подскажет кто, можно ли настроить openvpn так, чтобы в зависимости от имени пользователя добавлять определенные правила iptables? Собственно, за openvpn есть 20 подсетей. Я выдаю пользователю роуты в нужные, через client config dir. Но нужно еще закрыть возможность самому явно прописать маршрут в подсеть, в которую у него не должно быть доступа. Или можно как то проще сделать?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	128. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 01-Янв-17, 10:58
	> можно ли настроить openvpn так, чтобы в зависимости от имени пользователя добавлять определенные правила iptables? можно
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	138. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от анон on 09-Янв-17, 09:50
	через ccd выдаешь фиксированный ip, и ограничиваешь ему доступ фаерволом
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

129. "Доступен релиз OpenVPN 2.4.0"	+/–
Сообщение от demfloro (ok) on 01-Янв-17, 11:33
>Реализована возможность использования режима блочного шифрования AEAD GCM, при котором шифруется лишь важная часть данных (остаются открыты IP-адреса, номера протоколов и прочие метаданные) Я не могу найти подтверждения в источнике о том, что эти метаданные остаются открытыми. Везде указано что благодаря AEAD не нужен отдельный хеш и поэтому оверхед меньше. Откуда информация?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

130. "Доступен релиз OpenVPN 2.4.0"	–1 +/–
Сообщение от ALex_hha (ok) on 01-Янв-17, 23:36
> можно В какую сторону смотреть?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	131. "Доступен релиз OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (??) on 02-Янв-17, 09:10
	client-connect/client-disconnect/learn-address, $common_name например.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

139. "Доступен релиз OpenVPN 2.4.0"	+/–
Сообщение от Аноним (??) on 21-Мрт-17, 19:46
Заявленный пакет для CentOS кто-нибудь видел?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

140. "Доступен релиз OpenVPN 2.4.0"	+/–
Сообщение от Аноним (??) on 15-Апр-17, 12:34
Доброго дня, Бояре:) Кто может просветить, каким оброзом опция tls-crypt в 2.4 поможет справиться с DPI ? Проверял может кто иль курил мануалы иноземные? Спасибо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема