Comments
Спасибо. Пробовал использовать как шлюз и было необходимо поднять 2 экземпляра OpenVPN сервера — не нашел как, пришлось ставить обычный центос. Скажите, возможно иметь 2 и более экземпляра сервиса с разными настройками?

Я так понимаю, что аналогичное ограничение распространяется на любой коробочный продукт. Тот же Mikrotik RouterOS не умеет несколько ovpn серверов одномоментно. Разруливается индивидуальными конфигурациями для разных клиентов...

Для Микротика это можно частично победить с помощью metarouter (запустить альтернативную конфигурацию на виртуальной машине внутри основного роутера).
Я так понимаю, что аналогичное ограничение распространяется на любой коробочный продукт
В pfSense без проблем
ну, расскажите, как там реализовано. Т.е. там из коробки сразу поддержка нескольких отдельных инстансов openvpn-серверов?
Да, именно так. Из личной практики:
2 интерфейса во внешний мир от разных провайдеров, на одном из них 7 серверов oVPN для подключения удаленных филиалов (site-to-site) и один для удаленного подключения единичных пользователей. На втором пока только сервер для подключения пользователей (вобщем для себя, если вдруг основной канал упал)
скрин:
image

Все никак не дойдут руки наподнимать кучу тоннелей (все возможные) между всеми объектами (практически на всех объектах по 2 провайдера) и поднять поверх этого BGP

Или Вы что то другое имели ввиду и я Вас не понял?
Абсолютно точно это возможно, у меня 2 экземпляра OpenVPN используется на VyOS

Спасибо за обзор… Но не нашел ни одной причины использовать описанный продукт. Что я неправильно понял? Может пропустил какую-то убер-фишку VyOS?
При прочих равных мне или проще плодить Mikrotik CHR, либо ВМ с Debian/Ubuntu/Centos и самому решать какое наполнение пакетами у ОС будет. Ну, и конфигурацию могу изменять стандартными способами (ansible, salt, puppet, etc).
Я уж не говорю про то, что в облачных провайдерах (или — виртуализированных средах) есть свои пограничные узлы, настраиваемые через их панели. Ну, например, vmware nsx

на вкус и цвет все фломастеры разные. Могу только сказать что у всех разные потребности. Попробуйте как-то поднять nsx за 10 минут, ну или если CHR то что делать если нужен RPKI
Или если говорить деньгами например
AWS Site-to-Site VPN connection pricing
$0.05 per Site-to-Site VPN connection-hour ($36/m)
я NSX потребляю либо как сервис, либо пускай с ним борются сетевые инженеры.
Касательно Site-to-Site в самом облаке — ну, к сожалению, реально иногда нет вариантов, кроме как воспользоваться их нативными возможностями (вроде cloud.google.com/hybrid-connectivity, но раньше было интереснее написано)
Они так не думают, у них стоят cisco & juniper'ы.
В крайнем случае, если контора жмет денег — микротики.
Интересно — это безусловно. Спасибо!
Но в чем киллер-фича? Отсутствие GUI = CLI. Что должно мне помешать гонять какую-нибудь линуксятню через bash и все это конфигурячить?
Я об этом и спрашиваю. Единственное, что скажут (судя по всему), что де «все компоненты глубоко проинтегрированы друг с другом и проверенных версий, а не прямо апстримовых из нестабильных веток. В случае использования дистрибов ОС могут быть неожиданности»

Т.е. для меня такой проект может быть хорошей тестовой площадкой, чтобы потом бекпортировать кастомные патчи в основные ветки использованного софта.
Это Open Source проект, любые киллер фичи добавляют энтузиасты. Точно также и с идеями, если есть хорошая идея её проект принимает и реализует.

Свои идеи и запросы по фичам можно размещать на этом сайте phabricator.vyos.net в разделе «Submit Feature Request».
В общем то ничего, если есть желание.
Vyatta/VyOS привлекают монолитным единообразным конфигом, похожим на конфиги Juniper.
Хотя, конечно, область применения довольно ограничена и при наличии конкурентов типа pfSense. Действительно проще взять полностью готовую коробочку Микротика.
Тем не менее на Vyatta не пожалел денег Brocade.
он у них вроде был на сотню однообразных файлов или поменяли?
Конфиг именно один и работа с ним похожа на стиль работы с большими маршрутизаторами типа Джунипер, Циско.
Два варианта вывода, в структурированном виде со скобками или построчно:

nat {
    source {
        rule 1 {
            outbound-interface eth2
            source {
                address 10.10.10.10/32
            }
            translation {
                address masquerade
            }
        }

Или так

set nat source rule 1 source address '10.10.10.10/32'
set nat source rule 1 translation address 'masquerade'

Ну, и ценность конфига в одном файле, если все уже давным-давно пытаются натянуть SCM (salt, ansible, puppet) на сетевое оборудование? Чтобы конфигурации хранить в репозиториях и все-таки сначала их тестировать, а не выкатывать на продакшн.

И не могу, конечно, пройти мимо упоминания NAPALM
Каждому своё.
VyOS наверное не для масштабного применения.
А единичный маршрутизатор с точки зрения сетевого инженера удобнее с монолитным конфигом, а не голый линукс с настройкой всего вручную.
Опять же, тяжёлые маршрутизаторы Циско, Джунипер, Хуавей, Нокиа, все имеют монолитные конфиги. Попытки автоматизации их настроек есть, но именно что попытки, похожие на костыли.
да есть там и салт внутри, и в ансибл есть модули под VyOS как и NAPALM драйвер
и внезапно встроенный версионнинг конфигов тоже есть например.
С VyOS не придется писать тонны бойлерплейта, учитывающего все особенности конфигурации каждого сервиса…
Обычно, такое контраргументируют, что один раз настраивают все сервисы, а потом снимают образ и по необходимости раскатывают из образа.
Но при этом, всё таки, получается CLI GNU/Linux, а не CLI сетевого оборудования,
что может оказаться весьма критичным и неудобным.
Пользовался Vyatta: не нужно конфу размазывать по n-файлам (ip адреса в одном месте, настройки vpn в другом и т.п.) все конфигурируется в одной консоли, JunOS подобный синтаксис.
Еще раз — чем это принципиально отличается от кейса IaC, когда настройки могут храниться для каждого узла в декларативном виде в отдельном файле?
Все равно хорошей идеей является делать мастер-копию конфига в git-репозитории (как минимум — потом не будет головной болью вернуться к опреденной версии). Как максимум — можно построить процедуры применения изменений на ключевых маршрутизаторах/роутерах с тестированием и откатом изменений.
Роутер можно установить на голое железо, кастомные образы (в планах):

Это предполагает использование ASIC на этих платформах и останется ли тогда проект open source? Для этих железок уже есть cumulus, который имеет открытые исходники для всего, кроме взаимодействия с ASIC. Есть подозрение, что открыть исходники этой части просто невозможно из-за ограничений со стороны вендора.
Cumulus на свитчи ориентирован, в VyOS чуть другой фокус. О asic речь пока не идет, да и план у нас держать все опенсорсным всегда. Кастомные образы это собранные и натюненные под конкретную железяку в определенной конфигурации.
Вот с Edge-Core работаем на тему поддержки вот этих железок.
Есть Ubiquiti EdgeRouter железо которое юзает VyOS.
Почему Проект вдруг должен из-за этого закончиться, не понятно.
ну edgerouter юзает EdgeOS, форкнули в епох 6.2 а мы форкнули уже 6.6
так то уже давно наши пути разошлись )
Only those users with full accounts are able to leave comments. Log in, please.