Comments 14
В отличие от таких протоколов как GRE/IPIP туннели OpenVPN могут иметь MTU равное 1500 байт (потому что процесс OpenVPN скрывает «под капотом» всю фрагментацию/дефрагментацию, отдавая в туннельный интерфейс пакеты полной длины). Это упрощает настройку всяких вторичных туннелей поверх туннеля OpenVPN.

А плюс ли это? Оверхэд есть у любого туннеля, соответственно если у интерфейса MTU равен MTU внутри туннеля — придется дробить пакеты.

Ээээ. В отношении OpenVPN говорить об оверхэде смысла нет. Он не для сокращения оверхэда. В статье, где сравнивали пропускную способность OpenVPN и WireGuard однозначно показали что у OpenVPN ПС раза в три-четыре ниже, чем у WG. И всё из-за оверхеда, фрагментации/дефрагментации и т. п.


Как-то так.

Тут речь о другом.
Максимально эффективная утилизация канала будет если внутри туннеля используется MTU с учетом что туннелю как то эти пакеты еще заворачивать на физическом уровне.
Если внутри туннеля 1500 и у физического интерфейса 1500 — то в один пакет это сообщение упихать никак не получается (опустим сжатие — пакет вполне может быть несжимаем)
Максимально эффективная утилизация канала будет если внутри туннеля используется MTU с учетом что туннелю как то эти пакеты еще заворачивать на физическом уровне.

Я в данном случае даже и не спорю. Ещё раз повторю, OpenVPN в данном случае не про эффективность, он про «проходимость» (она же «проницаемость»). То есть если делать решение именно «эффективное» (не только с точки зрения утилизации), то это не к OpenVPN уже как минимум из-за того, что это комбайн, который содержит в себе маршрутизатор. Который а) дублирует функциональность ОС, которая делает это явно эффективнее (ибо делает это на уровне ядра, без переключения контекстов на userspace) и б) делает это явно менее функционально, потому что ядро позволяет использовать всякие другие «плюшки» вроде policy-based routing и иже с ним, чего OpenVPN не умеет от слова «совсем».

И да, вышеприведённая статья на самом-то деле «выросла» из удачной попытки скрестить Linux и RouterOS именно по OpenVPN и при этом обеспечить с обеих сторон динамическую маршрутизацию. Но изначальный первичный эксперимент делался таки именно между двумя чистыми Linux, а уже потом был «обратно» пристыкован RouterOS и схема подтверждена на такой связке. Кстати в случае если клиентом является RouterOS скрипт для клиента на сервере на одну команду меньше, потому что не нужна команда
echo 'push "iroute 0.0.0.0 0.0.0.0"'

Если вы за динамику, почему тогда bgp, а не ospf, например? Не очень понятно кто ваши "клиенты" — сеть филиалов, или вообще разные компании? Ну и картинок не хватает))

С одной стороны так сложилось, что моё знакомство с динамической маршрутизацией началось «по-серьёзному» с BGP (были «поигрулечки» с RIP, но это было давно и неправда).
С другой стороны про OSPF бытует мнение (не моё, где-то на форуме бегло проскочило), что он не очень оптимально работает в случае большого числа маршрутов /32. Что в моём случае как раз имеет место быть (обходы запретов одного «замечательного» ведомства как пример).
С третьей стороны ИМХО (Имею Мнение, Хрен Оспоришь) BGP кажется мне более управляемым протоколом, в первую очередь потому, что базируется на unicast, допускает multihop и всё такое.
Ну и наконец, BGP замечательно передаёт данные всяких там MPLS, VRF и иже с ними.

А картинка в самом простом случае очевидна: с одной стороны сервер, с другой клиент, между ними собственно туннель. В статье как раз специально рассмотрена типовая минимальная ситуация. То есть дальше можно масштабировать по своему усмотрению.

Ну вот так как-то.
Добрый )
У меня полтора десятка филиалов на pfsense\opnsense связаны с Центром по OpenVPN + OSPF. pfsense\opnsense живет на Proxmox VE (PVE). «Ни единого разрыва» (с). Скорость переключения с основного канала на резервный и обратно ~5-7 сек. На pfsense пользую пакет FRR (умеет и OSPF и BGP).

Зы. Кому нужна голая БСД — BSD Router Project (BSDRP) в помощь. Возможности bsdrp.net/features, пример настройки bsdrp.net/documentation/examples/simple_bgp-rip-ospf_lab
У меня полтора десятка филиалов на pfsense\opnsense связаны с Центром по OpenVPN + OSPF.

А из/в филиалы какого размера сети ходят? Уже не /24 ли случаем?

На pfsense пользую пакет FRR

Хотел попробовать, но руки пока не дошли. Ну и кроме того среди «промышленных» open source маршрутизаторов FRR как-то пока не особо засветился. В отличие от большой тройки (Quagga, BIRD, Exa-BGP). Соответственно изначально у меня как раз Quagga была, сейчас вот на BIRD мигрировал и пока FRR в планах нет. Но кто знает, может и появится.

Что же касается использования *BSD, то увы, без виртуализации у них очень уж маленький список поддерживаемого железа, а виртуализация так и так делается НЕ на платформах *BSD. В итоге с большой вероятностью так и так придётся иметь дело с Linux (ваш Proxmox тому пример, ибо это DebIan). Не вижу смысла городить огород/зоопарк, усложняя тем самым стоимость обслуживания и технической поддержки. Сам лично с FreeBSD я имел дело начиная с версии 1.1.5.1 годах ещё в 90-х, а полностью отказался от неё во всех проектах лет 5-7 назад и именно из-за катастрофически маленькой поддержки железа, прежде всего по «религиозным» (бишь лицензионным) соображениям: ну не могли в BSD портировать просто так скажем драйверы Wi-Fi из Linux, потому что нельзя код под лицензией GPL в BSD просто так взять и утащить. В итоге, когда Linux просто из коробки работал почти с любыми беспроводными адаптерами, на той же FreeBSD их было по пальцам одной руки посчитать. Тоже самое касалось поддержки многих видеоадаптеров и так далее по списку. А обновление была отдельная очень больная тема. До сих пор помню как переход с версии на версию (даже кажется минорную) тех же KDE потребовал пересборки половины портов в системе (да, я портами пользовался и продолжаю считать именно этот способ самым кашерным). А так да, системы хорошие.
Proxmox — это Debian + мод. ядро от Убунты.

А из/в филиалы какого размера сети ходят? Уже не /24 ли случаем?

Есть и /24 и /28
Proxmox — это Debian + мод. ядро от Убунты

Учитывая, что Ubuntu есть форк DebIan, разница не очень большая. Насколько я помню Proxmox всё-таки от чистого DebIan форкнулся, но могу и ошибаться.

Есть и /24 и /28

Вот тут один из главных моментов с OSPF и кроется. Насколько я читал он не очень хорош при большом числе сетей /32, а вот это как раз мой случай.

По большому же счёту вопрос не в том, OSPF, BGP или RIP. Вопрос в том, что в штатный (то есть не модифицированный специально) OpenVPN «на лету» маршруты ни добавить, ни убавить нельзя без переподключения. Именно о том как это собственно обойти как раз статья и есть.
Стоп-стоп.
У меня из Филиала к Центру постоянно подняты несколько впн-линков. Причем в настройках впн-сервера в Центре маршруты автоматом не раздаются и в Филиале «руками» маршруты не настраиваются. OSPF сам «решает», кто из линков «главнее» и пускает трафик через означенный впн-линк. При этом опенвпн — оригинальный, никем не патченный. И «ронять-поднимать» впн-туннели для этого не требуется.

Насколько я читал он не очень хорош при большом числе сетей /32, а вот это как раз мой случай.

Разверните тестовый стенд (да хотя бы и на VirtBOX-е) и проверьте свою «теорию».
Я вот как раз в начале приводил ссылочку на ровно такое решение (ссылка с названием «раз»). Оно именно про это.

Что касается неудобства OSPF для множества /32, то теория не моя, я выше уже писал что прочитал про это на форуме каком-то, сам лично не проверял. Моё же личное отношение к ЛЮБЫМ протоколам маршрутизации, которые базируются на мультикасте (RIP, OSPF) отрицательное. Ну просто из опыта разнообразной возни именно с самим мультикастом. Выше я писал про то, что BGP кажется мне более управляемым. Так вот как раз из-за того, что он НЕ-мультикастовый и можно легко понять почему скажем нет взаимодействия между двумя маршрутизаторами (смотрим в таблицу маршрутов и видим что скажем нет маршрута до пира) и всякое такое. А вот с мультикастом всё это выглядит посложнее уже (особенно если в промежутке какое-нибудь импортозамещённое оборудование стоит, не ко сну будь помянуто).

Ну вот так как-то.
Моё же личное отношение к ЛЮБЫМ протоколам маршрутизации, которые базируются на мультикасте (RIP, OSPF) отрицательное.


RIP, EIGRP, OSPF — все же broadcast.

Multicast (мультикаст) – процесс отправки пакета от одного хоста к некоторой ограниченной группе хостов.

Broadcast (бродкаст) – процесс отправки пакета от одного хоста ко всем хостам в сети.


OSPF умеет Non-Broadcast (NBMA)
Cкрин с настройками OSPF на pfsense (используется пакет FRR):

image

прочитал про это на форуме каком-то, сам лично не проверял
Не верьте на слово. Развертывайте и пробуйте.
Развертывайте и пробуйте.

Да как бы незачем мне. Меня (как я уже выше писал) более чем устраивает BGP. В том числе возможностью работы с несколькими протоколами (IPv4 и IPv6) в рамках ОДНОГО соединения. И не только IPv4/IPv6 но и L2VPN. И опять-таки в рамках ОДНОГО соединения.

Свои причины НЕ пользоваться всеми ветками BSD в промышленных решениях я также изложил выше. Они у меня примерно такие же как и всех крупных интернет-деятелей (вроде Яндекса), которые были вынуждены (не хотели, а именно были вынуждены по многим причинам) отказаться от BSD в пользу разных Linux. Да, возможно с тех пор и причины исчезли, и BSD ещё круче стали (надеюсь), но нам не шашечки, нам ехать. А вот ехать на них выходило дороже, чем на Linux-ах (и я тоже писал почему).

Предлагаю с советами кому, что и как делать закончить. На вкус и цвет все фломастеры разные. Кому-то красные нравятся, а кому-то синие.
Не хотите использовать BGP — не используйте, я не навязываю. Я вот лично НЕ ХОЧУ использовать OSPF. Ну не нравится он МНЕ и всё тут. То же самое и к BSD в промышленной эксплуатации относится. Да, система хорошая и всё такое, но по эксплуатационным затратам дороже выходит. И не надо мне рассказывать про то что «поставил и забыл». Дырки раз в 10 лет даже в OpenBSD находили. Так что обновлять раньше или позже таки приходится. И вот тут у «сообщественных» BSD были большие проблемы ещё в те времена когда RPM (который в тот момент «вилочничать» вздумал) и DPkg, и все прочие менеджеры пакетов успешно такие проблемы порешали. А в BSD в это время самый нормальный и рабочий способ обновления был «из портов». Особенно если ещё и система кастомизированная, включая ядро. Только-только в качестве решения пыталась пробиться PC-BSD. Да, допускаю что с тех пор много воды утекло и всё могло измениться, но как говорится «ложечки-то мы конечно нашли, но осадочек-то остался».
Да, и к FRR это тоже относится кстати. Который форк Квагги, которая форк просто Зебры, которая синтаксический, но НЕ пофункциональный (в частности advertize map нема) «клон» Cisco IOS. Мне хватило как раз Квагги, вот недавно перебрался на BIRD. Ну да, птиц штука интересная, настройка в некоторых моментах не такая очевидная как в Z/Q/FRR, но более функциональная и с точки зрения программиста явно более удобная и гибкая. И кстати да, управление со стороны скриптов очень даже удобная штука, хотя пока мне и не нужная.
Only those users with full accounts are able to leave comments. Log in, please.