OpenVPN vs L2TP, MTU=1500

[SUrov_IBM]

Уважаемые знатоки, доброго Вам времени суток.

 

Хотелось бы услышать мнение телеком’овцев, касательно следующего вопроса:

 

Через публичный Интернет, межу несколькими маршрутизаторами построенными на базе ОС FreeBSD и Linux,

необходимо построить «Site-to-Site VPN». Выбор пал между двумя решениями - OpenVPN и L2TP.

 

Шифрование и конвергентность (совместимость с CISCO и т.п.) практического значения не имеет.

Проходящий по VPN соединению трафик, исключительно L3 (без всяческих извращений).

 

Собственно вопросы:

1. Средствами, какого VPN соединения, можно обеспечить «прозрачное» транзитное прохождение L3

с MTU=1500, без дополнительных костылей в виде «обрезания» MSS на интерфейсе тоннеля?

 

2. Кто из вышеперечисленных работает «быстрее»? OpenVPN в режиме (TCP/UDP?) или L2TP?

 

 

Буду благодарен, за реальную рекомендацию, основанную на Вашем опыте эксплуатации.

[rdc]

1. оба могут

2. l2tp работает многократно быстрее, т.к. реализован на уровне ядра

[MMM]

Посмотрите еще tinc

 

P.S. openvpn и tinc будут использовать только 1 ядро процессора . L2TP не проверял.

[SUrov_IBM]

Посмотрите еще tinc

 

P.S. openvpn и tinc будут использовать только 1 ядро процессора . L2TP не проверял.

MMM, доброго Вам времени суток.

 

Насколько я понял из беглого просмотра, Tinc VPN очень похож на OpenVPN,только конфигурируется немножечко проще,

даже библиотеки для сжатия используют одинаковые, lzo например.

 

В отдельном примере было бы хорошо сравнить производительность Tinc VPN и OpenVPN (конфигурация PSK),

но к сожалению у меня сейчас нет возможности собрать тестовый стенд.

[SUrov_IBM]

Уважаемые знатоки, благодарю Вас за ответы.

 

Склоняюсь к решению на основе L2TP (без IPSec), хотя с OpenVPN знаком достаточно хорошо,

а вот L2TP на FreeBSD и Linux конфигурировать не доводилось.

 

Всегда стоит попробовать что-то новенькое, ещё раз спасибо за ответы! :)

[rdc]

Дело не в ядре процессора.

OpenVPN работает в юзерспейсе, для каждого пакета идут неоднократные переключения контекста.

Для l2tp же есть ядерные реализации. На фряхе это net/mpd5, например.

[edo]

а какая производительность нужна?

 

первая ссылка в гугле по "openvpn pps":

https://forums.openvpn.net/viewtopic.php?t=12318

тут правда нет упоминания процессора, но в 2013 году 200k+ получалось в лабораторных условиях

[s.lobanov]

Через публичный Интернет, межу несколькими маршрутизаторами построенными на базе ОС FreeBSD и Linux,

необходимо построить «Site-to-Site VPN». Выбор пал между двумя решениями - OpenVPN и L2TP.

 

Из предложенного - однозначно L2TPv2. Относительно L3MTU=1500 - теоретически это возможно и over Internet, за счёт frag/defrag, но в целом идея плохая, никогда это к добру не приводит. Я ещё ни разу не видел чтобы mss adjust что-то ломал.

 

Ну а если это у вас внутри вашей сети и все линки ваши или на аренде можно поднять MTU, то просто поднимайте MTU и гоняйте честный L3MTU=1500 для полезных данных внутри l2tpv2

 

А вообще, судя по задаче, я бы вам рекомендовал IPIP-тунель или даже дефолтный GRE, если это построение l3vpn over public

[rdc]

Относительно L3MTU=1500 - теоретически это возможно и over Internet, за счёт frag/defrag, но в целом идея плохая, никогда это к добру не приводит.

Практика показала, что никаких сколь-нибудь существенных проблем это не вызывает.

 

Я ещё ни разу не видел чтобы mss adjust что-то ломал.

Он не ломает, просто не всегда от него есть толк.

Например, если в туннеле бегает трафик с ещё какими-нибудь шифрованными абонентскими туннелями, в которых mss уже не расковыряешь.

Посему я применяю такую тактику - для tcp делаю mss adjust, но если уж пролезли большие пакеты прочих протоколов - пропускаю как есть.

 

я бы вам рекомендовал IPIP-тунель или даже дефолтный GRE, если это построение l3vpn over public

l2tp имеет жирный плюс - работает на динамике и через нат.

[SUrov_IBM]

OpenVPN работает в юзерспейсе, для каждого пакета идут неоднократные переключения контекста.

Для l2tp же есть ядерные реализации. На фряхе это net/mpd5, например.

rdc, доброго Вам времени суток.

 

Спасибо за информацию, я как раз читал пару статей, про работу сетевых приложений в "user space"

и "kernel space" режимах, собственно отсюда и возникло желание вместо OpenVPN использовать L2TPv2.

Но перед изменением чего либо, хотелось услышать авторитетное мнение людей, которые уже столкнулись

с данным вопросом на практике. :)

 

Со стороны FreeBSD, с демоном net/mpd5 доводилось сталкиваться (для организации PPTP VPN), а вот что

используется со стороны Linux (работающее с L2TPv2 в "kernel space" режиме) пока не изучил, но это

вопрос чтения разнообразных статей.

 

Относительно L3MTU=1500 - теоретически это возможно и over Internet, за счёт frag/defrag, но в целом идея плохая, никогда это к добру не приводит.

s.lobanov, доброго Вам времени суток.

 

Да, действительно VPN соединение строятся через публичный Интернет. Хотел бы понять,

в чём возможны «подводные камни» (в целом идея плохая), при фрагментации и последующей

дефрагментации инкапсулированного VPN трафика через публичный Интернет?

 

Насколько я понимаю, данная операция приводит к дополнительной нагрузке на маршрутизатор.

Или имеется в виду, что происходит "сильная задержка", из-за увеличения накладных расходов,

что может быть критичным для определённого вида трафика?

[ShyLion]

Хотел бы понять,

в чём возможны «подводные камни» (в целом идея плохая), при фрагментации и последующей

дефрагментации инкапсулированного VPN трафика через публичный Интернет?

 

Потеря одного пакета приравнивается к потере двух, кроме того, роутер будет какое-то время ждать остатки пакета хоть они и уже потерялись где-то.

Буфер фрагментаций тоже не бесконечный.

[s.lobanov]

l2tp имеет жирный плюс - работает на динамике и через нат.

 

Ну я всё понимаю конечно, но строить site-to-site VPN over NAT провайдеру это уж совсем какой-то позор. Я понимаю, когда клиенты так делают, но для ISP это печаль.

[s.lobanov]

Да, действительно VPN соединение строятся через публичный Интернет. Хотел бы понять,

в чём возможны «подводные камни» (в целом идея плохая), при фрагментации и последующей

дефрагментации инкапсулированного VPN трафика через публичный Интернет?

 

Насколько я понимаю, данная операция приводит к дополнительной нагрузке на маршрутизатор.

Или имеется в виду, что происходит "сильная задержка", из-за увеличения накладных расходов,

что может быть критичным для определённого вида трафика?

 

В целом, см. пост ShyLion. Но ещё могу добавить, что с операциями frag/defrag просто часто бывают баги у различных вендоров. Насколько оно стабильно у linux и freebsd я хз, но у всяких Cisco и прочего частенько оно глючит

[rdc]

что используется со стороны Linux (работающее с L2TPv2 в "kernel space" режиме

http://accel-ppp.org/

 

Но ещё могу добавить, что с операциями frag/defrag просто часто бывают баги у различных вендоров. Насколько оно стабильно у linux и freebsd я хз

Вполне стабильно.

 

Ещё есть такое решение - включить multilink и делать фрагментацию на уровне ppp.

При этом пакеты в инет уйдут без фрагментов - просто будет два l2tp пакета, а не один.

 

Ну я всё понимаю конечно, но строить site-to-site VPN over NAT провайдеру это уж совсем какой-то позор.

Во-первых, всякое бывает.

 

Пример - туннель кидается через интернет GPON-провайдера.

Эти коробки имеют аппаратный нат, но если переключать их в мост - трафик обрабатывается программно и никакого гигабита уже не получить.

А ещё бывает, что инженерный пароль от коробки неизвестен, а провайдер включать мост просто отказывается и всё.

 

Ещё пример - резервирование через LTE.

Там, помимо ната опсоса, будет ещё и нат роутера. И если избежать ната роутера некоторыми усилиями можно, то нат опсоса в некоторых регионах безальтернативен.

 

А во-вторых, кроме ната, есть ещё динамика.

И это не только отсутствие услуги статического ипа (опять же возвращаясь к резерву через LTE), но и возможность смены провайдера на удалённой точке без перенастройки. Удобно.

[dsk]

По опыту эксплуатации L2TP через разные LTE на микротиках (думаю актуально и для других софт решений):

Мегафон: - MTU 1500 работает нормально, мегафоновский нат нормально переваривает фрагментированные пакеты, но есть проблемы со стабильностью самого L2TP (видимо что-то опять где-то в нат-е залипает). PPTP стабильнее, но там MTU1450. Со статикой очевидно проблем не будет как и со стабильностью, так и с фрагментацией.

МТС: - NAT не отрабатывает фрагментацию и дропает пакеты.

Билайн: - где как, то пролезает, то дропает.

 

Вывод - получить MTU1500 - вещь сугубо индивидуальная.

[rdc]

Повторюсь - фрагментацию можно делать с помощью multilink ppp, и подобных проблем не будет.

[ShyLion]

Повторюсь - фрагментацию можно делать с помощью multilink ppp, и подобных проблем не будет.

Фрагменты один хрен нужно будет собирать кому-то.

[rdc]

На софтроутере с этим нет никаких проблем, памяти дохрена, буфер можно считать бесконечным.

[ShyLion]

Ок. Осталось понять для чего такое нужно. Учитывая перспективу IPv6 в котором фрагментацию отменили совсем.

[rdc]

Я уже приводил пример - клиенты гоняют свои шифрованные туннели, к трафику внутри которых mss adjust не применить.

В условиях, когда какой-нибудь долбоящер в интернете мог зарезать icmp, при этом ломается path mtu discovery и некоторые сайты перестают открываться.

 

Да и просто требовательный клиент может высказать претензию, что 1500 не пролезает.

 

Отсутствие фрагментации в ipv6 обходится с помощью multilink.

[ShyLion]

А откуда в задаче провайдер взялся?

[Ivan_83]

Ещё можно на фре с нетграфом туннелировать в юдп.

Ещё можно через всякие тап в gre интерфейсы хоть во фре хоть в линухе.

[SUrov_IBM]

а какая производительность нужна?

 

первая ссылка в гугле по "openvpn pps":

https://forums.openvpn.net/viewtopic.php?t=12318

тут правда нет упоминания процессора, но в 2013 году 200k+ получалось в лабораторных условиях

edo, доброго Вам времени суток.

 

В моём случае, высокой производительности не требуется, каналы доступа в публичный Интернет,

поверх которых строится VPN, не превышают 50Мбит/с. Изначально соединяя софт-маршрутизаторы,

я использовал OpenVPN (режим Ethernet Bridging), руководствуясь возможностью прохождения L3MTU=1500

через тоннель и единообразной конфигурацией данного VPN на разных ОС.

 

Столкнувшись с достаточно высокой загрузкой CPU софт-маршрутизаторов, возникло желание перенастроить

OpenVPN в режим routing, изменив конфигурацию с RSA на PSK, что должно привести к снижению нагрузки.

Правда я не уверен, что в режиме routing OpenVPN позволяет прохождения L3MTU=1500 через тоннель.

 

Небольшой обзор различных форумов, подтолкнул меня к мысли в качестве альтернативы использовать L2TPv2,

благодаря форуму nag.ru я понял, что выбрал интересное и правильное направление для решения своей задачи. :)

[SUrov_IBM]

Хотел бы понять,

в чём возможны «подводные камни» (в целом идея плохая), при фрагментации и последующей

дефрагментации инкапсулированного VPN трафика через публичный Интернет?

 

Потеря одного пакета приравнивается к потере двух, кроме того, роутер будет какое-то время ждать остатки пакета хоть они и уже потерялись где-то.

Буфер фрагментаций тоже не бесконечный.

ShyLion, доброго Вам времени суток.

 

Благодарю за прямой и простой ответ.

[SUrov_IBM]

Во-первых, всякое бывает.

 

Пример - туннель кидается через интернет GPON-провайдера.

Эти коробки имеют аппаратный нат, но если переключать их в мост - трафик обрабатывается программно и никакого гигабита уже не получить.

А ещё бывает, что инженерный пароль от коробки неизвестен, а провайдер включать мост просто отказывается и всё.

rdc, доброго Вам времени суток.

 

Вы практически видите корень проблемы, именно из-за подобного и нет возможности использовать

классические IP-IP тоннели и т.п.