Как настроить резервированную схему сети с двумя файерволами FortiGate
В этом тексте расскажем, как настроить резервированную схему сети с использованием двух файерволов (FortiGate) в разных локациях. Статья будет полезна всем, кто хочет построить отказоустойчивую инфраструктуру на уровне сети.
Подробно описанные шаги — под катом.
Какие задачи решает схема
Такое резервирование позволяет решить все перечисленные задачи одновременно:
- Использовать разнообразные платформы — выделенные серверы, облачную платформу, облако VMware — для размещения проекта.
- Объединить вычислительные ресурсы в единую изолированную сеть, защищенную от внешних угроз — например, DDoS-атак.
- Разделить проект на несколько окружений (например, Production, Staging, Testing, Development), изолированных друг от друга на уровне сети провайдера.
- Контролировать доступ как между проектами/окружениям, так и внешними сетями.
- Сделать проект максимально доступным из интернета, даже в случае выхода из строя или планового обслуживания оборудования в одном из ДЦ.
Чтобы резервирование работало, необходимо настроить не только сеть, но и инфраструктуру, на которой будут работать клиентские проекты. В этом тексте мы затронем только сетевую часть настройки.
В рассматриваемом примере мы используем:
- IaaS-продукты Selectel: выделенные серверы, облачную платформу, облако на базе VMware
- Услугу L3 VPN, которая строится на базе отдельной локальной сети Selectel, не пересекающейся с интернет-каналами.
- Разные VRF (Virtual Routing and Forwarding instance), или виртуальные маршрутизаторы, в локальной сети Selectel.
- Два файервола FortiGate, выполняющие роль пограничных роутеров и размещенные в разных городах.
- Внешнюю anycast-сеть, которая может быть доступна одновременно из разных местоположений (выдается дата-центром).
- Линковочные /29 подсети.
Итоговая схема сети выглядит так:
У нас есть роутинг-инстанс — vrf_1 (красные линии). Он объединяет вычислительные ресурсы, расположенные в Санкт-Петербурге и Москве: выделенные серверы, виртуальные машины, развернутые в облачной платформе Selectel и в облаке на базе VMware.
Для доступа к проектам из интернета выделена anycast-сеть 31.184.217.248/29.
Также выделены две внешние /29 сети для организации связи между FortiGate клиента и сетевым оборудованием провайдера. Адреса из данных сетей будут использоваться для настройки протоколов маршрутизации (Border Gateway Protocol, BGP), через которые клиент будет анонсировать свою anycast-сеть на оборудование в дата-центр. Также они могут использоваться для доступа в интернет.
Мы не используем /31 стыковочные сети, так как наш шлюз резервируется на базе технологии VRRP (подключено по умолчанию для FortiGate).
Чтобы реализовать расписанную схему, необходимо:
- Заказать необходимое количество выделенных серверов, файерволов, виртуальных машин.
- Понять, сколько изолированных виртуальных роутеров потребуется и какие серверы должны быть ими связаны.
- Определиться, сколько белых IP-адресов необходимо для доступа к клиентским сервисам из интернета.
- Заказать и настроить VRF.
- Настроить маршрутизации на клиентских серверах.
- Создать виртуальные машины с файерволами FortiGate.
- Настроить FG через CLI.
- Настроить BGP на FortiGate в локальной сети.
- Настроить BGP во внешней сети.
- Определить Master/Slave-роли для FortiGate.
- Настроить NAT на FortiGate.
- Протестировать схемы.
Заказ и настройка VRF
Мы опустим описание первых трех шагов, потому что они не связаны с настройками сети. О том, как арендовать серверы в Selectel, и что такое виртуальный роутер, можно почитать в базе знаний компании или обратиться за консультацией по почте sales@selectel.ru.
Итак, закажем необходимое количество VRF и добавим в них нужные серверы. Для этого нужно создать тикет через панель управления Selectel. Инструкция, как быстро создать локальную сеть, есть в базе знаний.
На данный момент конфигурировать такие сети можно самостоятельно через панель управления.
Мой текст тикета выглядел примерно так:
Здравствуйте!Просьба собрать L3 VPN.
Локация: облачная платформа ru-7
Проект ID: d0f49f94c5a44b1dbe82ac41d20d635a
Подсеть: 10.10.1.0/24, в качестве шлюза будет выступать адрес 10.10.1.254, для резервирования с вашей стороны можете забрать адреса 10.10.1.252–10.10.1.253
Далее адреса для шлюза и резервирования для каждой подсети будут аналогичными.Локация: облачная платформа ru-9
Проект ID: d0f49f94c5a44b1dbe82ac41d20d635a
Подсеть: 10.10.2.0/24Локация: MSK-2
VLAN:2450
Подсеть: 10.10.3.0/24Локация: SPB-5
VLAN:1303
Подсеть: 10.10.4.0/24Локация: VMware SPB
Виртуальный дата-центр: s-3327-SPB1-S1-vDC59
Подсеть: 10.10.5.0/24Локация: VMware MSK
Виртуальный дата-центр: s-3327-MSK1-S1-vDC30
Подсеть: 10.10.6.0/24
Какие изменения в инфраструктуре произойдут после этих действий?
В облачной платформе будет добавлена подсеть с доступом в локальную сеть L3 VPN. Для удобства ее можно переименовать. Чтобы изменить CIDR, потребуется оформить запрос через тикет-систему. Если вы планируете пользоваться сетью в дальнейшем, удалять ее нельзя, иначе придется заново открывать запрос на ее добавление в локальную сеть L3 VPN. Обращаем внимание, что существующую в облачной платформе подсеть добавить в L3 VPN невозможно по техническим причинам;
В облаке на базе VMware ситуация аналогичная: после заказа подсеть появится в vCloud Director.
Для выделенных серверов фиксированной конфигурации дополнительно просить о подключении локального порта не нужно. Серверы Selectel заранее подключены в обе плоскости сети — локальную и интернет.
Если у вас сервер произвольной конфигурации или вы разместили свое оборудование в Selectel (colocation), потребуется запросить подключение вашего оборудования к локальной сети Selectel через тикет
Дополнительно для построения BGP-сессий во внешней сети потребуется выделить по стандартной /29 внешней подсети для каждого файервола. В нашей схеме в
качестве примера будут использоваться сети 77.223.107.152/29 (Мск) и и 94.26.237.112/29 (СПб).
Настройка маршрутизации на клиентских серверах
Далее приступаем к базовой настройке всех серверов. Из начальных настроек нужно лишь указать адрес серверу и прописать маршрут по умолчанию в сторону шлюза, который находится на роутере Selectel.
Здесь будут полезны статьи по настройке маршрутов в L3 VPN-сети и настройке облака на базе VMware с нуля.
Создание виртуальных машин с файерволами FortiGate
В качестве файерволов мы выбрали Fortinet FortiGate (FG). Оба мы развернули из официального образа на виртуальной машине в облачной платформе. Отличий в конфигурировании виртуального и «железного» FG нет. Приступаем к развертыванию образа и настройке FG.
На что обратить внимание, если вы разворачиваете FortiOS на виртуальной машине в облачной платформе Selectel: для добавления портов в конфигурацию FG необходимо в панели управления облачной платформой на вкладке «Порты» добавить порт, затем программно перезапустить виртуальную машину с ОС FortiOS. Поэтому советуем заранее просчитать максимальное необходимое количество портов, которое потребуется для полноценной работы инфраструктуры с использованием FG.
В нашем примере потребуется добавить еще два порта (первый порт появляется, когда мы указываем его в поле «Сеть» при создании виртуальной машины).
В самой конфигурации на FG появится порт с базовой конфигурацией, адресации на нем никакой не будет. Но нужно учитывать, что определенный порт создан в определенном VLAN, подсеть которого ему назначена.
Первичная настройка FG через CLI
Продолжим настройку основной части схемы — файерволов. Первичная настройка, адресация на портах и BGP, производилась через CLI.
Итоговая конфигурация портов в CLI для FortiGate MSK будет выглядеть так:
config system interface
edit "port1"
set vdom "root"
set ip 10.10.1.200 255.255.255.0
set allowaccess ping ssh
set type physical
set snmp-index 1
next
edit "port2"
set vdom "root"
set ip 77.223.107.154 255.255.255.248
set allowaccess ping ssh http
set type physical
set snmp-index 5
next
edit "port3"
set vdom "root"
set ip 31.184.217.250 255.255.255.248
set allowaccess ping
set type physical
set snmp-index 6
next
...
end
Port 1 — располагается в локальной сети, которая прокинута в L3 VPN;
Port 2 — внешняя адресация;
Port 3 — anycast-подсеть (для анонсирования подсети в интернет, так как активных сервисов на серверах у нас пока нет).
Настройка BGP на FortiGate в локальной сети
Для поднятия BGP-сессий с L3 VPN-роутерами Selectel необходимо сделать заявку через тикет в панели управления. В нем нужно указать IP-адрес, который используется на FortiGate (в примере это 10.10.1.200 и 10.10.2.200 на FortiGate MSK).
В ответе будет следующая информация:
— IP-адреса роутеров Selectel (в примере 10.10.1.252 и 10.10.1.253);
— Selectel ASN (в примере 64530);
— Ваша ASN (в примере 65500).
Пример запроса на подключение BGP во внешней сети:
Локация: MSK-1
VLAN: 2380
IP-адрес для BGP-сессии: 212.41.3.146
Маршрутная политика: default route only
Номер AS: 52016
ID услуги: b3d3fst1a-81tt-4d12-7c77-d028526d81b0
Для поднятия сессии BGP с пограничными маршрутизаторами и L3 VPN-маршрутизаторами провайдера необходимо написать запрос в техническую поддержку.
Итоговый конфиг BGP для локальной сети:
config router bgp
set as 65500
set router-id 10.10.1.200
config neighbor
edit "10.10.1.252"
set interface "port1"
set remote-as 64530
next
edit "10.10.1.253"
set interface "port1"
set remote-as 64530
next
end
Можно также настроить BGP через neighbor-range. Это значит, что сессия поднимется с любым адресом из заданного диапазона:
config neighbor-group
edit "selectel"
set remote-as 64530
next
end
config neighbor-range
edit 2
set prefix 10.20.1.0 255.255.255.0
set neighbor-group "selectel"
next
end
Несмотря на то, что router-id отличен от того, который сконфигурирован как адрес соседа на другом конце, сессия установится в Established. В качестве router-id может быть указан внешний адрес, тогда сессии поднимутся и во внешней, и в локальной сетях. Если router-id будет содержать в себе адрес из диапазона локальных адресов, то локальные сессии поднимутся, а внешние нет.
Настройка BGP во внешней сети
Чтобы сессии установились во внешней сети, потребовалось изменить адрес router-id на внешний. Сессии в локальной сети при этом переустановились.
FG анонсирует в интернет подсеть 31.184.217.248/29 (напомним, что это anycast-подсеть) и принимает маршрут по умолчанию (0.0.0.0/0) от пограничных роутеров Selectel.
В Selectel для успешного построения BGP-сессии с бордерными роутерами необходимо:
- прописать опцию multihop (set ebgp-enforce-multihop enable),
- выставить TTL не менее 10 (set ebgp-multihop-ttl),
- прописать статический маршрут до адреса соседа (в нашем случае достаточно будет маршрута до /32 адреса).
С учетом всех вводных итоговый конфиг выглядит так:
config router bgp
set as 65500
set router-id 77.223.107.154
config neighbor
edit ""
set ebgp-enforce-multihop enable
set ebgp-multihop-ttl 10
set interface "port2"
set prefix-list-in "default_from_selectel_inet"
set prefix-list-out "anycast_subnet_out"
set remote-as 50340
next
edit ""
set ebgp-enforce-multihop enable
set ebgp-multihop-ttl 10
set interface "port2"
set prefix-list-in "default_from_selectel_inet"
set prefix-list-out "anycast_subnet_out"
set remote-as 50340
next
end
config router prefix-list
edit "anycast_subnet_out"
config rule
edit 1
set prefix 31.184.217.248 255.255.255.248
unset ge
unset le
next
edit 2
set action deny
set prefix any
unset ge
unset le
next
end
next
edit "default_from_selectel_inet"
config rule
edit 1
set prefix 0.0.0.0 0.0.0.0
unset ge
unset le
next
end
next
end
config router static
edit 4
set dst 255.255.255.255
set gateway 77.223.107.153
set device "port2"
next
edit 1
set dst 255.255.255.255
set gateway 77.223.107.153
set device "port2"
next
end
В результате мы получили следующую таблицу маршрутизации на FG:
Видим, что есть активный дефолтный маршрут, который изучен от одного из бордерных роутеров по BGP. Этот же дефолтный маршрут анонсируется в локальную сеть самим файерволом.
Так как мы добавили еще port 3 с адресом из anycast-подсети, сделаем так, чтобы данная подсеть начала анонсироваться через BGP и стала доступна из интернета. Для этого необходимо настроить редистрибуцию на FortiGate следующим образом:
config redistribute "connected"
set status enable
end
Аналогично настраиваем сессию со вторым бордерным роутером.
Таким же образом настраиваем FG в СПб.
Определение Master/Slave ролей для FortiGate
Рассматриваемая нами топология предполагает, что FortiGate работают по схеме Master/Slave. В нашем случае мастером будет FortiGate в Москве, а бэкапом — FG в Санкт-Петербурге. Это значит, что при отсутствии нештатных ситуаций в инфраструктуре, все активные сервисы будут располагаться и работать в московской части инфраструктуры.
Как обеспечить распределение ролей для FortiGate, мы описали ниже.
Применим список правил (route-map, объект, в котором указываются атрибуты для управления приоритетами маршрутов) на FG, располагающемся в Санкт-Петербурге, чтобы сделать его бэкапом во внешней и локальной сети. Для этого будем использовать:
- AS Path Prepend (во внешней сети)
- MED (в локальной сети).
Такие методы вывода одного из FG в бэкап могут игнорироваться на стороне оператора связи, в связи с особенностями конфигурации, поэтому рекомендуем уточнить у оператора связи возможность обработки отправляемых атрибутов маршрутизации для анонсируемых подсетей.
Technical Tip: BGP AS-Path Prepending Configuration Example
Настройки route-map на FG в СПб (бэкап):
config router route-map
edit "Secondary_exit"
config rule
edit 1
set set-aspath "65500 65500 65500"
unset set-ip-nexthop
unset set-ip6-nexthop
unset set-ip6-nexthop-local
unset set-originator-id
next
end
next
edit "Secondary_exit_local"
config rule
edit 1
unset set-ip-nexthop
unset set-ip6-nexthop
unset set-ip6-nexthop-local
set set-metric 500
unset set-originator-id
next
end
next
end
В это время активный маршрут до anycast-подсети 31.184.217.248/29 ведет на московский FG.
Настройка NAT на FortiGate
Далее для упрощения конфигурирования правил NAT можно перейти в WEB панель FG.
Настраиваем SNAT (механизм подмены адреса источника пакета):
Метод: One-to-one (механизм подмены локального адреса на внешний).
Внешний адрес: адрес из anycast-подсети.
Настраиваем DNAT (механизм подмены адреса назначения пакета):
В данном примере 10.10.6.2 — это адрес виртуальной машины в VMware.
P.S: На FG DST NAT называется VIP (Virtual IPs).
Настройка Firewall Policy на FortiGate
Создаем необходимые файервольные правила для прохождения трафика из интернета в локальную сеть и обратно.
Те же настройки нужно будет добавить на FG в СПб.
Пример настроек из примера выше в CLI:
config firewall policy
edit 1
set name "LAN_to_WAN"
set uuid f122f4a0-d40d-51eb-13d6-2bcda4bbb967
set srcintf "port1"
set dstintf "port2"
set srcaddr "lan_vrf_1"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL_TCP" "PING" "SSH" "TRACEROUTE"
set ippool enable
set poolname "snat"
set nat enable
next
edit 2
set name "WAN_to_LAN"
set uuid 19ad41c8-d40e-51eb-5332-1b1f167774ff
set srcintf "port2"
set dstintf "port1"
set srcaddr "all"
set dstaddr "WAN_to_LAN_31.184.217.252"
set action accept
set schedule "always"
set service "ALL_TCP" "PING" "SSH" "TRACEROUTE"
set fixedport enable
set nat enable
next
end
lan_vrf_1 — это подсеть 10.10.0.0/16.
edit "lan_vrf_1"
set uuid c90d6cf2-d40d-51eb-9a1d-554fdb82ae1d
set subnet 10.10.0.0 255.255.0.0
next
end
WAN_to_LAN_31.184.217.252 — это правило DST NAT.
config firewall vip
edit "WAN_to_LAN_31.184.217.252"
set uuid b767c3a0-3b2b-51ec-b73d-62bc3b513471
set extip 31.184.217.252
set mappedip "10.10.6.2"
set extintf "any"
set portforward enable
set protocol icmp
next
end
Это не все настройки, которые необходимо сделать на файерволах. В связи с некоторыми багами, с которыми мы столкнулись во время тестирования схемы, придется дополнительно изменить некоторые настройки по умолчанию. Подробнее об этом ниже.
Тестирование схемы (часть 1)
На схеме FortiGate в Санкт-Петербурге является бэкапом (мы настроили такое поведение в разделе «Определение Master/Slave ролей для FortiGate»), и все активные маршруты ведут на FortiGate в Москве.
Рассмотрим схему в действии с разных сторон.
Сначала посмотрим влияние отключения мастер-файервола, располагающегося в Москве, для серверов/виртуальных машин, находящихся в локальной сети, и на их возможность выходить в интернет.
Возьмем, например, железный сервер в СПб (10.10.4.2) и виртуальную машину в Москве в облаке VMware (10.10.6.2).
10.10.4.2
10.10.6.2
Сейчас на этих машинах есть доступ в интернет. Между собой машины также могут обмениваться трафиком по локальной сети.
10.10.4.2:
10.10.6.2:
Трафик в интернет идет через файервол. Внешних адресов на этих серверах нет.
10.10.4.2:
10.10.6.2:
Проверяем отсутствие возможности у серверов выйти в интернет при отключении файервола в Москве (мастер-файервол). На машинах запущена команда «ping 8.8.8.8».
Отключаем файервол в панели управления:
Результаты запуска утилиты ping:
с машины 10.10.4.2:
с машины 10.10.6.2:
Трассировка до отключения (слева) и после (справа) московского FortiGate:
с машины 10.10.4.2:
с машины 10.10.6.2:
Видим, что трафик после отключения московского мастер-файервола пошел через резервный FG, расположенный в СПб.
Тестируем возвращение мастер-файервола.
Результаты пинга 8.8.8.8:
с машины 10.10.4.2:
с машины 10.10.6.2:
По трассировкам будет видна обратная ситуация: сначала трафик шел через СПб, потом ушел в МСК.
Фиксируем приличные потери. Это происходит потому, что сессия в интернет-сети поднимается на долю секунды быстрее, чем в локальной сети. Поэтому дефолтный маршрут (0.0.0.0/0) начинает анонсироваться в локальную сеть только при следующем сообщении BGP update. По дефолту на FG таймер анонсирования подсетей равен 30 секундам. Чтобы уменьшить время даунтайма, выставим таймер в 2 секунды на московском FG для соседей в локальной сети.
Настройка таймера:
config neighbor
Description: BGP neighbor table.
edit
set advertisement-interval {integer}
Итоговый конфиг для соседей в локальной сети:
config router bgp
set as 65500
set router-id *белый IP-адрес*
config neighbor
edit "10.10.1.252"
set advertisement-interval 2
set interface "port1"
set remote-as 64530
next
edit "10.10.1.253"
set advertisement-interval 2
set interface "port1"
set remote-as 64530
next
end
Повторим тестирование и снимем результаты доступности внешего ресурса 8.8.8.8 после включения московского файервола.
Результаты пинга 8.8.8.8:
10.10.4.2:
10.10.6.2:
Вероятно, изменение таймеров — не самое лучшее решение проблемы, но оперативно найти и применить какой-либо другой workaround не удалось.
Тестирование схемы (часть 2)
Далее проверим доступность сервисов, которые работают на серверах и виртуальных машинах в локальной сети, из интернета.
Для простоты представим, что на виртуальной машине в Москве 10.10.6.2 крутится сервис, который транслируется через NAT на anycast-адрес 31.184.217.252.
На обоих файерволах настроено одно и то же правило DST NAT:
Из любой сети (домашняя/офисная/другая) ставим на ping адрес 31.184.217.252 и/или запускаем трассировку.
Выключаем мастер FG (московский) через панель управления, тем самым имитируем аварию/работы.
Спустя несколько миллисекунд во внешней сети маршрут перестраивается, и теперь anycast-подсеть доступна через петербургский FG.
Слева — до отключения FG в МСК, справа — после.
Результаты пинга:
Включаем московский FG в панели управления.
Получаем следующий результат утилиты ping:
Заключение
Мы описали сборку и базовую настройку отказоустойчивой схемы сети с использованием файерволов (Fortinet FortiGate) в разных регионах. Безусловно, все достоинства данной схемы сложно продемонстрировать в одном тексте. Какие-то функции вы можете «подкрутить» или подключить самостоятельно, что даст возможность более гибко подстроить текущую схему под ваши цели и задачи.
На данный момент описанная схема уже эксплуатируется в реальных проектах на сети Selectel.
Если возникнут вопросы или предложения по дополнению и улучшению схемы, пишите в комментарии. Кроме того, если вы клиент Selectel или хотите им стать, сотрудники компании помогут развернуть такую архитектуру в рамках услуги Managed Services.