Как настроить резервированную схему сети с использованием протокола BGP и anycast-подсети

Введение

В данной инструкции расскажем, как настроить резервированную схему сети на инфраструктуре 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.
• Протестировать схемы.

Заказ и настройка 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.

Чтобы не конфигурировать что-то в vdom (virtual domain) — по умолчанию («root»), следует создать новый vdom и там уже продолжить конфигурацию оборудования для организации схемы. В нашем примере это vdom «custom».

Итоговая конфигурация портов в CLI для FortiGate MSK будет выглядеть так:

config system interface
    edit "port1"
        set vdom "custom"
        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 "custom"
        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 "custom"
        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.