Недавно завершил проект у клиента по построению отказоустойчивой сетевой инфраструктуры. Пока воспоминания живы — и документация под рукой, хочу поделиться уникальным ноу-хау. В чем уникальность? В том, что такая конфигурация нигде в официальных документах Fortinet не упоминается, не рекомендуется и вообще официально не существует. Также никаких упоминаний такой конфигурации не было найдено на просторах интернета.
Итак, что имеем в наличии:
Две разнесенные в пространстве площадки, офис и дата-центр (ДЦ). Каждая площадка имеет независимый доступ в инетрнет и локальную подсеть. Между площадками существует выделенное соединение с возможностью создавать собственные VLAN. Из оборудования имеется два Fortigate 100D и четыре управляемых свитча Cisco Catalyst 2960XR со Stacking Module. Т.е. по два свитча и одному фортигейту на площадку.
Задача:
Обеспечить отказоустойчивость и непрерывность связи
1) в случае выхода из строя любой одной железки.
2) в случае падения любого из каналов связи.
3) в случае выхода из строя любого одного порта на любой из железок
Было бы у нас по 2 фортигейта на площадку — проблемы бы не было совсем — настраиваем стандартый кластер из двух фортигейтов на каждой площадке, динамическую маршрутизацию и наслаждаемся жизнью. Однако с оборудованием у нас то что есть, поэтому приходится изголяться.
В начале оборудования было еще меньше — по одному свитчу и одному фортигейту на площадку, но в данной статье я опишу конечную конфигурацию.
Итак приступим:
Обозначим SW1 и FG1 — стэк свитчей в офисе и фортигейт в офисе. SW2 и FG2 — аналогичные железки в датацентре.
Для правильной конфигурации всего нам понадобится 5 логических портов на каждом фортигейте (5 логических = 10 физических). Обозначим их как:
Еще задействуем оба HA порта для обеспечения синхронизации кластера, что добавляет еще 2 порта к используемым на свитче. Итого будет задействовано 6 портов на каждом физическом свитче (или 12 портов на стэк свитчей) только на подключение фортигейтов.
Конфигурация Layer1 (физические подключения):
Предполагаю что стэк свитчей уже собран, т.к. никаких сложностей там нет.
Подключаем фортигейты к свитчам по следующей схеме:
Для DC_Internet
Для Office_Internet
Для Office_Lan
Для DC_Lan
Для Interconnect
Для HA1 и HA2
Повторить операцию аналогично для FG2 и SW2.
Теперь нужно воткнуть в свитчи линки приходящие от провайдера. В моем случае это 2 подключения к интернетам и канал между ДЦ и офисом, соответственно конфигурация будет слегка отличаться между двумя площадками. Опять же в моем конкретном случае провайдеры предоставили по два линка к интернету и 2 линка для интерконнекта на каждой стороне.
Если вы не сможете получить 2 линка на каждый канал — тогда одно из требований останется частично не выполненным — в случае выхода порта на свитче куда подключен линк от провайдера будет потеря связи.
Здесь же подключим даунлинки к Access свитчам в офисе и ДЦ.
Подключаем в офисе:
Подключаем в ДЦ:
С Layer 1 закончили, можно переходить к конфигурации Port Aggregation и VLAN.
Layer 2
На данном этапе нужно сконфигурировать пары портов на свитчах и фортигейтах, и назначить VLAN для разграничения трафика.
— Создаем необходимые VLAN на свитчах и назначаем порты в них:
на свитчах в режиме конфигурации создаем необходмые VLAN
Там же на свитчах создаем port-channel и назначаем порты в них:
Для DC_Internet:
Повторяем для вышеприведенных пар портов и получаем port-channel 2-4
Для Interconnect:
Чуть-чуть другая конифгурация для HA1 и HA2 т.к. там нет аггрегации портов
Для HA1
Для HA2
Для Канала Офис-ДЦ:
Вышеприведенная конфигурация для Layer2 одинакова для офиса и ДЦ, ниже показаны отличающиеся части конфига.
В офисе:
В ДЦ:
Со стороны фортигейтов:
1. Включаем поддержку VDOM
2. Конфигурируем поддержку Virtual Cluster
3. Раскидываем порты — каждый в свой VDOM
4. Создаем пары портов Port Aggregation 802.3ad
Вот так это выглядит в виде кода:
Это все для Layer 2, переходим к Layer 3+. Здесь нам нужно:
— включить маршуртизацию
— настроить мониторинг маршрутизации
— настроить правила файрвола
— настроить VPN на случай падения канала между офисом и ДЦ
На свитчах делать ничего не надо. На фортигейте (после настройки кластера — мы управляем одной железкой):
Теперь в случае падения любого интернет-канала будет удаляться статический маршрут в интернет и будет задействован маршут через канал офиц-дц, в случае восстановления канала — все вернется как было.
Осталось создать правила файрвола (надеюсь это осилите самостоятельно). Нужно просто не забывать о том, что один и тот же трафик может придти из разных интерфейсов (интернет или интерконнект).
А также создать VPN соединение для соединения сайтов в случае падения канала ДЦ — оффис.
И соответствующие правила файрвола:
В результате VPN будет подниматься только в случае падения канала офис-дц.
Что мы получили в итоге:
1. Аггрегация портов нас защищает от падения либо одного порта, либо свитча целиком (за исключением каналов с одним проводом от провайдера).
2. Виртуальный кластер фортигейтов будет работать как маршрутизатор для сети, причем в нормальной ситуации фортигейт в офисе будет всегда перенаправлять пакеты для своей сетевой зоны, а фортигейт в ДЦ для своей. В случае падения одного из фортигейтов весь трафик будет маршрутизироваться вторым фортигейтом.
3. В случае падения одного из каналов интернет — весь трафик пойдет через другой канал, и вернется обратно как только канал в интернет поднимется.
4. В случае падения канала офис-дц трафик пойдет через автоматически поднимающийся VPN и будет идти по нему пока канал не восстановится.
Получилось много и наверное на первый взгляд сложно — но если есть вопросы, я готов на них ответить.
Итак, что имеем в наличии:
Две разнесенные в пространстве площадки, офис и дата-центр (ДЦ). Каждая площадка имеет независимый доступ в инетрнет и локальную подсеть. Между площадками существует выделенное соединение с возможностью создавать собственные VLAN. Из оборудования имеется два Fortigate 100D и четыре управляемых свитча Cisco Catalyst 2960XR со Stacking Module. Т.е. по два свитча и одному фортигейту на площадку.
Задача:
Обеспечить отказоустойчивость и непрерывность связи
1) в случае выхода из строя любой одной железки.
2) в случае падения любого из каналов связи.
3) в случае выхода из строя любого одного порта на любой из железок
Было бы у нас по 2 фортигейта на площадку — проблемы бы не было совсем — настраиваем стандартый кластер из двух фортигейтов на каждой площадке, динамическую маршрутизацию и наслаждаемся жизнью. Однако с оборудованием у нас то что есть, поэтому приходится изголяться.
В начале оборудования было еще меньше — по одному свитчу и одному фортигейту на площадку, но в данной статье я опишу конечную конфигурацию.
Итак приступим:
Обозначим SW1 и FG1 — стэк свитчей в офисе и фортигейт в офисе. SW2 и FG2 — аналогичные железки в датацентре.
Для правильной конфигурации всего нам понадобится 5 логических портов на каждом фортигейте (5 логических = 10 физических). Обозначим их как:
- Office_Internet
- DC_Internet
- Office_Lan
- DC_Lan
- Interconnect
Еще задействуем оба HA порта для обеспечения синхронизации кластера, что добавляет еще 2 порта к используемым на свитче. Итого будет задействовано 6 портов на каждом физическом свитче (или 12 портов на стэк свитчей) только на подключение фортигейтов.
Конфигурация Layer1 (физические подключения):
Предполагаю что стэк свитчей уже собран, т.к. никаких сложностей там нет.
Подключаем фортигейты к свитчам по следующей схеме:
Для DC_Internet
FG1-WAN1 - SW1-1/0/1
FG1-WAN2 - SW1-2/0/1
Для Office_Internet
FG1-DMZ - SW1-1/0/2
FG1-Port1 - SW1-2/0/2
Для Office_Lan
FG1-DMZ - SW1-1/0/3
FG1-Port1 - SW1-2/0/3
Для DC_Lan
FG1-Port2 - SW1-1/0/4
FG1-Port3 - SW1-2/0/4
Для Interconnect
FG1-Port4 - SW1-1/0/5
FG1-Port5 - SW1-2/0/5
Для HA1 и HA2
FG1-HA1 - SW1-1/0/6
FG1-HA2 - SW1-2/0/6
Повторить операцию аналогично для FG2 и SW2.
Теперь нужно воткнуть в свитчи линки приходящие от провайдера. В моем случае это 2 подключения к интернетам и канал между ДЦ и офисом, соответственно конфигурация будет слегка отличаться между двумя площадками. Опять же в моем конкретном случае провайдеры предоставили по два линка к интернету и 2 линка для интерконнекта на каждой стороне.
Если вы не сможете получить 2 линка на каждый канал — тогда одно из требований останется частично не выполненным — в случае выхода порта на свитче куда подключен линк от провайдера будет потеря связи.
Здесь же подключим даунлинки к Access свитчам в офисе и ДЦ.
Подключаем в офисе:
SW1-1/0/22 - Даунлинк в Office_LAN линк 1
SW1-2/0/22 - Даунлинк в Office_LAN линк 2
SW1-1/0/23 - Интернет от провайдера в офисе линк 1
SW1-2/0/23 - Интернет от провайдера в офисе линк 2
SW1-1/0/24 - Канал Офис-ДЦ линк 1
SW1-2/0/24 - Канал Офис-ДЦ линк 2
Подключаем в ДЦ:
SW1-1/0/22 - Даунлинк в DC_LAN линк 1
SW1-2/0/22 - Даунлинк в DC_LAN линк 2
SW2-1/0/23 - Интернет от провайдера в ДЦ линк 1
SW2-2/0/23 - Интернет от провайдера в ДЦ линк 2
SW2-1/0/24 - Канал Офис-ДЦ линк 1
SW2-2/0/24 - Канал Офис-ДЦ линк 2
С Layer 1 закончили, можно переходить к конфигурации Port Aggregation и VLAN.
Layer 2
На данном этапе нужно сконфигурировать пары портов на свитчах и фортигейтах, и назначить VLAN для разграничения трафика.
— Создаем необходимые VLAN на свитчах и назначаем порты в них:
на свитчах в режиме конфигурации создаем необходмые VLAN
vlan 10
name DC_Internet
vlan 20
name Office_Internet
vlan 30
name Office_Lan
vlan 40
name DC_LAN
vlan 50
name Interconnect
vlan 60
name HA
Там же на свитчах создаем port-channel и назначаем порты в них:
Для DC_Internet:
Interface port-channel1
switchport access vlan 10 # VLAN 10 = DC_Internet
switchport mode access
Interface GigabitEthernet1/0/1
switchport access vlan 10
switchport mode access
channel-group 1 mode passive
Interface GigabitEthernet2/0/1
switchport access vlan 10
switchport mode access
channel-group 1 mode passive
Повторяем для вышеприведенных пар портов и получаем port-channel 2-4
Для Interconnect:
Interface port-channel5
switchport access vlan 50
switchport mode access
Interface GigabitEthernet1/0/5
switchport access vlan 50
switchport mode access
channel-group 5 mode passive
Interface GigabitEthernet2/0/5
switchport access vlan 50
switchport mode access
channel-group 5 mode passive
Чуть-чуть другая конифгурация для HA1 и HA2 т.к. там нет аггрегации портов
Для HA1
Interface GigabitEthernet1/0/6
switchport access vlan 60 # Vlan 60 = HA
switchport mode access
Для HA2
Interface GigabitEthernet2/0/6
switchport access vlan 60 # Vlan 60 = HA
switchport mode access
Для Канала Офис-ДЦ:
Interface port-channel6
switchport mode trunk # !!! Trunk
Interface GigabitEthernet1/0/24
switchport mode trunk
channel-group 6 mode passive
Interface GigabitEthernet2/0/24
switchport mode trunk
channel-group 6 mode passive
Вышеприведенная конфигурация для Layer2 одинакова для офиса и ДЦ, ниже показаны отличающиеся части конфига.
В офисе:
Interface port-channel7
switchport access vlan 30 # VLAN 30 = Office_Lan
switchport mode access
Interface GigabitEthernet1/0/22
switchport access vlan 30
switchport mode access
channel-group 7 mode passive
Interface GigabitEthernet2/0/22
switchport access vlan 30
switchport mode access
channel-group 7 mode passive
Interface port-channel8
switchport access vlan 20 # VLAN 20 = Office_Internet
switchport mode access
Interface GigabitEthernet1/0/23
switchport access vlan 20
switchport mode access
channel-group 8 mode passive
Interface GigabitEthernet2/0/23
switchport access vlan 20
switchport mode access
channel-group 8 mode passive
В ДЦ:
Interface port-channel7
switchport access vlan 40 # VLAN 40 = DC_Lan
switchport mode access
Interface GigabitEthernet1/0/22
switchport access vlan 40
switchport mode access
channel-group 7 mode passive
Interface GigabitEthernet2/0/22
switchport access vlan 40
switchport mode access
channel-group 7 mode passive
Interface port-channel8
switchport access vlan 10 # VLAN 10 = DC_Internet
switchport mode access
Interface GigabitEthernet1/0/23
switchport access vlan 10
switchport mode access
channel-group 8 mode passive
Interface GigabitEthernet2/0/23
switchport access vlan 10
switchport mode access
channel-group 8 mode passive
Со стороны фортигейтов:
1. Включаем поддержку VDOM
2. Конфигурируем поддержку Virtual Cluster
3. Раскидываем порты — каждый в свой VDOM
4. Создаем пары портов Port Aggregation 802.3ad
Вот так это выглядит в виде кода:
Много кода
config system interface
edit "wan1"
set vdom "DataCenter"
set type physical
set snmp-index 1
next
edit "dmz"
set vdom "Office"
set type physical
set snmp-index 2
next
edit "wan2"
set vdom "DataCenter"
set type physical
set snmp-index 7
next
edit "ha1"
set vdom "root"
set type physical
set snmp-index 9
next
edit "ha2"
set vdom "root"
set status down
set type physical
set snmp-index 10
next
edit "port1"
set vdom "Office"
set type physical
set snmp-index 12
next
edit "port2"
set vdom "DataCenter"
set type physical
set snmp-index 13
next
edit "port3"
set vdom "Office"
set type physical
set snmp-index 17
next
edit "port4"
set vdom "DataCenter"
set type physical
set snmp-index 18
next
edit "port5"
set vdom "Office"
set type physical
set snmp-index 15
next
edit "port6"
set vdom "Office"
set type physical
set snmp-index 16
next
edit "port7"
set vdom "DataCenter"
set type physical
set snmp-index 19
next
edit "port8"
set vdom "Office"
set status down
set type physical
set snmp-index 20
next
edit "port9"
set vdom "DataCenter"
set status down
set type physical
set snmp-index 21
next
edit "port10"
set vdom "root"
set status down
set type physical
set snmp-index 22
next
edit "lan"
set vdom "root"
set status down
set type hard-switch
set snmp-index 11
next
edit "DC_Internet"
set vdom "DataCenter"
set ip 2.2.2.2 255.255.255.224
set allowaccess ping https ssh
set type aggregate
set member "wan1" "wan2"
set snmp-index 14
next
edit "Office_Internet"
set vdom "Office"
set ip 1.1.1.1 255.255.255.248
set allowaccess ping https
set type aggregate
set member "port5" "dmz"
set snmp-index 23
next
edit "Office-LAN"
set vdom "Office"
set dhcp-relay-service enable
set ip 192.168.100.1 255.255.255.0
set allowaccess ping https ssh
set type aggregate
set member "port6" "port1"
set snmp-index 24
next
edit "DC-LAN"
set vdom "DataCenter"
set ip 192.168.200.1 255.255.255.0
set allowaccess ping https ssh
set type aggregate
set member "port7" "port2"
set snmp-index 25
next
edit "Intercon-Office"
set vdom "Office"
set ip 192.168.150.1 255.255.255.252
set allowaccess ping
set type aggregate
set member "port8" "port3"
set snmp-index 26
next
edit "Intercon-DC"
set vdom "DataCenter"
set ip 192.168.150.2 255.255.255.252
set allowaccess ping
set type aggregate
set member "port9" "port4"
set snmp-index 27
next
end
config system ha
set group-name "aaa.com"
set mode a-p
set password ENC xxx
set hbdev "ha1" 50
set arps 30
set arps-interval 1
set session-pickup enable
set link-failed-signal enable
set ha-mgmt-status enable
set ha-mgmt-interface "mgmt"
set vcluster2 enable
set override enable
set priority 100
set monitor "Office_internet" "Office_LAN" "Intercon_Office"
config secondary-vcluster
set override enable
set priority 250
set monitor "DC_Internet" "DC_LAN" "Intercon_DC"
set vdom "DataCenter"
end
end
Это все для Layer 2, переходим к Layer 3+. Здесь нам нужно:
— включить маршуртизацию
— настроить мониторинг маршрутизации
— настроить правила файрвола
— настроить VPN на случай падения канала между офисом и ДЦ
На свитчах делать ничего не надо. На фортигейте (после настройки кластера — мы управляем одной железкой):
Маршрутизация и мониторинг маршрутизации
config vdom
edit DataCenter
config router static
edit 1
set gateway 2.2.2.3
set device "DC_Internet"
next
edit 2
set dst 192.168.100.0 255.255.255.0
set gateway 192.168.150.1
set device "Intercon-DC"
next
edit 3
set gateway 192.168.150.1
set distance 15
set device "Intercon-DC"
next
end
config system link-monitor
edit "DC-Internet"
set srcintf "DC_Internet"
set server "2.2.2.3"
set gateway-ip 2.2.2.3
set update-cascade-interface disable
next
edit "Interconnect"
set srcintf "Intercon-DC"
set server "192.168.150.1"
set gateway-ip 192.168.150.1
set update-cascade-interface disable
next
end
end
end
config vdom
edit Office
config router static
edit 1
set gateway 1.1.1.2
set distance 9
set device "Office_Internet"
next
edit 2
set dst 192.168.200.0 255.255.255.0
set gateway 192.168.150.2
set device "Intercon-Office"
next
edit 3
set gateway 192.168.150.2
set distance 15
set device "Intercon-Office"
next
end
config system link-monitor
edit "Office-Internet-Check"
set srcintf "Office_Internet"
set server "1.1.1.2"
set gateway-ip 1.1.1.2
set update-cascade-interface disable
next
edit "Interconnect"
set srcintf "Intercon-Office"
set server "192.168.150.2"
set gateway-ip 192.168.150.2
set update-cascade-interface disable
next
end
Теперь в случае падения любого интернет-канала будет удаляться статический маршрут в интернет и будет задействован маршут через канал офиц-дц, в случае восстановления канала — все вернется как было.
Осталось создать правила файрвола (надеюсь это осилите самостоятельно). Нужно просто не забывать о том, что один и тот же трафик может придти из разных интерфейсов (интернет или интерконнект).
А также создать VPN соединение для соединения сайтов в случае падения канала ДЦ — оффис.
Конфигурация VPN
config vdom
edit DataCenter
config vpn ipsec phase1
edit "site-to-site"
set interface "DC_Internet"
set nattraversal disable
set proposal aes256-sha256
set dhgrp 5
set remote-gw 1.1.1.1
set psksecret ENC xxx
next
end
config vpn ipsec phase2
edit "p2"
set phase1name "site-to-site"
set proposal aes256-sha256
set pfs disable
set replay disable
set auto-negotiate enable
set src-addr-type name
set dst-addr-type name
set src-name "192.168.200.x"
set dst-name "192.168.100.x"
next
end
config vdom
edit Office
config vpn ipsec phase1
edit "site-to-site"
set interface "Office_Internet"
set nattraversal disable
set proposal aes256-sha256
set dhgrp 5
set remote-gw 2.2.2.2
set psksecret ENC xxx
next
end
config vpn ipsec phase2
edit "p2"
set phase1name "site-to-site"
set proposal aes256-sha256
set pfs disable
set replay disable
set keepalive enable
set auto-negotiate enable
set src-addr-type name
set dst-addr-type name
set src-name "192.168.100.x"
set dst-name "192.168.200.x"
next
end
И соответствующие правила файрвола:
Правила файрвола
config vdom
edit Office
config firewall policy
edit 20
set srcintf "Office-LAN"
set dstintf "Office_Internet"
set srcaddr "192.168.100.x"
set dstaddr "192.168.200.x"
set action ipsec
set schedule "always"
set service "ALL"
set inbound enable
set outbound enable
set vpntunnel "site-to-site"
next
end
config vdom
edit DataCenter
edit 9
set srcintf "DC-LAN"
set dstintf "DC_Internet"
set srcaddr "192.168.200.x"
set dstaddr "192.168.100.x"
set action ipsec
set schedule "always"
set service "ALL"
set inbound enable
set outbound enable
set vpntunnel "site-to-site"
next
В результате VPN будет подниматься только в случае падения канала офис-дц.
Что мы получили в итоге:
1. Аггрегация портов нас защищает от падения либо одного порта, либо свитча целиком (за исключением каналов с одним проводом от провайдера).
2. Виртуальный кластер фортигейтов будет работать как маршрутизатор для сети, причем в нормальной ситуации фортигейт в офисе будет всегда перенаправлять пакеты для своей сетевой зоны, а фортигейт в ДЦ для своей. В случае падения одного из фортигейтов весь трафик будет маршрутизироваться вторым фортигейтом.
3. В случае падения одного из каналов интернет — весь трафик пойдет через другой канал, и вернется обратно как только канал в интернет поднимется.
4. В случае падения канала офис-дц трафик пойдет через автоматически поднимающийся VPN и будет идти по нему пока канал не восстановится.
Получилось много и наверное на первый взгляд сложно — но если есть вопросы, я готов на них ответить.
Поделиться с друзьями
Комментарии (4)
ksg222
18.10.2016 11:173. В случае падения одного из каналов интернет — весь трафик пойдет через другой канал, и вернется обратно как только канал в интернет поднимется.
На сколько видно из конфигурации, в качестве критерия работает/не работает канал использует информация о состояние порта. Т.е. если будут проблемы не с физикой (например, отказ где-нибудь дальше), схема переключения не отработает. Можно ли на Fortinet прикрутить некое подобие IP SLA? Схему с BGP для связи с интернет-провайдером не рассматривали?
4. В случае падения канала офис-дц трафик пойдет через автоматически поднимающийся VPN и будет идти по нему пока канал не восстановится.
Опять же, критерий — падение физики. Почему не рассматривали динамику между площадками?
1. Аггрегация портов нас защищает
Если используете стек и динамическую агрегацию (в вашем случае lacp), стоит внимательно смотреть на память коммутаторов, чтобы вовремя заметить баг с утечкой памяти (если он вдруг есть в используемом релизе IOS). Иначе в самый неподходящий момент, когда contrl-plane «умрёт», вместе с ним и lacp перестанет работать со всеми вытекающими последствиями для отказоустойчивой схемы.Zwerg
18.10.2016 16:31На сколько видно из конфигурации, в качестве критерия работает/не работает канал использует информация о состояние порта.
Не совсем так.
Вот эта часть
edit "Office-Internet-Check"
set srcintf "Office_Internet"
set server "1.1.1.2"
set gateway-ip 1.1.1.2
set update-cascade-interface disable
next
Просто пингует 1.1.1.2 (в нашем случае это дефолт гейтвей, но можно пинговать что угодно — хоть тот же гугл). В случае пропуска 5ти пингов подряд (количество настраивается) — канал считается мертвым и убирается соответствующая строчка из таблицы маршрутизации. В результате приоритет получает второй статический маршрут через канал оффис-дц, и трафик начинает течь по нему.
Опять же, критерий — падение физики. Почему не рассматривали динамику между площадками?
Можно и динамику, но люди которые это все поддерживают сильно просили статику — им так проще.ksg222
18.10.2016 16:35Понял, спасибо. Значит, я просто не правильно интерпретировал конфигурацию Fortinet.
epicf4il
Вы конечно большой молодец, что всё подробно расписали. Но мне кажется, что всего лишь пара картинок (с общей топологией и схемами переключения при отказах) и адекватное восприятие статьи возросло бы в разы.