Главная
/
Продукты
/
Типовые сценарии применения
/
С-Терра Шлюз
/
Примеры дополнительных возможностей
/
Настройка DMVPN (phase 2) dual cloud с протоколом динамической маршрутизации iBGP

Настройки multiwan

С-Терра Шлюз / Примеры дополнительных возможностей ~30 мин чтения 26630 слов

Настройка DMVPN (phase 2) dual cloud с протоколом динамической маршрутизации iBGP

Скачать в формате PDF

Настоящий документ содержит описание способа совместного использования Продуктов компании ООО «С-Терра СиЭсПи» и Продуктов третьих производителей.

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

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

Введение

Данная инструкция описывает настройку DMVPN для сетевых инженеров, знакомых с данной технологией по оборудованию Cisco, а также разбирающихся в базовых настройках «С-Терра Шлюз».

Краткое описание технологии DMVPN

Технология DMVPN (англ. Dynamic Multipoint Virtual Private Network – динамическая многоточечная виртуальная частная сеть) позволяет динамически строить защищенные соединения без необходимости описывать каждое соединение в политике безопасности, что существенно упрощает масштабирование крупных сетей с полносвязной топологией. Автоматическое построение полносвязной защищенной топологии достигается за счет применения динамических протоколов маршрутизации и таких протоколов как NHRP (англ. Next Hop Resolution Protocol – протокол разрешения следующего узла) и multipoint GRE (англ. Generic Routing Encapsulation).

Предварительные требования

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

Для переноса запросов и сертификатов между криптошлюзами и центром выпуска сертификатов требуется USB Flash накопитель.

Требования к квалификации администратора

Администратор должен обладать обширными знаниями в области сетевой информационной безопасности, иметь опыт работы с аналогичным оборудованием/программным обеспечением, знать и понимать следующие технологии и протоколы: PKI, IPsec, NAT, Firewall, routing, switching, NHRP, GRE, OSPF, BGP, VRRP.

Администратор должен быть ознакомлен со сценарием «Организация защищенного взаимодействия между подсетями центрального офиса и филиалов посредством IPsec VPN туннеля (протокол IPv4)». Далее по тексту он будет называться базовым сценарием.

Требования к инфраструктуре

Требования к устройствам.
1. «С-Терра Шлюз».
1.1 Устройства «С-Терра Шлюз» должны быть инициализированы (подробнее на http://doc.s-terra.ru раздел С-Терра Шлюз -> С-Терра Шлюз <версия> -> «Подключение ПАК и инициализация С-Терра Шлюз на вычислительных системах архитектуры Intel x86-64»).

В «С-Терра Шлюз» версии 5.0 появилась возможность пройти инициализацию через интерфейс управления (management) по SSH, данная процедура и ее ограничения описаны в документации и на портале https://doc.s-terra.ru.

2. Центр выпуска сертификатов.
2.1 Должен быть настроен центр выпуска сертификатов (удостоверяющий центр, далее УЦ) для IPsec. Устройство с именем Certification_authority на схеме.
2.2 Для выпуска цифровых сертификатов допускается использование встроенного в OC Windows Server 2016 (или новее) удостоверяющего центра совместно с сертифицированным СКЗИ «КриптоПро» CSP 5.0 R2 (или новее).
2.3 Для тестовых целей можно использовать тестовый УЦ от «КриптоПро» (веб-интерфейс: https://testgost2012.cryptopro.ru/certsrv/certrqxt.asp).

Категорически запрещено использование тестового УЦ от «КриптоПро» в производственной (боевой) эксплуатации, так как в данном случае отсутствует возможность контролировать процесс выпуска сертификатов и, соответственно, процедуру аутентификации.

3. HTTP сервер для распространения списка отозванных сертификатов.
3.1 Функционирующий HTTP сервер для распространения списка отозванных сертификатов (СОС). Устройство с именем CRL_distribution_point на схеме. Если по объективным причинам использование СОС не представляется возможным или не требуется, то проверку СОС можно отключить в CLI «С-Терра Шлюз» (при соблюдении правил пользования).

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

Требования к сетевому взаимодействию.
1. Между устройствами стенда должна быть обеспечена IP связность.

Общая схема стенда

Рисунок 1. Общая схема стенда

Общая логика работы

Данная инструкция описывает настройку технологии DMVPN на криптошлюзах безопасности «С-Терра Шлюз» 5.0. Будет настроено две mGRE подсети (dual cloud) и использован протокол динамической маршрутизации iBGP. В каждой mGRE подсети будет по два Hub. По окончании настройки реализуется возможность построения динамических защищенных соединений между всеми подсетями филиалов, а также подсетями филиалов и центрального офиса (см. Рисунок 1).

Стенд состоит из 20 устройств:

«С-Терра Шлюз 5.0»: Hub1, Hub2, Hub3, Hub4, Spoke1‑n1, Spoke1‑n2, Spoke2.
Роутеры на базе ОС Debian 12: Int‑router‑Hub, Ext‑router‑Hub1, Ext‑router‑Hub2, Ext‑router‑Hub3, Ext‑router‑Hub4, Core‑router, Ext‑router1‑Spoke1, Ext‑router2‑Spoke1.
Управляемые коммутаторы: Int‑switch‑Hub, Int‑switch‑Spoke1.
Персональные компьютеры: Host‑b‑hub, Host‑b‑spoke1, Host‑b‑spoke2.

Роутеры на базе ОС Debian 12 выбраны в качестве примера. В общем случае могут быть использованы любые маршрутизаторы, поддерживающие функции NAT и динамической маршрутизации (NAT в ОС Debian 12 будет реализован при помощи iptables, а динамическая маршрутизация при помощи пакета FRR).

Из-за особенностей реализации криптошлюзов безопасности «С-Терра Шлюз» 5.0, для совместимости работы «С-Терра Шлюз» 4.3 потребуется дополнительная настройка. Подробнее про совместимость «С-Терра Шлюз» 5.0 с «С-Терра Шлюз» 4.3 описано в главе «Совместимость «С-Терра Шлюз» 5.0 с «С-Терра Шлюз» 4.3».

Размещение устройств.
1. В центральном офисе размещаются: центр выпуска сертификатов (Certification_authority), 4 криптошлюза «С-Терра Шлюз» (Hub1, Hub2, Hub3 и Hub4) версии 5.0, 4 маршрутизатора, преобразующие IPv4 адреса (Ext‑router‑Hub1, Ext‑router‑Hub2, Ext‑router‑Hub3, Ext‑router‑Hub4), маршрутизатор, анонсирующий в BGP маршрут до защищаемой подсети центрального офиса (Int‑router‑Hub), и персональный компьютер (Host‑b‑hub).
2. В филиале № 1 размещаются: 2 криптошлюза «С-Терра Шлюз» (Spoke1‑n1 и Spoke1‑n2) версии 5.0, 2 маршрутизатора, преобразующие IPv4 адрес, и персональный компьютер (Host‑b‑spoke1).
3. В филиале № 2 размещаются: криптошлюз «С-Терра Шлюз» (Spoke2) версии 5.0 и персональный компьютер (Host‑b‑spoke2).
4. В неконтролируемом сегменте размещаются: маршрутизатор (Core‑router) и HTTP сервер для распространения списка отозванных сертификатов (CRL_distribution_point).
Подключение к сети Интернет.
В данном сценарии для эмуляции сети Интернет используется маршрутизатор Core‑router.
Подключение к сети Интернет на устройствах «С-Терра Шлюз» будет считаться успешным, если по протоколу ICMP (или «ping») будет доступен HTTP сервер для распространения списка отозванных сертификатов (устройство CRL_distribution_point на схеме).
1. Криптошлюзы Hub1, Hub2, Hub3 и Hub4 подключаются к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизаторы Ext‑router‑Hub1, Ext‑router‑Hub2, Ext‑router‑Hub3 и Ext‑router‑Hub4 соответственно).
2. Криптошлюзы Spoke1‑n1 и Spoke1‑n2 подключается к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизатор Ext-router1-Spoke и Ext-router2-Spoke соответственно).
3. Криптошлюз Spoke2 подключается к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизатор Core‑router).
Параметры шифрования IPsec.
Весь трафик между центральным офисом (192.168.100.0/24) и филиалами (192.168.1.0/24, 192.168.2.0/24) инкапсулируется в GRE, а GRE трафик защищается с использованием алгоритмов ГОСТ и протокола IPsec в транспортном IPv4 режиме.
Между криптошлюзами в филиалах и центральным офисом устанавливаются статические IPsec туннели. Инициатором подключения является служебный трафик протоколов NHRP/BGP.
Между филиальными криптошлюзами устанавливаются динамические IPsec туннели. Инициатором построения туннелей является реальный трафик защищаемых подсетей филиалов.

Режим работы IPsec туннеля должен быть транспортным. Работа IPsec туннеля в туннельном режиме не поддерживается для сети DMVPN на криптошлюзах безопасности «С-Терра Шлюз 5.0».

1. Параметры протокола IKE
1.1 Параметры протокола IKE для версии 5.0:

Аутентификация при помощи цифровых сертификатов, алгоритм подписи – ГОСТ Р 34.10-2012 (ключ 256 бит);
Алгоритм шифрования – ГОСТ Р 34.12-2015 Магма (ключ 256 бит);
Алгоритм вычисления хеш-функции – ГОСТ Р 34.11-2012 ТК26 Стрибог (ключ 256 бит);
Алгоритм выработки общего ключа (аналог алгоритма Диффи-Хеллмана) – VKO_GOSTR3410_2012_256 (ключ 256 бит).

1.2 Параметры протокола IKE для совместимости с версией 4.3:

Аутентификация при помощи цифровых сертификатов, алгоритм подписи – ГОСТ Р 34.10-2012 (ключ 256 бит);
Алгоритм шифрования – ГОСТ 28147-89 (ключ 256 бит);
Алгоритм вычисления хеш-функции – ГОСТ Р 34.11-2012 ТК26 (ключ 256 бит);
Алгоритм выработки общего ключа (аналог алгоритма Диффи-Хеллмана) – VKO_GOSTR3410_2012_256 (ключ 256 бит).

2. Параметры протокола ESP
2.1 Параметры протокола ESP для версии 5.0:

Комбинированный алгоритм шифрования и имитозащиты (контроль целостности) – ГОСТ Р 34.12-2015 Магма в режиме MGM (ключ 256 бит).

2.2 Параметры протокола ESP для совместимости с версией 4.3:

Комбинированный алгоритм шифрования и имитозащиты (контроль целостности) – ESP_GOST-4M-IMIT (ключ 256 бит).

Параметры межсетевого экранирования.
Для пакетов, которые не защищаются IPsec применяются следующие правила фильтрации:
1. Для «С-Терра Шлюз» версии 5.0:
1.1 На LAN интерфейсах IPv4 трафик не контролируется.
1.2 На LAN интерфейсах IPv6 трафик заблокирован.
1.3 На WAN интерфейсах разрешен входящий IPv4 трафик:
1.3.1. Протокол UDP порты 500 и 4500 – для IKE и NAT-Traversal (ESP in UDP).
1.3.2. Протокол ICMP – для проверки доступности криптошлюза и работы механизма PathMTUd.
1.3.3. Протокол ESP (номер 50) – для работы IPsec.
1.3.4. Весь TCP и UDP трафик, для которого есть исходящее соединение (это динамические правила, которые создаются при помощи stateful фильтрации).
1.4 На WAN интерфейсах заблокирован исходящий незашифрованный GRE трафик и транзитный трафик до приватных IP адресов.
1.5 На WAN интерфейсах IPv6 трафик заблокирован.
1.6 На WAN интерфейсах инспектируются все исходящие локальные и транзитные IPv4 соединения для протоколов TCP и UDP. На основе результатов инспектирования осуществляется фильтрация входящего трафика с учетом состояния сессии (stateful).
2. Для «С-Терра Шлюз» версии 4.3(в сценарии не используется, указано для совместимости«С-Терра Шлюз» версии 5.0 с «С-Терра Шлюз» версии 4.3):

Использование stateful фильтрации для версии 4.3 нежелательно, поэтому рекомендуется использовать статические правила (ACL).

2.1 На LAN интерфейсах IPv4 трафик не контролируется.
2.2 На WAN интерфейсах заблокирован исходящий незашифрованный GRE трафик и трафик до приватных IP адресов.
2.3 На LAN и WAN интерфейсах IPv6 трафик заблокирован (протокол IPv6 отключен в ядре операционной системы).
Отказоустойчивость.
Отказоустойчивость обеспечивается протоколом NHRP и протоколом динамической маршрутизации BGP. Филиальные криптошлюзы одновременно регистрируются по протоколу NHRP на Hub1, Hub2, Hub3 и Hub4. Hub1 и Hub2 находятся в одной mGRE-подсети (10.10.10.0/24), а Hub3 и Hub4 находятся во второй mGRE-подсети (10.10.20.0/24).

Поддержка нескольких Hub в одной mGRE-подсети осуществляется, начиная с «С-Терра Шлюз» версии 5.0.

1. Динамическая маршрутизация.
Динамическая маршрутизация между криптошлюзами филиалов и центрального офиса обеспечивается протоколом Internal BGP. Все криптошлюзы безопасности находятся в одной автономной системе №65000.
Криптошлюзы безопасности, установленные в филиалах, отсылают маршрутную информацию о защищаемых подсетях только криптошлюзам в центральный офис, соответственно, получение маршрутной информации происходит тоже только из центрального офиса. Маршруты до защищаемых подсетей устанавливаются через mGRE-интерфейсы. Центральные криптошлюзы являются роут-рефлекторами (route-reflector), а филиальные – роут-рефлектор клиентами (route-reflector client).
Между криптошлюзами в центральном офисе и роутером Int-router-Hub (AS №65001) передача маршрутной информации обеспечивается при помощи External BGP. Между криптошлюзами в центральном офисе передача маршрутной информации не обеспечивается.
На каждом криптошлюзе филиала и на роутере Int-router-Hub будет набор резервирующих друг друга маршрутов для каждой из защищаемых подсетей, из которых будет использоваться лучший из доступных в настоящий момент. Выбор лучшего из доступных маршрутов будет настроен по правилу статического приоритета, которые будут определены при конфигурировании.
2. Отказоустойчивость филиала № 1.
Повышение отказоустойчивости Филиала № 1 обеспечивается использованием протокола VRRP на LAN интерфейсе криптошлюзов. Криптошлюзы Spoke1‑n1 и Spoke1‑n2 объединяются в отказоустойчивый кластер, работающий на базе протокола VRRP в режиме Master/Backup. Протокол VRRP реализуется сервисом keepalived.

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

Нода, находящаяся в состоянии Master, владеет VIP адресом в доверенном сегменте и, соответственно, обрабатывает трафик. Нода, находящаяся в состоянии Backup или Fault, не владеет VIP адресом.
При помощи скрипта /etc/keepalived/scripts/check_ping сервис keepalived дополнительно контролирует состояние канала Интернет-провайдера посредством проверки доступности заданных узлов по протоколу ICMP. Если все заданные узлы недоступны определенное время, то нода кластера переходит в состояние FAULT, что приводит к переключению кластера на резервную ноду (в случае, если она была в состоянии BACKUP), которая подключена к другому Интернет-провайдеру. Резервирование подключения к сети Интернет обеспечивается следующим принципом – каждая нода кластера филиала подключается к соответствующему Интернет-провайдеру.
При помощи конфигурационного файла /etc/keepalived/notify_common.conf и скрипта /etc/keepalived/scripts/notify_common обеспечивается следующая логика. Если нода переходит в состояние BACKUP или FAULT, то BGP пиринг с центральными криптошлюзами выключается. Если нода переходит в состояние MASTER, то BGP пиринг с центральными криптошлюзами включается.
Также в настройках FRR добавляется маршрут до защищаемой сети центрального офиса через VIP адрес с дистанцией 240. Таким образом, если был получен маршрут по BGP, он будет более приоритетным чем маршрут через VIP адрес.

На портах коммутатора Int‑switch‑Spoke1, подключенных к криптошлюзам, обязательно должен быть включен режим portfast.

3. Отказоустойчивость филиала № 2.
Отказоустойчивость филиала реализована резервированием каналов связи и управлением резервированными каналами связи при помощи сервиса «multiwan». Режим работы каналов основной/резервный. При отказе основного канала связи происходит переключение на работу через резервный канал связи (если он был доступен). При восстановлении работы основного канала связи происходит переключение на работу через основной канал связи.
Маcштабирование.
Реальные сети DMVPN могут содержать существенно больше Spoke’ов, чем в настоящем сценарии, где демонстрируются основные возможности реализации DMVPN сетей на криптошлюзах версии 5.0.

Для DMVPN сетей, построенных на основе криптошлюзов версии 5.0, максимальное рекомендуемое количество Spoke’ов составляет не более 1000 Spoke’ов (при условии достаточной производительности Hub’а).

Рекомендации по настройке больших DMVPN сетей приведены в Приложении.

Настройка стенда

Настройка устройства Host-b-hub

На данном устройстве должны быть настроены IP-адреса и маршрутизация в соответствии с общей схемой стенда (см. Рисунок 1). В приложении представлены сетевые настройки (содержимое файла /etc/network/interfaces).

Настройка устройства Host-b-spoke1

Настройка устройства Host-b-spoke2

Настройка устройства Int-switch-Hub

На данном устройстве сетевые интерфейсы, коммутирующие криптошлюзы Hub1, Hub2, Hub3, Hub4 и роутер Int‑router‑Hub, должны быть в одном VLAN и в режиме portfast.

Настройка устройства Int-switch-Spoke1

На данном устройстве сетевые интерфейсы, коммутирующие криптошлюзы Spoke1‑n1, Spoke1‑n2 и персональный компьютер Host‑b‑spoke1, должны быть в одном VLAN и в режиме portfast.

Настройка устройства Core-router

На данном устройстве должны быть настроены IP-адреса в соответствии с общей схемой стенда (см. Рисунок 1). В приложении представлены сетевые настройки (содержимое файла /etc/network/interfaces).

Настройка устройства Ext-router-Hub1

На данном устройстве должно быть настроено:

IP-адреса и маршрутизация в соответствии с общей схемой стенда (см. Рисунок 1). В приложении представлены сетевые настройки (содержимое файла /etc/network/interfaces).
Source NAT/Destination NAT. В приложении представлены настройки iptables (содержимое файла /etc/iptables.rules).

Настройка устройства Ext-router-Hub2

На данном устройстве должно быть настроено:

IP-адреса и маршрутизация в соответствии с общей схемой стенда (см. Рисунок 1). В приложении представлены сетевые настройки (содержимое файла /etc/network/interfaces).
Source NAT/Destination NAT. В приложении представлены настройки iptables (содержимое файла /etc/iptables.rules).

Настройка устройства Ext-router-Hub3

На данном устройстве должно быть настроено:

IP-адреса и маршрутизация в соответствии с общей схемой стенда (см. Рисунок 1). В приложении представлены сетевые настройки (содержимое файла /etc/network/interfaces).
Source NAT/Destination NAT. В приложении представлены настройки iptables (содержимое файла /etc/iptables.rules).

Настройка устройства Ext-router-Hub4

На данном устройстве должно быть настроено:

IP-адреса и маршрутизация в соответствии с общей схемой стенда (см. Рисунок 1). В приложении представлены сетевые настройки (содержимое файла /etc/network/interfaces).
Source NAT/Destination NAT. В приложении представлены настройки iptables (содержимое файла /etc/iptables.rules).

Настройка устройства Ext-router1-Spoke1

На данном устройстве должно быть настроено:

IP-адреса и маршрутизация в соответствии с общей схемой стенда (см. Рисунок 1). В приложении представлены сетевые настройки (содержимое файла /etc/network/interfaces).
Source NAT/Destination NAT. В приложении представлены настройки iptables (содержимое файла /etc/iptables.rules).

Настройка устройства Ext-router2-Spoke1

На данном устройстве должно быть настроено:

IP-адреса и маршрутизация в соответствии с общей схемой стенда (см. Рисунок 1). В приложении представлены сетевые настройки (содержимое файла /etc/network/interfaces).
Source NAT/Destination NAT. В приложении представлены настройки iptables (содержимое файла /etc/iptables.rules).

Настройка устройства Int-router-Hub

На данном устройстве должно быть настроено:

IP-адреса в соответствии с общей схемой стенда (см. Рисунок 1). В приложении представлены сетевые настройки (содержимое файла /etc/network/interfaces).
Динамическая маршрутизация. В приложении представлены настройки FRR.

Настройка устройства Hub1

Настройка может осуществляться и удаленно (по SSH), но исключительно по доверенному каналу связи. Доверенным каналом связи может считаться канал в пределах контролируемой зоны в случае отсутствия в нем нарушителя (в нашем примере это подсети 192.168.100.0/24, 192.168.1.0/24, 192.168.2.0/24). Доверенным каналом связи также считается канал, защищенный при помощи протокола IPsec.

Начальные настройки

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

Войдите в CLI разграничения доступа (пользователь и пароль по умолчанию: administrator, s-terra) установите правильный тип терминала и требуемую ширину, смените пароль для пользователя administrator.

Перейдите в linux bash консоль, установите пароль для пользователя root, правильное время и временную зону.

Подробная настройка с описанием команд приведена в базовом сценарии.

Настройки PKI (запросы и сертификаты)

Продукт не поддерживает разностные (delta) списки отзыва сертификатов, только базовые. Учитывайте это при выборе или развертывании УЦ.

Для аутентификации партнеров по IPsec можно использовать цифровые сертификаты, выпущенные при помощи сертифицированного СКЗИ, или предварительно распределенные ключи, созданные и введённые в соответствии с правилами пользования СКЗИ (появились в версии 5.0).

Сгенерируйте запрос на сертификат криптошлюза и сохраните этот запрос в файл на USB Flash накопителе. Доставьте файл с запросом на УЦ и выпустите по нему сертификат. Сертификат криптошлюза вместе с сертификатом УЦ доставьте на шлюз и импортируйте их в базу Продукта.

Подробная настройка с описанием команд приведена в базовом сценарии.

Настройка паролей доступа к консоли cisco-like

Войдите в cisco-like консоль и смените пароль для пользователя cscons (пароль по умолчанию: csp) и пароль на enable (пароль по умолчанию: csp).

Подробная настройка с описанием команд приведена в базовом сценарии.

Настройка сетевых параметров

Изменение состояния интерфейсов и назначение IP адресов в cisco-like консоли применяются сразу после ввода соответствующих команд. Политика безопасности применяется после выхода из режима конфигурирования.

Задайте имя устройства:

sterragate(config)#hostname Hub1

Включите WAN и LAN интерфейсы и настройте IP адрес на WAN интерфейсе в соответствии со схемой стенда:

Hub1(config)#interface TenGigabitEthernet0/0

Hub1(config-if)# ip address 100.100.100.2 255.255.255.0

Hub1(config-if)# no shutdown

Hub1(config-if)#interface TenGigabitEthernet0/1

Hub1(config-if)# ip address 192.168.255.10 255.255.255.0

Hub1(config-if)# no shutdown

Hub1(config-if)# exit

Hub1(config)#ip route 0.0.0.0 0.0.0.0 100.100.100.1

Hub1(config)#end

Проверьте доступность маршрута по умолчанию:

Hub1#ping 100.100.100.1

PING 100.100.100.1 (100.100.100.1) 100(128) bytes of data.

108 bytes from 100.100.100.1: icmp_req=1 ttl=64 time=0.404 ms

108 bytes from 100.100.100.1: icmp_req=2 ttl=64 time=0.216 ms

108 bytes from 100.100.100.1: icmp_req=3 ttl=64 time=0.232 ms

108 bytes from 100.100.100.1: icmp_req=4 ttl=64 time=0.212 ms

108 bytes from 100.100.100.1: icmp_req=5 ttl=64 time=0.230 ms

--- 100.100.100.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4002ms

rtt min/avg/max/mdev = 0.212/0.258/0.404/0.075 ms

Настройка шифрования

Настройки шифрования осуществляются из cisco-like консоли криптошлюза.

Параметры IKE:
1. Задайте общие параметры IKE:

Hub1(config)#crypto isakmp identity dn

Hub1(config)#crypto isakmp keepalive 3 3

Hub1(config)#crypto isakmp keepalive retry-count 3

Hub1(config)#crypto isakmp fragmentation

Hub1(config)#crypto isakmp security-association lifetime delta 50

Hub1(config)#crypto isakmp initiator-sessions-max 100

Hub1(config)#crypto isakmp responder-sessions-max 100

2. Создайте политику 1, описывающую алгоритмы IKE туннеля для совместимости с версией 5.0:

Hub1(config)#crypto isakmp policy 1

Hub1(config-isakmp)# encr magma

Hub1(config-isakmp)# hash stribog-256

Hub1(config-isakmp)# authentication gost-sig

Hub1(config-isakmp)# group vko2

Hub1(config-isakmp)#exit

3. Опционально: создайте политику 2, описывающую алгоритмы IKE туннеля для совместимости с версией 4.3:

Hub1(config)#crypto isakmp policy 2

Hub1(config-isakmp)# encr gost

Hub1(config-isakmp)# hash gost341112-256-tc26

Hub1(config-isakmp)# authentication gost-sig

Hub1(config-isakmp)# group vko2

Hub1(config-isakmp)#exit

4. Создайте профиль настроек ISAKMP (алгоритм IKE) под именем ALGS_PROFILE, чтобы далее его прикрепить к соответствующему разделу крипто-карты:

Hub1(config)#crypto isakmp profile ALGS_PROFILE

% A profile is deemed incomplete until it has match identity statements

Hub1(conf-isa-prof)# match identity dn

Hub1(conf-isa-prof)# set identity mapping

Hub1(conf-isa-prof)# set policy 1

Hub1(conf-isa-prof)# set policy 2

Hub1(conf-isa-prof)#exit

Примечание - В базовом сценарии для указания различающихся политик, используемых для подключения криптошлюзов версий 4.3 и 5.0, использовалось два раздела криптокарты. Эти разделы были обособлены друг от друга двумя списками доступа с непересекающимися адресными пространствами. Однако, для перевода существующей DMVPN сети с криптошлюзов версии 4.3 на версию 5.0 представляется актуальной задача сохранения существующего единого адресного пространства. В связи с этим в настоящем сценарии в отличии от базового сценария используется один раздел криптокарты как для подключения криптошлюзов версии 4.3, так и для подключения криптошлюзов версии 5.0. Так как к разделу криптокарты можно привязать только один isakmp профиль используется isakmp профиль с двумя привязанными isakmp политиками – одна для подключения криптошлюзов версии 4.3, вторая для подключения криптошлюзов версии 5.0.

Параметры IPsec:
1. Отключите обновление ключа IPsec SA по достижению определенного объема переданного трафика:

Hub1(config)# crypto ipsec security-association lifetime kilobytes unlimited

2. Создайте IPsec трансформ, задающий комбинированный алгоритм шифрования и имитозащиты ГОСТ 34.12-2015 Магма в режиме MGM для трафика (для версий 5.0):

Hub1(config)#crypto ipsec transform-set MAGMA_GOST_ENCRYPT_AND_INTEGRITY esp-magma-mgm

Hub1(cfg-crypto-trans)# mode transport

Hub1(cfg-crypto-trans)#exit

Hub1(config)#

Режим работы IPsec туннеля должен быть транспортным. В отличие от криптошлюзов версии 4.3 туннельный режим IPsec в сценарии DMVPN для криптошлюзов версии 5.0 не поддерживается и не может быть использован даже при отсутствии NAT.

3. Опционально: для совместимости с 4.3 создайте IPsec трансформ, задающий комбинированный алгоритм шифрования и имитозащиты на базе ГОСТ 28147-89 для трафика:

Hub1(config)#crypto ipsec transform-set GOST_ENCRYPT_AND_INTEGRITY esp-gost28147-4m-imit

Hub1(cfg-crypto-trans)# mode transport

Hub1(cfg-crypto-trans)#exit

Hub1(config)#

4. Создайте сетевой object-group с именем SELF для хранения в нем WAN адресов криптошлюза с целью дальнейшего его использования в ACL:

Hub1(config)#object-group network SELF

Hub1(config-network-group)#description IP on WAN interface

Hub1(config-network-group)#host 100.100.100.2

Hub1(config-network-group)#exit

5. Создайте сетевой object-group с именем PRIVATE для хранения в нем приватных подсетей с целью дальнейшего его использования в ACL:

Hub1(config)#object-group network PRIVATE

Hub1(config-network-group)#description private LANs

Hub1(config-network-group)#100.64.0.0 255.192.0.0

Hub1(config-network-group)#172.16.0.0 255.240.0.0

Hub1(config-network-group)#192.168.0.0 255.255.0.0

Hub1(config-network-group)#10.0.0.0 255.0.0.0

Hub1(config-network-group)#exit

6. Создайте список доступа (ACL) для IPv4 трафика, который нужно защищать между центральным офисом и филиалом:

Hub1(config)#ip access-list extended IPSEC_DMVPN

Hub1(config-ext-nacl)# remark special DMVPN filter

Hub1(config-ext-nacl)# permit gre object-group SELF each

Hub1(config-ext-nacl)#exit

Hub1(config)#

Примечание - Ключевое слово each позволяет строить узкие IPsec туннели для любого адреса назначения. Адрес назначения берется из IP заголовка GRE пакета. в котором находится NBMA адрес криптошлюза.
7. Опционально: создайте список доступа (ACL) для IPv4 трафика, который нужно защищать между центральным офисом и филиалом, работающим на версии криптошлюза 4.3:

Hub1(config)#object-group network MULTICAST

Hub1(config-network-group)#host 224.0.0.5

Hub1(config-network-group)#host 224.0.0.6

Hub1(config-network-group)#host 224.0.0.18

Hub1(config-network-group)#exit

Hub1(config)#ip access-list extended IPSEC_DMVPN_FOR_4.3

Hub1(config-ext-nacl)# remark special DMVPN filter for 4.3

Hub1(config-ext-nacl)# deny icmp object-group SELF any

Hub1(config-ext-nacl)# deny udp object-group SELF any

Hub1(config-ext-nacl)# deny tcp object-group SELF any

Hub1(config-ext-nacl)# deny ip object-group SELF object-group MULTICAST

Hub1(config-ext-nacl)# permit ip object-group SELF each

8. Создайте динамическую крипто-карту (имя DMAP, раздел 1) и привяжите её к статической (имя VPN, раздел 1):

Hub1(config)#crypto dynamic-map DMAP 1

Hub1(config-crypto-map)# match address IPSEC_DMVPN

Hub1(config-crypto-map)# set transform-set MAGMA_GOST_ENCRYPT_AND_INTEGRITY

Для совместимости с 4.3 требуется использовать список доступа для 4.3. А также указать комбинированный алгоритм шифрования и имитозащиты на базе ГОСТ 28147-89:

Hub1(config-crypto-map)#match address IPSEC_DMVPN_FOR_4.3

Hub1(config-crypto-map)#set transform-set MAGMA_GOST_ENCRYPT_AND_INTEGRITY GOST_ENCRYPT_AND_INTEGRITY

Обратите внимание, что в команде set transform-set важен порядок указания алгоритмов шифрования. В случае постепенного перевода криптошлюзов на объекте внедрения с версии 4.3 на 5.0 необходимо указываль алгоритмы шифрования в последовательности MAGMA_GOST_ENCRYPT_AND_INTEGRITY (обязательно первым) GOST_ENCRYPT_AND_INTEGRITY (вторым). Если указать алгоритмы шифрования в обратном порядке криптошлюзы версии 5.0 будут взаимодействовать между собой на старом алгоритме GOST_ENCRYPT_AND_INTEGRITY.

Hub1(config-crypto-map)# set isakmp-profile ALGS_PROFILE

Hub1(config-crypto-map)# set security-association mss-fix out

Hub1(config-crypto-map)# set pre-fragmentation

Hub1(config-crypto-map)# set dead-connection history off

Hub1(config-crypto-map)#exit

Hub1(config)#crypto map VPN 1 ipsec-isakmp dynamic DMAP

Hub1(config)#

9. Прикрепите созданную статическую крипто-карту к внешнему интерфейсу TenGigabitEthernet0/0:

Hub1(config)#interface TenGigabitEthernet0/0

Hub1(config-if)#crypto map VPN

Hub1(config-if)#exit

Подробная настройка с описанием команд приведена в базовом сценарии.

Настройка политики обработки СОС (CRL)

В целях безопасности настоятельно рекомендуется включать проверку списков отзыва сертификатов. Разностные списки отозванных сертификатов (delta CRL) не поддерживаются.

Включите проверку СОС и настройте автоматическую загрузку и импортирование в базу Продукта списка отозванных сертификатов с HTTP сервера CRL_distribution_point.

Подробная настройка с описанием команд приведена в базовом сценарии.

Настройка межсетевого экрана

По умолчанию на всех сетевых интерфейсах IPv6 трафик заблокирован – команда ipv6 default filtering deny, если требуется разрешить IPv6 трафик, то нужно выполнить команду ipv6 default filtering permit и далее уже фильтровать IPv6 трафик по аналогии с IPv4.

Настройка межсетевого экрана осуществляются из cisco-like консоли.

Создайте ACL с именем FIREWALL_OUT для исходящего с WAN интерфейса трафика:

Список доступа для исходящего трафика должен блокировать открытый трафик из защищаемой подсети криптошлюза в подсети RFC1918/RFC6598 (считаем, что трафик непубличных подсетей должен обязательно шифроваться), а также незашифрованный GRE.

Hub1(config)#ip access-list extended FIREWALL_OUT

Hub1(config-ext-nacl)# permit ip object-group SELF object-group PRIVATE

Hub1(config-ext-nacl)# deny ip any object-group PRIVATE

Hub1(config-ext-nacl)# deny gre any any

Hub1(config-ext-nacl)# permit ip any any

Hub1(config-ext-nacl)#exit

Создайте ACL с именем FIREWALL_IN для входящего на WAN интерфейс трафика:

Hub1(config)#ip access-list extended FIREWALL_IN

Hub1(config-ext-nacl)# permit udp any object-group SELF eq isakmp

Hub1(config-ext-nacl)# permit udp any object-group SELF eq non500-isakmp

Hub1(config-ext-nacl)# permit icmp any object-group SELF

Hub1(config-ext-nacl)# permit esp any object-group SELF

Hub1(config-ext-nacl)#exit

Примечание - Список доступа для входящего трафика разрешает входящие пакеты протоколов IKE, ESP, ICMP, а остальные блокирует только для случая, когда криптошлюз является ответчиком впервые. Если криптошлюз является инициатором или ответчиком в рамках ранее созданной сессии, то ответные пакеты будут разрешены, так как согласно алгоритму работы stateful фильтрации динамические разрешающие правила более приоритетны чем статические. Stateful фильтрация будет настроена далее в данном разделе. Динамические правила stateful фильтрации в cisco-like консоли НЕ отображаются, их можно посмотреть при помощи утилиты fwconn_mgr с параметром show.

Создайте правила инспектирования всего TCP и UDP трафика и задайте необходимое максимальное количество сессий:

Hub1(config)#ip inspect name INSPECT tcp

Hub1(config)#ip inspect name INSPECT udp

Hub1(config)#ip inspect tcp sessions-max 256000

Hub1(config)#ip inspect udp sessions-max 65536

Прикрепите списки доступа и правила инспектирования на внешний интерфейс:

Hub1(config)#interface TenGigabitEthernet0/0

Hub1(config-if)# ip access-group FIREWALL_IN in

Hub1(config-if)# ip access-group FIREWALL_OUT out

Hub1(config-if)# ip inspect INSPECT out

Hub1(config-if)#exit

Подробная настройка с описанием команд приведена в базовом сценарии.

Настройка mGRE-интерфейса

На центральных криптошлюзах должно быть по одному mGRE-интерфейсу

Настройки применяются при выходе из настройки интерфейса.

Настройки mGRE-интерфейса осуществляются из cisco-like консоли криптошлюза:

Hub1(config)#interface Tunnel1

Hub1(config-if)#ip address 10.10.10.100 255.255.255.0

Hub1(config-if)#mtu 1400

Hub1(config-if)#tunnel key 1

Hub1(config-if)#tunnel mode gre multipoint

Hub1(config-if)#tunnel ttl 64

Hub1(config-if)#tunnel tos inherit

Hub1(config-if)#end

Настройка NHRP

Настройки NHRP интерфейсов осуществляются из linux bash, чтобы попасть в linux bash выполните следующую команду в CLI разграничения доступа:

Hub1#exit

administrator@Hub1] system

Entering system shell...

root@Hub1:~#

Приведите файл /etc/opennhrp/opennhrp.conf к виду:

interface mgre_1

multicast dynamic

holding-time 90

cisco-authentication secret

non-caching

Примечание – Допустимый диапазон значения holding-time – от 30 до 150 секунд. Подробное описание параметра holding-time и ограничения по его изменению приведено в разделе Описание параметра holding-time.
Добавьте сервис OpenNHRP в автозагрузку и запустите его:

root@Hub1:~# systemctl enable opennhrp

Created symlink /etc/systemd/system/multi-user.target.wants/opennhrp.service -> /lib/systemd/system/opennhrp.service.

root@Hub1:~# systemctl start opennhrp

Настройка BGP

Динамическая маршрутизация настраивается через консоль сервиса FRR.

Добавьте сервис FRR в автозагрузку и запустите его:

root@Hub1:~# systemctl enable frr

Synchronizing state of frr.service with SysV service script with /lib/systemd/systemd-sysv-install.

Executing: /lib/systemd/systemd-sysv-install enable frr

Created symlink /etc/systemd/system/multi-user.target.wants/frr.service → /lib/systemd/system/frr.service.

root@Hub1:~# systemctl start frr

Войдите в консоль сервиса FRR, для этого нужно из linux bash набрать следующую команду:

root@Hub1:~# vtysh

Hello, this is FRRouting (version 9.0.2).

hub1#

Настройте BGP (см. описание http://docs.frrouting.org):

Hub1# configure terminal

1. Создайте route-map FROM-HUB1-OUT, которая будет менять local-preference для маршрутов, которые Hub1 получает из автономной системы 65001 (192.168.100.0/24) и ретранслирует в криптошлюзы филиалов:

Hub1(config)# route-map FROM-HUB1-OUT permit 1

Hub1(config-route-map)# set local-preference 100

Hub1(config-route-map)# exit

Примечания:

1. route-map будет изменять статический приоритет (local-preference) для объявляемых маршрутов или маршрутов, полученных по eBGP и не будет влиять на local‑preference маршрутов, полученных от Spoke-ов;

2. Обратите внимание, что рекомендуемая логика использования route‑map BGP для задания статических приоритетов в версии 5.0 отличается от рекомендовавшейся логики использования route‑map BGP в версии 4.3. Это необходимо учитывать при миграции DMVPN сети с криптошлюзов версии 4.3 на 5.0. В версии 4.3 route‑map bgp настраивались на Spoke’ах в направлении in. В версии 5.0 рекомендуется настраивать route‑map BGP и на Hub’ах, и на Spoke’ах в направлении out. Перед началом миграции DMVPN сети с криптошлюзов версии 4.3 на версию 5.0 следует проверить настройки route‑map на Spoke’ах и при необходимости предпринять меры по согласованию route‑map на Spoke’ах и Hub’ах во избежание ассиметричности трафика между Hub и Spoke’ами.

2. Включите процесс протокола BGP для автономной системы 65000 и перейдите в режим его конфигурирования:

Hub1(config)# router bgp 65000

3. Установите идентификатор маршрутизатора:

Hub1(config-router)# bgp router-id 10.10.10.100

4. Включите логирование изменения статуса (например, up, down и другие) BGP соседа в журнале работы:

Hub1(config-router)# bgp log-neighbor-changes

5. Отключите обязательное наличие BGP фильтров для обмена маршрутами по eBGP сессий:

Hub1(config-router)# no bgp ebgp-requires-policy

Примечание - Команда bgp ebgp-requires-policy включена по умолчанию и требует наличие фильтров при работе с eBGP соседями. При отсутствии входящих фильтров, маршруты не будут приниматься от eBGP соседа. При отсутствии исходящих фильтров, маршруты не будут транслироваться eBGP соседу. В настоящем сценарии отключение ebgp-requires-policy производится с целью упрощения конфигурирования.

6. Установите таймеры keepalive и hold time для BGP соседей:

Hub1(config-router)# timers bgp 3 9

Примечание - Данные настройки производятся с целью ускорения сходимости iBGP и по согласованию с Производителем могут изменяться.

7. Создайте группу spokes-ibgp с номером автономной системы 65000 для BGP соседей из mgre подсети (криптошлюзов филиалов):

Hub1(config-router)# neighbor spokes-ibgp peer-group

Hub1(config-router)# neighbor spokes-ibgp remote-as 65000

Hub1(config-router)# bgp listen range 10.10.10.0/24 peer-group spokes-ibgp

8. Измените максимальное количество BGP соседей, которые могут подключиться к криптошлюзу по BGP одновременно:

Hub1(config-router)# bgp listen limit 5000

9. Добавьте bgp соседа 192.168.255.1 с номером автономной системы 65001:

Hub1(config-router)# neighbor 192.168.255.1 remote-as 65001

10. Включите пересылку маршрутов для группы spokes-ibgp:

Hub1(config-router)# address-family ipv4 unicast

Hub1(config-router-af)# neighbor spokes-ibgp route-reflector-client

11. Включите изменение nexthop адреса для маршрутов, полученных по eBGP, на адрес Hub1:

Hub1(config-router-af)# neighbor spokes-ibgp next-hop-self

Примечание - Чтобы изменять next-hop адреса маршрутов, полученных по iBGP, можно использовать команду «neighbor spokes-ibgp next-hop-self force». В этом случае трафик между филиалами будет идти через центр (Аналог первой фазы DMVPN).

12. Примените route-map FROM-HUB1-OUT на отправленные маршруты к соседям из группы spokes-ibgp:

Hub1(config-router-af)# neighbor spokes-ibgp route-map FROM-HUB1-OUT out

Примечание - Для данного сценария local-preference будет изменён для ретранслируемого маршрута до 192.168.100.0/24.

13. Сохраните изменения:

Hub1(config-router-af)# end

Hub1# write

Note: this version of vtysh never writes vtysh.conf

Building Configuration...

Warning: /etc/frr/frr.conf.sav unlink failed

Integrated configuration saved to /etc/frr/frr.conf

[OK]

В Приложении представлены тексты конфигураций для криптошлюза Hub1:

текст консоли cisco-like;
Содержимое /etc/opennhrp/opennhrp.conf;
Содержимое /etc/frr/frr.conf.

Настройка устройства Hub2

Настройка устройства Hub2 осуществляется аналогично устройству Hub1 с учетом соответствующих IP-адресов (см. Рисунок 1). В настройках FRR значение local-preference должно быть равно 75.

Значение mGRE key на Hub1 и на Hub2 должны совпадать. Но должен отличаться от значения mGRE key на Hub3 и Hub4.

В Приложении представлены тексты конфигураций для криптошлюза Hub2:

текст консоли cisco-like;
Содержимое /etc/opennhrp/opennhrp.conf;
Содержимое /etc/frr/frr.conf.

Настройка устройства Hub3

Настройка устройства Hub3 осуществляется аналогично устройству Hub1 с учетом соответствующих IP-адресов (см. Рисунок 1). В настройках FRR значение local-preference должно быть равно 50.

Значение mGRE key на Hub3 и на Hub4 должны совпадать. Но должен отличаться от значения mGRE key на Hub1 и Hub2.

В Приложении представлены тексты конфигураций для криптошлюза Hub3:

текст консоли cisco-like;
Содержимое /etc/opennhrp/opennhrp.conf;
Содержимое /etc/frr/frr.conf.

Настройка устройства Hub4

Настройка устройства Hub4 осуществляется аналогично устройству Hub1 с учетом соответствующих IP-адресов (см. Рисунок 1). В настройках FRR значение local-preference должно быть равно 25.

Значение mGRE key на Hub3 и на Hub4 должны совпадать. Но должен отличаться от значения mGRE key на Hub1 и Hub2.

В Приложении представлены тексты конфигураций для криптошлюза Hub4:

текст консоли cisco-like;
Содержимое /etc/opennhrp/opennhrp.conf;
Содержимое /etc/frr/frr.conf.

Настройка устройства Spoke1-n1

Начальные настройки, настройки PKI, настройка паролей доступа к консоли cisco-like, настройка сетевых параметров, настройка шифрования, настройка политики обработки СОС (CRL) и настройка межсетевого экрана осуществляется аналогично устройству Hub1 с учетом соответствующих IP-адресов (см. Рисунок 1).

Настройка mGRE-интерфейсов

На филиальных криптошлюзах должно быть по два mGRE-интерфейса (по одному на каждую mGRE-подсеть).

Настройки применяются при выходе из настройки интерфейса.

Настройки mGRE-интерфейса осуществляются из cisco-like консоли криптошлюза:

Spoke1‑n1#conf t

Spoke1‑n1(config)#interface Tunnel1

Spoke1‑n1(config-if)#ip address 10.10.10.1 255.255.255.0

Spoke1‑n1(config-if)#mtu 1400

Spoke1‑n1(config-if)#tunnel key 1

Spoke1‑n1(config-if)#tunnel mode gre multipoint

Spoke1‑n1(config-if)#tunnel ttl 64

Spoke1‑n1(config-if)#tunnel tos inherit

Spoke1‑n1(config-if)#exit

Spoke1‑n1(config)#interface Tunnel2

Spoke1‑n1(config-if)#ip address 10.10.20.1 255.255.255.0

Spoke1‑n1(config-if)#mtu 1400

Spoke1‑n1(config-if)#tunnel key 2

Spoke1‑n1(config-if)#tunnel mode gre multipoint

Spoke1‑n1(config-if)#tunnel ttl 64

Spoke1‑n1(config-if)#tunnel tos inherit

Spoke1‑n1(config-if)#end

Настройка NHRP

Настройка NHRP осуществляются из linux bash.

Приведите файл /etc/opennhrp/opennhrp.conf к виду:

Маска в настройках opennhrp должна совпадать с маской на mgre интерфейсе.

interface mgre_1

map 10.10.10.100/24 172.16.100.2 register

map 10.10.10.200/24 172.16.101.2 register

multicast nhs

holding-time 90

cisco-authentication secret

non-caching

interface mgre_2

map 10.10.20.200/24 172.17.200.2 register

map 10.10.20.200/24 172.17.101.2 register

multicast nhs

holding-time 90

cisco-authentication secret

non-caching

Примечание – В больших DMVPN сетях, содержащих более сотни устройств, может наблюдаться повышение нагрузки на криптошлюзы Центрального офиса после потери связи со всеми или большинством филиалов, например, из-за отказа провайдера. В этом случае криптошлюзы филиалов могут направлять Registration Request на Hub практически одновременно создавая пик нагрузки на него. Дополнительно, количество одновременно создаваемых туннелей на Hub ограничено. Это может привести к увеличению длительности подключения филиальных криптошлюзов и полного восстановления DMVPN сети после отказа. Для повышения равномерности распределения по времени запросов Registration Request от филиальных криптошлюзов введен параметр reregister-time – время до начала перерегистрации Spoke на Hub после потери связи между ними. Пример настроек с использованием reregister-time:

interface mgre_1

map 10.10.10.100/24 172.16.100.2 register reregister-time 60

map 10.10.10.200/24 172.16.101.2 register reregister-time 45-75

multicast nhs

holding-time 90

cisco-authentication secret

non-caching

interface mgre_2

map 10.10.20.200/24 172.17.200.2 register

map 10.10.20.200/24 172.17.101.2 register

multicast nhs

reregister-time 45-75

holding-time 90

cisco-authentication secret

non-caching

Команда reregister-time A изменяет время перерегистрации на постоянное указанное значение.

Команда reregister-time A-B изменяет время перерегистрации на случайное число из указанного диапазона.

Указание reregister-time в начале строки изменяет время перерегистрации на всех Hub’ах, объявленных под этим интерфейсом.

Команда reregister-time для интерфейса должна отделяться от команды map A.B.C.D/X A.B.C.D register значащей командой из набора допустимых в opennhrp.conf команд. Если команда reregister-time для интерфейса после команды map A.B.C.D/X A.B.C.D register будет отделяться пробелом, нескольким пробелами или даже символом перевода строки, она будет восприниматься частью команды map.

Пример идентичных команд:

map 10.10.10.100/24 172.16.100.2 register reregister-time 60

map 10.10.10.100/24 172.16.100.2 register

reregister-time

Пример, когда reregister-time задаётся для интерфейса:

interface mgre_2

map 10.10.20.200/24 172.17.200.2 register

map 10.10.20.200/24 172.17.101.2 register

multicast nhs

reregister-time 45-75

Указание reregister-time в строке map A.B.C.D/X A.B.C.D register изменяет время перерегистрации только для указанного криптошлюза. Указание reregister-time для интерфейса изменяет время перерегистрации для всех криптошлюзов, описанных в интерфейсе и без reregister-time.

По умолчанию время перерегистрации берётся из диапазона 60-180 секунд.

Добавьте сервис OpenNHRP в автозагрузку и запустите его:

root@Spoke1‑n1:~# systemctl enable opennhrp

Created symlink /etc/systemd/system/multi-user.target.wants/opennhrp.service -> /lib/systemd/system/opennhrp.service.

root@Spoke1‑n1:~# systemctl start opennhrp

Через некоторое время проверьте, что между Spoke1‑n1 и центральными криптошлюзами Hub1, Hub2, Hub3, Hub4 поднялись IPsec туннели (если туннели не поднялись – проверьте настройки сети/IPsec/Firewall/NHRP, лог-файлы /var/log/cspvpngate.log и /var/log/syslog):

root@Spoke1‑n1:~# sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd

1 5 (100.100.1.2,4500)-(172.16.100.2,4500) active 2208 2232

2 6 (100.100.1.2,4500)-(172.17.100.2,4500) active 1784 1744

3 7 (100.100.1.2,4500)-(172.17.101.2,4500) active 2240 2200

4 8 (100.100.1.2,4500)-(172.16.101.2,4500) active 1848 1744

5 9 (100.100.1.2,4500)-(172.17.100.2,4500) active 1752 1776

IPsec connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd

1 5 (100.100.1.2,*)-(172.16.100.2,*) 47 ESP nat-t-trans 308 168

2 6 (100.100.1.2,*)-(172.16.100.2,*) 47 ESP nat-t-trans 16160 15732

3 7 (100.100.1.2,*)-(172.17.101.2,*) 47 ESP nat-t-trans 348 380

4 8 (100.100.1.2,*)-(172.16.101.2,*) 47 ESP nat-t-trans 15780 16220

5 9 (100.100.1.2,*)-(172.17.100.2,*) 47 ESP nat-t-trans 0 16208

6 10 (100.100.1.2,*)-(172.17.100.2,*) 47 ESP nat-t-trans 13692 0

7 11 (100.100.1.2,*)-(172.17.101.2,*) 47 ESP nat-t-trans 15316 15744

Настройка BGP

Динамическая маршрутизация настраивается через консоль сервиса FRR.

Добавьте сервис FRR в автозагрузку и запустите его:

root@Spoke1‑n1:~# systemctl enable frr

Synchronizing state of frr.service with SysV service script with /lib/system/system-sysv-install.

Executing: /lib/system/system-sysv-install enable frr

root@Spoke1‑n1:~# systemctl start frr

Войдите в консоль сервиса FRR, для этого нужно из linux bash набрать следующую команду:

root@Spoke1‑n1:~# vtysh

Hello, this is FRRouting (version 9.0.2).

Добавьте маршрут 192.168.100.0/24 через VIP адрес (192.168.1.1) с дистанцией 240:

Spoke1‑n1#configure terminal

Spoke1‑n1(config)# ip route 192.168.100.0/24 192.168.1.1 240

Примечание – Данный маршрут будет устанавливаться в систему на резервной ноде кластера VRRP для обеспечения возможности опроса ее LAN интерфейса из подсети Центрального офиса, например, с целью централизованного сбора диагностической информации из Центрального офиса. На основной ноде кластера VRRP будут находится 2 маршрута: добавленный нами с дистанцией 240 и полученный по BGP с дистанцией 200. FRR добавит в систему маршрут с меньшей дистанцией. Резервная нода кластера VRRP будет находится в состоянии BACKUP/FAULT и BGP пиринг с криптошлюзами Центрального офиса на ней будет остановлен (смотри настройки в следующем разделе - Настройки VRRP). При остановке BGP пиринга на резервную ноду кластера VRRP перестанут поступать маршруты по BGP. В сценарии для версии 4.3 аналогичный функционал настраивался через конфигурационный файл /etc/keepalived/notify_common.conf, управляющий работой скрипта /etc/keepalived/scripts/notify_common.

Настройте BGP (см. описание http://docs.frrouting.org):
1. Создайте route-map TO-HUB1-OUT, TO-HUB2-OUT, TO-HUB3-OUT, TO-HUB4-OUT. Данные route-map будет менять local-preference для маршрутов, анонсируемых филиалом в сторону криптошлюзов Центрального офиса (192.168.1.0/24):

Spoke1‑n1(config)# route-map TO-HUB1-OUT permit 1

Spoke1‑n1(config-route-map)#set local-preference 100

Spoke1‑n1(config-route-map)#exit

Spoke1‑n1(config)#route-map TO-HUB2-OUT permit 1

Spoke1‑n1(config-route-map)#set local-preference 75

Spoke1‑n1(config-route-map)#exit

Spoke1‑n1(config)#route-map TO-HUB3-OUT permit 1

Spoke1‑n1(config-route-map)#set local-preference 50

Spoke1‑n1(config-route-map)#exit

Spoke1‑n1(config)#route-map TO-HUB4-OUT permit 1

Spoke1‑n1(config-route-map)#set local-preference 25

Spoke1‑n1(config-route-map)#exit

Примечание - На криптошлюзах всех остальных филиалах маршрут до защищаемой подсети Spoke1-n1, полученный через Hub1, будет иметь наибольший приоритет, а маршрут до защищаемой подсети Spoke1-n1, полученный через Hub4, будет иметь наименьший приоритет.

2. Включите процесс протокола BGP для автономной системы 65000 и перейдите в режим его конфигурирования:

Spoke1‑n1(config)#router bgp 65000

3. Установите идентификатор маршрутизатора:

Spoke1‑n1(config-router)#bgp router-id 192.168.1.10

4. Включите логирование изменения статуса (например, up, down и другие) BGP соседа в журнале работы:

Spoke1‑n1(config-router)#bgp log-neighbor-changes

5. Установите таймеры keepalive и holdtime для BGP соседа:

Spoke1‑n1(config-router)#timers bgp 3 9

6. Добавьте mGRE-адреса Hub-ов в качестве BGP соседей с номером автономной системы 65000 и установите время повторной попытки построения BGP соседства в 30 секунд:

Spoke1‑n1(config-router)#neighbor 10.10.10.100 remote-as 65000

Spoke1‑n1(config-router)#neighbor 10.10.10.100 timers connect 30

Spoke1‑n1(config-router)#neighbor 10.10.20.100 remote-as 65000

Spoke1‑n1(config-router)#neighbor 10.10.20.100 timers connect 30

Spoke1‑n1(config-router)#neighbor 10.10.10.200 remote-as 65000

Spoke1‑n1(config-router)#neighbor 10.10.10.200 timers connect 30

Spoke1‑n1(config-router)#neighbor 10.10.20.200 remote-as 65000

Spoke1‑n1(config-router)#neighbor 10.10.20.200 timers connect 30

7. Включите анонсирование маршрута до защищаемой подсети Филиала №1:

Spoke1‑n1(config-router)#address-family ipv4 unicast

Spoke1‑n1Spoke1‑n1(config-router-af)#network 192.168.1.0/24

8. Примените route-map к соседям:

Spoke1‑n1(config-router-af)#neighbor 10.10.10.100 route-map TO-HUB1-OUT out

Spoke1‑n1(config-router-af)#neighbor 10.10.10.200 route-map TO-HUB2-OUT out

Spoke1‑n1(config-router-af)#neighbor 10.10.20.100 route-map TO-HUB3-OUT out

Spoke1‑n1(config-router-af)#neighbor 10.10.20.200 route-map TO-HUB4-OUT out

9. Сохраните изменения:

Spoke1‑n1(config-router-af)#end

Spoke1‑n1(config-router)# exit

Spoke1‑n1# write

Note: this version of vtysh never writes vtysh.conf

Building Configuration...

Integrated configuration saved to /etc/frr/frr.conf[OK]

[OK]

Настройка VRRP

В отличие от версии 4.3 в версии 5.0 значительная часть настроек VRRP перенесена в cisco‑like консоль. Но настройка VRRP конфигурационного файла /etc/keepalived/notify_common.conf осуществляется из linux bash.
Сохраните копию файла /etc/keepalived/notify_common.conf в /etc/keepalived/notify_common.conf.backup и приведите файл /etc/keepalived/notify_common.conf к виду:

FLAG_DMVPN_SCENARIO_ON_CLUSTERED_SPOKE="true"

DMVPN_INTERNAL_ROUTING_PROTOCOL="IBGP"

DMVPN_LOCAl_ASN="65000"

DMVPN_BGP_NEIGHBORS="10.10.10.100 10.10.10.200 10.10.20.100 10.10.20.200"

Конфигурационный файл /etc/keepalived/notify_common.conf управляет скриптом /etc/keepalived/scripts/notify_common. Логика следующая: если нода переходит в состояние BACKUP или FAULT, то BGP пиринг с центральными криптошлюзами (10.10.10.100, 10.10.10.200, 10.10.20.100, 10.10.20.200) выключается. Если нода переходит в состояние MASTER, то BGP пиринг с центральными криптошлюзами включается.

Изменение параметров DMVPN в файле /etc/keepalived/notify_common.conf после настройки keepalived (в процессе работы):

При необходимости изменения параметров следует:

1) Перезапустить FRR с помощью команды "systemctl restart frr" (это действие загрузит конфигурацию, которая соответствует состоянию MASTER). ВАЖНО: после перезапуска FRR может возникнуть ассиметричная маршрутизация. Это связано с тем, что устройство в состоянии BACKUP или FAULT будет участвовать в обмене BGP маршрутами;

2) Изменить требуемые настройки FRR, которые соответствует состоянию MASTER;

3) Сохранить настройки FRR (команда write).

4) После настройки FRR требуется изменить соответствующие параметры DMVPN в файле /etc/keepalived/notify_common.conf.

5) Для устройств, находящихся в состоянии BACKUP или FAULT, следует перезапустить сервис keepalived, чтобы применить настройки из файла /etc/keepalived/notify_common.conf. Для устройства в состоянии MASTER настройки применяются после перехода в состояние BACKUP или FAULT.

Если была допущена ошибка в файле /etc/keepalived/notify_common.conf в части DMVPN (например, номер автономной системы или IP-адрес BGP пира не совпадает с настройками FRR), то при переходе ноды в состояние BACKUP или FAULT в логах /var/log/cspvpngate.log появится сообщение "VRRP notify common script: ERROR: can not set shutdown on neighbor". После исправления ошибок в файле достаточно перезапустить сервис keepalived.

Остальные настройки VRRP осуществляются из cisco-like консоли криптошлюза. Включите использование vrrp v3:

Spoke1‑n1# configure terminal

Spoke1‑n1(config)# fhrp version vrrp v3

Включите запуск общего скрипт-файла (/etc/keepalived/scripts/notify_common) при переходе VRRP инстанса между состояниями:

Spoke1‑n1(config)# vrrp notify common

Создайте правило SLA (по умолчанию для IPv4):

Spoke1‑n1(config)#vrrp track sla check_isp_link

Укажите целевые хосты для проверки связи:

Spoke1‑n1(vrrp-track-sla)# host 172.16.1.1

Spoke1‑n1(vrrp-track-sla)# host 172.16.101.15

Укажите режим SLA на проверку с помощью ICMP:

Spoke1‑n1(vrrp-track-sla)# mode icmp-echo

Задайте условие успешности проверки, как доступность любого из указанного хостов:

Spoke1‑n1(vrrp-track-sla)# reachability any

Задайте интерфейс, с которого будут отправляться ICMP:

Spoke1‑n1(vrrp-track-sla)# source TenGigabitEthernet0/0

Задайте количество допустимых неуспешных попыток проверки доступности хостов:

Spoke1‑n1(vrrp-track-sla)# fall 15

Задайте количество необходимых успешных попыток проверки доступности хостов:

Spoke1‑n1(vrrp-track-sla)# rise 10

Задайте время ожидания проверки доступности хоста:

Spoke1‑n1(vrrp-track-sla)# timeout 2

Интервал между проверками доступности хоста:

Spoke1‑n1(vrrp-track-sla)# interval 3

Spoke1‑n1(vrrp-track-sla)# exit

Включите VRRP на внутреннем интерфейсе (создает VRRP инстанс):

Spoke1‑n1(config)# interface TenGigabitEthernet0/1

Spoke1‑n1(config-if)# vrrp 1 address-family ipv4

Spoke1‑n1(config-if-vrrp)#

Задайте кластерный IPv4 адрес:

Spoke1‑n1(config-if-vrrp)# address 192.168.1.1 255.255.255.0

Установите интервал отправки advertisement-сообщений:

Spoke1‑n1(config-if-vrrp)# timers advertise 3

Установите интервал отправки gratuitous ARP-сообщения:

Spoke1‑n1(config-if-vrrp)# timers garp 5

Прикрепите к интерфейсу SLA правило:

Spoke1‑n1(config-if-vrrp)# track sla check_isp_link

Включите отслеживание внешнего интерфейса:

Spoke1‑n1(config-if-vrrp)# track interface TenGigabitEthernet0/0

Отключите preempt mode:

Spoke1‑n1(config-if-vrrp)# no preempt

Установите приоритет для VRRP инстанса:

Spoke1‑n1(config-if-vrrp)# priority 100

Spoke1‑n1(config-if-vrrp)#end

Убедитесь, что нода перешла в состояние MASTER. Для этого войдите в cisco-like консоль криптошлюза и посмотрите настройки VRRP:

Spoke1‑n1#show vrrp

Interface VRID State AddrFamily

-------------------------------------------------------

TenGigabitEthernet0/1 1 Master IPv4

Убедитесь, что доступен один из хостов указанных в SLA:

Spoke1‑n1#sh vrrp sla check_isp_link

Rule name: check_isp_link

Result: Success

Hostname State Last checked at

172.16.1.1 reachable 2022-07-07|13:21:58.593

172.16.101.15 unknown None

Примечание - Из-за того, что проверяется доступность любого хоста, после получения ответа от 172.16.1.1 проверка второго хоста не происходит.

Убедитесь, что на внутреннем интерфейсе eth1 появился кластерный VIP-адрес:

root@Spoke1‑n1:~# ip address show dev eth1

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

link/ether 00:50:56:9e:c3:fe brd ff:ff:ff:ff:ff:ff

altname enp11s0

altname ens192

altname TenGigabitEthernet0_1

inet 192.168.1.10/24 brd 192.168.1.255 scope global eth1

valid_lft forever preferred_lft forever

inet 192.168.1.1/24 scope global secondary eth1:900

valid_lft forever preferred_lft forever

inet6 fe80::250:56ff:fe9e:c3fe/64 scope link

valid_lft forever preferred_lft forever

В Приложении представлены тексты конфигураций для криптошлюза Spoke1‑n1:

текст консоли cisco-like;
Содержимое /etc/opennhrp/opennhrp.conf;
Содержимое /etc/frr/frr.conf;
Содержимое /etc/opennhrp/opennhrp.conf;
Содержимое /etc/keepalived/keepalived.conf.

Настройка устройства Spoke1-n2

Настройка устройства Spoke1‑n2 осуществляется аналогично устройству Spoke1‑n1 с учетом соответствующих IP-адресов (см. Рисунок 1).

Значение bgp router-id у резервной ноды должно отличаться от значения основной ноды (Spoke1‑n1).

Значение priority в VRRP у резервной ноды должно быть меньше, чем у основной ноды.

В Приложении представлены тексты конфигураций для криптошлюза Spoke1‑n1:

текст консоли cisco-like;
Содержимое /etc/opennhrp/opennhrp.conf;
Содержимое /etc/frr/frr.conf;
Содержимое /etc/opennhrp/opennhrp.conf;
Содержимое /etc/keepalived/keepalived.conf.

Настройка устройства Spoke2

Начальные настройки, настройки PKI, настройка паролей доступа к консоли cisco-like, настройка политики обработки СОС (CRL), настройка межсетевого экрана, настройка mGRE-интерфейсов, настройка NHRP и настройка BGP осуществляется аналогично устройству Spoke1-n1 с учетом соответствующих IP-адресов (см. Рисунок 1). В настройках BGP не нужно добавлять маршрут через VIP адрес. Настройки VRRP на Spoke2 не выполняются.

Из-за отсутствия маршрута по умолчанию до настройки multiwan, СОС не будет загружен в базу Продукта во время настройки политики обработки СОС (CRL).

Настройка сетевых параметров

Изменение состояния интерфейсов и назначение IP адресов в cisco-like консоли применяются сразу после ввода соответствующих команд. Политика безопасности применяются после выхода из режима конфигурирования.

Задайте имя устройства:

sterragate(config)#hostname Spoke2

Включите WAN и LAN интерфейсы и настройте IP адрес на WAN интерфейсе в соответствии со схемой стенда:

Spoke2(config)#interface TenGigabitEthernet0/0

Spoke2(config-if)# ip address 172.16.2.2 255.255.255.0

Spoke2(config-if)# no shutdown

Spoke2(config-if)#interface TenGigabitEthernet0/1

Spoke2(config-if)# ip address 172.17.2.2 255.255.255.0

Spoke2(config-if)# no shutdown

Spoke2(config-if)#interface TenGigabitEthernet0/2

Spoke2(config-if)# ip address 192.168.2.1 255.255.255.0

Spoke2(config-if)# no shutdown

Spoke2(config)#end

Примечание – маршрут по умолчанию будет добавлен с помощью сервиса multiwan.

Настройка шифрования

Настройка шифрования осуществляется аналогично устройству Spoke1-n1 с учетом соответствующих IP-адресов (см. Рисунок 1) и указанием двух WAN адресов в object-group с именем SELF:

Spoke2(config)#object-group network SELF

Spoke2(config-network-group)# description IP on WAN interface

Spoke2(config-network-group)# host 172.16.2.2

Spoke2(config-network-group)# host 172.17.2.2

Spoke2(config-network-group)#exit

Настройка multiwan

Настройка осуществляются из linux bash. Подробное описание параметров приведено в сценарии «Резервирование каналов связи при помощи пакета «multiwan»».
Приведите файл /etc/multiwan/config.yaml к виду:

config_format_version: 1

links_params:

links:

- name: ISP1

iface_name: eth0

prio: 300

routes:

ipv4:

networks:

- 0.0.0.0/0

nexthop: 172.16.2.1

watch_foreign_routes: true

check:

hosts_reachability: any

ipv4:

hosts:

- 172.16.101.15

- 172.16.1.1

method:

icmp:

max_rtt: 100

interval: 3

restore_interval: 1

restore_count: 10

failure_count: 10

tos: 184

data_size: 56

- name: ISP2

iface_name: eth1

prio: 200

routes:

ipv4:

networks:

- 0.0.0.0/0

nexthop: 172.17.2.1

watch_foreign_routes: True

check:

hosts_reachability: any

ipv4:

hosts:

- 172.16.101.15

- 172.16.1.1

method:

icmp:

max_rtt: 100

interval: 3

restore_interval: 1

restore_count: 10

failure_count: 10

tos: 184

data_size: 56

Завершение настройки Spoke2

После настройки запустите сервис multiwan, а также добавьте его в автозагрузку:

root@Spoke2:~# systemctl start multiwan.service

root@Spoke2:~# systemctl enable multiwan.service

Посмотреть лог работы сервиса можно в файле /var/log/cspvpngate.log:

root@Spoke2:~# tail -n 1000 /var/log/cspvpngate.log | grep multiwan

2023-12-04T15:10:14.853421+03:00 Spoke2 multiwan: INFO: Starting multiwan...

2023-12-04T15:10:15.908671+03:00 Spoke2 multiwan: INFO: NAT translations table has been cleared.

2023-12-04T15:10:16.923643+03:00 Spoke2 multiwan: INFO: LSP was reloaded.

2023-12-04T15:10:16.930806+03:00 Spoke2 multiwan: INFO: Used interface "eth0". Nexthop "172.16.100.1".

Проверьте, что добавлены маршруты объявлены в настройках multiwan:

root@Spoke2:~# ip route show proto multiwan

default via 172.16.2.1 dev eth0 src 172.16.2.2 metric 700

Проверьте что маршрут до IP адреса HTTP сервера CRL_distribution_point в системе:

root@Spoke2:~# ip route get 172.16.101.15

172.16.101.15 via 172.16.2.1 dev eth0 src 172.16.2.2 uid 0

cache

Если всё настроено верно, то перезагрузите сервис getcrls для загрузки СОС в базу Продукта:

root@Spoke2:~# systemctl restart getcrls.service

Выполните проверку статуса сертификатов в базе Продукта:

root@Spoke2:~# cert_mgr check

1 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA

2 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Spoke2

В Приложении представлены тексты конфигураций для криптошлюза Spoke2:

текст консоли cisco-like;
Содержимое /etc/opennhrp/opennhrp.conf;
Содержимое /etc/frr/frr.conf;
Содержимое /etc/multiwan/config.yaml

Проверка работоспособности стенда

Проверка работоспособности стенда проводится в трех состояниях:

Все узлы в центральном офисе и филиалах функционируют и исправны.
Проблема на основном криптошлюзе в центральном офисе: отказ центрального криптошлюза, отказ внешнего сетевого интерфейса.
Проблема на основной ноде кластера в филиале: отказ основной ноды кластера, недоступность Интернет-провайдера, недоступность сервиса opennhrp.

Все узлы в центральном офисе и филиалах функционируют и исправны

Убедитесь, что криптошлюз второго филиала работает через основной интерфейс:

root@Spoke2:~# mwan_mgr show --links_status

Link: 1

Name: ISP1

Interface: eth0

Priority: 300

State: reachable

Active: True

Hosts reachability: any

IPv4 hosts: "172.16.101.15", "172.16.1.1"

IPv6 hosts: None

Link: 2

Name: ISP2

Interface: eth1

Priority: 200

State: reachable

Active: False

Hosts reachability: any

IPv4 hosts: "172.16.101.15", "172.16.1.1"

IPv6 hosts: None

Видно, что активным интерфейсом является eth0.
Убедитесь, что на центральных криптошлюзах установлены IPsec-туннели со всеми филиальными криптошлюзами, для этого в linux bash выполните следующую команду:

root@Hub1:~# sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd

1 2 (100.100.100.2,4500)-(172.16.1.2,4500) active 2232 2208

2 3 (100.100.100.2,4500)-(172.17.1.2,4500) active 1808 1848

3 4 (100.100.100.2,4500)-(172.16.2.2,4500) active 1908 1948

IPsec connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd

1 2 (100.100.100.2,*)-(172.16.1.2,*) 47 ESP nat-t-trans 168 140

2 3 (100.100.100.2,*)-(172.16.1.2,*) 47 ESP nat-t-trans 7340 7092

3 4 (100.100.100.2,*)-(172.17.1.2,*) 47 ESP nat-t-trans 876 656

4 5 (100.100.100.2,*)-(172.16.2.2,*) 47 ESP nat-t-trans 6108 5928

root@Hub2:~# sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd

1 1 (100.100.101.2,4500)-(172.16.1.2,4500) active 1808 1848

2 2 (100.100.101.2,4500)-(172.16.1.2,4500) active 1744 1848

3 3 (100.100.101.2,4500)-(172.17.1.2,4500) active 1808 1848

4 4 (100.100.101.2,4500)-(172.16.2.2,4500) active 1808 1848

IPsec connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd

1 1 (100.100.101.2,*)-(172.16.1.2,*) 47 ESP nat-t-trans 1312 996

2 2 (100.100.101.2,*)-(172.16.1.2,*) 47 ESP nat-t-trans 7500 7240

3 3 (100.100.101.2,*)-(172.17.1.2,*) 47 ESP nat-t-trans 876 656

4 4 (100.100.101.2,*)-(172.16.2.2,*) 47 ESP nat-t-trans 6256 6076

root@Hub3:~# sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd

1 2 (100.101.100.2,4500)-(172.16.1.2,4500) active 1776 1752

2 3 (100.101.100.2,4500)-(172.16.1.2,4500) active 1744 1784

3 4 (100.101.100.2,4500)-(172.17.1.2,4500) active 1808 1848

4 5 (100.101.100.2,4500)-(172.16.2.2,4500) active 1908 1948

IPsec connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd

1 2 (100.101.100.2,*)-(172.16.1.2,*) 47 ESP nat-t-trans 0 7316

2 3 (100.101.100.2,*)-(172.16.1.2,*) 47 ESP nat-t-trans 7584 0

3 4 (100.101.100.2,*)-(172.17.1.2,*) 47 ESP nat-t-trans 876 656

4 5 (100.101.100.2,*)-(172.16.2.2,*) 47 ESP nat-t-trans 6136 6192

root@Hub4:~# sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd

1 3 (100.101.101.2,4500)-(172.16.1.2,4500) active 2200 2240

2 4 (100.101.101.2,4500)-(172.17.1.2,4500) active 1808 1848

3 5 (100.101.101.2,4500)-(172.16.2.2,4500) active 1808 1848

IPsec connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd

1 2 (100.101.101.2,*)-(172.16.1.2,*) 47 ESP nat-t-trans 548 348

2 3 (100.101.101.2,*)-(172.16.1.2,*) 47 ESP nat-t-trans 7268 7040

3 4 (100.101.101.2,*)-(172.17.1.2,*) 47 ESP nat-t-trans 876 656

4 5 (100.101.101.2,*)-(172.16.2.2,*) 47 ESP nat-t-trans 6476 6340

Видно, что на каждом центральном криптошлюзе установлено по три IPsec-туннеля – два с нодами кластера в первом филиале (IP-адреса 172.16.1.2, 172.17.1.2) и третий с криптошлюзом во втором филиале (IP-адрес: 172.16.2.2). Строка «ESP nat-t-trans» свидетельствует о том, что IPsec-туннель работает в транспортном режиме через NAT. Состояние, когда один IPsec-туннель отображается как два IPsec-туннеля (один для входящего трафика, другой для исходящего) является нормальным. Так же состояние, когда происходит дублирование записи IPsec-туннеля и счётчики меняются только у последней записи, является нормальным.

Убедитесь, что на центральных криптошлюзах протокол NHRP верно отображает информацию о филиальных криптошлюзах, для этого в linux bash выполните следующую команду:

root@Hub1:~# opennhrpctl show

Status: ok

Interface: mgre_1

Type: local

Protocol-Address: 10.10.10.255/32

Alias-Address: 10.10.10.100

Flags: up

Interface: mgre_1

Type: local

Protocol-Address: 10.10.10.100/32

Flags: up

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.10.2/32

NBMA-Address: 172.17.1.2

NBMA-NAT-OA-Address: 100.101.1.2

Flags: used up

Expires-In: 1:28

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.10.1/32

NBMA-Address: 172.16.1.2

NBMA-NAT-OA-Address: 100.100.1.2

Flags: up

Expires-In: 1:20

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.10.3/32

NBMA-Address: 172.16.2.2

Flags: up

Expires-In: 1:02

root@Hub2:~# opennhrpctl show

Status: ok

Interface: mgre_1

Type: local

Protocol-Address: 10.10.10.255/32

Alias-Address: 10.10.10.200

Flags: up

Interface: mgre_1

Type: local

Protocol-Address: 10.10.10.200/32

Flags: up

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.10.2/32

NBMA-Address: 172.17.1.2

NBMA-NAT-OA-Address: 100.101.1.2

Flags: used up

Expires-In: 1:27

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.10.1/32

NBMA-Address: 172.16.1.2

NBMA-NAT-OA-Address: 100.100.1.2

Flags: up

Expires-In: 1:18

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.10.3/32

NBMA-Address: 172.16.2.2

Flags: up

Expires-In: 1:01

root@Hub3:~# opennhrpctl show

Status: ok

Interface: mgre_1

Type: local

Protocol-Address: 10.10.20.255/32

Alias-Address: 10.10.20.100

Flags: up

Interface: mgre_1

Type: local

Protocol-Address: 10.10.20.100/32

Flags: up

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.20.2/32

NBMA-Address: 172.17.1.2

NBMA-NAT-OA-Address: 100.101.1.2

Flags: up

Expires-In: 1:26

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.20.1/32

NBMA-Address: 172.16.1.2

NBMA-NAT-OA-Address: 100.100.1.2

Flags: up

Expires-In: 1:17

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.20.3/32

NBMA-Address: 172.16.2.2

Flags: up

Expires-In: 1:00

root@Hub4:~# opennhrpctl show

Status: ok

Interface: mgre_1

Type: local

Protocol-Address: 10.10.20.255/32

Alias-Address: 10.10.20.200

Flags: up

Interface: mgre_1

Type: local

Protocol-Address: 10.10.20.200/32

Flags: up

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.20.3/32

NBMA-Address: 172.16.2.2

Flags: up

Expires-In: 1:29

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.20.2/32

NBMA-Address: 172.17.1.2

NBMA-NAT-OA-Address: 100.101.1.2

Flags: used up

Expires-In: 1:24

Interface: mgre_1

Type: dynamic

Protocol-Address: 10.10.20.1/32

NBMA-Address: 172.16.1.2

NBMA-NAT-OA-Address: 100.100.1.2

Flags: up

Expires-In: 1:15

Видно, что на каждом центральном криптошлюзе протокол NHRP корректно отображает информацию о филиальных криптошлюзах (записи с пометкой «Type: dynamic»), а именно mGRE-адрес (Protocol-Address) соответствует NBMA IP-адресу (NBMA-Address). Также правильно отображается информация об исходном IP-адресе до выполнения процедуры трансляции (NBMA-NAT-OA-Address) для тех криптошлюзов, которые находятся за устройствами, выполняющими функции NAT.

Убедитесь, что на центральных криптошлюзах подсистема ip neighbor ядра ОС Linux корректно отображает информацию о маппинге mGRE-адреса в NBMA-адрес филиальных криптошлюзов, для этого в linux bash выполните следующую команду:

root@Hub1:~# ip neighbor show

192.168.255.1 dev eth1 lladdr 00:50:56:9e:19:47 REACHABLE

10.10.10.2 dev mgre_1 lladdr 172.17.1.2 REACHABLE

10.10.10.1 dev mgre_1 lladdr 172.16.1.2 REACHABLE

100.100.100.1 dev eth0 lladdr 00:50:56:9e:47:c6 REACHABLE

10.10.10.3 dev mgre_1 lladdr 172.16.2.2 REACHABLE

root@Hub2:~# ip neighbor show

10.10.10.3 dev mgre_1 lladdr 172.16.2.2 REACHABLE

192.168.255.1 dev eth1 lladdr 00:50:56:9e:19:47 REACHABLE

100.100.101.1 dev eth0 lladdr 00:50:56:9e:11:d8 REACHABLE

10.10.10.1 dev mgre_1 lladdr 172.16.1.2 REACHABLE

10.10.10.2 dev mgre_1 lladdr 172.17.1.2 REACHABLE

root@Hub3:~# ip neighbor show

100.101.100.1 dev eth0 lladdr 00:50:56:9e:e0:5d REACHABLE

10.10.20.1 dev mgre_1 lladdr 172.16.1.2 REACHABLE

192.168.255.1 dev eth1 lladdr 00:50:56:9e:19:47 REACHABLE

10.10.20.3 dev mgre_1 lladdr 172.16.2.2 REACHABLE

10.10.20.2 dev mgre_1 lladdr 172.17.1.2 REACHABLE

root@Hub4:~# ip neighbor show

10.10.20.3 dev mgre_1 lladdr 172.16.2.2 REACHABLE

10.10.20.2 dev mgre_1 lladdr 172.17.1.2 REACHABLE

100.101.101.1 dev eth0 lladdr 00:50:56:9e:43:b9 REACHABLE

10.10.20.1 dev mgre_1 lladdr 172.16.1.2 REACHABLE

192.168.255.1 dev eth1 lladdr 00:50:56:9e:19:47 REACHABLE

Видно, что на каждом центральном криптошлюзе маппинг mGRE-адреса в NBMA-адрес филиальных криптошлюзов выполнен верно.

Убедитесь, что на центральных криптошлюзах корректно работает протокол BGP, для этого зайдите в linux bash выполните следующие команды:

root@Hub1:~# vtysh

Hello, this is FRRouting (version 9.0.2).

Hub1# show ip bgp summary

IPv4 Unicast Summary (VRF default):

BGP router identifier 10.10.10.100, local AS number 65000 vrf-id 0

BGP table version 3

RIB entries 5, using 960 bytes of memory

Peers 3, using 61 KiB of memory

Peer groups 1, using 64 bytes of memory

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc

*10.10.10.1 4 65000 116 118 3 0 0 00:05:37 1 3 N/A

*10.10.10.3 4 65000 112 114 3 0 0 00:05:24 1 3 N/A

192.168.255.1 4 65001 131 131 3 0 0 00:06:15 1 3 N/A

Total number of neighbors 3

* - dynamic neighbor

2 dynamic neighbor(s), limit 5000

Hub1# show ip route bgp

Codes: K – kernel route, C – connected, S – static, R – RIP,

O – OSPF, I – IS-IS, B – BGP, E – EIGRP, N – NHRP,

T – Table, v – VNC, V – VNC-Direct, A – Babel, F – PBR,

f – OpenFabric,

> - selected route, * - FIB route, q – queued, r – rejected, b – backup

t – trapped, o – offload failure

B>* 192.168.1.0/24 [200/0] via 10.10.10.1, mgre_1, weight 1, 00:05:48

B>* 192.168.2.0/24 [200/0] via 10.10.10.3, mgre_1, weight 1, 00:05:36

B>* 192.168.100.0/24 [20/0] via 192.168.255.1, eth1, weight 1, 00:06:27

root@Hub2:~# vtysh

Hello, this is FRRouting (version 9.0.2).

Hub2# show ip bgp summary

IPv4 Unicast Summary (VRF default):

BGP router identifier 10.10.10.200, local AS number 65000 vrf-id 0

BGP table version 3

RIB entries 5, using 960 bytes of memory

Peers 3, using 61 KiB of memory

Peer groups 1, using 64 bytes of memory

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc

*10.10.10.1 4 65000 117 119 3 0 0 00:05:40 1 3 N/A

*10.10.10.3 4 65000 113 115 3 0 0 00:05:28 1 3 N/A

192.168.255.1 4 65001 130 130 3 0 0 00:06:15 1 3 N/A

Total number of neighbors 3

* - dynamic neighbor

2 dynamic neighbor(s), limit 5000

Hub2# show ip route bgp

Codes: K – kernel route, C – connected, S – static, R – RIP,

O – OSPF, I – IS-IS, B – BGP, E – EIGRP, N – NHRP,

T – Table, v – VNC, V – VNC-Direct, A – Babel, F – PBR,

f – OpenFabric,

> - selected route, * - FIB route, q – queued, r – rejected, b – backup

t – trapped, o – offload failure

B>* 192.168.1.0/24 [200/0] via 10.10.10.1, mgre_1, weight 1, 00:05:53

B>* 192.168.2.0/24 [200/0] via 10.10.10.3, mgre_1, weight 1, 00:05:41

B>* 192.168.100.0/24 [20/0] via 192.168.255.1, eth1, weight 1, 00:06:28

root@Hub3:~# vtysh

Hello, this is FRRouting (version 9.0.2).

Hub3# show ip bgp summary

IPv4 Unicast Summary (VRF default):

BGP router identifier 10.10.20.100, local AS number 65000 vrf-id 0

BGP table version 3

RIB entries 5, using 960 bytes of memory

Peers 3, using 61 KiB of memory

Peer groups 1, using 64 bytes of memory

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc

*10.10.20.1 4 65000 117 119 3 0 0 00:05:41 1 3 N/A

*10.10.20.3 4 65000 113 115 3 0 0 00:05:29 1 3 N/A

192.168.255.1 4 65001 130 130 3 0 0 00:06:14 1 3 N/A

Total number of neighbors 3

* - dynamic neighbor

2 dynamic neighbor(s), limit 5000

Hub3# show ip route bgp

Codes: K - kernel route, C - connected, S - static, R - RIP,

O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,

T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,

f - OpenFabric,

> - selected route, * - FIB route, q - queued, r - rejected, b - backup

t - trapped, o - offload failure

B>* 192.168.1.0/24 [200/0] via 10.10.20.1, mgre_1, weight 1, 00:05:54

B>* 192.168.2.0/24 [200/0] via 10.10.20.3, mgre_1, weight 1, 00:05:42

B>* 192.168.100.0/24 [20/0] via 192.168.255.1, eth1, weight 1, 00:06:27

root@Hub4:~# vtysh

Hello, this is FRRouting (version 9.0.2).

Hub4# show ip bgp summary

IPv4 Unicast Summary (VRF default):

BGP router identifier 10.10.20.200, local AS number 65000 vrf-id 0

BGP table version 3

RIB entries 5, using 960 bytes of memory

Peers 3, using 61 KiB of memory

Peer groups 1, using 64 bytes of memory

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc

*10.10.20.1 4 65000 118 120 3 0 0 00:05:43 1 3 N/A

*10.10.20.3 4 65000 114 116 3 0 0 00:05:30 1 3 N/A

192.168.255.1 4 65001 130 130 3 0 0 00:06:15 1 3 N/A

Total number of neighbors 3

* - dynamic neighbor

2 dynamic neighbor(s), limit 5000

Hub4# show ip route bgp

Codes: K - kernel route, C - connected, S - static, R - RIP,

O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,

T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,

f - OpenFabric,

> - selected route, * - FIB route, q - queued, r - rejected, b - backup

t - trapped, o - offload failure

B>* 192.168.1.0/24 [200/0] via 10.10.20.1, mgre_1, weight 1, 00:05:55

B>* 192.168.2.0/24 [200/0] via 10.10.20.3, mgre_1, weight 1, 00:05:43

B>* 192.168.100.0/24 [20/0] via 192.168.255.1, eth1, weight 1, 00:06:28

Видно, что на каждом центральном криптошлюзе по протоколу BGP установлено соседство с основной нодой кластера в филиале №1, с криптошлюзом в филиале №2 и роутером Int‑router‑Hub. Соседство с резервной нодой кластера в филиале №1 отсутствует, как и требуется (нода, которая находится в состоянии BACKUP/FAULT не участвует в BGP).

Маршруты до филиальных подсетей (192.168.1.0/24 и 192.168.2.0/24) в таблице маршрутизации присутствуют, а также до 192.168.100.0/24.

Убедитесь, что основная нода кластера в филиале №1 находится в состоянии MASTER, для этого в linux bash выполните следующие команды:

root@Spoke1‑n1:~# ip address show dev eth1

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

link/ether 00:50:56:9e:82:c4 brd ff:ff:ff:ff:ff:ff

altname enp11s0

altname ens192

altname TenGigabitEthernet0_1

inet 192.168.1.10/24 brd 192.168.1.255 scope global eth1

valid_lft forever preferred_lft forever

inet 192.168.1.1/24 scope global secondary eth1:900

valid_lft forever preferred_lft forever

inet6 fe80::250:56ff:fe9e:82c4/64 scope link

valid_lft forever preferred_lft forever

root@Spoke1‑n1:~# tcpdump -i eth1 -n -c 4 vrrp

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode

listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes

09:44:27.771740 IP 192.168.1.10 > 224.0.0.18: VRRPv3, Advertisement, vrid 1, prio 100, intvl 300cs, length 12

09:44:30.771915 IP 192.168.1.10 > 224.0.0.18: VRRPv3, Advertisement, vrid 1, prio 100, intvl 300cs, length 12

09:44:33.772098 IP 192.168.1.10 > 224.0.0.18: VRRPv3, Advertisement, vrid 1, prio 100, intvl 300cs, length 12

09:44:36.772248 IP 192.168.1.10 > 224.0.0.18: VRRPv3, Advertisement, vrid 1, prio 100, intvl 300cs, length 12

4 packets captured

4 packets received by filter

0 packets dropped by kernel

root@Spoke1-n1:~# ip route show

default via 100.100.1.1 dev eth0 proto st_policy

10.10.10.0/24 dev mgre_1 proto kernel scope link src 10.10.10.1

10.10.20.0/24 dev mgre_2 proto kernel scope link src 10.10.20.1

100.100.1.0/24 dev eth0 proto kernel scope link src 100.100.1.2

192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.10

192.168.2.0/24 nhid 65 via 10.10.10.3 dev mgre_1 proto bgp metric 20

192.168.100.0/24 nhid 125 via 10.10.10.100 dev mgre_1 proto bgp metric 20

Видно, что на внутреннем интерфейсе eth1 имеется VIP-адрес 192.168.1.1, а также с данного интерфейса (с IP-адреса 192.168.1.10) отсылаются VRRP пакеты. В таблице маршрутизации присутствуют маршруты до защищаемых подсетей центрального офиса и филиала №2.

Также в cisco-like консоли криптошлюза можно увидеть состояние VRRP:

Spoke1‑n1#show vrrp

Interface VRID State AddrFamily

-------------------------------------------------------

TenGigabitEthernet0/1 1 Master IPv4

Убедитесь, что на резервной ноде есть маршрут до 192.168.100.0/24 через VIP-адрес.

root@Spoke1-n2:~# ip route show

default via 100.101.1.1 dev eth0 proto st_policy

10.10.10.0/24 dev mgre_1 proto kernel scope link src 10.10.10.2

10.10.20.0/24 dev mgre_2 proto kernel scope link src 10.10.20.2

100.101.1.0/24 dev eth0 proto kernel scope link src 100.101.1.2

192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.20

192.168.100.0/24 nhid 14 via 192.168.1.1 dev eth1 proto static metric 20

Убедитесь, что на внутреннем маршрутизаторе центрального офиса есть марштрты до защищищаемых подсетей филиалов через Hub1.

root@Int-router-Hub:~# ip route show

192.168.1.0/24 nhid 171 via 192.168.255.10 dev ens192 proto bgp metric 20

192.168.2.0/24 nhid 171 via 192.168.255.10 dev ens192 proto bgp metric 20

192.168.100.0/24 dev ens224 proto kernel scope link src 192.168.100.1

192.168.255.0/24 dev ens192 proto kernel scope link src 192.168.255.1

Убедитесь, что присутствует трафик между защищаемым подсетями филиала №1 и центрального офиса. Для этого запустите ping с устройства Host‑b‑spoke1 на устройство Host‑b‑hub и удостоверьтесь в прохождении пакетов:

root@Host‑b‑spoke1:~# ping 192.168.100.100 -c 4

PING 192.168.100.100 (192.168.100.100) 56(84) bytes of data.

64 bytes from 192.168.100.100: icmp_seq=1 ttl=61 time=2.05 ms

64 bytes from 192.168.100.100: icmp_seq=2 ttl=61 time=2.12 ms

64 bytes from 192.168.100.100: icmp_seq=3 ttl=61 time=2.05 ms

64 bytes from 192.168.100.100: icmp_seq=4 ttl=61 time=2.42 ms

--- 192.168.100.100 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3004ms

rtt min/avg/max/mdev = 2.048/2.157/2.415/0.151 ms

Убедитесь, что защищенное соединение между основной нодой кластера в филиале №1 и криптошлюзом в филиале №2 успешно строится, для этого запустите ping с устройства Host‑b‑spoke1 на устройство Host‑b‑spoke2 и проверьте наличие IPsec-туннеля на основной ноде кластера в филиале №1:

root@Host‑b‑spoke1:~# ping 192.168.2.100 -c 4

PING 192.168.2.100 (192.168.2.100) 56(84) bytes of data.

64 bytes from 192.168.2.100: icmp_seq=1 ttl=61 time=2.81 ms

64 bytes from 192.168.2.100: icmp_seq=2 ttl=62 time=339 ms

64 bytes from 192.168.2.100: icmp_seq=3 ttl=62 time=2.27 ms

64 bytes from 192.168.2.100: icmp_seq=4 ttl=62 time=1.53 ms

--- 192.168.2.100 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3004ms

rtt min/avg/max/mdev = 1.531/86.441/339.151/145.902 ms

root@Spoke1‑n1:~# sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd

1 5 (100.100.1.2,4500)-(172.16.100.2,4500) active 2208 2232

2 6 (100.100.1.2,4500)-(172.17.100.2,4500) active 1784 1744

3 7 (100.100.1.2,4500)-(172.17.101.2,4500) active 2240 2200

4 8 (100.100.1.2,4500)-(172.16.101.2,4500) active 1848 1744

5 9 (100.100.1.2,4500)-(172.17.100.2,4500) active 1752 1776

6 10 (100.100.1.2,4500)-(172.16.2.2,4500) active 1848 1816