Fortigate настройка двух провайдеров
В данной инструкции расскажем, как настроить резервированную схему сети с использованием двух файерволов (FortiGate) в разных локациях на инфраструктуре Selectel.
Статья будет полезна всем, кто хочет построить отказоустойчивую инфраструктуру на уровне сети. Такая схема резервирования позволяет решить все перечисленные ниже задачи одновременно:
- Использовать разнообразные платформы — выделенные серверы, облачную платформу, облако VMware — для размещения проекта.
- Объединить вычислительные ресурсы в единую изолированную сеть, защищенную от внешних угроз — например, DDoS-атак.
- Разделить проект на несколько окружений (например, Production, Staging, Testing, Development), изолированных друг от друга на уровне сети провайдера.
- Контролировать доступ как между проектами/окружениям, так и внешними сетями.
- Сделать проект максимально доступным из интернета, даже в случае выхода из строя или планового обслуживания оборудования в одном из ДЦ.
Чтобы резервирование работало, необходимо настроить не только сеть, но и инфраструктуру, на которой будут работать клиентские проекты. В этом тексте мы затронем только сетевую часть настройки.
В рассматриваемом примере мы используем:
- IaaS-продукты Selectel.
- Услугу 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.
- Протестировать схемы.
Настройка Firewall Policy на FortiGate
Создаем необходимые файервольные правила для прохождения трафика из интернета в локальную сеть и обратно.
Те же настройки нужно будет добавить на FG в СПб.
Пример настроек из примера выше в CLI:
lan_vrf_1 — это подсеть 10.10.0.0/16.
WAN_to_LAN_31.184.217.252 — это правило DST NAT.
Это не все настройки, которые необходимо сделать на файерволах. В связи с некоторыми багами, с которыми мы столкнулись во время тестирования схемы, придется дополнительно изменить некоторые настройки по умолчанию. Подробнее об этом ниже.
Настройка NAT на FortiGate
Далее для упрощения конфигурирования правил NAT можно перейти в WEB панель FG.
Настраиваем SNAT (механизм подмены адреса источника пакета):
Метод: One-to-one (механизм подмены локального адреса на внешний).
Внешний адрес: адрес из anycast-подсети.
Настраиваем DNAT (механизм подмены адреса назначения пакета):
В данном примере 10.10.6.2 — это адрес виртуальной машины в VMware.
P.S: На FG DST NAT называется VIP (Virtual IPs).
Настройка NAT на FortiGate
Далее для упрощения конфигурирования правил NAT можно перейти в WEB панель FG.
Настраиваем SNAT (механизм подмены адреса источника пакета):
Метод: One-to-one (механизм подмены локального адреса на внешний).
Внешний адрес: адрес из anycast-подсети.
Настраиваем DNAT (механизм подмены адреса назначения пакета):
В данном примере 10.10.6.2 — это адрес виртуальной машины в VMware.
P.S: На FG DST NAT называется VIP (Virtual IPs).
Тестирование схемы (часть 1)
На схеме FortiGate в Санкт-Петербурге является бэкапом (мы настроили такое поведение в разделе «Определение Master/Slave ролей для FortiGate»), и все активные маршруты ведут на FortiGate в Москве.
Рассмотрим схему в действии с разных сторон.
Сначала посмотрим влияние отключения мастер-файервола, располагающегося в Москве, для серверов/виртуальных машин, находящихся в локальной сети, и на их возможность выходить в интернет.
Возьмем, например, железный сервер в СПб (10.10.4.2) и виртуальную машину в Москве в облаке VMware (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:
По трассировкам будет видна обратная ситуация: сначала трафик шел через СПб, потом ушел в МСК.
Итоговый конфиг для соседей в локальной сети:
Повторим тестирование и снимем результаты доступности внешего ресурса 8.8.8.8 после включения московского файервола.
Результаты пинга 8.8.8.8:
Вероятно, изменение таймеров — не самое лучшее решение проблемы, но оперативно найти и применить какой-либо другой workaround не удалось.
Какие задачи решает схема
Такое резервирование позволяет решить все перечисленные задачи одновременно:
- Использовать разнообразные платформы — выделенные серверы, облачную платформу, облако VMware — для размещения проекта.
- Объединить вычислительные ресурсы в единую изолированную сеть, защищенную от внешних угроз — например, DDoS-атак.
- Разделить проект на несколько окружений (например, Production, Staging, Testing, Development), изолированных друг от друга на уровне сети провайдера.
- Контролировать доступ как между проектами/окружениям, так и внешними сетями.
- Сделать проект максимально доступным из интернета, даже в случае выхода из строя или планового обслуживания оборудования в одном из ДЦ.
В рассматриваемом примере мы используем:
У нас есть роутинг-инстанс — 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.
- Протестировать схемы.
Тестирование схемы (часть 2)
Далее проверим доступность сервисов, которые работают на серверах и виртуальных машинах в локальной сети, из интернета.
Для простоты представим, что на виртуальной машине в Москве 10.10.6.2 крутится сервис, который транслируется через NAT на anycast-адрес 31.184.217.252.
На обоих файерволах настроено одно и то же правило DST NAT:
Из любой сети (домашняя/офисная/другая) ставим на ping адрес 31.184.217.252 и/или запускаем трассировку.
Выключаем мастер FG (московский) через панель управления, тем самым имитируем аварию/работы.
Спустя несколько миллисекунд во внешней сети маршрут перестраивается, и теперь anycast-подсеть доступна через петербургский FG.
Слева — до отключения FG в МСК, справа — после.
Включаем московский FG в панели управления.
Получаем следующий результат утилиты ping:
Настройка Firewall Policy на FortiGate
Создаем необходимые файервольные правила для прохождения трафика из интернета в локальную сеть и обратно.
Те же настройки нужно будет добавить на FG в СПб.
Пример настроек из примера выше в CLI:
lan_vrf_1 — это подсеть 10.10.0.0/16.
WAN_to_LAN_31.184.217.252 — это правило DST NAT.
Это не все настройки, которые необходимо сделать на файерволах. В связи с некоторыми багами, с которыми мы столкнулись во время тестирования схемы, придется дополнительно изменить некоторые настройки по умолчанию. Подробнее об этом ниже.
Заказ и настройка VRF
Итак, закажем необходимое количество 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 (СПб).
Тестирование схемы (часть 2)
Далее проверим доступность сервисов, которые работают на серверах и виртуальных машинах в локальной сети, из интернета.
Для простоты представим, что на виртуальной машине в Москве 10.10.6.2 крутится сервис, который транслируется через NAT на anycast-адрес 31.184.217.252.
На обоих файерволах настроено одно и то же правило DST NAT:
Из любой сети (домашняя/офисная/другая) ставим на ping адрес 31.184.217.252 и/или запускаем трассировку.
Выключаем мастер FG (московский) через панель управления, тем самым имитируем аварию/работы.
Спустя несколько миллисекунд во внешней сети маршрут перестраивается, и теперь anycast-подсеть доступна через петербургский FG.
Слева — до отключения FG в МСК, справа — после.
Включаем московский FG в панели управления.
Получаем следующий результат утилиты ping:
Тестирование схемы (часть 1)
На схеме FortiGate в Санкт-Петербурге является бэкапом (мы настроили такое поведение в разделе «Определение Master/Slave ролей для FortiGate» ), и все активные маршруты ведут на FortiGate в Москве.
Рассмотрим схему в действии с разных сторон.
Сначала посмотрим влияние отключения мастер-файервола, располагающегося в Москве, для серверов/виртуальных машин, находящихся в локальной сети, и на их возможность выходить в интернет.
Возьмем, например, железный сервер в СПб (10.10.4.2) и виртуальную машину в Москве в облаке VMware (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:
По трассировкам будет видна обратная ситуация: сначала трафик шел через СПб, потом ушел в МСК.
Итоговый конфиг для соседей в локальной сети:
Повторим тестирование и снимем результаты доступности внешего ресурса 8.8.8.8 после включения московского файервола.
Результаты пинга 8.8.8.8:
Вероятно, изменение таймеров — не самое лучшее решение проблемы, но оперативно найти и применить какой-либо другой workaround не удалось.
Определение Master/Slave ролей для FortiGate
Рассматриваемая нами топология предполагает, что FortiGate работают по схеме Master/Slave. В нашем случае мастером будет FortiGate в Москве, а бэкапом — FG в Санкт-Петербурге. Это значит, что при отсутствии нештатных ситуаций в инфраструктуре, все активные сервисы будут располагаться и работать в московской части инфраструктуры.
Как обеспечить распределение ролей для FortiGate, мы описали ниже.
Применим список правил (route-map, объект, в котором указываются атрибуты для управления приоритетами маршрутов) на FG, располагающемся в Санкт-Петербурге, чтобы сделать его бэкапом во внешней и локальной сети. Для этого будем использовать:
- AS Path Prepend (во внешней сети)
- MED (в локальной сети).
Настройки route-map на FG в СПб (бэкап):
В это время активный маршрут до anycast-подсети 31.184.217.248/29 ведет на московский FG.
Первичная настройка FG через CLI
Продолжим настройку основной части схемы — файерволов. Первичная настройка, адресация на портах и BGP, производилась через CLI.
Итоговая конфигурация портов в CLI для FortiGate MSK будет выглядеть так:
Port 1 — располагается в локальной сети, которая прокинута в L3 VPN;
Port 2 — внешняя адресация;
Port 3 — anycast-подсеть (для анонсирования подсети в интернет, так как активных сервисов на серверах у нас пока нет).
Scenario 1: Link redundancy and no load-sharing
Link redundancy ensures that if your Internet access is no longer available through a certain port, the FortiGate uses an alternate port to connect to the Internet.
In this scenario, two interfaces, WAN1 and WAN2, are connected to the Internet using two different ISPs. WAN1 is the primary connection. In the event of a failure of WAN1, WAN2 automatically becomes the connection to the Internet. For this configuration to function correctly, you must configure the following settings:
- Link health monitor: To determine when the primary interface (WAN1) is down and when the connection returns.
- Routing: Configure a default route for each interface.
- Security policies: Configure security policies to allow traffic through each interface to the internal network.
Настройка 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 во внешней сети:
Для поднятия сессии BGP с пограничными маршрутизаторами и L3 VPN-маршрутизаторами провайдера необходимо написать запрос в техническую поддержку.
Итоговый конфиг BGP для локальной сети:
Можно также настроить BGP через neighbor-range. Это значит, что сессия поднимется с любым адресом из заданного диапазона:
Несмотря на то, что router-id отличен от того, который сконфигурирован как адрес соседа на другом конце, сессия установится в Established. В качестве router-id может быть указан внешний адрес, тогда сессии поднимутся и во внешней, и в локальной сетях. Если router-id будет содержать в себе адрес из диапазона локальных адресов, то локальные сессии поднимутся, а внешние нет.
Заключение
Мы описали сборку и базовую настройку отказоустойчивой схемы сети с использованием файерволов (Fortinet FortiGate) в разных регионах. Безусловно, все достоинства данной схемы сложно продемонстрировать в одном тексте. Какие-то функции вы можете «подкрутить» или подключить самостоятельно, что даст возможность более гибко подстроить текущую схему под ваши цели и задачи.
На данный момент описанная схема уже эксплуатируется в реальных проектах на сети Selectel.
Если возникнут вопросы или предложения по дополнению и улучшению схемы, пишите в комментарии. Кроме того, если вы клиент Selectel или хотите им стать, сотрудники компании помогут развернуть такую архитектуру в рамках услуги Managed Services.
1 Подключение межсетевого экрана Fortigate к двум интернет провайдерам для обеспечения отказоустойчивого подключения к Интернет Задача Подключить резервное Интернет соединение к устройству FortiGate, таким образом чтобы в момент выхода из строя основного Интернет подключения, часть либо весь трафик автоматически переключается на резервное Интернет подключение. Как только основное Интернет подключение восстановлено, трафик автоматически должен переключиться на основной канал. Решение Видео: Ниже описана процедура настройки отказоустойчивого подключения с использованием двух интернет каналов. В решении основной канал подключен к интерфейсу wan1 устройства с использованием статического IP адреса. Резервный канал подключен в интерфейсу wan2, IP адрес которого назначается по протоколу DHCP. Для того чтобы разрешить прохождение трафика из сети internal через интерфейс wan1, необходимо создать политику безопасности. Также необходимо создать дополнительную политику безопасности для прохождения трафика из сети internal через интерфейс wan2. Примечание: можно значительно сократить объемы трафика по резервирующему wan2 интерфейсу используя ограничение полосы пропускания и веб-фильтрацию FortiGuard для не приоритетных веб- сайтов. Также можно использовать функцию контроля приложений для установки ограничений использования резервного интерфейса.
2 Настройка основного Интернет подключения (интерфейс wan1). 1. Подключите интерфейс wan1 устройства к оборудованию основного интернет провайдера. Подключите внутреннюю сеть к интерфейсу internal. 2. Используя ПК из внутренней сети подключитесь к веб интерфейсу устройства (IP адрес по умолчанию ) используя логин admin без пароля. 3. Зайдите в меню System->Network->Interface->Edit, выберите интерфейс wan1 и измените следующие настройки: Addressing mode Manual IP/Netmask / Зайдите в меню System->Network->Interface->Edit, выберите интерфейс internal и измените следующие настройки: Addressing mode Manual IP/Netmask /
3 5. Зайдите в меню Router->Static->Static Route, выберите Create New и добаввьте маршрут по умолчанию: Destination IP/Mask / Device wan1 IP/Netmask Зайдите в меню System->Network->DNS, добавьте DNS сервера в полях Primary и Secondary. 7. Для того чтобы добавить политику безопасности, которая разрешает пользователям внутренней сети получать доступ к сети Интернет через интерфейс wan1, зайдите в меню Policy->Policy, выберите пункт Create New->Policy Примечание: в некоторых моделях FortiGate данная политика присутствует в заводской конфигурации. Если политика присутствует, пропустите этот пункт Source interface/zone Source address Internal All Destination Interface/Zone wan1 Destination Address Schedule Service Action All always ANY ACCEPT 8. Включите Enable NAT и Use Destination Interface Address 9. Для сохранения настроек нажмите кнопку OK Настройка резервного Интернет подключения через интерфейс wan2 1. Подключите интерфейс wan2 устройства к оборудованию резервного интернет провайдера.
4 2. Подключитесь к веб-интерфейсу устройства. 3. Зайдите в меню System -> Network -> Interface->Edit, выберите интерфейс wan2. 4. Установите параметр Addressing Mode->DHCP и выберите параметр Retrieve Default Gateway. Отключите параметр Override Internal DNS. 5. Для сохранения настроек нажмите кнопку OK Если физическое подключение сделано правильно, на интерфейс wan2 должен быть назначен IP адрес от DHCP сервера. Данная операция может занять несколько минут. Для проверки состояния воспользуйтесь ссылкой Status. Полученный адрес должен появиться в статусной строке Obtained IP/Netmask. Если DHCP сервер передает адреса DNS серверов, они также должны появиться в статусной строке. Внимание!: убедитесь что параметр Retrieve Default Gateway from server активирован и маршрут по умолчанию появился в таблице маршрутизации. Обычно в резервируемых конфигурациях должен быть включен параметр Override Internal DNS, поскольку нет необходимости использовать DNS сервера резервного интернет провайдера 6. Для того чтобы добавить политику безопасности, которая разрешает пользователям внутренней сети получить доступ к сети Интернет через интерфейс wan2, зайдите в меню Policy->Policy, выберите пункт Create New->Policy Source interface/zone Source address Destination Internal All wan2
5 Interface/Zone Destination Address Schedule Service Action All always ANY ACCEPT 7. Включите Enable NAT и Use Destination Interface Address. 8. Для сохранения настроек нажмите кнопку OK Настройка шлюза по умолчанию через интерфейс wan1 как приоритетный маршрут, а также настройка ping серверов для интерфейсов wan1 и wan2 На устройстве FortiGate должны быть настроены два маршрута по умолчанию, один направляет трафик через интерфейс wan1, второй, через интерфейс wan2. Примечание: поскольку маршрут по умолчанию для интерфейса wan2 устройство получает от интернет провайдера по протоколу DHCP, необходимо отредактировать интерфейс wan2 и изменить дистанцию для маршрута. 1. Зайдите в меню Router->Static->Static Route. Отредактируйте(Edit) маршрут по умолчанию для интерфейса wan1, выберите пункт Advanced и установите значение параметра Distance в Зайдите в меню System->Network->Interface. Отредактируйте интерфейс wlan2 и установите параметр Distance в 20 (либо любое другое значение больше 10). 3. Используйте функции мониторинга меню Router->Monitor->Routing Monitor для проверки какой маршрут по умолчанию используется. Неиспользуемые маршруты не появляются в таблице маршрутизации. В примере ниже виден только статический маршрут(дистанция 10) через интерфейс wan1. Примечание: если установить на интерфейсе wan2 меньшую дистанцию (например 5), шлюз по умолчанию интерфейса wan1 будет удален, а в списке появится шлюз по умолчанию интерфейса wan2. Также можно использовать одинаковую дистанцию для обоих маршрутов по умолчанию(например 10). В таком случае будут использоваться оба маршрута по алгоритму маршрутизации множественных путей(ecmp). Активные сессии будут балансироваться по обоим интерфейсам. 4. Зайдите в меню Router->Static->Settings->Create New, добавьте ping сервер для интерфейса wan1:
6 Interface wan1 Ping Server Detect Protocol Ping interval(seconds) ICMP Ping 5 Failover thershold 5 5. Выберите Create New и добавьте ping сервер для интерфейса wan2. Interface Результаты wan2 Ping Server Detect Protocol Ping interval(seconds) ICMP Ping 5 Failover thershold 5 Если IP адрес ping сервера wan1 доступен, то в мониторе маршрутов будет доступен маршрут по умолчанию интерфейса wan1. Весь трафик маршрутизируется в Интернет через интерфейс wan1. Для проверки можно использовать монитор маршрутов либо с помощью счетчика Count политик internal->wan1 и internal->wan2 в меню Policy->Policy. Счетчик политики internal->wan1 должен расти. Счетчик политики internal->wan2 не будет изменяться. Если ping сервер wan1 перестал быть доступным, (это можно проверить физически отключив кабель из интерфейса wan1), маршрут по умолчанию должен измениться на интерфейс wan2: Данное событие должно быть отображено в отчете событий: :16:39 log_id= type=event subtype=system pri=critical vd=root interface="wan1" status=down msg="ping peer: ( > ping down)" Попробуйте подключиться к какому либо Интернет ресурсу, в тот момент когда соединение wan2 активно. Если вы можете подключиться, это является
7 подтверждением того что устройство настроено правильно. Проверьте счетчик политики безопасности internal->wan2. Значения счетчика должны возрастать. Восстановите wan1 соединение. Ping сервер должен определить, что основное Интернет соединение восстановлено и изменит маршрут по умолчанию на wan1. Все новые сессии будут маршрутизироваться через это соединение. Текущие сессии, пока не будут завершены, продолжат работать через интерфейс wan2. Примечание: во время переключения на резервное соединение, входящие сессии полученные VIP политикой безопасности с интерфейса wan1 до переключения будут быть пересланы через интерфейс wan2 после переключения. Исходящие сессии инициированные сервером через VIP политику безопасности будут иметь исходящий IP адрес того интерфейса, который на данный момент является активным. Включение ECMP на резервном Интернет соединении Сценарий описанный выше должен успешно работать для большинства сетей. Однако во избежание ложных срабатываний переключения (например в моменты кратковременных обрывов связи) рекомендуется активировать алгоритм ECMP. Для реализации ECMP конфигурации необходимо настроить одинаковую дистанцию на обоих соединениях и указать приоритет маршрутов. Маршрут который имеет приоритет ниже является лучшим. Измените конфигурацию следующим образом: 1. Зайдите в меню Router->Static->Static Route, выберите Edit для маршрута wan1. 2. Выберите пункт Advanced и установите параметры Distance в 10, Priority в Используя интерфейс командной строки(cli) измените дистанцию и приоритет для интерфейса wan2: config system interface edit wan2 set distance 10 set priority 20 end Имея самый низкий приоритет интерфейс wan1 определяется как основной нмаршрут и весь трафик из приватной сети маршрутизируется через интерфейс wan1. Примечание: если в маршрутах wan1 и wan2 настроены разные дистанции, ответы на входящий Интернет трафик может присылать только интерфейс с меньшей дистанцией(wan1). Если входящее соединение установлено через интерфейс wan1, оно будет разорвано в момент отказа. После кратковременного прерывания соединение будет автоматически восстановлено через интерфейс wan2. Соединение будет разорвано второй раз, как только wan1 соединение будет восстановлено, поскольку после переключения на основной канал прохождение трафика через интерфейс wan2 будет невозможно. Если алгоритм ECMP активирован, оба интерфейса будут всегда активны. Соединение будет разорвано если произошел сбой соединения wan1, но после восстановления
8 работоспособности будет продолжать работать через интерфейс wan2. Таким образом разрыв соединения произойдет только один раз.
Dual internet connections, also referred to as dual WAN or redundant internet connections, refers to using two FortiGate interfaces to connect to the Internet. This is generally accomplished with SD-WAN, but this legacy solution provides the means to configure dual WAN without using SD-WAN. You can use dual internet connections in several ways:
- Link redundancy: If one interface goes down, the second interface automatically becomes the main connection.
- Load sharing: This ensures better throughput.
- Use a combination of link redundancy and load sharing.
This section describes the following dual internet connection scenarios:
Заключение
Мы описали сборку и базовую настройку отказоустойчивой схемы сети с использованием файерволов (Fortinet FortiGate) в разных регионах. Безусловно, все достоинства данной схемы сложно продемонстрировать в одном тексте. Какие-то функции вы можете «подкрутить» или подключить самостоятельно, что даст возможность более гибко подстроить текущую схему под ваши цели и задачи.
На данный момент описанная схема уже эксплуатируется в реальных проектах на сети Selectel.
Если возникнут вопросы или предложения по дополнению и улучшению схемы, пишите в комментарии. Кроме того, если вы клиент Selectel или хотите им стать, сотрудники компании помогут развернуть такую архитектуру в рамках услуги Managed Services.
Как можно попасть на Камчатку и полюбоваться Тихим океаном, попробовать краба и посмотреть вулканы? Можно несколько месяцев планировать отпуск, подобрать удобный рейс, гостиницу под свой вкус, а можно и за два дня 一 если получить недовольный звонок клиента, у которого от сети отваливаются филиалы на Дальнем Востоке. Проблема плавающая, причина непонятная 一 поэтому, говорят, приезжайте, посмотрите нашу природу, попробуете местные деликатесы. Если останутся время и силы.
Хотим оставить подобные истории на уровне баек из курилки, поэтому стали перебирать решения и пришли к идее, что пора осваивать программно-определяемые сети (SD-WAN). Для этого мы обратились к оборудованию, которое хорошо знаем по другим проектам: взяли сетевые экраны Fortinet c поддержкой SD-WAN и протестировали на них несколько популярных запросов от клиентов. Посмотрели, как можно разворачивать распределенную сеть и управлять ею через общий веб-интерфейс, и расписали результаты тестов и наше мнение о возможностях этого оборудования.
Концепция SD-WAN началась с идеи сделать контроль удалённых сетей проще и получить возможность управлять (в т. ч. автоматически) передачей данных в любой точке планеты. Идея подразумевает также удалённую настройку сетевых устройств через облачную среду или управляющее устройство: вместо десяти умных и мощных роутеров используем десять slave-устройств, управляемых из единого центра.
Такая идея красиво и просто звучит на уровне буклетов, но мы работаем сразу с несколькими производителями (Cisco, Fortinet, Huawei, Versa Networks, VMware) и видим, что концепцию SD-WAN каждый бренд трактует и реализует по-своему. Из-за этого нельзя объединять оборудование разных производителей, а у каждой реализации есть свои особенности, о которых нужно знать до того, как придётся всё исправлять.
В последнее время основное требование у наших клиентов 一 это безопасность. В таких случаях мы часто используем FortiGate'ы. Их фишка — отслеживание несанкционированной активности внутри сети, управление трафиком отдельных приложений и гибкое создание правил, за что его и любят безопасники. Добавим сюда сетевые правила SD-WAN (это будет выглядеть максимально естественно) и получим очень любопытное решение.
Работа с любым вендором начинается со стенда: во-первых, это интересно, во-вторых — позволяет избежать ситуации, когда посреди казахских степей обнаруживается, что какая-то важная функция не работает.
- FortiManager, FMG-VM-Base.
- FortiGate (виртуальные), FG-VM02.
Мы смоделировали сеть, связывающую головной офис и два удалённых филиала. Они соединены через два виртуальных ISP, характеристики подключения которых мы можем менять. Одна линия эмулирует подключение филиала к публичному интернету, а другая — к каналу VPN. Это означает, что у нас две разные WAN-среды подключения к двум разным провайдерам (ISP). А где есть разделение на две сети в одной подсети — там и разделение на две разных политики работы.
Представьте, что далеко в горах в полузаброшенном отеле «Оверлук» вам нужно развернуть сеть, на которой будут работать видеонаблюдение, телефония, несколько кассовых аппаратов и много чего ещё. Сеть нужна «ещё вчера», а таких точек много. Всё осложняется тем, что разумной жизни (хотя бы уровня CCNA) рядом нет.
Тут важны скорость и удобство развёртывания, поэтому нас будет интересовать, как у Fortinet реализуется функция ZTP (Zero Touch Provisioning). Она позволяет добавить оборудование в систему и настроить по серийному номеру, а созданная конфигурация автоматически загрузится при первом подключении к сети. Устройство само найдёт сервер управления, подключится и скачает настройки.
Мы начали тестирование с проверки ZTP - в галерее мы покажем по шагам, что делали и как вели себя FortiGate’ы.
ZTP мы хотели использовать для минимизации усилий, но, как показало дальнейшее исследование в лаборатории, такой подход возможен только на заводской конфигурации (мы же помним про особенности каждого бренда). Это можно проверить в CLI, отследив значение специального бита config-touched. Делаем запрос к одному из наших FortiGate-40F, видим значение «0», т. е. конфигурация заводская, всё в порядке.
Подключаем FortiGate-40F сетевым интерфейсом в сегмент с рабочим DHCP-сервером и доступом в интернет. Запускаем tcpdump и видим, что FortiGate запрашивает и получает DHCP-опцию 240 (IP-адрес FortiManager):
Проверяем конфигурацию на предмет добавления соответствующих строчек. Видим, что IP-адрес на интерфейсе и IP-адрес системы управления FortiManager успешно сконфигурированы.
На данном этапе FortiGate пытается установить связь с системой управления и уже должен быть обнаружен ею и добавлен в список неавторизованных устройств. Проверяем: устройство присутствует в списке Unauthorized Devices, как и ожидалось. Выполняем его авторизацию.
Оборудование готово к дальнейшим настройкам: централизованному обновлению ПО, установке политик безопасности и шаблонов конфигураций. Альтернативой ZTP является использование для загрузки стартовой конфигурации USB-флешек, — это не так удобно, как ZTP, но подойдёт в случаях, когда со стороны провайдеров нет поддержки автоматической конфигурации внешних интерфейсов. В любом случае это удобнее, чем ехать на объект и настраивать всё руками.
Продолжаем наш штурм гор: объект доступен, теперь нужно минимизировать потерю данных между ним и центральным офисом. У Fortinet для таких случаев есть механизм FEC (Forward Error Correction), позволяющий добавлять к передаваемым пакетам некоторое количество избыточных, что даёт возможность восстановить на принимающей стороне потерянные. Альтернативный вариант: механизм DUP, при котором трафик передаётся по основному каналу и дублируется по одному или сразу нескольким резервным.
В качестве тестовой передачи запустим (и примем) трансляцию видеоролика с использованием VLC media player. Транслировать будем с тестовой рабочей станции в центральном офисе в сторону удалённого офиса. Трафик будет отправляться в режиме unicast по протоколу UDP. Потери на канале будем вносить с использованием ПО WANem.
- Посмотрим эффект от FEC. Тест будем считать пройденным, если получим приемлемое качество работы при нестабильном канале. Параллельно проверим, появился ли адаптивный FEC (мечтать не вредно), какой максимальный процент потерь (и джиттер) может скорректировать FEC.
- Проверим, как отображается картинка ролика. Изучим размер избыточности трафика, который при этом возникает, а также узнаем, соответствуют ли теоретические расчёты результатам на практике.
- Рассчитаем нагрузку на CPU/ASIC оборудования, проведём тест на DUP (дупликацию), проверим возможность нормальной работы на двух плохих каналах.
Теперь включаем FEC на туннельных интерфейсах FortiGate с обеих сторон в настройках фазы 1 IKE (параметры fec-…).
После пересогласования туннелей снова проверяем картинку. Теперь никаких рассыпаний и прочих артефактов нет. Звери снова уродливые, но помехи на канале тут ни при чём.
Очевидный минус этой функции — пропускная способность канала, которой мы будем с FEC стабильно жертвовать ради передачи избыточных пакетов. Попытка найти настройки адаптивного FEC в интерфейсе провалилась, но это неудивительно. Увидеть реализацию такой функциональности на практике нам пока не доводилось.
В целом можно подбирать параметры (fec-base, fec-redundant) в зависимости от значения текущих потерь на канале и целевых, т. е. тех, которые нас устроят. Существуют готовые скрипты для расчётов (требуется знание китайского). В нашем случае использовались параметры fec-base=20, fec-redundant=6 и до 1% исходных потерь на канале. При такой конфигурации мы получаем менее 0,0001% целевых потерь при избыточной загрузке канала от 30 до 40%.
Механизм дупликации пакетов DUP в каком-то смысле может быть альтернативой FEC. При его настройке не требуется переустановление туннелей, т. к. данные настройки выполняются в конфигурации SD-WAN:
Включаем в конфиге DUP. После включения технологии на обоих FortiGate проверяем статус загрузки каналов на FortiGate приёмной стороны.
Видим, что по обоим каналам входящая загрузка одинаковая, что намекает на наличие дублированных пакетов.
Снова включаем потери в размере 1% на канале. И после включения DUP картинка в VLC на приёме не восстанавливается. Возможно, это связано с работой механизма дедупликации на принимающей стороне, т. е. при удалении дубликатов пакетов или с изменением порядка следования пакетов после дедупликации при приёме их на рабочей станции. В общем, не взлетело.
В целом по этому тесту видно, что при сравнении FEC vs DUP однозначно выигрывает FEС — даже ценой более высокой нагрузки каналов. Возможно, это следствие того, что Fortinet использует собственные ASIC-чипы и аппаратное ускорение сетевых функций SD-WAN и контентной фильтрации. Это даёт плюс к общей скорости, что бывает критично в точках развёртывания, где сложно спрогнозировать качество связи (выставки, демозоны и тому подобное).
Часто наполеоновские планы по развертыванию масштабных сетей на несколько сотен офисов разбиваются о суровую реальность: операторы связи на местах подключают точки слабыми каналами, которых по отдельности не хватает на весь конечный трафик. В итоге нам необходимо использовать их одновременно в режиме балансировки.
Для генерации тестового трафика используем ПО iPerf. Клиент будет располагаться на рабочей станции в удалённом офисе, сервер — на рабочей станции в головном. Будем генерировать поток из 50 UDP-сессий общей пропускной способностью 50 Мбит/с и проверять, распределяются ли они по обоим каналам. В качестве алгоритма балансировки используется Round Robin.
В этом тесте мы зададим правила для удалённого оборудования и будем ждать равномерного распределения трафика по каналам, т. е. примерно 25 Мбит/с на канал.
Так мы ожидали увидеть равномерное распределение между каналами. А дальше — как проверяли и что получили.
Если характеристики какого-либо из каналов выйдут за рамки пороговых значений, данный канал будет временно исключён из общего пула. Конфигурация SLA Target: оставляем jitter 5 мс, delay 5 мс и 0 для значения потерь (можем себе позволить в лабораторных условиях; в реальности значения, конечно же, будут другие).
Проверим статистику Performance SLA по потерям до того, как включим их по одному из каналов. Видим, что всё хорошо: потери отсутствуют.
Проверяем текущую загрузку по каждому из каналов, используя соответствующие виджеты. Видим, что оба канала (VPN1_0 и VPN2_0) загружены равномерно в исходящем направлении, примерно по 25 Мбит/с, как и предполагалось.
Теперь внесём потери на одном из каналов (VPN2_0) с использованием ПО WANem. Проверим, что Performance SLA зафиксировал это. Видим, что по каналу VPN2_0 фиксируются потери. Это значит, что теперь трафик, подпадающий под ранее созданное правило SD-WAN, не будет передаваться по каналу VPN2_0. Точнее, не будет передаваться до тех пор, пока потери на нём не исчезнут.
Снова проверяем текущую загрузку по каждому из каналов. Видим, что трафик с проблемного канала VPN2_0 переехал на VPN1_0, как и ожидалось. Дополнительно отметим, что, если ни один из интерфейсов не удовлетворяет SLA Target, трафик, конечно же, всё равно будет передаваться и при этом балансироваться между каналами.
В итоге мы быстро развернули правило SD-WAN на удалённых устройствах и теперь, в случае проблем одного из каналов, оборудование отследит это и перебросит трафик на резервный канал. Это позволяет экономить на трафике, перебрасывая второстепенные приложения и сервисы на более дешёвые каналы. Поговаривают, что 30−40% затрат на связь можно сэкономить. Дополнительно Fortinet позволяет автоматически настраивать тоннели между филиалами и снижать задержку по сравнению с маршрутизацией через центр.
Первичная настройка FG через CLI
Продолжим настройку основной части схемы — файерволов. Первичная настройка, адресация на портах и BGP, производилась через CLI.
Итоговая конфигурация портов в CLI для FortiGate MSK будет выглядеть так:
Port 1 — располагается в локальной сети, которая прокинута в L3 VPN;
Port 2 — внешняя адресация;
Port 3 — anycast-подсеть (для анонсирования подсети в интернет, так как активных сервисов на серверах у нас пока нет).
Настройка 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 адреса).
С учетом всех вводных итоговый конфиг выглядит так:
В результате мы получили следующую таблицу маршрутизации на FG:
Видим, что есть активный дефолтный маршрут, который изучен от одного из бордерных роутеров по BGP. Этот же дефолтный маршрут анонсируется в локальную сеть самим файерволом.
Так как мы добавили еще port 3 с адресом из anycast-подсети, сделаем так, чтобы данная подсеть начала анонсироваться через BGP и стала доступна из интернета. Для этого необходимо настроить редистрибуцию на FortiGate следующим образом:
Аналогично настраиваем сессию со вторым бордерным роутером.
Таким же образом настраиваем FG в СПб.
Настройка 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 адреса).
В результате мы получили следующую таблицу маршрутизации на FG:
Видим, что есть активный дефолтный маршрут, который изучен от одного из бордерных роутеров по BGP. Этот же дефолтный маршрут анонсируется в локальную сеть самим файерволом.
Так как мы добавили еще port 3 с адресом из anycast-подсети, сделаем так, чтобы данная подсеть начала анонсироваться через BGP и стала доступна из интернета. Для этого необходимо настроить редистрибуцию на FortiGate следующим образом:
Аналогично настраиваем сессию со вторым бордерным роутером.
Таким же образом настраиваем FG в СПб.
Создание виртуальных машин с файерволами FortiGate
В качестве файерволов мы выбрали Fortinet FortiGate (FG). Оба мы развернули из официального образа на виртуальной машине в облачной платформе. Отличий в конфигурировании виртуального и «железного» FG нет. Приступаем к развертыванию образа и настройке FG.
В нашем примере потребуется добавить еще два порта (первый порт появляется, когда мы указываем его в поле «Сеть» при создании виртуальной машины).
В самой конфигурации на FG появится порт с базовой конфигурацией, адресации на нем никакой не будет. Но нужно учитывать, что определенный порт создан в определенном VLAN, подсеть которого ему назначена.
Настройка маршрутизации на клиентских серверах
Далее приступаем к базовой настройке всех серверов. Из начальных настроек нужно лишь указать адрес серверу и прописать маршрут по умолчанию в сторону шлюза, который находится на роутере Selectel.
Здесь будут полезны статьи по настройке маршрутов в L3 VPN-сети и настройке облака на базе VMware с нуля.
Заказ и настройка VRF
Итак, закажем необходимое количество VRF и добавим в них нужные серверы. Для этого нужно создать тикет через панель управления Selectel. Инструкция, как быстро создать локальную сеть, есть в базе знаний.
На данный момент конфигурировать такие сети можно самостоятельно через панель управления.
Мой текст тикета выглядел примерно так:
Какие изменения в инфраструктуре произойдут после этих действий?
В облачной платформе будет добавлена подсеть с доступом в локальную сеть 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 (СПб).
Создание виртуальных машин с файерволами FortiGate
В качестве файерволов мы выбрали Fortinet FortiGate (FG). Оба мы развернули из официального образа на виртуальной машине в облачной платформе. Отличий в конфигурировании виртуального и «железного» FG нет. Приступаем к развертыванию образа и настройке FG.
В нашем примере потребуется добавить еще два порта (первый порт появляется, когда мы указываем его в поле «Сеть» при создании виртуальной машины).
В самой конфигурации на FG появится порт с базовой конфигурацией, адресации на нем никакой не будет. Но нужно учитывать, что определенный порт создан в определенном VLAN, подсеть которого ему назначена.
Настройка маршрутизации на клиентских серверах
Далее приступаем к базовой настройке всех серверов. Из начальных настроек нужно лишь указать адрес серверу и прописать маршрут по умолчанию в сторону шлюза, который находится на роутере Selectel.
Здесь будут полезны статьи по настройке маршрутов в L3 VPN-сети и настройке облака на базе VMware с нуля.
Настройка 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 во внешней сети:
Для поднятия сессии BGP с пограничными маршрутизаторами и L3 VPN-маршрутизаторами провайдера необходимо написать запрос в техническую поддержку.
Итоговый конфиг BGP для локальной сети:
Можно также настроить BGP через neighbor-range. Это значит, что сессия поднимется с любым адресом из заданного диапазона:
Несмотря на то, что router-id отличен от того, который сконфигурирован как адрес соседа на другом конце, сессия установится в Established. В качестве router-id может быть указан внешний адрес, тогда сессии поднимутся и во внешней, и в локальной сетях. Если router-id будет содержать в себе адрес из диапазона локальных адресов, то локальные сессии поднимутся, а внешние нет.
Определение Master/Slave ролей для FortiGate
Рассматриваемая нами топология предполагает, что FortiGate работают по схеме Master/Slave. В нашем случае мастером будет FortiGate в Москве, а бэкапом — FG в Санкт-Петербурге. Это значит, что при отсутствии нештатных ситуаций в инфраструктуре, все активные сервисы будут располагаться и работать в московской части инфраструктуры.
Как обеспечить распределение ролей для FortiGate, мы описали ниже.
Применим список правил (route-map, объект, в котором указываются атрибуты для управления приоритетами маршрутов) на FG, располагающемся в Санкт-Петербурге, чтобы сделать его бэкапом во внешней и локальной сети. Для этого будем использовать:
- AS Path Prepend (во внешней сети)
- MED (в локальной сети).
Такие методы вывода одного из FG в бэкап могут игнорироваться на стороне оператора связи, в связи с особенностями конфигурации, поэтому рекомендуем уточнить у оператора связи возможность обработки отправляемых атрибутов маршрутизации для анонсируемых подсетей.
Настройки route-map на FG в СПб (бэкап):
В это время активный маршрут до anycast-подсети 31.184.217.248/29 ведет на московский FG.
Link health monitor
Adding a link health monitor is required for routing failover traffic. A link health monitor confirms the device interface connectivity by probing a gateway or server at regular intervals to ensure it is online and working. When the server is not accessible, that interface is marked as down.
Set the interval (how often to send a ping) and failtime (how many lost pings are considered a failure). A smaller interval value and smaller number of lost pings results in faster detection, but creates more traffic on your network.
В этом тексте расскажем, как настроить резервированную схему сети с использованием двух файерволов (FortiGate) в разных локациях. Статья будет полезна всем, кто хочет построить отказоустойчивую инфраструктуру на уровне сети.
Подробно описанные шаги — под катом.
Читайте также: