Как уже стало понятно из прошлого поста, не во всем я уверен... В этом посте начнем строить топологию снизу вверх и посмотреть как будут работать фичи (или не работать).
Посты в серии:
EVE-NG
Как обычно я все буду делать в EVE-NG. Нам потребуются два образа. VyOS для всех сетевых устройств и что-то для клиентских устройств. Как добавить VyOS можно почитаться здесь, а в качестве клиентских машин у меня Centos8. Его можно добавить по этой инструкции.
Далее все это добавляем в топологию.
Стоит заранее подумать про адресацию. Сегодня коснемся только нижней части схемы.
Будем постепенно усложнять сеть
- Протестируем правильно ли работает VRRP
- "Дотянем" сети до файерволов
- Настроим Conntrack (синхронизацию сессий) на файерволах
- В следующем посте финализируем топологию (BGP, отказоустойчивость и все, что вылезет)
VRRP
Первое, что я хочу проверить - будет ли VRRP работать как мне надо. У нас есть две сети, R1 мастер в первой, R2 во второй. Таким образом трафик будет ходить немного причудливо. Запрос от клиента одной сети к другому будет идти через MASTER роутер, а вот ответ всегда будет идти от BACKUP.
Вот неполная череда событий
- PC1 (10.0.11.11) хочет пинговать PC2 (10.0.12.12)
- PC1 понимает, что это не его сеть
- PC1 узнает MAC своего default gateway (R1)
- PC1 отправляет трафик на default gateway (R1)
- R1 получает трафик и понимает, что имеет интерфейс в 10.0.12.0/24
- R1 роутит трафик до 10.0.12.12
- PC2 получает трафик и собирается отправить ответ
- PC2 понимает, что это не его сеть
- PC2 узнает MAC своего default gateway (R2)
- PC2 отправляет трафик на default gateway (R2)
- R2 имеет интерфейс в 10.10.11.0/24 и отправляет трафик напрямую.
Все это мы сейчас проверим, но для начала вот конфигурация R1. R2 имеет симметричный конфиг.
set system host-name 'R1'
set high-availability vrrp group VLAN11 hello-source-address '10.0.11.1'
set high-availability vrrp group VLAN11 interface 'eth1'
set high-availability vrrp group VLAN11 peer-address '10.0.11.2'
set high-availability vrrp group VLAN11 priority '200'
set high-availability vrrp group VLAN11 virtual-address '10.0.11.254/24'
set high-availability vrrp group VLAN11 vrid '11'
set high-availability vrrp group VLAN12 hello-source-address '10.0.12.1'
set high-availability vrrp group VLAN12 interface 'eth2'
set high-availability vrrp group VLAN12 peer-address '10.0.12.2'
set high-availability vrrp group VLAN12 priority '100'
set high-availability vrrp group VLAN12 virtual-address '10.0.12.254/24'
set high-availability vrrp group VLAN12 vrid '12'
set interfaces ethernet eth1 address '10.0.11.1/24'
set interfaces ethernet eth1 description 'VLAN11'
set interfaces ethernet eth2 address '10.0.12.1/24'
set interfaces ethernet eth2 description 'VLAN12'
После конфигурации роли распределились как надо. R1 мастер в 10.0.11.0/24, R2 в 10.0.12.0/2.
На клиентах настраиваем адреса и вуаля, пинги ходят.
А вот что собственно происходит (трафик снят с PC1).
- PC1 спрашивает MAC своего "маршрутизатора последней надежды"
- R1 отвечает (запоминаем MAC)
- PC1 отправляет ICMP запрос для PC2 на этот MAC
- Но вот ответ приходит не от R1. SRC MAC другой и принадлежит R2 eth1.
VRF
Будем усложнять сеть постепенно. Мы знаем, что VRRP работает, теперь надо сделать так, чтобы роутились сети не на R1/R2 а на F1/F2, которые будут эти сессии фильтровать.
На данном этапе я хочу реализовать это используя VRF и кучку статических маршрутов. Потом придется это немного поменять/модернизировать.
Добавляем интерфейс с парой сабинтерфейсов к файерволу. Соответственно трафик из разных сетей должен приходить в разные интерфейсы. Ниже пара R1-F1. Абсолютно такая же конфигурация и на R2-F2.
На R1/R2
set interfaces ethernet eth0 address '172.16.0.0/31'
set interfaces ethernet eth0 description 'F1'
set interfaces ethernet eth0 vif 11 address '172.16.11.0/31'
set interfaces ethernet eth0 vif 12 address '172.16.12.0/31'
На F1/F2
set interfaces ethernet eth1 address '172.16.0.1/31'
set interfaces ethernet eth1 description 'R1'
set interfaces ethernet eth1 vif 11 address '172.16.11.1/31'
set interfaces ethernet eth1 vif 12 address '172.16.12.1/31'
Создаем два VRFа на R1/R2 и добавляем в них нужные интерфейсы.
set vrf name VL11
set vrf name VL11 table 111
set interface ethernet eth1 vrf VL11
set interface ethernet eth0 vif 11 vrf VL11
set vrf name VL12
set vrf name VL12 table 112
set interface ethernet eth2 vrf VL12
set interface ethernet eth0 vif 12 vrf VL12
Файервол должен знать как добраться до клиентских сетей. Каждый VRF на R1/R2 должен слать все вверх на файерволы.
На R1/R2
set protocols vrf VL11 static route 0.0.0.0/0 next-hop 172.16.11.1
set protocols vrf VL12 static route 0.0.0.0/0 next-hop 172.16.12.1
На F1/F2
set protocols static route 10.0.11.0/24 next-hop 172.16.11.0
set protocols static route 10.0.12.0/24 next-hop 172.16.12.0
Пробуем работает ли
Как видно 172.16.11.1 (F1) теперь присутствует в пути между двумя хостами.
Трафик ходит ассиметрично, как я и планировал в прошлом посте. Можно быстро глянуть трафик на линках R1-F1, R2-F2. Запускаем 1 ICMP запрос с PC1 на PC2.
Запрос от PC1 до PC2 (от R1 к F1 и обратно)
А вот ответ идет через R2
Conntrack
Я вообще такие штуки не очень люблю, но в нашем случае никуда не деться. ) Документации по этой фиче не очень много, так что я пока не уверен как она работает.
Для начала нам нужно создать простой Zone-Based firewall. Конфигурация ниже создает две зоны, добавляет в них по интерфейсу и создает дефолтную конфигурацию самих политик. На данный момент ничего не разрешено, кроме related и established соединений.
set zone-policy zone VL11 default-action 'drop'
set zone-policy zone VL11 description 'VL11'
set zone-policy zone VL11 from VL12 firewall name 'VL12-TO-VL11'
set zone-policy zone VL11 interface 'eth1.11'
set zone-policy zone VL12 default-action 'drop'
set zone-policy zone VL12 description 'VL12'
set zone-policy zone VL12 from VL11 firewall name 'VL11-TO-VL12'
set zone-policy zone VL12 interface 'eth1.12'
set firewall name VL12-TO-VL11 default-action 'drop'
set firewall name VL12-TO-VL11 enable-default-log
set firewall name VL12-TO-VL11 rule 1 action 'accept'
set firewall name VL12-TO-VL11 rule 1 state established 'enable'
set firewall name VL12-TO-VL11 rule 1 state related 'enable'
set firewall name VL12-TO-VL11 rule 2 action 'drop'
set firewall name VL12-TO-VL11 rule 2 state invalid 'enable'
set firewall name VL11-TO-VL12 default-action 'drop'
set firewall name VL11-TO-VL12 enable-default-log
set firewall name VL11-TO-VL12 rule 1 action 'accept'
set firewall name VL11-TO-VL12 rule 1 state established 'enable'
set firewall name VL11-TO-VL12 rule 1 state related 'enable'
set firewall name VL11-TO-VL12 rule 2 action 'drop'
set firewall name VL11-TO-VL12 rule 2 state invalid 'enable'
Добавим еще несколько строк, чтобы разрешить "пинги" от PC1 к PC2.
set firewall name VL11-TO-VL12 rule 10 action 'accept'
set firewall name VL11-TO-VL12 rule 10 destination address '10.0.12.12'
set firewall name VL11-TO-VL12 rule 10 protocol 'icmp'
set firewall name VL11-TO-VL12 rule 10 source address '10.0.11.11'
После коммита, пинги от PC1 до PC2 ожидаемо пропадут из-за несимметричности трафика. Это хорошо видно по счетчикам.
От PC1 к PC2 трафик проходит.
А вот обратно сбрасывается на F2, потому что у него нет правила под этот трафик. Он не related и не established.
Теперь попробуем починить эту ситуацию... Применив конфигурацию из примера я получил ошибку.
conntrack-sync error: Clustering isn’t running
Чуть-чуть погуглив, я понял что надо еще включить кластеризацию или VRRP... Но примеров я не нашел... Ok... В итоге конфигурация выглядит так. Я использую мультикаст, а не юникаст.
set cluster group Fs primary 'F1'
set cluster group Fs secondary 'F2'
set cluster interface 'eth0'
set cluster pre-shared-secret 'SECRET_KEY'
set service conntrack-sync accept-protocol 'tcp,udp,icmp'
set service conntrack-sync event-listen-queue-size '8'
set service conntrack-sync failover-mechanism cluster group 'Fs'
set service conntrack-sync interface 'eth0'
set service conntrack-sync mcast-group '225.0.0.50'
set service conntrack-sync sync-queue-size '8'
Но пинги так и не появились...
Причем в таком случае сессию видно на обоих файерволах.
Пообщался я с поддержкой и мне подсказали, что есть соответствующая опция в CLI (надо было самому поковыряться конечно...).
set service conntrack-sync disable-external-cache
Cессия теперь ставится напрямую в internal-cache и трафик наконец начинает бегать причудливым образом...
Итак, на данный момент VRRP + VRF + CONNTRACK работает. Niiiiice )
Вместо заключения
Ребята из VyOS предупредили, что в такой конфигурации могут наблюдаться странности в сети. Синхронизация сессий не происходит мгновенно, поэтому трафик может долететь до того, как файервол будет к этому готов.
Все описанное в статье не является руководство к действию. Дизайн получился специфичный.)
В следующий раз поговорим про BGP.
Ну и да, вышесказанное не имеет никакого отношения к моему работодателю.
Комментариев нет:
Отправить комментарий