bbk 31 янв 2019 в 03:58

VyOS OpenSource Router

5 мин

49K

Open source*IT-инфраструктура*Сетевые технологии*Софт

+16

Комментарии 37

FeNUMe 31 янв 2019 в 07:16

Познавательно, но с тегами явный перебор.

quakerdjj 31 янв 2019 в 07:56

тут ссылка на релизы
downloads.vyos.io/?dir=rolling/current/amd64

НЛО прилетело и опубликовало эту надпись здесь

gecube 31 янв 2019 в 09:32

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

-1

DaemonGloom 31 янв 2019 в 11:34

Для Микротика это можно частично победить с помощью metarouter (запустить альтернативную конфигурацию на виртуальной машине внутри основного роутера).

astraleuro 31 янв 2019 в 13:12

Я так понимаю, что аналогичное ограничение распространяется на любой коробочный продукт

В pfSense без проблем

gecube 31 янв 2019 в 14:27

ну, расскажите, как там реализовано. Т.е. там из коробки сразу поддержка нескольких отдельных инстансов openvpn-серверов?

-1

astraleuro 31 янв 2019 в 17:00

Да, именно так. Из личной практики:
2 интерфейса во внешний мир от разных провайдеров, на одном из них 7 серверов oVPN для подключения удаленных филиалов (site-to-site) и один для удаленного подключения единичных пользователей. На втором пока только сервер для подключения пользователей (вобщем для себя, если вдруг основной канал упал)

скрин:

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

Или Вы что то другое имели ввиду и я Вас не понял?

bbk 31 янв 2019 в 18:13

На сколько я знаю, то это можно сделать, но я не пробовал.
Спросите лучше на форуме или в слаке.

НЛО прилетело и опубликовало эту надпись здесь

hexes 27 июн 2019 в 10:34

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

plastilin 17 мая 2020 в 01:09

set interfaces openvpn vtun0
set interfaces openvpn vtun1
И ТД...

gecube 31 янв 2019 в 09:30

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

НЛО прилетело и опубликовало эту надпись здесь

gecube 31 янв 2019 в 18:58

я NSX потребляю либо как сервис, либо пускай с ним борются сетевые инженеры.
Касательно Site-to-Site в самом облаке — ну, к сожалению, реально иногда нет вариантов, кроме как воспользоваться их нативными возможностями (вроде cloud.google.com/hybrid-connectivity, но раньше было интереснее написано)

-2

bbk 31 янв 2019 в 22:12

Собственно VyOS он как раз для сетевых инженеров.

gecube 31 янв 2019 в 23:41

Они так не думают, у них стоят cisco & juniper'ы.
В крайнем случае, если контора жмет денег — микротики.

-1

НЛО прилетело и опубликовало эту надпись здесь

pupsegadm 31 янв 2019 в 10:28

Интересно — это безусловно. Спасибо!
Но в чем киллер-фича? Отсутствие GUI = CLI. Что должно мне помешать гонять какую-нибудь линуксятню через bash и все это конфигурячить?

gecube 31 янв 2019 в 10:45

Я об этом и спрашиваю. Единственное, что скажут (судя по всему), что де «все компоненты глубоко проинтегрированы друг с другом и проверенных версий, а не прямо апстримовых из нестабильных веток. В случае использования дистрибов ОС могут быть неожиданности»

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

-2

bbk 31 янв 2019 в 17:51

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

Свои идеи и запросы по фичам можно размещать на этом сайте phabricator.vyos.net в разделе «Submit Feature Request».

wlr398 31 янв 2019 в 10:58

В общем то ничего, если есть желание.
Vyatta/VyOS привлекают монолитным единообразным конфигом, похожим на конфиги Juniper.
Хотя, конечно, область применения довольно ограничена и при наличии конкурентов типа pfSense. Действительно проще взять полностью готовую коробочку Микротика.
Тем не менее на Vyatta не пожалел денег Brocade.

eri 31 янв 2019 в 11:43

он у них вроде был на сотню однообразных файлов или поменяли?

wlr398 31 янв 2019 в 11:52

Конфиг именно один и работа с ним похожа на стиль работы с большими маршрутизаторами типа Джунипер, Циско.
Два варианта вывода, в структурированном виде со скобками или построчно:

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'

gecube 31 янв 2019 в 12:34

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

И не могу, конечно, пройти мимо упоминания NAPALM

-2

wlr398 31 янв 2019 в 12:49

Каждому своё.
VyOS наверное не для масштабного применения.
А единичный маршрутизатор с точки зрения сетевого инженера удобнее с монолитным конфигом, а не голый линукс с настройкой всего вручную.
Опять же, тяжёлые маршрутизаторы Циско, Джунипер, Хуавей, Нокиа, все имеют монолитные конфиги. Попытки автоматизации их настроек есть, но именно что попытки, похожие на костыли.

НЛО прилетело и опубликовало эту надпись здесь

YaDr 31 янв 2019 в 17:28

С VyOS не придется писать тонны бойлерплейта, учитывающего все особенности конфигурации каждого сервиса…

wlr398 31 янв 2019 в 18:18

Обычно, такое контраргументируют, что один раз настраивают все сервисы, а потом снимают образ и по необходимости раскатывают из образа.
Но при этом, всё таки, получается CLI GNU/Linux, а не CLI сетевого оборудования,
что может оказаться весьма критичным и неудобным.

red5 31 янв 2019 в 22:13

Пользовался Vyatta: не нужно конфу размазывать по n-файлам (ip адреса в одном месте, настройки vpn в другом и т.п.) все конфигурируется в одной консоли, JunOS подобный синтаксис.

gecube 31 янв 2019 в 23:42

Еще раз — чем это принципиально отличается от кейса IaC, когда настройки могут храниться для каждого узла в декларативном виде в отдельном файле?
Все равно хорошей идеей является делать мастер-копию конфига в git-репозитории (как минимум — потом не будет головной болью вернуться к опреденной версии). Как максимум — можно построить процедуры применения изменений на ключевых маршрутизаторах/роутерах с тестированием и откатом изменений.

-2

creker 31 янв 2019 в 11:43

Роутер можно установить на голое железо, кастомные образы (в планах):

Это предполагает использование ASIC на этих платформах и останется ли тогда проект open source? Для этих железок уже есть cumulus, который имеет открытые исходники для всего, кроме взаимодействия с ASIC. Есть подозрение, что открыть исходники этой части просто невозможно из-за ограничений со стороны вендора.