Привет, Habr! Для обеспечения доступа между офисами у нас уже давно построена и успешно эксплуатируется классическая схема Hub and Spoke с несколькими хабами в центральном узле и споками в удаленных точках, на цисковской технологии DMVPN. В качестве транспортной среды используются в основном интернет каналы. Шифрование, естественно, IPSec.

Случилось импортозамещение. Контролирующие организации потребовали организовать шифрование каналов передачи данных с использованием отечественной криптографии.

Нам хочется внедрить ГОСТовую криптографию с минимальными потерями отказоустойчивости и управляемости действующей сети и с максимально простой конфигурацией устройств шифрации, с минимальным использованием их дополнительного функционала. Для этого шифраторам нужно поручить только шифрацию, а динамическую маршрутизацию с балансировкой трафика оставить маршрутизаторам, умеющим это делать хорошо.

Появилась идея разделить существующее DMVPN облако на две половинки, одна из которых будет заниматься передачей трафика через интернет, другая маршрутизацией сетей офисов между собой, а между ними встроить шифрование.

В итоге получилась такая «луковица», где каждый уровень является транспортной сетью для вышестоящего. На самом глубоком уровне находится интернет. Поверх него строится полносвязная сеть DMVPN туннелей. Назовем эту сеть – опорной, а туннели, соответственно, назовем опорными. Поверх опорной сети строится полносвязная (FullMesh) сеть шифрованных по ГОСТу VPN туннелей. И, наконец, на верхнем уровне строится сеть туннелей для передачи трафика непосредственно между локальными сетями офисов. Эти туннели назовем защищенными.

FullMesh VPN находится посередине этой «луковицы», и шифраторы (криптошлюзы) ничего не знают ни о локальных сетях, ни о интернете. Поэтому получилось максимально упростить настройки криптошлюзов.

При изменении топологии локальных сетей офисов (добавлении или удалении сетей, смене ip адресации) настройки на криптошлюзах вообще не меняются, поскольку шифруется только GRE трафик туннеля, а источником трафика выступает ip адрес tunnel source.

Как вы уже наверняка заметили, такая топология имеет ряд недостатков. Практически, все они связаны с увеличением этапов обработки пакета. В результате мы имеем рост задержки, увеличение загрузки маршрутизатора за счет двойной инкапсуляции трафика. Наконец, на каждом этапе обработки, к пакету добавляется очередной заголовок, за счет этого уменьшается допустимый MTU, и снижается объем допустимого полезного трафика. Об этом чуть ниже.

Сначала идея была опробована на стенде, где в качестве криптошлюзов выступали обычные маршрутизаторы, умеющие в IPSec. Дальше захотелось провести испытания с реальным отечественным оборудованием.

Для тестирования было выбраны криптошлюзы серии «Континент 3.9» компании Код безопасности. Почему именно Континенты? А потому что, нам понравился необычный салатовый цвет устройств.

Но, мы полагаем, что эту идею можно реализовать если не полносвязной топологией, то, в крайнем случае, топологией звезда на любом оборудовании для ГОСТового ip шифрования.

В сети есть центральный офис (1) с маршрутизатором – хабом и два удаленных офиса (2 и 3) с маршрутизаторами – споками. Маршрутизатор, разумеется, поддерживает VRF, динамическую маршрутизацию и DMVPN. В каждом офисе установлено по криптошлюзу. Для эмуляции работы интернет провайдеров используется L3 коммутатор.

Интерфейсы управления криптошлюзов и маршрутизаторов на схеме не показаны. Через эти интерфейсы настроены маршруты к станции администратора, серверу SNMP мониторинга и серверу SysLog.

Перечень ip сетей стенда

• 192.0.2.0/30 – сеть первого провайдера хаба;

• 192.0.2.128/30 – сеть второго провайдера хаба;

• 198.51.100.0/30 – сеть первого провайдера спока 2;

• 198.51.100.0/30 – сеть первого провайдера спока 2;

• 198.51.100.128/30 – сеть второго провайдера спока 2;

• 203.0.113.0/30 – сеть первого провайдера спока 3;

• 203.0.113.128/30 – сеть второго провайдера спока 3;

• 172.16.1.0/24 – сеть DMVPN опорного туннеля 1;

• 172.16.2.0/24 – сеть DMVPN опорного туннеля 2;

• 172.16.3.0/24 – сеть DMVPN опорного туннеля 3;

• 172.16.4.0/24 – сеть DMVPN опорного туннеля 4;

• 172.17.1.0/30 – сеть внешнего интерфейса криптошлюза хаба;

• 172.17.2.0/30 – сеть внешнего интерфейса криптошлюза спока 2;

• 172.17.2.0/30 – сеть внешнего интерфейса криптошлюза спока 3;

• 172.18.1.0/30 – сеть внутреннего интерфейса криптошлюза хаба;

• 172.18.2.0/30 – сеть внутреннего интерфейса криптошлюза спока 2;

• 172.18.2.0/30 – сеть внутреннего интерфейса криптошлюза спока 3;

• 172.19.0.0/24 – защищенная сеть DMVPN туннеля 100;

• 192.168.1.0/24 – локальная сеть хаба;

• 192.168.2.0/24 – локальная сеть спока 2;

• 192.168.3.0/24 – локальная сеть спока 3.

Конфигурация маршрутизаторов

Ниже интенсивно используются понятия VRF, front-door VRF и inside VRF.

Схема, когда сам туннельный интерфейс находится в одном VRF, который называется inside VRF, а инкапсулированный в GRE трафик ходит в другом VRF, под названием front-door VRF.

Подробнее об этом можно прочитать по ссылке habr.com/ru/companies/cbs/articles/302772/.

Такое использование VRF позволяет, в том числе, максимально изолировать криптошлюзы, от сетей офисов.

На каждом маршрутизаторе настроено несколько VRF.

VRF WAN1 и VRF WAN2

В этих VRF находятся WAN интерфейсы, выходящие в интернет. К каждому узлу подключено по два интернет провайдера.

WAN1 и WAN2 – это front-door VRF для опорных туннелей 1, 2, 3 и 4.

В этом VRF настроена статическая маршрутизация через шлюзы интернет провайдеров между WAN интерфейсами хаба и споков.

Конфигурация VRF WAN1 и WAN2 на хабе (на споках настройки аналогичные, меняются только ip адреса и маршруты)

ip vrf WAN1
ip vrf WAN2

interface GigabitEthernet0/0/0.901
encapsulation dot1Q 901
ip vrf forwarding WAN1
ip address 192.0.2.2 255.255.255.252

interface GigabitEthernet0/0/0.902
encapsulation dot1Q 902
ip vrf forwarding WAN2
ip address 192.0.2.130 255.255.255.252

ip route vrf WAN1 0.0.0.0 0.0.0.0 192.0.2.1
ip route vrf WAN2 0.0.0.0 0.0.0.0 192.0.2.129

VRF EXTERNAL

VRF EXTERNAL – это inside VRF для туннелей 1, 2, 3 и 4.

Также в этом VRF находится сеть точка-точка между внешним интерфейсом криптошлюза и интерфейсом маршрутизатора. Далее будем называть ее внешней сетью криптошлюза.

Здесь настроена динамическая маршрутизация для обеспечения балансировки работы через интернет каналы. Динамически отдается маршрут к внешней сети криптошлюза, принимаются аналогичные маршруты к внешним сетям всех остальных криптошлюзов.

В этом VRF ходят только зашифрованные криптошлюзом пакеты и пакеты протокола маршрутизации.

В таблице показано, через каких провайдеров строятся туннели.

Такой вариант построения туннелей обеспечивает работоспособность при одновременном отключении одного любого провайдера на хабе и одного любого провайдера на споке.

Конфигурация VRF EXTERNAL на хабе

ip vrf EXTERNAL

interface Tunnel1
bandwidth 100000
ip vrf forwarding EXTERNAL
ip address 172.16.1.1 255.255.255.0
ip nhrp authentication DMVPN1
ip nhrp network-id 1
ip nhrp registration timeout 120
ip nhrp redirect
tunnel source GigabitEthernet0/0/0.901
tunnel mode gre multipoint
tunnel key 1
tunnel vrf WAN1

interface Tunnel2
bandwidth 100000
ip vrf forwarding EXTERNAL
ip address 172.16.2.1 255.255.255.0
ip nhrp authentication DMVPN2
ip nhrp network-id 2
ip nhrp registration timeout 120
ip nhrp redirect
tunnel source GigabitEthernet0/0/0.902
tunnel mode gre multipoint
tunnel key 2
tunnel vrf WAN2

interface Tunnel3
bandwidth 100000
ip vrf forwarding EXTERNAL
ip address 172.16.3.1 255.255.255.0
ip nhrp authentication DMVPN3
ip nhrp network-id 3
ip nhrp registration timeout 120
ip nhrp redirect
tunnel source GigabitEthernet0/0/0.902
tunnel mode gre multipoint
tunnel key 3
tunnel vrf WAN2

interface Tunnel4
bandwidth 100000
ip vrf forwarding EXTERNAL
ip address 172.16.4.1 255.255.255.0
ip nhrp authentication DMVPN4
ip nhrp network-id 4
ip nhrp registration timeout 120
ip nhrp redirect
tunnel source GigabitEthernet0/0/0.901
tunnel mode gre multipoint
tunnel key 4
tunnel vrf WAN1

interface GigabitEthernet0/0/1
ip vrf forwarding EXTERNAL
ip address 172.17.1.1 255.255.255.252

Конфигурация VRF EXTERNAL на споке 2

ip vrf EXTERNAL

interface Tunnel1
bandwidth 100000
ip vrf forwarding EXTERNAL
ip address 172.16.1.2 255.255.255.0
ip nhrp authentication DMVPN1
ip nhrp map multicast 192.0.2.2
ip nhrp map 172.16.1.1 192.0.2.2
ip nhrp network-id 1
ip nhrp nhs 172.16.1.1
ip nhrp registration timeout 120
ip nhrp shortcut
tunnel source GigabitEthernet0/0/0.901
tunnel mode gre multipoint
tunnel key 1
tunnel vrf WAN1

interface Tunnel2
bandwidth 100000
ip vrf forwarding EXTERNAL
ip address 172.16.2.2 255.255.255.0
ip nhrp authentication DMVPN2
ip nhrp map multicast 192.0.2.130
ip nhrp map 172.16.2.1 192.0.2.130
ip nhrp network-id 2
ip nhrp nhs 172.16.2.1
ip nhrp registration timeout 120
ip nhrp shortcut
tunnel source GigabitEthernet0/0/0.901
tunnel mode gre multipoint
tunnel key 2
tunnel vrf WAN1

interface Tunnel3
bandwidth 100000
ip vrf forwarding EXTERNAL
ip address 172.16.3.2 255.255.255.0
ip nhrp authentication DMVPN3
ip nhrp map multicast 192.0.2.130
ip nhrp map 172.16.3.1 192.0.2.130
ip nhrp network-id 3
ip nhrp nhs 172.16.3.1
ip nhrp registration timeout 120
ip nhrp shortcut
tunnel source GigabitEthernet0/0/0.902
tunnel mode gre multipoint
tunnel key 3
tunnel vrf WAN2

interface Tunnel4
bandwidth 100000
ip vrf forwarding EXTERNAL
ip address 172.16.4.2 255.255.255.0
ip nhrp authentication DMVPN4
ip nhrp map multicast 192.0.2.2
ip nhrp map 172.16.4.1 192.0.2.2
ip nhrp network-id 4
ip nhrp nhs 172.16.4.1
ip nhrp registration timeout 120
ip nhrp shortcut
tunnel source GigabitEthernet0/0/0.902
tunnel mode gre multipoint
tunnel key 4
tunnel vrf WAN2

interface GigabitEthernet0/0/1
ip vrf forwarding EXTERNAL
ip address 172.17.2.1 255.255.255.252

Конфигурация EIGRP VRF EXTERNAL на хабе

router eigrp 200
address-family ipv4 vrf EXTERNAL autonomous-system 200
eigrp router-id 172.17.1.1
passive-interface GigabitEthernet0/0/1
network 172.16.1.0 0.0.0.255
network 172.16.2.0 0.0.0.255
network 172.16.3.0 0.0.0.255
network 172.16.4.0 0.0.0.255
network 172.17.1.0 0.0.0.3

interface Tunnel1
no ip split-horizon eigrp 200
no ip next-hop-self eigrp 200

interface Tunnel2
no ip split-horizon eigrp 200
no ip next-hop-self eigrp 200

interface Tunnel3
no ip split-horizon eigrp 200
no ip next-hop-self eigrp 200

interface Tunnel4
no ip split-horizon eigrp 200
no ip next-hop-self eigrp 200

Конфигурация EIGRP VRF EXTERNAL на споке 2

router eigrp 200
address-family ipv4 vrf EXTERNAL autonomous-system 200
eigrp router-id 172.17.2.1
passive-interface GigabitEthernet0/0/1
eigrp stub
network 172.16.1.0 0.0.0.255
network 172.16.2.0 0.0.0.255
network 172.16.3.0 0.0.0.255
network 172.16.4.0 0.0.0.255
network 172.17.2.0 0.0.0.3

Для опорной сети вместо EIGRP можно выбрать OSPF.

Конфигурация OSPF VRF EXTERNAL на хабе

router ospf 200 VRF EXTERNAL
router-id 172.17.1.1
passive-interface GigabitEthernet0/0/1
network 172.16.1.0 0.0.0.255 area 0
network 172.16.2.0 0.0.0.255 area 0
network 172.16.3.0 0.0.0.255 area 0
network 172.16.4.0 0.0.0.255 area 0
network 172.17.1.0 0.0.0.3 area 1

interface Tunnel1
ip ospf network broadcast
ip ospf priority 10

interface Tunnel2
ip ospf network broadcast
ip ospf priority 10

interface Tunnel3
ip ospf network broadcast
ip ospf priority 10

interface Tunnel4
ip ospf network broadcast
ip ospf priority 10

Конфигурация OSPF VRF EXTERNAL на споке 2

router ospf 200 VRF EXTERNAL
router-id 172.17.2.1
passive-interface GigabitEthernet0/0/1
network 172.16.1.0 0.0.0.255 area 0
network 172.16.2.0 0.0.0.255 area 0
network 172.16.3.0 0.0.0.255 area 0
network 172.16.4.0 0.0.0.255 area 0
network 172.17.2.0 0.0.0.3 area 2

interface Tunnel1
ip ospf network broadcast
ip ospf priority 0

interface Tunnel2
ip ospf network broadcast
ip ospf priority 0

interface Tunnel3
ip ospf network broadcast
ip ospf priority 0

interface Tunnel4
ip ospf network broadcast
ip ospf priority 0

VRF INTERNAL

VRF, в котором находится только сеть точка точка между внутренним интерфейсом криптошлюза и маршрутизатором. Назовем ее внутренней сетью криптошлюза.

INTERNAL – это front-door VRF для туннеля 100.

В этом VRF настроена статическая маршрутизация через внутренний интерфейс криптошлюза ко всем аналогичным внутренним сетям всех остальных криптошлюзов.Так мы получаем маршруты к ip адресам, разученным через NHRP туннеля 100.

Криптошлюз шифрует только пакеты, исходящие из интерфейса маршрутизатора, а расшифровывает только пакеты пришедшие из аналогичных интерфейсов других маршрутизаторов.

Конфигурация VRF INTERNAL на хабе (на споках настройки аналогичные, меняются только ip адреса и маршруты)

ip vrf INTERNAL

interface GigabitEthernet0/0/2
ip vrf forwarding INTERNAL
ip address 172.18.1.1 255.255.255.252

ip route vrf INTERNAL 172.18.0.0 255.255.0.0 172.18.1.2

Глобальный VRF

В этом VRF находятся интерфейсы локальной сети офиса и интерфейс туннеля 100. Глобальный VRF является inside VRF для туннеля 100.

В этом VRF настроена динамическая маршрутизация для обеспечения доступа между локальными сетями всех офисов.

Динамически отдаются маршруты локальных сетей офиса, принимаются аналогичные маршруты локальных сетей остальных офисов.

Конфигурация глобального VRF на хабе

interface GigabitEthernet0/0/0.12
encapsulation dot1Q 12
ip address 192.168.1.1 255.255.255.0

interface Tunnel100
bandwidth 100000
ip address 172.19.0.1 255.255.255.0
ip nhrp authentication DMVPN0
ip nhrp network-id 100
ip nhrp registration timeout 120
ip nhrp redirect
tunnel source GigabitEthernet0/0/2
tunnel mode gre multipoint
tunnel key 100
tunnel vrf INTERNAL

Конфигурация глобального VRF на споке 2

GigabitEthernet0/0/0.22
encapsulation dot1Q 22
ip address 192.168.2.1 255.255.255.0

interface Tunnel100
bandwidth 100000
ip address 172.19.0.2 255.255.255.0
ip nhrp authentication DMVPN0
ip nhrp map multicast 172.18.1.1
ip nhrp map 172.19.0.1 172.18.1.1
ip nhrp network-id 100
ip nhrp nhs 172.19.0.1
ip nhrp registration timeout 120
ip nhrp shortcut
tunnel source GigabitEthernet0/0/2
tunnel mode gre multipoint
tunnel key 100
tunnel vrf INTERNAL

Конфигурация EIGRP глобального VRF на хабе

router eigrp 100
eigrp router-id 172.19.0.1
passive-interface default
no passive-interface Tunnel100
network 172.19.0.0 0.0.0.255
network 192.168.1.0 0.0.0.255

interface Tunnel100
no ip split-horizon eigrp 100
no ip next-hop-self eigrp 100

Конфигурация EIGRP глобального VRF на споке 2

router eigrp 100
eigrp router-id 172.19.0.2
passive-interface default
no passive-interface Tunnel100
eigrp stub
network 172.19.0.0 0.0.0.255
network 192.168.2.0 0.0.0.255

Для защищенной сети вместо EIGRP можно выбрать OSPF.

Конфигурация OSPF глобального VRF на хабе

router ospf 100
router-id 172.19.0.1
passive-interface default
no passive-interface Tunnel100
network 172.19.0.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 1

interface Tunnel100
ip ospf network broadcast
ip ospf priority 10

Конфигурация OSPF глобального VRF на споке 2

router ospf 100
router-id 172.19.0.2
passive-interface default
no passive-interface Tunnel100
network 172.19.0.0 0.0.0.255 area 0
network 192.168.2.0 0.0.0.255 area 2

interface Tunnel100
ip ospf network broadcast
ip ospf priority 0

Этапы прохождения пакета от станции в локальной сети до шлюза провайдера

1. Пакет из локальной сети приходит на интерфейс маршрутизатора в глобальном VRF.

2. Маршрутизатор добавляет к пакету GRE заголовок и отправляет пакет в VRF INTERNAL на внутренний интерфейс криптошлюза.

3. Криптошлюз шифрует пакет и отправляет его на интерфейс маршрутизатора в VRF EXTERNAL.

4. Маршрутизатор добавляет к зашифрованному пакету GRE заголовок и отправляет на шлюз провайдера в VRF WAN1 (или WAN2).

Конфигурация криптошлюзов

Поскольку управление Континентами осуществляется через GUI, то будем показывать скрины настроек.

Криптошлюзы строят между собой однонаправленные VPN каналы. В топологии FullMesh количество таких каналов для n узлов рассчитывается по формуле n*(n-1).

Статическая маршрутизация на криптошлюзе представляет из себя одну запись – маршрут по умолчанию через его внешний интерфейс.

Настройка правил фильтрации на криптошлюзах также минимальная. Изначально созданы по одному объекту «IP адрес tunnel source защищаемого туннеля» на каждый криптошлюз. Все эти объекты объединены в одну группу.

Создано одно единственное правило, разрешающее GRE трафик с группы на группу.

После добавления нового криптошлюза нужно будет создать новый объект «IP-адрес tunnel source» и добавить его в группу, чтобы разрешить работу нового спока.

На криптошлюзах групповое правило автоматически разворачивается в несколько. Количество правил на каждом устройстве определяется формулой (n-1)*2, где n – количество узлов.

Вот так, например, выглядит список правил для криптошлюза на хабе:

@0 pass in quick on igb1 inet proto gre from 172.18.1.1 to <dstset_0:3> keep state (if‑bound) label “P0516”
@1 pass out quick on igb2 inet proto gre from 172.18.1.1 to <dstset_2:2> keep state (if‑bound) label “P0516”
@2 pass in quick on igb2 inet proto gre from <srcset_1:2> to 172.18.1.1 keep state (if‑bound) label “P0516”
@3 pass out quick on igb1 inet proto gre from <srcset_2:3> to 172.18.1.1 keep state (if‑bound) label “P0516”

Эксплуатация криптошлюзов в этой топологии сводится к периодической смене ключей, что, кстати, можно автоматизировать штатными средствами. Поэтому ее можно безболезненно передать в службы информационной безопасности, даже если там нет персонала, владеющими сетевыми технологиями.

С Континентов можно собирать статистику по SNMP. Для контроля загрузки процессора, памяти, дисков и сетевых интерфейсов практически без доработок подошел Zabbix шаблон «OS Linux SNMP». Для контроля специфических вещей (VPN каналы, парные связи, ключи), разумеется, придется писать свои шаблоны.

Континенты версии 3.9.3 научились экспортировать логи на SysLog сервер, чем мы тоже воспользовались.

Оборудование на стенде

Маршрутизаторами офисов на стенде выступали старые, но надежные Cisco 2921. Мы тестировали криптошлюзы Континент 3.9 IPC 10, IPC R10, IPC 50. Еще на стенде использовались снятые с производства IPC 100.

Информация об загрузке процессора, памяти, дисков и интерфейсов собиралась по SNMP на сервер Zabbix. Для сбора информации с криптошлюзов использовались выделенные интерфейсы.

Генерацию трафика для анализа пропускной способности сети осуществляли с помощью программы iperf3. Использовали трафик TCP. MSS пакета был установлен в 1338 байт.

Сразу оговоримся, что это были не полноценные нагрузочные испытания. Cisco 2921 просто не способны в такой схеме полностью загрузить GRE трафиком модели криптошлюзов начиная с IPC-50.

Целью испытаний был подбор моделей оборудования под пропускные способности существующих интернет каналов.

Результаты

В ходе испытаний было выяснено, что модели IPC 10 и IPC R10 способны полностью загрузить в обе стороны канал в 50 Мбит/c немного недотягивая до 100 Мбит/c.

IPC 50 полностью загружает в обе стороны канал в 100 Мбит/c. Однако, при таком трафике уже начинает реже отдавать по SNMP информацию об загрузке интерфейсов, в результате чего на графиках появляются провалы. При небольшом снижении трафика от станций, например 90 Мбит/c в одну сторону и 70 Мбит/c в другую криптошлюз своевременно отвечает на SNMP запросы.

Поговорим подробнее про сужение пропускной способности канала из за уменьшения MTU.

В документации указано, что overhead пакета, проходящего через криптошлюз, составляет 52 байта.

Накладные расходы на DMVPN GRE составят 28 байт. (24 байта – обычный GRE и 4 байта – ключ DMVPN). Чтобы пакет ушел через WAN интерфейс без фрагментации, его размер, в теории, мы должны уменьшить следующим образом:

• 1500 байт – размер пакета на входе WAN интерфейса;

• 1472 байт – размер пакета на входе опорного туннеля) (1500-28);

• 1420 байт – размер пакета на входе внутреннего интерфейса криптошлюза (1472-52);

• 1392 байт – размер пакета на входе защищенного туннеля (1420-28).

При съеме дампа трафика с интерфейсов теория подтвердилась.

Чтобы пропускать пакеты без фрагментации необходимо будет значительно понизить их размер. На стенде мы установили MTU на рабочих станциях в 1378 байт (с запасом).

Тройная инкапсуляция приводит к тому, что за счет увеличения на каждом этапе объема трафика, пропускная способность самой сети становится ниже, чем пропускная способность интернет канала.

На графике показаны приросты объема передаваемого трафика на каждом этапе инкапсуляции. При среднем трафике из локальной сети примерно в 90 Мбит/c на интернет канале занято почти 100 Мбит/c.

По нашим измерениям получилось, что криптошлюз вносит задержку около 3 мс, а двойная GRE инкапсуляция добавляет к задержке еще 5 мс.

Еще одна проблема этой схемы в том, что пакеты протоколов динамической маршрутизации туннелей опорной сети передаются практически в открытом виде, только инкапсулированые в GRE. Следует озаботиться рисками возможных атак на протоколы маршрутизации.

---

Распределение сессий криптошлюза по нескольким ядрам происходит на основании L3 хэш или L2 хэш. По умолчанию для криптошлюза такое распределение пакетов разрешено.

В нашей схеме наиболее характерны соединения с центральным офисом. У такого трафика пара источник – получатель всегда будет одинаковая (tunnel source – tunnel destination).

В этом случае весь трафик офиса будет шифроваться одним ядром. Поэтому, при необходимости задействовать все ядра, нужно будет запретить распределение сессий. Однако, разработчики предупреждают, что в этом случае пакеты будут обрабатываются асинхронно, и, хотя общая производительность повышается, но понижается качество одной сессии.

В конфигурации стенда отсутствует ряд необходимых в промышленной эксплуатации настроек. Например, никак не организована защита интерфейсов, подключенных к интернету. Как минимум на них нужно повесить списки доступа. Также, вместо маршрута по умолчанию в интернет, можно использовать точные маршруты по списку узлов.

Для центрального и отдельных важных узлов необходимо аппаратное резервирование. Предлагаемое вендором объединение криптошлюзов в кластер имеет ряд недостатков. Кластер работает в режиме active-passive. Поэтому, пассивный член кластера будет простаивать. В ранних версиях время переключения кластера было слишком большим, но с этим разработчики нещадно борются, и в последних версиях прошивки заявленная скорость переключения снижена до двух секунд.

Мы вместо кластеризации криптошлюзов планируем использовать два транспортных туннеля с включенным BFD, каждый из туннелей терминируется через один криптошлюз. Во время нормальной работы трафик будет балансироваться через два туннеля и, соответственно, через два криптошлюза.

Для передачи BFD пакетов по защищенной сети нужно модифицировать правило на криптошлюзах, разрешив BFD трафик.

В заключение можно сказать, что решение можно использовать для любых схем построения туннелей, не обязательно Hub and Spoke.

Главное, понять основную идею. Раньше использовался один шифрованный туннель с front-door VRF в интернете и inside VRF в локальной сети офиса.

В новой схеме у нас будут два нешифрованных туннеля. Опорный туннель с front-door VRF в интернете и inside VRF во внешней сети криптошлюза. Второй туннель с front-door VRF во внутренней сети криптошлюза и inside VRF в локальной сети офиса.