вторник, 9 февраля 2021 г.

VyOS | Странная лаба | Первый взгляд


Не ждали?! А я еще в строю! Сегодня "колхозим" странную лабу на VyOS!
Посты в серии:

Вместо вступления

Прошло уже больше года с моего последнего поста про новый сервер. Не смотря на затишье в блоге, я его таки доделал. Как всегда в процессе многое поменялось, но в целом сама концепция более или менее соблюдена. Прошлый год был лихим и было признаться совсем не до блога. В этом году хочу начать исправляться. В голове много тем. Много чего хочется затронуть. Как то, что интересно лично мне, так и то, c чем удалось познакомиться в AWS. Но это было бы совсем голословным заявлением, поэтому "для весу" я решил начать с довольно простой, но интересной темы. 

Сервер уже пашет больше года, но вот функцию для которой он был куплен (лабы) он совсем не выполняет... 40Гб оперативки простаивают без нагрузки, поэтому сегодня попробуем немного размяться. 

С чего вдруг VyOS?

В общем, когда я выбирал роутер для своего уютного серверочка я впал в замешательство. С одной стороны выбор был для меня очевиден - Mikrotik Router OS. Но блин, это так скучно. Подумывал про Cisco/Juniper, но душа не лежит... И так их много в моей жизни. Я уже начал смотреть на FRR c iptables, но друзья подсказали VyOS и я купился. Проект показался мне интересным. Тем более он активно развивается, что очень радует.

VyOS это open source сетевая OS c Juniper-like CLI. Звучит как хороший повод покрасноглазить вечерок другой...

Установка

Система OpenSource, но это не всегда значит просто (скорее никогда). Для начала надо что? Правильно, сбилдить...

На сколько мне известно, система распространяется в нескольких вариантах
  • Бесплатно
    • Стабильный релиз придется сбилдить самому, благо для этого есть докер контейнер, который в принципе весь процесс упрощает донельзя. Именно по этому "тру" пути пошел я и сбилдил себе пару образов для своих роутеров. 
    • "rolling" релиз собирается каждый день и его можно скачать. Он содержит самую последнюю версию кода, а значит и самые последние баги. Вместе с багами мы получаем и самые новые фичи (API например). 
  • По подписке
    • Тут есть несколько опций, возможность поддержки и легко скачивать готовые образы. 
Тут у меня есть два замечания
  • для своего сервера я использую стабильный релиз (фиг знает вообще почему) и билдил я его сам. После года работы в AWS менеджить даже два роутера руками как минимум странно, поэтому я вынужден был написать пару скриптов для того, чтобы это было удобно делать - https://github.com/MelHiour/vyos_cfg. Наверное в следующих постах расскажу и про это. В лабе же планирую использовать rolling релиз, уж очень хочется API.
  • VyOS раздает подписку "for educational and non-profit institutions". Будет честным заметить, что некоторое время назад и мне такую дали (спасибо Роман!). Но пост не проплачен. ) 

Топология

На этом этапе я конкретно "подвис". Сначала я хотел воспроизвести то, что настроено у меня на сервере. Но там ничего особенного и все как-то "утилитарно". Второй идее было "нахимичить" что-то провайдерское. От этой идеи я тоже отказался. Далее хотел сделать клос фабрику, но это это как-то не в тему совсем. Была идея воспроизвести мою любимую топологию отсюда, но в другой раз. В общем, остановился я на следующей неведомой зверушке...

Тезисно

  • пусть это будет некая граница сети с необходимостью фильтровать трафик
  • хочу воплотить концепцию "чтобы файерволы файерволили, а роутеры роутили" на максималках 
  • цели сделать рабочую топологию для жизни нет (не надо пытаться придумать ей юзкейс)
  • хочется попробовать несколько новых идей и фич
В общем и целом, все это носит скорее экспериментаторский характер "А заведется ли или нет". В конце концов писать гайд как настроить файервол хоть и полезно, но не очень весело. Плюс я не особо то и работал с VyOS. )

Предметно


С виду все довольно просто. 
  • Есть четыре типа устройств в топологии
    • Интернет роутеры (это некий BGP домен)
    • Роутеры на нашей границы сети (одной стороной смотрят в мир, другой внутрь сети)
    • Файерволы 
    • Роутеры смотрящие внутрь сети (по задумке смотрят прям в клиентов и терминитруют VRRP).
  • Требования
    • Трафик разных клиентских сетей должен фильтроваться (не на роутерах, а на файерволах)
    • Файерволы нужно исключить из роутинга по максимуму
    • При такой топологии трафик будет практически всегда ходить не симметрично, а значит файерволам надо синхронизировать сессии. 
    • Сеть должна работать )

А теперь к интересному и подробней

По задумке я хочу убрать роутинг с файерволов по максимуму, в том числе и VRRP. VRRP сети будут терминироваться на роутерах смотрящих в клиентов. Чтобы "поднять" этот трафик до файерволов я планирую использовать VRF для каждой сети. Ниже развертка двух сетей на R1/R2. Клиенты шлют трафик на них, те имеют маршрут по умолчанию через файервол. На файерволе планирую настроить фильтрацию по зонам, каждый интерфейс прикреплен к VRFу и соответсвующей зоне. 


Таким образом, трафик между двумя клиентскими сетями будет (я надеюсь) ходить весьма причудливым образом. (А и В это Active и Backup роутеры в VRRP). 


Синим цветом запрос из одной сети в другую, красным ответ. Тут есть два вопроса
  • Будет ли синхронизация сессий между файерволами работать так как мне надо
  • Будет ли бэкап роутер форвардить пакеты в сеть. Например, при запросе трафик после фильтрации попадет обратно на роутер, который является бэкап роутером для этой сети. Отправит ли он такой пакет в сеть? Вообще, почему собственно нет?
Примерно так же будет ходить трафик и в Интернет, только здесь добавляется NAT. 


Главный вопрос - будут ли NAT сессии синхронизироваться? Должны я думаю, мы синхронизируем по сути netfilter сессии, а они делают и нат и фильтрацию.

Продолжаем развлекаться. Одна из идей в лабе - убрать роутинг с файерволов. VRRP убран, пришло время BGP. 


По задумке iBGP сессия будет проходить через файервол. На файерволе придется добавить несколько статических маршрутов. В сети снизу через клиентские роутеры и маршрут по умолчанию вверх для Интернет трафика. Заметьте, что пограничные роутер анонсируют /24 в мир, в то время как клиентские роутеры снизу анонсируют более длинные подсети и привлекают трафик к файерволам, которые эти подсети используют для NATа.

Пока вижу здесь проблему  с R1/R2. В линке между роутерами и файерволами будут ходить много VRFов, а VRF в VyOS умеет только в статику на сколько я знаю. Возможно удастся поднять сессию в нативном VRF, но возможно придется изобретать велосипед. Что-то вроде анонса /32 префикса с B1/B2 по BGP и статического маршрута на R1/R2 в каждом VRF на этот префикс. По идее, если этот префикс уйдет, то статический маршрут перестанет быть валидным.


Вообще да, идея всех этих BGP в том, чтобы не "блэкхоулить" трафик. При выходе их строя любого файервола или роутера, соседство падает, префикс уходить из таблицы и трафик уходить на живые железки. Если синхронизация между файерволами будет работать так как я думаю, то даже сессии переустанавливаться не будут. Приятный бонус.

План на ближайшее будущее
  • Собрать лабу
  • Попытаться воплотить в жизнь задуманное
  • Покопать в сторону API и того как всем этим можно управлять

Важное замечание

Я понятия не имею на данный момент возможно ли сделать то, что я задумал. Повторюсь целью является поэкспериментировать и решить поставленную задачку с помощью имеющихся средств. Скорее всего многое придется переиграть, хотя бы потому, что я не знаю всех ограничений и особенностей платформы. Например, BGP на сколько мне известно не работает в VRF. А как синхронизировать сессии между файерволами я вообще пока не представляю. 

В следующий раз будем мастерить active-active конфигурацию.

Комментариев нет:

Отправить комментарий