В этом тексте расскажем, как настроить резервированную схему сети с использованием двух файерволов (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 "<selectel-brd-1>"
            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 "<selectel-brd-2>"
            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 <selectel-brd-1> 255.255.255.255
        set gateway 77.223.107.153
        set device "port2"
    next
    edit 1
        set dst <selectel-brd-2> 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, располагающемся в Санкт-Петербурге, чтобы сделать его бэкапом во внешней и локальной сети. Для этого будем использовать:

1. AS Path Prepend (во внешней сети)
2. 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 <ip>
              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.