После почти четырёх лет с момента публикации ветки 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/OpenvpnSoftwareRe... для 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
интересно, производительность по сравнению с open any connect как? Кто-нибудь замерял?
А это что такое, впрочем, мне не интересно, линуха-линуха и через ssh нормально туннелится, а роутеры умеют gre, ipip и openvpn. gre у каждого свой, ipip бесполезен, так что выбор не велик.
>gre у каждого свойнеправда, прекрасно стандартизован.
> неправда, прекрасно стандартизован.А я утверждал обратное? Нет.
Я говорил о том, что сервер под разных клиентов gre поднять заморочно, а может и невозможно, так как стандартов много, а на софт-vpn легко, тока копии процесса по разным портам расскидать с разными настройками.
Можете чуть подробнее рассказать, что вы имеете ввиду под GRE у каждого свой? Не считая первое RFC, их всего два вида заголовков стандартизировали. Один причём исклюзиано для PPTP, а второй общепринятый, его все и используют.
> Можете чуть подробнее рассказать, что вы имеете ввиду под GRE у каждого
> свой? Не считая первое RFC, их всего два вида заголовков стандартизировали.
> Один причём исклюзиано для PPTP, а второй общепринятый, его все и
> используют.GRE, OSPF, BGP, STP, LLDP и наверняка еще столько же не вспомнил, протоколы и стандарты, которые у каждого вендора, со своими "плюшками" из-за которых частенько оно в кроссвендорных связках не работает или работает, но криво.
Полгода назад, ковырял этот gre, уж не помню откуда куда, но на одном конце пакеры tcpdump показывает in-out, на другом показывает только out.
Если честно, исключая LLDP, с ним плотно не работал, у названных протоколов проблем в реализации между вендорами не встречал. Под вендорами я имею ввиду, Cisco, Juniper и тд., D-Link, TP-Link и прочие ломают что угодно и когда угодно.
> Если честно, исключая LLDP, с ним плотно не работал, у названных протоколов
> проблем в реализации между вендорами не встречал. Под вендорами я имею
> ввиду, Cisco, Juniper и тд., D-Link, TP-Link и прочие ломают что
> угодно и когда угодно.Повезло вам, а нам на циски денег не дают, лучшее из того, что есть - это хуавей, хотя однажды и он заставил понервничать, когда порт в даун не уронил, а трафик дропнул
Я слышал много хорошего о Huawei, по отношению к другим Китайским брендам.
> Я слышал много хорошего о Huawei, по отношению к другим Китайским брендам.В целом железо прекрасное, в 2 раза дешевле и в 2 раза производительнее циски.
> Под вендорами я имею ввиду, Cisco, Juniper и тд.Со стороны Juniper проблем тоже ни видел и вряд ли будут, но вот Cisco очень любят скупать и ребрандировать под себя все что сумеют. Правда с GRE проблем пока не видел, но вот с невозможностью запустить BGP или скажем IPSEC из за экзотичности диалекта сталкивался не раз. Самое интересное что если обоих стран - Cisco шансы на такой конфуз увеличиваются.
Если пакеты на одной из сторон не возвращаются, значит имеет место быть их потеря в транзите, например по причине асимметричной маршрутизации, при которой обратные пакеты уходят не туда.Возможно я вас не правильно понял, но не вижу тут причин винить GRE, если пакеты вообще не пришли на интерфейс.
> Если пакеты на одной из сторон не возвращаются, значит имеет место быть
> их потеря в транзите, например по причине асимметричной маршрутизации, при которой
> обратные пакеты уходят не туда.
> Возможно я вас не правильно понял, но не вижу тут причин винить
> GRE, если пакеты вообще не пришли на интерфейс.НА Интерфейс туннеля нет, а на интерфейс физический gre трафик сыпется.
С удовольствием бы сделал TSHOOT по данной теме, если трафик дошёл до физического интерфейса, значит debug или имеющийся аналог функции на устройстве, мог бы пролить свет на то, что происходит далее с пакетом.
Было время когда GRE грустно ходил через NAT на сохо железках. Лично я с той поры как-то в UDP верую больше.
с тех пор что-то изменилось? GRE и сейчас грустно ходит через NAT
> Было время когда GRE грустно ходил через NAT на сохо железках. Лично
> я с той поры как-то в UDP верую больше.Даже сейчас есть железо через которое gre не натится, причем операторское.
Тому есть вполне простое объяснение, вытекающие из формата заголовка GRE, а делать ALG в масштабах операторских решений не всегда рентабельно вестимо.
> Тому есть вполне простое объяснение, вытекающие из формата заголовка GRE, а делать
> ALG в масштабах операторских решений не всегда рентабельно вестимо.Дело в том, что железка которая не умеет стоила 3 миллиона дервянных в 13-14 годах, сейчас она толи 5, толи 6 стоит, при этом вендор для решения проблемы предлагает поставить циску и ацлками завернуть на нее gre трафик, хотя проще было бы купить циску и использовать ее, в стойке их стоит 4 штуки, а для 20 миллионой покупки формат заголовка не оправдание, к счастью или сожалению это не единственная проблема железки, поэтому, аллилуя, их скоро заменят хуавеями, но тем не менее.
>> Тому есть вполне простое объяснение, вытекающие из формата заголовка GRE, а делать
>> ALG в масштабах операторских решений не всегда рентабельно вестимо.
> Дело в том, что железка которая не умеет стоила 3 миллиона дервянных
> в 13-14 годах, сейчас она толи 5, толи 6 стоит, при
> этом вендор для решения проблемы предлагает поставить циску и ацлками завернуть
> на нее gre трафик, хотя проще было бы купить циску и
> использовать ее, в стойке их стоит 4 штуки, а для 20
> миллионой покупки формат заголовка не оправдание, к счастью или сожалению это
> не единственная проблема железки, поэтому, аллилуя, их скоро заменят хуавеями, но
> тем не менее.Cisco тоже не умеет делать ASIC accelerated NAT для GRE, насколько я знаю, поскольку заголовок GRE просто не обладает полем с уникальным значением для идентификации отдельных пакетов.
GRE без IPSec бесполезен, если же вы про PPTP GRE вариант, то он не актуален совершенно уже.
Кстати, насчёт UDP, есть вот такой draft, GRE-in-UDP: https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-enca...Но я бы всё равно GRE без IPSec использовать в рамках сети Internet в жизни бы не стал.
> Но я бы всё равно GRE без IPSec использовать в рамках сети
> Internet в жизни бы не стал.Не в обиду, но все эти ваши ipsec и gre очень геморны в настройке, застревают на первом же фаере или нате, через прокси не жильцы в принципе и еще и безопасность достаточно хилая. В результате долботни много а толку мало. Вот народ и предпочел дружно сабжа. Он сделан для реального интернета и его неидеальностей. Так что это можно быстренько настроить и потом еще и работать будет. Без секаса с ипсеками и прочих gre.
Есть хорошая статья по установке и настройке OpenVPN?
> Есть хорошая статья по установке и настройке OpenVPN?"Измена Родине" подойдёт?
спасибо, поржал :) хотя на сегодня более актуальна ст. 280
>спасибо, поржал :) хотя на сегодня более актуальна ст. 280282-я же, для опеннета, по крайней мере. После 130-й. :)
P.S. Притянуто за уши, но и верхние - тоже не ангелы, а йумаристы. :)
Есть, а что?
да и книги есть
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
косвенно https://bettercrypto.org/
На Digitalocean все есть.https://www.digitalocean.com/community/tutorials/how-to-set-...
Нижняя палата РФ уже работает над этим. ))
>Please note that OpenVPN 2.4 installers will not work on Windows XP.Плак-плак :(
это диверсия !
с этим надо что-то делать
Я слышал, что есть какие-то системы, определяющие OpenVPN, вроде как провайдет может определить OpenVPN и порвать соединение. В том же Китае он не работает, и некоторые VPN-провайдеры предлагают проприетарные решения для обхода таких блокировок. Я слышал, что OpenVPN вроде-бы хочет предпринять что-то в этом направлении, чтобы была маскировка от таких "детекторов". Что известно об этом?
> Я слышал, что есть какие-то системы,
>Я слышал, что OpenVPN вроде-бы хочет предпринять что-то в этом
> направлении, чтобы была маскировка от таких "детекторов". Что известно об этом?
Спасибо, очень интересно.
> https://duckduckgo.com/?q=openvpn+traffic+obfuscationПосадят тебя по твоей же статье. Хоть и за утку вместо спутника.
Для этого как раз сделали опцию tls-crypt в новой версии.
> Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN.Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть, или где-то еще?
Не совсем понимаю в каких случаях это может пригодиться?
GPRS
Не актуально. Прокачиваться будет не более 33.6кбит/c. даже заголовки сообщений будут с трудом просачиваться на таком соединении.
> Прокачиваться будет не более 33.6кбит/cна IRC хватит
Например, чтобы не палиться перед ISP, постоянно переподключая VPN-соединение для смены IP.
Multi-Wan вариации(всех типов) и Multipath-TCP использование.
в Ad-Hoc/Mesh сетях тоже обычное дело(а там и оборонные и помышленные среди них есть а не только меш потато и вские гипербореи).
Вот авторы 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 звонка, это плохо, снижение скорости закачки файла на короткий промежуток времени нет.
> Не совсем понимаю в каких случаях это может пригодиться?В любых когда соединение нестабильное. Например беспроводка. Не круто, понимаешь, если все дружно отлипает только на том основании что реконект случился.
> Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть,
> или где-то еще?Чет не очень понимаю зачем, давеча поставил фалег лится на ноут с хранилища, смотрю скорость бе, воткнул провод, 1 строкой в shell перевесил ip на ethernet и ни ssh не порвалось, ни закачка.
Хотя чисто из академического интереса можно запихивать vpn-интерфейсы в мост с stp, но при сходимость кольца все равно потеряет данные, IP всегда теряет данные, он байдизайн ширину канала по потерям расчитывает, так-то.
Ни хера не понял в твоих манипуляциях. Подробности, пожалуйста.
Это явно юный админ локалхоста говорит фразы продолжения которых не знает.
brctl addif br0 tun0че непонятного
>> Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN.
> перевесил ip на ethernet и ни ssh не порвалось, ни закачка.В новости говорится что можно сменить IP или/и порт и соединение не прервётся.
Я правильно понял что ты не менял ни IP ни порт и говоришь "У меня и так работает"?
> Я правильно понял что ты не менял ни IP ни порт и говоришь "У меня и так работает"?ты всё правильно понял, а гражданин суммирует часы и устриц.
> ты всё правильно понял, а гражданин суммирует часы и устриц.Устрицы в голове у тебя. ядро шлет пакеты на хост до которого нет маршрута, между удалением ip с одного интерфейса и навешиванием на другой, и должно бы возвращать - но_роут_ту_хост, но не возвращает же, покрайней мере сразу, значит переустановить соединение-туннель есть время, а уж ip и порт нового значения не имеют, при правильно отстроенных буфферах и таймаутах соединения в туннеле даже не поймут, что что-то произошло.
IP рассчитывает ширину канала по потерям? Можете подробнее изложить свою мысль, что вы имеете ввиду?Для каких целей IP протоколу, который является stetaless протоколом, потребовалось рассчитывать ширину канала, да ещё и по потерям. Может быть вы имели ввиду TCP?
> Может быть вы имели ввиду TCP?Определенно, но хотел включить UDP в множество, хотя зря, так как особенности реализации отдельного кое-чего на udp к делу отношения не имеют.
Речь я так понимаю идёт о том, что OpenVPN теперь может динамически в рамках одной сессии, менять tunnel source, что в прошлом приводило к разрыву сессии.Вы же я так понимаю tunnel source не меняли, а изменили только его положение (перенесли на другой интерфейс). Поэтому да, tunnel destiantion не заметил подмены, как вы сами правильно заметили при правильных размерах буфера и dead interval, сессия не будет потеряна.
> сессия не будет потеряна.А какая ценность у этой сессии? я хотел обратить внимание на то, что при ее разрыве и скорой установки новой, соединения внутри туннеля при надлежащих параметрах не разорвуться.
>> сессия не будет потеряна.
> А какая ценность у этой сессии? я хотел обратить внимание на то,
> что при ее разрыве и скорой установки новой, соединения внутри туннеля
> при надлежащих параметрах не разорвуться.а какие надлежащие параметры и требуют ли они установки с обоих сторон соединения внутри туннеля - и на клиенте (подконтрольном) и на сервере (неподконтрольном)
(частенько рвётся впн и приходится клиентскую подтуннельную программу переподключать)
и стоит ли мне задуматься над схемой "виртуальноеEth -> впнEth1+впнEth2(на разные сервера целевой подсети) -> целевой_сервер" ? (и как такое вообще делать?)
Как любил говорить один не_товарищь - открытия требую экспериментов.> виртуальноеEth -> впнEth1+впнEth2(на разные сервера целевой подсети) -> целевой_сервер
Вообще не понял ничего, не благодарное дело гадать, но в большенстве случаев на сервера ходят или за сервисами или для управления, сервисы лучше предоставлять через единую точку входа, где их можно будет прикрыть фаерволом ежели чего, управления на серверах, вроде и так не плохо защищено, смысла его туннелировать нет, это я о ssh говорю, как там оно в виндах и макосях беспонятия.
macOS не чем принципиально от любого другого Unix в этом отличаться не будет, такой же SSH и TLS.Windows, по крайней мере в свежих реинкарнациях охотно использует TLS (WS-Management Protocol), возможно и SSH можно использовать, поинтересуюсь у коллег.
У меня конечно же нет ответа, который устроит всех, но давайте представим следующий кейс, у нас есть стандартная, я бы сказал обыденная топология 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/ Я не претендую этим сообщением на всеобъемлющее исследование или истину в последней инстанции, просто изложил свои мысли.
> Руководство ставит задачуЭто какбы его работа, которая выполняется ровно на столько, на сколько выделятся ресурсов.
Всегда конечно можно чего-то сколхозить и часто это даже работает, но самопал есть самопал.> GRE over IPSec, в классическом
Ну для кого как. Последнее время "модно" филиалы подключать через микротики, там опенвпн и гре, и много всякого, и по сути обеспечивается л2 с резервом или без, в зависимости от готовности платить. У цисок есть решения для такой задачи. У операторов есть решение, л2 из москвы на чутотку легко, но стоить будет много.
> учесть все детали каждого кейса сложно в абстрактном сообщении
Подключение филиалов вполне типовая задача.
> установить отношения соседства в OSPF/EIGRP
А вот это уже задача транспортного подразделения, которое либо организовывает и поддерживает л2 для вашего ip, либо выгоняется на мороз, а на эти деньги покупается л2 у провайдера с резервированием, допустимыми потерями и прочим, что оговоренно в договоре, на клинтских концах ставятся деморкаторы и наступает счастье.
MPLS L2 VPN через всю страну, это очень дорогое удовольствие в каждый филиал, его ещё нужно чем-то обосновать.Нечего против Mikrotik не имею, они дёшевы, умеют достаточно много, пусть и с оговорками во многих аспектах.
Что касается поддержания L2, то я снова не совсем вас понимаю, что вы имеете ввиду? 2 Data-Link Layer, исключая решения MPLS L2 VPN, поддерживать в рамках всего канала между Hub и Spoke, совершенно не возможно, поскольку он закончится на точке демаркации оператора.
Объясните, как вы видите работу транспортного отдела? Что он должен обеспечить мне, как сетевому инженеру, чтобы отношения соседства EIGRP/OSPF между Hub и Spoke не нарушались?
P/S/ Вообще не вижу причин, для того, чтобы строить именно L2 VPN между филиалами всегда, кроме нескольких специальных кейсов.
> кроме нескольких специальных кейсов.Согласен, но в большенстве случаев перед ИТ клиентов л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 инстанции, чтобы изолироваться, влан прописал и забыл.
Вы всё время замыкаетесь на 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 с точки зрения теории.
> Что касается 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 строк на порт с указанием точки выхода - любой город.
Выбор типа 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 находится в центральном офисе.
Мне сложно судить о том, какая у вас архитектура опорной сети, поэтому, ещё сложнее судить о предложения которые делали какие-то _умнники_. :)
Если у вас так, то я за вас рад. А у нас все сильно по-другому, и у остальных тоже. Мелкие и средние компании имеют большое преимущество перед крупными в этом плане.
Что касается GRE, то у него компактный заголовок, он без каких либо проблем позволяет передавать мультикаст пакеты, исключая трудности с NAT, не каких проблем у него не вижу других. А уж multipoint GRE, так вообще счастье, для любого сетевого инженера.Если вы имеете ввиду, что лучше, то это тема для долгих споров, интернет ими и так полон. :)
Странно, при размещении сообщения куда-то OpenVPN потерялся. Я имел ввиду, что OpenVPN vs L2TP vs GRE vs SSTP и так далее, это длинный спор с множеством возможных ситуаций, где лучше один, а где другой ИМХО. :)
Поясню насчёт кейсов, что я имел ввиду.Первый кейс, классическая топология 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 сетей в этом сообщении, открыт для любых обсуждений.
> у всех разные задачи, бюджеты, технические возможности, требования безопасностине такие уж и разные, о безопасности вообще спорно, нормальные безопасники сами все что надо зашуфруют, а похЕРистам оно и не надо, а иначе ходить каждые полгода с инспекцией к провайдеру, а он прям так взял и пустил вас ага))).
Под требованиями безопасности я понимаю, не только обеспечение конфиденциальности, целостности и аутентичности передаваемых данных через VPN линк. А такие аспекты, как противодействие утечкам конфиденциальных данных, например путём анализа всего трафика филиалов на Intrusion Prevention System устройствах, для выявления заданных паттернов, свидетельствующих об утечках определённых данных к примеру.К провайдеру ходить совершенно не зачем, IPsec, OpenVPN или любой другой не объявленный устаревшим протокол, обеспечивает все три базовых элемента, конфиденциальность, целостность, аутентичность передаваемой информации, при должном внимание при их настройке конечно.
Информационная безопасность же, распространяется не только на такие аспекты, есть ещё масса других организационно правовых норм, которые могут налагать определённые требования на построение сети.
В общем и целом, проблема защиты от утечек конфиденциальной информации или атак совершаемых изнутри компании, является не менее актуальной, чем защита передаваемых данных через не подконтрольные каналы передачи данных, как например предоставляемый оператором нам 802.1Q Vlan или целый 802.1ad QinQ trunk.
> Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть, или где-то еще?ipsec mobike https://tools.ietf.org/html/rfc4555
Жаль что многопоточность так и не завезли.
> Жаль что многопоточность так и не завезли.А на кой, если надо из in-буффера скопировать в out-buffer, у вас копирование файлов тоже многопоточное? дефрагментировать не надоело?
> дефрагментировать не надоелочто делают виндопользователи на опеннете?
>> дефрагментировать не надоело
> что делают виндопользователи на опеннете?Ламерить не надоело?
ext3? С разморозкой!
Не ed25519, не chacha20-poly1305.
Как-то не очень секьюрно.
> Не ed25519, не chacha20-poly1305.Ну тогда во: https://www.phoronix.com/scan.php?page=news_item&px=WireGuar...
> Как-то не очень секьюрно.
Это OpenSSL, детка. Секурно его настроить не сможет даже вон тот CCNA, судя по его постам. Туда же и ipsec'ов всяких.
Многопоточности все еще не хватает :(
>В том числе обеспечена возможность запуска OpenVPN GUI в Windows без наличия привилегий администратора.маршруты как будут добавляться? У них и раньше можно было запускать, только без маршрутов оказываешься после этого
Возможно они допилили OpenVPN Service под виндой. Теперь OpenVPN GUI просто просит этот сервис запускать OpenVPN, а сервис работает с правами админа, а OpenVPN статусы читаются через management interface.
Ваш K.O.
> У них и раньше можно было запускать, только без маршрутов оказываешься после этогоВендузятники должны страдать.
Многопоточности все еще не хватает :(
> Добавлена возможность бесшовной смены IP-адреса
> Реализована возможность использования режима блочного шифрования AEAD GCM
> Добавлена поддержка протокола согласования ключей на основе эллиптических кривых ECDHУже сто лет как есть в IPsec. Приятно, что OpenVPN догоняет.
Скажите честно вы ipsec вообще использовали ?
Я использую уже несколько лет (Linux—[Linux|Android], если важно). Прекрасно работает. А что, должны быть какие-то сложности?
Админов локалхоста просят проходить мимо.
Да, постоянно пользуюсь. Настроил pcrypt (многопоточное шифрование) - вообще красота.
Авторизация конечно же psk ?
>> Добавлена возможность бесшовной смены IP-адреса
>> Реализована возможность использования режима блочного шифрования AEAD GCM
>> Добавлена поддержка протокола согласования ключей на основе эллиптических кривых ECDH
> Уже сто лет как есть в IPsec. Приятно, что OpenVPN догоняет.Тут и можно поспорить кто догоняет. Ipsec если бы был прост в настройке так же как опенвпн.. Но увы.
А уж как прекрасно у ipsec c межвендорной совместимостью, это просто праздник какой-то.
Всё относительно, Cisco EasyVPN Server (IPsec) + Cisco AnyConnect Client (IPsec), будет не сложнее OpenVPN, по крайней мере на клиентах, настройка сервера, тут повод сравнивать детально уже.
Разве IPSec поддерживает динамические изменение IP адреса? IKE при этом сохранит имеющиеся SA? Можете дать ссылку на RFC, где описан данный механизм?
> Уже сто лет как есть в IPsec. Приятно, что OpenVPN догоняет.Догоняет что? Нормальная кривая это 25519. А нистовские кривые возможно с бэкдорами. И если вы поюзаете nist-овский ECDH завтра над вашей перепиской будет плакать все АНБ.
А ipsec не надо догонять. Это встревает на ближайшем NAT. А сабж даже через прокси можно запустить, если это за каким-то надо.
Интересно, а почему это --no-iv объявлена устаревшей?
> Интересно, а почему это --no-iv объявлена устаревшей?ну и за что минус? по существу вопроса сказать нечего?
А подскажет кто, можно ли настроить openvpn так, чтобы в зависимости от имени пользователя добавлять определенные правила iptables?Собственно, за openvpn есть 20 подсетей. Я выдаю пользователю роуты в нужные, через client config dir. Но нужно еще закрыть возможность самому явно прописать маршрут в подсеть, в которую у него не должно быть доступа. Или можно как то проще сделать?
> можно ли настроить openvpn так, чтобы в зависимости от имени пользователя добавлять определенные правила iptables?можно
через ccd выдаешь фиксированный ip, и ограничиваешь ему доступ фаерволом
>Реализована возможность использования режима блочного шифрования AEAD GCM, при котором шифруется лишь важная часть данных (остаются открыты IP-адреса, номера протоколов и прочие метаданные)Я не могу найти подтверждения в источнике о том, что эти метаданные остаются открытыми. Везде указано что благодаря AEAD не нужен отдельный хеш и поэтому оверхед меньше. Откуда информация?
> можноВ какую сторону смотреть?
client-connect/client-disconnect/learn-address, $common_name например.
Заявленный пакет для CentOS кто-нибудь видел?
Доброго дня, Бояре:) Кто может просветить, каким оброзом опция tls-crypt в 2.4 поможет справиться с DPI ? Проверял может кто иль курил мануалы иноземные?
Спасибо.