Насчёт "закрученного" линукса против обычного: на обычном у меня сходу не "взлетел" только модем, который а) не особо-то и нужен и б) не взлетел сходу потому что не до него было (собственно из-за п. а) ).
С хакинтошем мало-мало бядааа на этой машинке. Мало того что большая часть железа не та от слова СОВСЕМ, так ещё и главная компонента, то есть процессор из тех, под которые Mac OS X не затачивалась от слова совсем. Ну например полное отсутствие x86_64. А на тот момент Mac OS X хотя и был в переходе от PowerPC к Intel, но уже на Intel он был 64-битный. А тут проц увы только 32-битный.
А про карманы да, тема старая. Компания SONY в своё время ввела в моду мужские рубашки с увеличенным размером кармана. Только потому что в штатный не влезал свежесозданный Walkman. Так что ничто не ново.
Если ставить на него скажем Ubuntu (штатно ставить 16.04 и штатно же обновлять до 18.04) , да вместо Unity поставить например FluxBox (который на SSD-версии запускается за ВОСЕМЬ СЕКУНД), то для настройки всякого разного сетевого железа машинка более чем достаточная. Размер позволяет запихнуть её в буквальном смысле в задний карман джинсов, на USB вполне себе вешается USB-COM-порт, а малые габариты позволяют её держать в одной руке, набирая в это время второй или же держать двумя руками, а набирать двумя большими пальцами (тут вопрос привычки или удобства в конкретный момент). Ну или в том же коммуникационном шкафу она гораздо меньше места занимает в отличие от скажем 13-14-15-дюймового ноутбука.
Да как бы незачем мне. Меня (как я уже выше писал) более чем устраивает 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, но более функциональная и с точки зрения программиста явно более удобная и гибкая. И кстати да, управление со стороны скриптов очень даже удобная штука, хотя пока мне и не нужная.
Я вот как раз в начале приводил ссылочку на ровно такое решение (ссылка с названием «раз»). Оно именно про это.
Что касается неудобства OSPF для множества /32, то теория не моя, я выше уже писал что прочитал про это на форуме каком-то, сам лично не проверял. Моё же личное отношение к ЛЮБЫМ протоколам маршрутизации, которые базируются на мультикасте (RIP, OSPF) отрицательное. Ну просто из опыта разнообразной возни именно с самим мультикастом. Выше я писал про то, что BGP кажется мне более управляемым. Так вот как раз из-за того, что он НЕ-мультикастовый и можно легко понять почему скажем нет взаимодействия между двумя маршрутизаторами (смотрим в таблицу маршрутов и видим что скажем нет маршрута до пира) и всякое такое. А вот с мультикастом всё это выглядит посложнее уже (особенно если в промежутке какое-нибудь импортозамещённое оборудование стоит, не ко сну будь помянуто).
Учитывая, что Ubuntu есть форк DebIan, разница не очень большая. Насколько я помню Proxmox всё-таки от чистого DebIan форкнулся, но могу и ошибаться.
Есть и /24 и /28
Вот тут один из главных моментов с OSPF и кроется. Насколько я читал он не очень хорош при большом числе сетей /32, а вот это как раз мой случай.
По большому же счёту вопрос не в том, OSPF, BGP или RIP. Вопрос в том, что в штатный (то есть не модифицированный специально) OpenVPN «на лету» маршруты ни добавить, ни убавить нельзя без переподключения. Именно о том как это собственно обойти как раз статья и есть.
У меня полтора десятка филиалов на 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 потребовал пересборки половины портов в системе (да, я портами пользовался и продолжаю считать именно этот способ самым кашерным). А так да, системы хорошие.
Максимально эффективная утилизация канала будет если внутри туннеля используется MTU с учетом что туннелю как то эти пакеты еще заворачивать на физическом уровне.
Я в данном случае даже и не спорю. Ещё раз повторю, OpenVPN в данном случае не про эффективность, он про «проходимость» (она же «проницаемость»). То есть если делать решение именно «эффективное» (не только с точки зрения утилизации), то это не к OpenVPN уже как минимум из-за того, что это комбайн, который содержит в себе маршрутизатор. Который а) дублирует функциональность ОС, которая делает это явно эффективнее (ибо делает это на уровне ядра, без переключения контекстов на userspace) и б) делает это явно менее функционально, потому что ядро позволяет использовать всякие другие «плюшки» вроде policy-based routing и иже с ним, чего OpenVPN не умеет от слова «совсем».
И да, вышеприведённая статья на самом-то деле «выросла» из удачной попытки скрестить Linux и RouterOS именно по OpenVPN и при этом обеспечить с обеих сторон динамическую маршрутизацию. Но изначальный первичный эксперимент делался таки именно между двумя чистыми Linux, а уже потом был «обратно» пристыкован RouterOS и схема подтверждена на такой связке. Кстати в случае если клиентом является RouterOS скрипт для клиента на сервере на одну команду меньше, потому что не нужна команда
С одной стороны так сложилось, что моё знакомство с динамической маршрутизацией началось «по-серьёзному» с BGP (были «поигрулечки» с RIP, но это было давно и неправда).
С другой стороны про OSPF бытует мнение (не моё, где-то на форуме бегло проскочило), что он не очень оптимально работает в случае большого числа маршрутов /32. Что в моём случае как раз имеет место быть (обходы запретов одного «замечательного» ведомства как пример).
С третьей стороны ИМХО (Имею Мнение, Хрен Оспоришь) BGP кажется мне более управляемым протоколом, в первую очередь потому, что базируется на unicast, допускает multihop и всё такое.
Ну и наконец, BGP замечательно передаёт данные всяких там MPLS, VRF и иже с ними.
А картинка в самом простом случае очевидна: с одной стороны сервер, с другой клиент, между ними собственно туннель. В статье как раз специально рассмотрена типовая минимальная ситуация. То есть дальше можно масштабировать по своему усмотрению.
Ээээ. В отношении OpenVPN говорить об оверхэде смысла нет. Он не для сокращения оверхэда. В статье, где сравнивали пропускную способность OpenVPN и WireGuard однозначно показали что у OpenVPN ПС раза в три-четыре ниже, чем у WG. И всё из-за оверхеда, фрагментации/дефрагментации и т. п.
Есть некая вероятность, что единственный Линукс, где ZFS будет на полных правах — это Oracle Linux. Который есть ветвь RHEL, более того, что-то Оракул даже отдаёт в апстрим, но вот ZFS вероятнее всего не будет, самый страшный зверь (жаба) задушит.
Насчёт "закрученного" линукса против обычного: на обычном у меня сходу не "взлетел" только модем, который а) не особо-то и нужен и б) не взлетел сходу потому что не до него было (собственно из-за п. а) ).
С хакинтошем мало-мало бядааа на этой машинке. Мало того что большая часть железа не та от слова СОВСЕМ, так ещё и главная компонента, то есть процессор из тех, под которые Mac OS X не затачивалась от слова совсем. Ну например полное отсутствие x86_64. А на тот момент Mac OS X хотя и был в переходе от PowerPC к Intel, но уже на Intel он был 64-битный. А тут проц увы только 32-битный.
А про карманы да, тема старая. Компания SONY в своё время ввела в моду мужские рубашки с увеличенным размером кармана. Только потому что в штатный не влезал свежесозданный Walkman. Так что ничто не ново.
Если ставить на него скажем Ubuntu (штатно ставить 16.04 и штатно же обновлять до 18.04) , да вместо Unity поставить например FluxBox (который на SSD-версии запускается за ВОСЕМЬ СЕКУНД), то для настройки всякого разного сетевого железа машинка более чем достаточная. Размер позволяет запихнуть её в буквальном смысле в задний карман джинсов, на USB вполне себе вешается USB-COM-порт, а малые габариты позволяют её держать в одной руке, набирая в это время второй или же держать двумя руками, а набирать двумя большими пальцами (тут вопрос привычки или удобства в конкретный момент). Ну или в том же коммуникационном шкафу она гораздо меньше места занимает в отличие от скажем 13-14-15-дюймового ноутбука.
Да как бы незачем мне. Меня (как я уже выше писал) более чем устраивает 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, но более функциональная и с точки зрения программиста явно более удобная и гибкая. И кстати да, управление со стороны скриптов очень даже удобная штука, хотя пока мне и не нужная.
Что касается неудобства OSPF для множества /32, то теория не моя, я выше уже писал что прочитал про это на форуме каком-то, сам лично не проверял. Моё же личное отношение к ЛЮБЫМ протоколам маршрутизации, которые базируются на мультикасте (RIP, OSPF) отрицательное. Ну просто из опыта разнообразной возни именно с самим мультикастом. Выше я писал про то, что BGP кажется мне более управляемым. Так вот как раз из-за того, что он НЕ-мультикастовый и можно легко понять почему скажем нет взаимодействия между двумя маршрутизаторами (смотрим в таблицу маршрутов и видим что скажем нет маршрута до пира) и всякое такое. А вот с мультикастом всё это выглядит посложнее уже (особенно если в промежутке какое-нибудь импортозамещённое оборудование стоит, не ко сну будь помянуто).
Ну вот так как-то.
Учитывая, что Ubuntu есть форк DebIan, разница не очень большая. Насколько я помню Proxmox всё-таки от чистого DebIan форкнулся, но могу и ошибаться.
Вот тут один из главных моментов с OSPF и кроется. Насколько я читал он не очень хорош при большом числе сетей /32, а вот это как раз мой случай.
По большому же счёту вопрос не в том, OSPF, BGP или RIP. Вопрос в том, что в штатный (то есть не модифицированный специально) OpenVPN «на лету» маршруты ни добавить, ни убавить нельзя без переподключения. Именно о том как это собственно обойти как раз статья и есть.
А из/в филиалы какого размера сети ходят? Уже не /24 ли случаем?
Хотел попробовать, но руки пока не дошли. Ну и кроме того среди «промышленных» 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 потребовал пересборки половины портов в системе (да, я портами пользовался и продолжаю считать именно этот способ самым кашерным). А так да, системы хорошие.
Я в данном случае даже и не спорю. Ещё раз повторю, OpenVPN в данном случае не про эффективность, он про «проходимость» (она же «проницаемость»). То есть если делать решение именно «эффективное» (не только с точки зрения утилизации), то это не к OpenVPN уже как минимум из-за того, что это комбайн, который содержит в себе маршрутизатор. Который а) дублирует функциональность ОС, которая делает это явно эффективнее (ибо делает это на уровне ядра, без переключения контекстов на userspace) и б) делает это явно менее функционально, потому что ядро позволяет использовать всякие другие «плюшки» вроде policy-based routing и иже с ним, чего OpenVPN не умеет от слова «совсем».
И да, вышеприведённая статья на самом-то деле «выросла» из удачной попытки скрестить Linux и RouterOS именно по OpenVPN и при этом обеспечить с обеих сторон динамическую маршрутизацию. Но изначальный первичный эксперимент делался таки именно между двумя чистыми Linux, а уже потом был «обратно» пристыкован RouterOS и схема подтверждена на такой связке. Кстати в случае если клиентом является RouterOS скрипт для клиента на сервере на одну команду меньше, потому что не нужна команда
С другой стороны про OSPF бытует мнение (не моё, где-то на форуме бегло проскочило), что он не очень оптимально работает в случае большого числа маршрутов /32. Что в моём случае как раз имеет место быть (обходы запретов одного «замечательного» ведомства как пример).
С третьей стороны ИМХО (Имею Мнение, Хрен Оспоришь) BGP кажется мне более управляемым протоколом, в первую очередь потому, что базируется на unicast, допускает multihop и всё такое.
Ну и наконец, BGP замечательно передаёт данные всяких там MPLS, VRF и иже с ними.
А картинка в самом простом случае очевидна: с одной стороны сервер, с другой клиент, между ними собственно туннель. В статье как раз специально рассмотрена типовая минимальная ситуация. То есть дальше можно масштабировать по своему усмотрению.
Ну вот так как-то.
Ээээ. В отношении OpenVPN говорить об оверхэде смысла нет. Он не для сокращения оверхэда. В статье, где сравнивали пропускную способность OpenVPN и WireGuard однозначно показали что у OpenVPN ПС раза в три-четыре ниже, чем у WG. И всё из-за оверхеда, фрагментации/дефрагментации и т. п.
Как-то так.
Я вообще больше ветку DebIan жалую, так что за шапками, копейками и иже с ними не особо слежу.