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

С-Терра Шлюз КВ ~11 мин чтения 9244 слов

Построение кластера на базе протокола VRRPv3 (протокол IPv4) с настройкой при помощи CLI с использованием «С-Терра Шлюз КВ»

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

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

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

Введение

Данный сценарий описывает настройку VRRPv3 кластера из криптошлюзов «С-Терра Шлюз КВ» и безопасного взаимодействия между защищаемыми подсетями центрального офиса и филиала. Защищаемые подсети в LAN сегменте и недоверенные подсети в WAN сегменте – IPv4. Обеспечение безопасного взаимодействия достигается путем шифрования и туннелирования трафика с применением отечественных отраслевых стандартов ГОСТ и протокола IPsec.

Партнеры по IPsec, в настоящем документе – криптошлюзы, для аутентификации будут использовать сертификаты в формате x509. В качестве криптопровайдера будет использована криптографическая библиотека, разработанная компанией «С-Терра СиЭсПи».

На криптошлюзах будет настроено межсетевое экранирование с применением статических списков доступа (ACL) и пакетной фильтрации с контролем состояния сессий (stateful, аналог CBAC в Cisco IOS) для протоколов TCP и UDP.

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

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

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

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

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

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

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

Требования к устройствам.
1. «С-Терра Шлюз КВ».
1.1. Устройства «С-Терра Шлюз КВ» должны быть в заводском состоянии.
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. Схема взаимодействия

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

Устройства «С-Терра Шлюз КВ».
1. Криптошлюз – в данном сценарии так будет называться «С-Терра Шлюз КВ» («С-Терра Шлюз NF КB», исполнение «3MB»), инициализированный в роли network и использующийся для защиты сетевого трафика (устройства Hub1-n1, Hub1-n2 и Spoke1 на схеме).
2. МГК (модуль генерации ключей) – в данном сценарии так будет называться «С-Терра Шлюз КВ» («С-Терра МГК КB», исполнение «МГК»), инициализированный в роли management и использующийся для подготовки ключевых носителей для криптошлюзов (устройство МГК на схеме).
Ключевые носители.
В данном сценарии используются следующие типы ключевых носителей:
1. Шифроблокнот – CD-диск однократной записи, содержащий случайную последовательность. Шифроблокнот используется устройством МГК при подготовке рабочих ключевых носителей.
2. Административный носитель – USB Flash накопитель, использующийся на МГК и содержащий ключевую и конфигурационную информацию.
3. Рабочий ключевой носитель (РКН) – USB Flash накопитель, содержащий доверенный сертификат, контейнер с закрытым ключом и состояние ПДСЧ. Рабочий носитель используются при введении криптошлюза в эксплуатацию и при запуске СКЗИ.
Администраторские роли:
1. Администратор безопасности – это администратор устройства МГК.
2. Администратор сети – это администратор криптошлюза.
Размещение устройств.
1. В центральном офисе размещаются: центр выпуска сертификатов (Certification_authority), устройства «С-Терра Шлюз КВ» (МГК, Hub1-n1 и Hub1-n2) и персональный компьютер (Host-b-hub1).
2. В филиале размещаются: криптошлюз «С-Терра Шлюз КВ» (Spoke1) и персональный компьютер (Host-b-spoke1).
3. В неконтролируемом сегменте (синее облако на схеме) размещаются: HTTP сервер для распространения списка отозванных сертификатов (CRL_distribution_point), маршрутизатор (Router1).
Отказоустойчивость.
Криптошлюзы Hub1-n1 и Hub1-n2 объединяются в отказоустойчивый кластер, работающий на базе протокола VRRPv3 в состоянии Master/Backup. За реализацию протокола VRRPv3 отвечает ПО «keepalived». Криптошлюзы Hub1-n1 и Hub1-n2 являются нодами кластера.

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

Нода, находящаяся в состоянии Master, владеет кластерными адресами в доверенном и недоверенном сегментах и, соответственно, обрабатывает трафик. Нода, находящаяся в состоянии Backup или Fault, не владеет кластерными адресами.
По умолчанию все VRRPv3 интерфейсы синхронизированы в группу номер ноль. Соответственно, одновременно меняют свое состояние (данное поведение отличается от Cisco IOS, где по умолчанию VRRPv3 интерфейсы не синхронизированы).
Обнаружение отказа происходит благодаря служебным пакетам протокола VRRPv3 (VRRP Advertisement messages). Служебные пакеты отправляются только нодой, находящейся в состоянии Master (адрес источника пакетов – основной IP адрес на интерфейсе, где включен VRRPv3; IP адрес назначения - 224.0.0.18). Если резервная нода в состоянии Backup перестает получать на всех синхронизированных интерфейсах пакеты VRRP Advertisement messages от основной ноды, то она захватывает роль Master.
На нодах есть маршрут по умолчанию через адрес доверенного сегмента другой ноды (для доступа резервной ноды в сеть интернет). Метрика данного маршрута должна быть больше, чем метрика маршрута, добавляемая при переходе ноды в состоянии Master.
Кластер обрабатывает следующие типы отказов:

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

Подключение к сети Интернет.
В данном сценарии для эмуляции сети Интернет используются маршрутизатор Router1.
Подключение к сети Интернет на криптошлюзах «С-Терра Шлюз КВ» будет считаться успешным, если по протоколу ICMP (или «ping») будет доступен HTTP сервер для распространения списка отозванных сертификатов (устройство CRL_distribution_point на схеме).
1. Криптошлюзы Hub1-n1 и Hub1-n2 подключается к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизатор Router1).
2. Криптошлюз Spoke1 подключается к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизатор Router1).
3. Устройство МГК к сети не подключается.
Параметры шифрования IPsec.
Весь IPv4 трафик между подсетями центрального офиса (192.168.100.0/24) и филиала (192.168.1.0/24) защищается с использованием алгоритмов ГОСТ и протокола IPsec в туннельном IPv4 режиме.
Инициировать защищенное соединение между криптошлюзом центрального офиса в состоянии Master и криптошлюзом Spoke1 может как трафик из подсети филиала (192.168.1.0/24) в подсеть центра (192.168.100.0/24), так и трафик из центра в филиал.
1. Параметры протокола IKEv2:

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

2. Параметры протокола ESP:

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

Параметры межсетевого экранирования.
Для пакетов, которые не защищаются IPsec применяются следующие правила фильтрации:
1. На LAN и WAN интерфейсах IPv6 трафик заблокирован.
2. На LAN интерфейсах IPv4 трафик не контролируется.
3. На WAN интерфейсах разрешен входящий IPv4 трафик:
3.1. Протокол UDP порты 500 и 4500 – для IKEv2 и NAT-Traversal (ESP in UDP).
3.2. Протокол ICMP – для проверки доступности криптошлюза и работы механизма PathMTUd.
3.3. Протокол ESP (номер 50) – для работы IPsec.
3.4. Весь TCP и UDP трафик, для которого есть исходящее соединение (это динамические правила, которые создаются при помощи stateful фильтрации).
3.5. VRRP трафик – для работы VRRPv3.
3.6. На WAN интерфейсах инспектируются все исходящие локальные и транзитные IPv4 соединения для протоколов TCP и UDP. На основе результатов инспектирования осуществляется фильтрация входящего трафика с учетом состояния сессии (stateful).

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

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

Настройте IP адрес – 172.16.100.1 и маску – 255.255.255.0 на сетевом интерфейсе ens192
Настройте IP адрес – 172.16.1.1 и маску – 255.255.255.0 на сетевом интерфейсе ens224.
Разрешите прохождение IP трафика (если заблокировано).

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

Настройте IP адрес – 192.168.100.100 и маску – 255.255.255.0 на сетевом интерфейсе.
Задайте маршрут по умолчанию через 192.168.100.1.
Разрешите прием и отправку ICMP пакетов (если заблокировано).

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

Настройте IP адрес – 192.168.1.100 и маску – 255.255.255.0 на сетевом интерфейсе.
Задайте маршрут по умолчанию через 192.168.1.1.
Разрешите прием и отправку ICMP пакетов (если заблокировано).

Настройка устройства МГК

Настройте устройство МГК в соответствии с базовым сценарием. Подготовьте ключевые носители для криптошлюзов Hub1-n1, Hub1-n2 и Spoke1.

Настройка криптошлюза Hub1-n1

Настройка будет происходить локально при помощи консольного подключения. Все действия на криптошлюзе Hub1-n1 выполняются Администратором сети.

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

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

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

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

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

Инициализация

Подключите к устройству рабочий ключевой носитель с сессионными данными для криптошлюза Hub1-n1.

Запустите процедуру инициализации в роли network с помощью команды initialize role_network, введите лицензионную информацию, укажите id криптошлюза (в соответствии со значением, заданным при записи сессионных данных на рабочий носитель), отключите маршрутизацию IPv6 и установите надежные пароли для пользователей admin, user и root.

После завершения процедуры инициализации выполните перезагрузку устройства.

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

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

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

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

Войдите в консоль управления под учетной записью admin, выполните команду deploy, указав id криптошлюза, и введите транспортный пароль для загрузки сессионных данных и запуска VPN-подсистемы.

Убедитесь, что контейнер с закрытым ключом и доверенный сертификат УЦ успешно импортированы с помощью команд run cont_mgr show и run cert_mgr show.

Сгенерируйте запрос на сертификат, используя ранее созданный контейнер закрытого ключа, и сохраните этот запрос в файл на USB Flash накопитель.

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

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

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

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

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

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

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

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

sterragate(config)#hostname Hub1-n1

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

Hub1-n1(config)#interface GigabitEthernet 0/0

Hub1-n1(config-if)#ip address 172.16.100.10 255.255.255.0

Hub1-n1(config-if)#no shutdown

Hub1-n1(config-if)#exit

Hub1-n1(config)#interface GigabitEthernet 0/1

Hub1-n1(config-if)#no shutdown

Hub1-n1(config-if)#ip address 192.168.100.10 255.255.255.0

Hub1-n1(config-if)#exit

Задайте маршрут по умолчанию через LAN интерфейс второй ноды с метрикой 100:

Hub1-n1(config)#ip route 0.0.0.0 0.0.0.0 192.168.100.20 100

Данный маршрут будет использоваться нодой, когда она переходит в состояние Backup/Fault.

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

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

Параметры IKEv2.
1. Создайте набор параметров аутентификации с использованием сертификатов в рамках протокола IKEv2 под именем IKEv2_AUTH:

Hub1-n1(config)#crypto ikev2 authentication sig IKEv2_AUTH

Hub1-n1(conf-ikev2-auth)#identity dn

Hub1-n1(conf-ikev2-auth)#exit

2. Создайте набор алгоритмов под номером 1 для защиты IKEv2 туннеля:

Hub1-n1(config)#crypto ikev2 proposal 1

Hub1-n1(config-ikev2-proposal)#encryption magma

Hub1-n1(config-ikev2-proposal)#group gost3410-12-256

Hub1-n1(config-ikev2-proposal)#prf streebog512

Hub1-n1(config-ikev2-proposal)#exit

3. Создайте политику IKEv2 под номером 1 и добавьте в нее созданный выше набор алгоритмов:

Hub1-n1(config)#crypto ikev2 policy 1

Hub1-n1(config-ikev2-policy)#proposal 1

Hub1-n1(config-ikev2-policy)#exit

4. Создайте профиль настроек IKEv2 под именем IKEv2_ALGS:

Hub1-n1(config)#crypto ikev2 profile IKEv2_ALGS

Hub1-n1(config-ikev2-profile)#set policy 1

Hub1-n1(config-ikev2-profile)#authentication local IKEv2_AUTH

Hub1-n1(config-ikev2-profile)#authentication remote IKEv2_AUTH

Hub1-n1(config-ikev2-profile)#dpd 3 on-demand

Hub1-n1(config-ikev2-profile)#exit

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

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

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

Hub1-n1(config)#crypto ikev2 ipsec-proposal IKEv2_IPSEC_ALGS

Hub1-n1(ipsec-proposal)#esp encryption magma-mgm

Hub1-n1(ipsec-proposal)#exit

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

Hub1-n1(config)#ip access-list extended IPSEC_ACL_HUB1_AND_SPOKE1

Hub1-n1(config-ext-nacl)#permit ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255

Hub1-n1(config-ext-nacl)#exit

4. Создайте крипто-карту (имя VPN, раздел 1) для построения IPsec туннеля между центральным офисом и филиалом:

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

Hub1-n1(config-crypto-map)#match address IPSEC_ACL_HUB1_AND_SPOKE1

Hub1-n1(config-crypto-map)#set ikev2-ipsec-proposal IKEv2_IPSEC_ALGS

Hub1-n1(config-crypto-map)#set ikev2-profile IKEv2_ALGS

Hub1-n1(config-crypto-map)#set peer 172.16.1.2

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

Hub1-n1(config-crypto-map)#set mode tunnel

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

Hub1-n1(config-crypto-map)#exit

5. Прикрепите созданную крипто-карту VPN к внешнему WAN интерфейсу GigabitEthernet0/0:

Hub1-n1(config)#interface GigabitEthernet0/0

Hub1-n1(config-if)#crypto map VPN

Hub1-n1(config-if)#exit

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

Настройка VRRPv3

Для «С-Терра Шлюз КВ» в данном сценарии настройка VRRPv3 будет происходить только из cisco-like консоли. Настройка notify-common скрипта не нужна из-за возможности указать в cisco-like консоли метрику для маршрутов. Маршрут по умолчанию, добавленный с помощью VRRPv3, будет более приоритетным, чем маршрут по умолчанию с метрикой, добавленный с помощью cisco-like консоли. Нода в режиме Master будет использовать маршрут по умолчанию, добавленный с помощью VRRPv3. Нода в режиме Backup/Fault будет использовать маршрут по умолчанию, добавленный в cisco-like консоли.

Включите использование протокола VRRPv3:

Hub1-n1(config)#fhrp version vrrp v3

При использовании VRRPv3 протокол VRRPv2 недоступен и наоборот.

Настройте VRRPv3 в соответствии со схемой стенда на внешнем GigabitEthernet0/0:

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

Для стабильности работы кластера не рекомендуется уменьшать advertisement интервал (команда: timers advertise <SECONDS>) и отключать периодическую отсылку gARP пакетов (команда: timers garp <SECONDS>).

1. Создайте VRRPv3 для IPv4 трафика на внешнем интерфейсе:

Hub1-n1(config)#interface GigabitEthernet0/0

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

2. Настройте IP адрес, который будет добавлен к интерфейсу, когда нода переходит в состояние Master:

Hub1-n1(config-if-vrrp)#address 172.16.100.100 255.255.255.0

3. Установите интервал между отправкой VRRP advertise пакетов:

Hub1-n1(config-if-vrrp)#timers advertise 3

Примечание. Если за время, равное трём интервалам между отправкой VRRP advertise пакетов, резервная нода не будет получать VRRP advertise пакеты, то резервная нода перейдёт в состояние Master. При большом размере конфигурационного файла время загрузки конфигурации может превысить три интервала между отправкой VRRP advertise пакетов. Например, для LSP конфигурации размером от 100000 строк время загрузки может составить 9 секунд. Во время загрузки будет использоваться политика драйвера по умолчанию (DDP), которая в данном сценарии блокирует весь трафик. VRRP advertise пакеты не будут отсылаться и резервная нода может перейти в состояние Master. После загрузки конфигурации обе ноды будут в состоянии Master и будут иметь кластерные адреса.
Для отображения количества строк в используемой LSP конфигурации используете команду “lsp_mgr show | wc -l”.
4. Установите периодический интервал, с которым VRRP-маршрутизатор, находящийся в состоянии Master, будет отправлять Gratuitous ARP-сообщения:

Hub1-n1(config-if-vrrp)#timers garp 5

5. Установите приоритет для VRRP-маршрутизатора:

Hub1-n1(config-if-vrrp)#priority 100

По умолчанию приоритет 100 и данная команда не будет отображаться в настройках консоли cisco-like.
6. Отключите режим перехвата роли Master в зависимости от приоритета:

Hub1-n1(config-if-vrrp)#no preempt

Hub1-n1(config-if-vrrp)#exit

Hub1-n1(config-if)#exit

Настройте VRRPv3 в соответствии со схемой стенда на внутреннем GigabitEthernet0/1:

Hub1-n1(config)#interface GigabitEthernet0/1

Hub1-n1(config-if)#vrrp 2 address-family ipv4

Hub1-n1(config-if-vrrp)#address 192.168.100.1 255.255.255.0

Hub1-n1(config-if-vrrp)#timers advertise 3

Hub1-n1(config-if-vrrp)#timers garp 5

Hub1-n1(config-if-vrrp)#priority 100

Hub1-n1(config-if-vrrp)#no preempt

Hub1-n1(config-if-vrrp)#exit

Hub1-n1(config-if)#exit

Настройте VRRPv3 маршрут, который будет добавляться в таблицу маршрутизации, когда нода будет переходить в состояние Master (в качестве src нужно указать кластерный IP адрес внешнего интерфейса):

Hub1-n1(config)#vrrp ip route 0.0.0.0 0.0.0.0 172.16.100.1 src 172.16.100.100

VRRPv3 маршрут будет использоваться нодой когда она переходит в состояние Master. При переходе ноды в состояние Backup/Fault, VRRPv3 маршрут будет удаляться из системы. Нода будет использовать маршрут с большей метрикой через адрес 192.168.100.20. Данный маршрут был добавлен ранее в главе «Настройка сетевых параметров».
Примените настройки (настройки VRRP и IPsec применяются по выходу из режима конфигурирования):

Hub1-n1(config)#end

Hub1-n1#

Проверьте состояние VRRPv3:

Hub1-n1#show vrrp

Interface VRID State AddrFamily

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

GigabitEthernet0/0 1 Master IPv4

GigabitEthernet0/1 2 Master IPv4

Убедитесь, что маршрут по умолчанию добавлен через 172.16.100.1:

Hub1-n1#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.16.100.1 to network 0.0.0.0

S* 0.0.0.0/0 [0/0] via 172.16.100.1, Source is 172.16.100.100

[100/0] via 192.168.100.20

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 [0/0] is directly connected, GigabitEthernet0/0, Source is

172.16.100.10

C 192.168.100.0/24 [0/0] is directly connected, GigabitEthernet0/1, Source i

s 192.168.100.10

Чтобы посмотреть получившийся конфигурационный файл /etc/keepalived/keepalived.conf сервиса keepalived выполните:

При настройке VRRPv3 через cisco-like консоль менять файл /etc/keepalived/keepalived.conf вручную категорически запрещено, это может привести к неработоспособности кластера.

Hub1-n1#run cat /etc/keepalived/keepalived.conf

global_defs {

enable_dbus

}

vrrp_sync_group 0 {

group {

eth0_1

eth1_2

}

vrrp_instance eth0_1 {

version 3

interface eth0

virtual_routes {

0.0.0.0/0 via 172.16.100.1 src 172.16.100.100 dev eth0

}

virtual_ipaddress {

172.16.100.100/24 label eth0:900

}

nopreempt

priority 100

advert_int 3

garp_master_refresh 5

virtual_router_id 1

}

vrrp_instance eth1_2 {

version 3

interface eth1

virtual_ipaddress {

192.168.100.1/24 label eth1:900

}

nopreempt

priority 100

advert_int 3

garp_master_refresh 5

virtual_router_id 2

}

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

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

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

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

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

Создайте сетевой object-group с именем SELF для хранения в нем WAN адресов:

Hub1-n1#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Hub1-n1(config)#object-group network SELF

Hub1-n1(config-network-group)#remark WAN IP

Hub1-n1(config-network-group)#host 172.16.100.100

Hub1-n1(config-network-group)#host 172.16.100.10

Hub1-n1(config-network-group)#exit

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

Hub1-n1(config)#ip access-list extended FW_INPUT_WAN

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

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

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

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

Hub1-n1(config-ext-nacl)#permit vrrp any host 224.0.0.18

Hub1-n1(config-ext-nacl)#exit

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

Hub1-n1(config)#ip inspect name INSPECT tcp

Hub1-n1(config)#ip inspect name INSPECT udp

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

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

Прикрепите правила межсетевого экранирования на WAN интерфейс GigabitEthernet0/0:

Hub1-n1(config)#interface GigabitEthernet0/0

Hub1-n1(config-if)#ip access-group FW_INPUT_WAN in

Hub1-n1(config-if)#ip inspect INSPECT out

Hub1-n1(config-if)#exit

Примените настройки:

Hub1-n1(config)#end

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

Настройка трансляции адресов источника (source NAT)

Настройка sourse NAT выполняется, если устройствам из защищаемой сети или ноде в состоянии Backup/Fault необходим выход в Интернет, например, для загрузки СОС.

Трансляция адресов источника осуществляется в кластерный адрес 172.16.100.100 для трафика, выходящего с внешнего интерфейса GigabitEthernet0/0, который в данном документе соответствует eth0 (соответствие между именем интерфейса в нотации cisco-like и linux можно посмотреть в файле /etc/ifaliases.cf).

Важно:

1) Порядок обработки исходящих с интерфейса пакетов: сначала source NAT, потом IPsec (зашифрование);

2) Если требуется использовать метки (marks) в iptables, то на криптошлюзе запрещено изменять старшие 16 бит значения метки, так как они используются для внутренних нужд Продукта. Для работы с метками используйте маску (подробнее см. документ «Инструкция по настройке межсетевого экрана на «С-Терра Шлюз» при помощи утилиты «iptables»).

Войдите в linux bash:

Hub1-n1] system

Entering system shell...

Password:

root@Hub1-n1:~#

Посмотрите содержимое карты интерфейсов и найдите интерфейс в нотации linux для внешнего интерфейса GigabitEthernet0/0:

root@Hub1-n1:~# cat /etc/ifaliases.cf

interface (name="GigabitEthernet0/0" pattern="eth0")

interface (name="GigabitEthernet0/1" pattern="eth1")

interface (name="GigabitEthernet0/2" pattern="eth2")

interface (name="default" pattern="*")

Видно, что интерфейсу GigabitEthernet0/0 соответствует eth0.
Очистите настройки iptables:

root@Hub1-n1:~# netfilter-persistent flush

run-parts: executing /usr/share/netfilter-persistent/plugins.d/10-ipset flush

run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables flush

run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables flush

run-parts: executing /usr/share/netfilter-persistent/plugins.d/35-ebtables flush

run-parts: executing /usr/share/netfilter-persistent/plugins.d/40-ipset flush

Добавьте две цепочки в таблицу NAT:

root@Hub1-n1:~# iptables -N NO_SOURCE_NAT -t nat

root@Hub1-n1:~# iptables -N SOURCE_NAT -t nat

В цепочку NO_SOURCE_NAT будет направляться трафик, для которого не нужно делать source NAT. В цепочку SOURCE_NAT будет направляться трафик, для которого нужно делать source NAT.
Добавьте правила в цепочку POSTROUTING для перенаправления пакетов в цепочки NO_SOURCE_NAT, SOURCE_NAT:

root@Hub1-n1:~# iptables -I POSTROUTING -t nat -j NO_SOURCE_NAT -m comment --comment 'pass traffic to chain to bypass source NAT'

root@Hub1-n1:~# iptables -A POSTROUTING -t nat -j SOURCE_NAT -m comment --comment 'pass traffic to chain to do source NAT'

Логика следующая: все пакеты из цепочки POSTROUTING сначала направляются в цепочку NO_SOURCE_NAT, в которой определяется трафик, для которого не нужно делать source NAT. После того как трафик был определен, он прекращает свою обработку (действие ACCEPT) и, соответственно, не попадает в цепочку SOURCE_NAT. То есть в цепочку SOURCE_NAT попадает все, что не «отсеялось» в цепочке NO_SOURCE_NAT.
Добавьте iptables правила в цепочку NO_SOURCE_NAT для трафика, для которого не нужно делать source NAT:
1. Выключите source NAT для локальных IKE/ESP/NAT-T пакетов:

root@Hub1-n1:~# iptables -t nat -A NO_SOURCE_NAT -m mark --mark 0x8000000/0x8000000 -j ACCEPT -m comment --comment 'local IKE packets'

root@Hub1-n1:~# iptables -t nat -A NO_SOURCE_NAT -m mark --mark 0x40000000/0x40000000 -j ACCEPT -m comment --comment 'local ESP/NAT-T packets'

Метки 0x8000000 и 0x40000000 являются внутренними метками Продукта для локальных IKE и ESP/NAT-T пакетов соответственно.

2. Выключите source NAT для пакетов протокола VRPP:

root@Hub1-n1:~# iptables -t nat -A NO_SOURCE_NAT -p 112 -j ACCEPT -m comment --comment 'local VRRP packets'

3. Выключите source NAT для трафика, который должен шифроваться:

root@Hub1-n1:~# iptables -t nat -A NO_SOURCE_NAT -s 192.168.100.0/24 -d 192.168.1.0/24 -j ACCEPT -m comment --comment 'traffic which must be protected by IPsec'

Добавьте iptables правила в цепочку SOURCE_NAT для трафика, для которого нужно делать source NAT:
1. Включите source NAT для транзитного IPsec трафика, использующего порты 500/4500 протокола UDP:

root@Hub1-n1:~# iptables -t nat -A SOURCE_NAT -p udp --sport 500 -o eth0 -j SNAT --to-source 172.16.100.100:40500-40540 -m comment --comment 'transit IKE packets'

root@Hub1-n1:~# iptables -t nat -A SOURCE_NAT -p udp --sport 4500 -o eth0 -j SNAT --to-source 172.16.100.100:44500-44540 -m comment --comment 'transit ESP/NAT-T packets'

Нельзя, чтобы транзитный IPsec трафик использовал те же source UDP порты (500/4500), что и Продукт, так как в этом случае Продукт будет считать входящие транзитные IPsec пакеты за свои.

2. Включите source NAT для трафика из подсети 192.168.100.0/24:

root@Hub1-n1:~# iptables -t nat -A SOURCE_NAT -s 192.168.100.0/24 -o eth0 -j SNAT --to-source 172.16.100.100

Сохраните добавленные iptables правила (правила сохраняются в файл /etc/iptables/rules.v4):

root@Hub1-n1:~# netfilter-persistent save

run-parts: executing /usr/share/netfilter-persistent/plugins.d/10-ipset save

run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save

run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save

run-parts: executing /usr/share/netfilter-persistent/plugins.d/35-ebtables save

run-parts: executing /usr/share/netfilter-persistent/plugins.d/40-ipset save

Добавьте сервис netfilter-persistent.service в автозапуск, чтобы правила iptables применялись во время старта криптошлюза:

root@Hub1-n1:~# systemctl enable netfilter-persistent.service

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

Executing: /lib/systemd/systemd-sysv-install enable netfilter-persistent

Для просмотра текущих NAT правил воспользуйтесь командой:

root@Hub1-n1:~# iptables -L -n -v -t nat

Для очистки текущей таблицы трансляций сетевых соединений воспользуйтесь командой:

root@Hub1-n1:~# conntrack -D conntrack

При изменении NAT правил во время работы могут использоваться старые NAT правила. Очистка таблицы трансляций сетевых соединений позволит использовать новые правила.
Для просмотра текущей таблицы NAT трансляций воспользуйтесь командой:

root@Hub1-n1:~# conntrack -L

Опционально: сохранение контрольных сумм конфигурации

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

При последующем выполнении команды deploy будет выполняться проверка целостности конфигурации; при обнаружении расхождений VPN сервис не будет запущен. Для обновления контрольных сумм необходимо повторно выполнить команду record checksum.

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

Настройка криптошлюза Hub1-n1 завершена.

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

текст консоли cisco-like;
текст LSP;
правила iptables.

Настройка криптошлюза Hub1-n2

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

Значение priority в VRRPv3 у Hub1-n2 ноды должно быть меньше, чем у основной ноды.

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

текст консоли cisco-like;
текст LSP;
правила iptables.

Настройка криптошлюза Spoke1

Настройка криптошлюза Spoke1 происходит аналогично настройке Hub1-n1, за исключением настройки межсетевого экрана для VRRP трафика. Настройки VRRPv3 и настройка трансляции адресов источника на Spoke1 не выполняются. Все действия на криптошлюзе Spoke1 выполняются Администратором сети.

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

текст консоли cisco-like;
текст LSP.

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

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

Проверка IP связности

Проверьте, что с криптошлюзов по ICMP доступен шлюз по умолчанию (Router1). Для этого выполните команду ping из cisco-like консоли соответствующего криптошлюза.

Hub1-n1#ping 172.16.100.1

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

108 bytes from 172.16.100.1: icmp_seq=1 ttl=64 time=1.03 ms

108 bytes from 172.16.100.1: icmp_seq=2 ttl=64 time=0.364 ms

108 bytes from 172.16.100.1: icmp_seq=3 ttl=64 time=0.366 ms

108 bytes from 172.16.100.1: icmp_seq=4 ttl=64 time=0.407 ms

108 bytes from 172.16.100.1: icmp_seq=5 ttl=64 time=0.304 ms

--- 172.16.100.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.304/0.494/1.029/0.269 ms

Hub1-n2#ping 172.16.100.1

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

108 bytes from 172.16.100.1: icmp_seq=1 ttl=64 time=1.56 ms

108 bytes from 172.16.100.1: icmp_seq=2 ttl=64 time=2.41 ms

108 bytes from 172.16.100.1: icmp_seq=3 ttl=64 time=0.261 ms

108 bytes from 172.16.100.1: icmp_seq=4 ttl=64 time=0.235 ms

108 bytes from 172.16.100.1: icmp_seq=5 ttl=64 time=0.257 ms

--- 172.16.100.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.235/0.944/2.407/0.890 ms

Spoke1#ping 172.16.1.1

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

108 bytes from 172.16.1.1: icmp_seq=1 ttl=64 time=0.340 ms

108 bytes from 172.16.1.1: icmp_seq=2 ttl=64 time=0.944 ms

108 bytes from 172.16.1.1: icmp_seq=3 ttl=64 time=0.958 ms

108 bytes from 172.16.1.1: icmp_seq=4 ttl=64 time=0.380 ms

108 bytes from 172.16.1.1: icmp_seq=5 ttl=64 time=0.478 ms

--- 172.16.1.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.340/0.620/0.958/0.274 ms

Видно, что устройство Router1 доступно по ICMP со всех криптошлюзов.

Проверьте, что с защищаемых устройств Host-b-hub1 и Host-b-spoke1 доступены по ICMP соответствующие криптошлюзы. Для этого выполните команду ping из linux bash консоли защищаемых устройств.

root@Host-b-hub1:~# ping 192.168.100.1 -c 5

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

64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.307 ms

64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.361 ms

64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=2.91 ms

64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=0.625 ms

64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=0.295 ms

--- 192.168.100.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.295/0.898/2.906/1.010 ms

root@Host-b-hub1:~# ping 192.168.100.10 -c 5

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

64 bytes from 192.168.100.10: icmp_seq=1 ttl=64 time=0.361 ms

64 bytes from 192.168.100.10: icmp_seq=2 ttl=64 time=0.564 ms

64 bytes from 192.168.100.10: icmp_seq=3 ttl=64 time=0.287 ms

64 bytes from 192.168.100.10: icmp_seq=4 ttl=64 time=0.327 ms

64 bytes from 192.168.100.10: icmp_seq=5 ttl=64 time=0.349 ms

--- 192.168.100.10 ping statistics ---

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

rtt min/avg/max/mdev = 0.287/0.377/0.564/0.096 ms

root@Host-b-hub1:~# ping 192.168.100.20 -c 5

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

64 bytes from 192.168.100.20: icmp_seq=1 ttl=64 time=0.699 ms

64 bytes from 192.168.100.20: icmp_seq=2 ttl=64 time=0.595 ms

64 bytes from 192.168.100.20: icmp_seq=3 ttl=64 time=0.426 ms

64 bytes from 192.168.100.20: icmp_seq=4 ttl=64 time=0.402 ms

64 bytes from 192.168.100.20: icmp_seq=5 ttl=64 time=0.387 ms

--- 192.168.100.20 ping statistics ---

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

rtt min/avg/max/mdev = 0.387/0.501/0.699/0.123 ms

root@Host-b-spoke1:~# ping 192.168.1.1 -c 5

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

64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.335 ms

64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.485 ms

64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.08 ms

64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.403 ms

64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.341 ms

--- 192.168.1.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.335/0.528/1.076/0.279 ms

Видно, что со всех защищаемых устройств соответствующие криптошлюзы доступны по ICMP.

Проверьте, что с криптошлюза Hub1-n1 доступен по ICMP криптошлюз Spoke1 (по внешнему интерфейсу). Для этого выполните команду ping из cisco-like консоли криптошлюза Hub1-n1.

Hub1-n1#ping 172.16.1.2

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

108 bytes from 172.16.1.2: icmp_seq=1 ttl=63 time=1.01 ms

108 bytes from 172.16.1.2: icmp_seq=2 ttl=63 time=2.02 ms

108 bytes from 172.16.1.2: icmp_seq=3 ttl=63 time=1.81 ms

108 bytes from 172.16.1.2: icmp_seq=4 ttl=63 time=0.622 ms

108 bytes from 172.16.1.2: icmp_seq=5 ttl=63 time=1.91 ms

--- 172.16.1.2 ping statistics ---

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

rtt min/avg/max/mdev = 0.622/1.473/2.022/0.556 ms

Видно, что с криптошлюза Hub1-n1 доступен по ICMP криптошлюз Spoke1.

Проверка PKI

Проверьте, что на криптошлюзах СОС импортирован в базу Продукта. Для этого выполните команду run cert_mgr show из cisco-like консоли соответствующего криптошлюза.

Hub1-n1#run cert_mgr show

Found 2 certificates. Found 1 CRL.

1 Status: local C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1-n1

2 Status: trusted C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA

3 CRL: C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA

Hub1-n2#run cert_mgr show

Found 2 certificates. Found 1 CRL.

1 Status: local C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1-n2

2 Status: trusted C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA

3 CRL: C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA

Spoke1#run cert_mgr show

Found 2 certificates. Found 1 CRL.

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

2 Status: local C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Spoke1

3 CRL: C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA

Видно, что на криптошлюзах СОС импортирован в базу Продукта. Если этого не произошло, то проверьте файл журнала (команда run grep getcrls_daemon /var/log/cspvpngate.log) и, при необходимости, перезапустите сервис автоматической загрузки СОС (команда run systemctl restart getcrls.service).

Проверьте, что на криптошлюзах статус всех сертификатов Active. Для этого выполните команду run cert_mgr check из cisco-like консоли соответствующего криптошлюза.

Hub1-n1#run cert_mgr check

1 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1-n1

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

Hub1-n2#run cert_mgr check

1 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1-n2

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

Spoke1#run 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=Spoke1

Видно, что на криптошлюзах статус всех сертификатов Active. Если статус Inactive, то проверьте:

загружен ли СОС в базу Продукта;
правильны и одинаковы ли дата и время на всех криптошлюзах.

Проверка построения защищенного соединения

Инициируйте построение защищенного соединения при помощи ICMP трафика, посылаемого с устройства Host-b-spoke1 на Host-b-hub1 (можно и наоборот). Для этого выполните команду ping из linux bash консоли защищаемого устройства Host-b-spoke1.

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

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=62 time=890 ms

64 bytes from 192.168.100.100: icmp_seq=2 ttl=62 time=1.25 ms

64 bytes from 192.168.100.100: icmp_seq=3 ttl=62 time=1.31 ms

64 bytes from 192.168.100.100: icmp_seq=4 ttl=62 time=5.04 ms

64 bytes from 192.168.100.100: icmp_seq=5 ttl=62 time=5.18 ms

--- 192.168.100.100 ping statistics ---

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

rtt min/avg/max/mdev = 1.245/180.510/889.774/354.635 ms

Проверьте, что на криптошлюзах Hub1-n1 и Spoke1 установлено защищенное IPsec соединение. Для этого выполните команду run sa_mgr show из cisco-like консоли криптошлюзов.

Hub1-n1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

IKEv2 connections:

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

1 1 (172.16.100.100,500)-(172.16.1.2,500) active 1397 1427

IPsec connections:

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

1 1 (192.168.100.0-192.168.100.255,*)-(192.168.1.0-192.168.1.255,*) * ESP tunn 440 440

Hub1-n2#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

Spoke1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

IKEv2 connections:

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

1 1 (172.16.1.2,500)-(172.16.100.100,500) active 1427 1397

IPsec connections:

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

1 1 (192.168.1.0-192.168.1.255,*)-(192.168.100.0-192.168.100.255,*) * ESP tunn 440 440

Видно, что между криптошлюзами Hub1-n1 и Spoke1 установлено защищенное IPsec соединение. Если этого не произошло, то проверьте файл журнала (команда run less /var/log/cspvpngate.log). При необходимости увеличьте уровень логирования (команда logging trap debugging в консоли cisco-like) и заново инициируйте защищенное соединение.

Проверка работы межсетевого экрана

Для проверки работы межсетевого экрана выполните последовательно следующие команды из cisco-like консоли криптошлюзов и проанализируйте их вывод.

Hub1-n1#run fwconn_mgr show

Hub1-n1#run klogview -f FW,drop

Проверка отказоустойчивого решения

Файлы журналов:

сервис keepalived - /tmp/keepalived.log, /tmp/keepalived_vrrp.log (также содержимое данных лог файлов присутствует в /var/log/cspvpngate.log, префикс Keepalived).
сервис vpngate (IKE/IPsec) - /var/log/cspvpngate.log (для включения расширенных лог сообщений выполните в консоли cisco-like команду logging trap debugging).

Убедитесь, что основная нода Hub1-n1 находится в состоянии Master, а резервная Hub1-n2 в Backup, для этого выполните следующие команды из консоли cisco-like:

Hub1-n1#show vrrp

Interface VRID State AddrFamily

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

GigabitEthernet0/0 1 Master IPv4

GigabitEthernet0/1 2 Master IPv4

Hub1-n2#show vrrp

Interface VRID State AddrFamily

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

GigabitEthernet0/0 1 Backup IPv4

GigabitEthernet0/1 2 Backup IPv4

Убедитесь, что на основной ноде Hub1-n1 есть маршрут по умолчанию через Router1, а на резервной ноде Hub1-n2 через LAN адрес Hub1-n1:

Hub1-n1#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.16.100.1 to network 0.0.0.0

S* 0.0.0.0/0 [0/0] via 172.16.100.1, Source is 172.16.100.100

[100/0] via 192.168.100.20

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 [0/0] is directly connected, GigabitEthernet0/0, Source is

172.16.100.10

C 192.168.100.0/24 [0/0] is directly connected, GigabitEthernet0/1, Source i

s 192.168.100.10

Hub1-n2#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.100.10 to network 0.0.0.0

S* 0.0.0.0/0 [100/0] via 192.168.100.10

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 [0/0] is directly connected, GigabitEthernet0/0, Source is

172.16.100.20

C 192.168.100.0/24 [0/0] is directly connected, GigabitEthernet0/1, Source i

s 192.168.100.20

Смоделируйте отказ на основной ноде Hub1-n1, например отключите сетевой кабель от интерфейса GigabitEthernet0/0 и убедитесь, что роль мастера перешла к Hub1-n2:

Hub1-n1#show interfaces gigabitEthernet 0/0

GigabitEthernet0/0 is down, line protocol is down

Hardware address is 000c.294a.7eb4

MTU 1500 bytes

Hub1-n1#show vrrp

Interface VRID State AddrFamily

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

GigabitEthernet0/0 1 Fault IPv4

GigabitEthernet0/1 2 Fault IPv4

Hub1-n2#show vrrp

Interface VRID State AddrFamily

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

GigabitEthernet0/0 1 Master IPv4

GigabitEthernet0/1 2 Master IPv4

Убедитесь, что IPsec туннель между резервной нодой кластера Hub1-n2 и криптошлюзом в филиале Spoke1 успешно устанавливается. Для этого выполните следующие действия:
1. Пустите трафик с устройства Host-b-spoke1 на устройство Host-b-hub1, который должен шифроваться, например:

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

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

--- 192.168.100.100 ping statistics ---

5 packets transmitted, 0 received, 100% packet loss, time 4083ms

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

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=62 time=798 ms

64 bytes from 192.168.100.100: icmp_seq=2 ttl=62 time=3.86 ms

64 bytes from 192.168.100.100: icmp_seq=3 ttl=62 time=1.50 ms

64 bytes from 192.168.100.100: icmp_seq=4 ttl=62 time=2.55 ms

64 bytes from 192.168.100.100: icmp_seq=5 ttl=62 time=1.31 ms

--- 192.168.100.100 ping statistics ---

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

rtt min/avg/max/mdev = 1.308/161.507/798.315/318.404 ms

Видно, что первые 5 пакетов были потеряны (при перестроении IPsec туннеля). Далее связь восстановилась.
2. Проверьте наличие IPsec туннелей на Hub1-n2 и Spoke1 (на Hub1-n1 IPsec туннелей не должно быть):

Hub1-n1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

Hub1-n2#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

IKEv2 connections:

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

1 1 (172.16.100.100,500)-(172.16.1.2,500) active 1397 1427

IPsec connections:

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

1 1 (192.168.100.0-192.168.100.255,*)-(192.168.1.0-192.168.1.255,*) * ESP tunn 440 440

Spoke1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

IKEv2 connections:

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

1 2 (172.16.1.2,500)-(172.16.100.100,500) active 1427 1397

IPsec connections:

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

1 2 (192.168.1.0-192.168.1.255,*)-(192.168.100.0-192.168.100.255,*) * ESP tunn 440 440

Исправьте причину отказа на основной ноде Hub1-n1 и убедитесь, что она перешла из состояния Fault в Backup, а также проверьте наличие маршрута по умолчанию через LAN адрес Hub1-n2:

Нода Hub1-n1 не захватит роль Master (пока нода Hub1-n2 работоспособна), так как выключен preempt mode.

Hub1-n1#show interfaces GigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up

Hardware address is 000c.294a.7eb4

Internet address is 172.16.100.10/24

MTU 1500 bytes

Hub1-n1#show vrrp

Interface VRID State AddrFamily

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

GigabitEthernet0/0 1 Backup IPv4

GigabitEthernet0/1 2 Backup IPv4

Hub1-n1#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.100.20 to network 0.0.0.0

S* 0.0.0.0/0 [100/0] via 192.168.100.20

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 [0/0] is directly connected, GigabitEthernet0/0, Source is

172.16.100.10

C 192.168.100.0/24 [0/0] is directly connected, GigabitEthernet0/1, Source i

s 192.168.100.10

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

Приложение

Конфигурации криптошлюза Hub1-n1

Консоль cisco-like:

version 12.4

no service password-encryption

crypto ipsec df-bit copy

crypto isakmp identity address

crypto ipsec security-association lifetime kilobytes unlimited

username cscons privilege 15 secret 5 $6$RiWz4IVm$qMp6sbpYnTfSUxuaJPZ9UCq4yy8/xheIEbSmbTfMzmbQqepMD6R1b18vHTdFQt949xNXzpRXWA9dZ/gCK70z./

aaa new-model

fhrp version vrrp v3

hostname Hub1-n1

enable secret 5 HGJcyG+CRmCjINGFkW48VQ==

logging console critical

crypto ikev2 proposal 1

encryption magma

group gost3410-12-256

prf streebog512

crypto ikev2 policy 1

proposal 1

crypto ikev2 authentication sig IKEv2_AUTH

identity dn

set identity-mapping auto

crypto ikev2 profile IKEv2_ALGS

authentication remote IKEv2_AUTH

authentication local IKEv2_AUTH

set policy 1

dpd 3 on-demand

crypto ikev2 ipsec-proposal IKEv2_IPSEC_ALGS

esp encryption magma-mgm

object-group network SELF

remark WAN IP

host 172.16.100.100

host 172.16.100.10

ip access-list extended IPSEC_ACL_HUB1_AND_SPOKE1

permit ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255

ip access-list extended FW_INPUT_WAN

permit udp any object-group SELF eq isakmp

permit udp any object-group SELF eq non500-isakmp

permit icmp any object-group SELF

permit esp any object-group SELF

permit vrrp any host 224.0.0.18

ipv6 default filtering deny

ip inspect tcp sessions-max 256000

ip inspect udp sessions-max 65536

ip inspect name INSPECT tcp

ip inspect name INSPECT udp

crypto map VPN 1 ipsec-isakmp

match address IPSEC_ACL_HUB1_AND_SPOKE1

set ikev2-ipsec-proposal IKEv2_IPSEC_ALGS

set ikev2-profile IKEv2_ALGS

set security-association mss-fix out

set mode tunnel

set peer 172.16.1.2

set pre-fragmentation

interface GigabitEthernet0/0

ip address 172.16.100.10 255.255.255.0

ip access-group FW_INPUT_WAN in

crypto map VPN

ip inspect INSPECT out

vrrp 1 address-family ipv4

timers advertise 3

timers garp 5

no preempt

address 172.16.100.100 255.255.255.0

exit-vrrp

interface GigabitEthernet0/1

ip address 192.168.100.10 255.255.255.0

vrrp 2 address-family ipv4

timers advertise 3

timers garp 5

no preempt

address 192.168.100.1 255.255.255.0

exit-vrrp

ip route 0.0.0.0 0.0.0.0 192.168.100.20 100

crypto pki trustpoint s-terra_technological_trustpoint

revocation-check crl

crl download group ROOTCA http://172.16.101.15/certcrl.crl

crl download time 60

crypto pki certificate chain s-terra_technological_trustpoint

certificate 58E026BFD6D625BE4582C16C6189C183

...

AD4F8901771632E0A0AF83

quit

vrrp ip route 0.0.0.0 0.0.0.0 172.16.100.1 src 172.16.100.100

end

Конфигурация LSP:

# This is automatically generated LSP

# Conversion Date/Time: Mon Jan 19 16:46:52 2026

GlobalParameters(

Title = "This LSP was automatically generated by CSP Converter at Mon Jan 19 16:46:52 2026 (user: cscons)"

Version = LSP_5_0

CRLHandlingMode = ENABLE

PreserveIPsecSA = FALSE

)

RoutingTable(

Routes =

Route(

Destination = 0.0.0.0/0

Gateway = 172.16.100.1

)

FirewallParameters(

TCPSynSentTimeout = 30

TCPFinTimeout = 5

TCPClosedTimeout = 30

TCPSynRcvdTimeout = 30

TCPEstablishedTimeout = 3600

TCPHalfOpenLow = 400

TCPHalfOpenMax = 500

TCPSessionRateLow = 400

TCPSessionRateMax = 500

TCPSessionsMax = 256000

TCPStrictnessLevel = 3

UDPNotEstablishedTimeout = 30

UDPEstablishedTimeout = 120

UDPSessionsMax = 65536

)

IKEParameters2 (

SessionTimeout = 20

ResponseTimeMax = 10

SendRetries = 5

RetryTimeBase = 1

RetryTimeMax = 10

CookieChallenge = 10

NATKeepaliveInterval = 20

NATKeepaliveRetain = 300

FragmentSize = 576

FragmentSize6 = 1280

)

IKEProposal2 n1 (

EncryptionAlg = ENCR_MAGMA_MGM_KTREE

PrfAlg = PRF_HMAC_STREEBOG_512

KeyAlg = GOST3410_2012_256

)

IPsecProposal2 IKEv2_IPSEC_ALGS (

ESPEncryptionAlg = ENCR_MAGMA_MGM_KTREE

)

IdentityEntry id:local:IKEv2_AUTH (

DistinguishedName = USER_SPECIFIC_DATA

)

IKEAuthSignature2 local:IKEv2_AUTH (

Identity = id:local:IKEv2_AUTH

Credential = CertDescription()

SendCertMode = ALWAYS

)

IdentityEntry id:remote:IKEv2_AUTH (

DistinguishedName = USER_SPECIFIC_DATA

)

IKEAuthSignature2 remote:IKEv2_AUTH (

Identity = id:remote:IKEv2_AUTH

Credential = CertDescription()

SendRequestMode = ALWAYS

)

FilterChain FilterChain:FW_INPUT_WAN (

Filters = Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.2

ProtocolID = 17

DestinationPort = 500

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.2

ProtocolID = 17

DestinationPort = 4500

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.2

ProtocolID = 1

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.2

ProtocolID = 50

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 0.0.0.0/0

Action = DROP

)

IPv6Filters = Filter (

SourceIP = ::/0

DestinationIP = ::/0

Action = DROP

)

FilterChain InspectChain:INSPECT (

Filters = Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 0.0.0.0/0

ProtocolID = 6

Action = PASS

ExtendedAction = inspect_tcp<>

LogEventID = "Inspect:INSPECT:tcp"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 0.0.0.0/0

ProtocolID = 17

Action = PASS

ExtendedAction = inspect_udp<>

LogEventID = "Inspect:INSPECT:udp"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 0.0.0.0/0

Action = PASS

)

IPv6Filters = Filter (

SourceIP = ::/0

DestinationIP = ::/0

Action = DROP

)

FilterChain IPv6Default (

Filters = Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 0.0.0.0/0

Action = PASS

)

IPv6Filters = Filter (

SourceIP = ::/0

DestinationIP = ::/0

Action = DROP

)

IKEParameters(

FragmentSize = 0

)

IKERule2 IKERule2:VPN:1

(

IKEPeerIPFilter = 172.16.1.2

Proposals = n1

LocalAuth = local:IKEv2_AUTH

RemoteAuth = remote:IKEv2_AUTH

DPDMode = ONDEMAND

DPDIdleDuration = 3

Priority = 10

)

IPsecAction2 IPsecAction2:VPN:1

(

TunnelingParameters = TunnelEntry(

PeerAddress = 172.16.1.2

Prefragmentation = ENABLE

)

ContainedProposals = IKEv2_IPSEC_ALGS

MSSFixOutgoing = TRUE

DFHandling = COPY

IKERule = IKERule2:VPN:1

)

FilterChain IPsecPolicy:VPN (

Filters = Filter (

ProtocolID = 17

SourcePort = 500, 4500

Action = PASS

PacketType = LOCAL_UNICAST, LOCAL_MISDIRECTED

Filter (

SourceIP = 192.168.100.0/24

DestinationIP = 192.168.1.0/24

Action = PASS

ExtendedAction = ipsec< sa = IPsecAction2:VPN:1 >

LogEventID = "IPsec:Protect:VPN:1:IPSEC_ACL_HUB1_AND_SPOKE1"

)

NetworkInterface (

LogicalName = "GigabitEthernet0/0"

InputFilter = FilterChain:FW_INPUT_WAN

OutputFilter = InspectChain:INSPECT

IPsecPolicy = IPsecPolicy:VPN

)

NetworkInterface (

LogicalName = "GigabitEthernet0/1"

InputFilter = IPv6Default

OutputFilter = IPv6Default

)

Правила iptables:

iptables -N NO_SOURCE_NAT -t nat

iptables -N SOURCE_NAT -t nat

iptables -I POSTROUTING -t nat -j NO_SOURCE_NAT -m comment --comment 'pass traffic to chain to bypass source NAT'

iptables -A POSTROUTING -t nat -j SOURCE_NAT -m comment --comment 'pass traffic to chain to do source NAT'

iptables -t nat -A NO_SOURCE_NAT -m mark --mark 0x8000000/0x8000000 -j ACCEPT -m comment --comment 'local IKE packets'

iptables -t nat -A NO_SOURCE_NAT -m mark --mark 0x40000000/0x40000000 -j ACCEPT -m comment --comment 'local ESP/NAT-T packets'

iptables -t nat -A NO_SOURCE_NAT -p 112 -j ACCEPT -m comment --comment 'local VRRP packets'

iptables -t nat -A NO_SOURCE_NAT -s 192.168.100.0/24 -d 192.168.1.0/24 -j ACCEPT -m comment --comment 'traffic which must be protected by IPsec'

iptables -t nat -A SOURCE_NAT -p udp --sport 500 -o eth0 -j SNAT --to-source 172.16.100.100:40500-40540 -m comment --comment 'transit IKE packets'

iptables -t nat -A SOURCE_NAT -p udp --sport 4500 -o eth0 -j SNAT --to-source 172.16.100.100:44500-44540 -m comment --comment 'transit ESP/NAT-T packets'

iptables -t nat -A SOURCE_NAT -s 192.168.100.0/24 -o eth0 -j SNAT --to-source 172.16.100.100

Конфигурации криптошлюза Hub1-n2

Консоль cisco-like:

version 12.4

no service password-encryption

crypto ipsec df-bit copy

crypto isakmp identity address

crypto ipsec security-association lifetime kilobytes unlimited

username cscons privilege 15 secret 5 $6$RiWz4IVm$qMp6sbpYnTfSUxuaJPZ9UCq4yy8/xheIEbSmbTfMzmbQqepMD6R1b18vHTdFQt949xNXzpRXWA9dZ/gCK70z./

aaa new-model

fhrp version vrrp v3

hostname Hub1-n2

enable secret 5 HGJcyG+CRmCjINGFkW48VQ==

logging console critical

crypto ikev2 proposal 1

encryption magma

group gost3410-12-256

prf streebog512

crypto ikev2 policy 1

proposal 1

crypto ikev2 authentication sig IKEv2_AUTH

identity dn

set identity-mapping auto

crypto ikev2 profile IKEv2_ALGS

authentication remote IKEv2_AUTH

authentication local IKEv2_AUTH

set policy 1

dpd 3 on-demand

crypto ikev2 ipsec-proposal IKEv2_IPSEC_ALGS

esp encryption magma-mgm

object-group network SELF

remark WAN IP

host 172.16.100.100

host 172.16.100.20

ip access-list extended IPSEC_ACL_HUB1_AND_SPOKE1

permit ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255

ip access-list extended FW_INPUT_WAN

permit udp any object-group SELF eq isakmp

permit udp any object-group SELF eq non500-isakmp

permit icmp any object-group SELF

permit esp any object-group SELF

permit vrrp any host 224.0.0.18

ipv6 default filtering deny

ip inspect tcp sessions-max 256000

ip inspect udp sessions-max 65536

ip inspect name INSPECT tcp

ip inspect name INSPECT udp

crypto map VPN 1 ipsec-isakmp

match address IPSEC_ACL_HUB1_AND_SPOKE1

set ikev2-ipsec-proposal IKEv2_IPSEC_ALGS

set ikev2-profile IKEv2_ALGS

set security-association mss-fix out

set mode tunnel

set peer 172.16.1.2

set pre-fragmentation

interface GigabitEthernet0/0

ip address 172.16.100.20 255.255.255.0

ip access-group FW_INPUT_WAN in

crypto map VPN

ip inspect INSPECT out

vrrp 1 address-family ipv4

timers advertise 3

timers garp 5

no preempt

priority 50

address 172.16.100.100 255.255.255.0

exit-vrrp

interface GigabitEthernet0/1

ip address 192.168.100.20 255.255.255.0

vrrp 2 address-family ipv4

timers advertise 3

timers garp 5

no preempt

priority 50

address 192.168.100.1 255.255.255.0

exit-vrrp

ip route 0.0.0.0 0.0.0.0 192.168.100.10 100

crypto pki trustpoint s-terra_technological_trustpoint

revocation-check crl

crl download group ROOTCA http://172.16.101.15/certcrl.crl

crl download time 60

crypto pki certificate chain s-terra_technological_trustpoint

certificate 58E026BFD6D625BE4582C16C6189C183

...

AD4F8901771632E0A0AF83

quit

vrrp ip route 0.0.0.0 0.0.0.0 172.16.100.1 src 172.16.100.100

end

Конфигурация LSP:

# This is automatically generated LSP

# Conversion Date/Time: Wed Apr 22 13:59:14 2026

GlobalParameters(

Title = "This LSP was automatically generated by CSP Converter at Wed Apr 22 13:59:14 2026 (user: cscons)"

Version = LSP_5_0

CRLHandlingMode = ENABLE

PreserveIPsecSA = FALSE

)

RoutingTable(

Routes =

Route(

Destination = 0.0.0.0/0

Gateway = 192.168.100.10

Metric = 100

)

FirewallParameters(

TCPSynSentTimeout = 30

TCPFinTimeout = 5

TCPClosedTimeout = 30

TCPSynRcvdTimeout = 30

TCPEstablishedTimeout = 3600

TCPHalfOpenLow = 400

TCPHalfOpenMax = 500

TCPSessionRateLow = 400

TCPSessionRateMax = 500

TCPSessionsMax = 256000

TCPStrictnessLevel = 3

UDPNotEstablishedTimeout = 30

UDPEstablishedTimeout = 120

UDPSessionsMax = 65536

)

IKEParameters2 (

SessionTimeout = 20

ResponseTimeMax = 10

SendRetries = 5

RetryTimeBase = 1

RetryTimeMax = 10

CookieChallenge = 10

NATKeepaliveInterval = 20

NATKeepaliveRetain = 300

FragmentSize = 576

FragmentSize6 = 1280

)

IKEProposal2 n1 (

EncryptionAlg = ENCR_MAGMA_MGM_KTREE

PrfAlg = PRF_HMAC_STREEBOG_512

KeyAlg = GOST3410_2012_256

)

IPsecProposal2 IKEv2_IPSEC_ALGS (

ESPEncryptionAlg = ENCR_MAGMA_MGM_KTREE

)

IdentityEntry id:local:IKEv2_AUTH (

DistinguishedName = USER_SPECIFIC_DATA

)

IKEAuthSignature2 local:IKEv2_AUTH (

Identity = id:local:IKEv2_AUTH

Credential = CertDescription()

SendCertMode = ALWAYS

)

IdentityEntry id:remote:IKEv2_AUTH (

DistinguishedName = USER_SPECIFIC_DATA

)

IKEAuthSignature2 remote:IKEv2_AUTH (

Identity = id:remote:IKEv2_AUTH

Credential = CertDescription()

SendRequestMode = ALWAYS

)

FilterChain FilterChain:FW_INPUT_WAN (

Filters = Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.100

ProtocolID = 17

DestinationPort = 500

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.20

ProtocolID = 17

DestinationPort = 500

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.100

ProtocolID = 17

DestinationPort = 4500

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.20

ProtocolID = 17

DestinationPort = 4500

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.100

ProtocolID = 1

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.20

ProtocolID = 1

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.100

ProtocolID = 50

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 172.16.100.20

ProtocolID = 50

Action = PASS

LogEventID = "FW_INPUT_WAN"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 0.0.0.0/0

Action = DROP

)

IPv6Filters = Filter (

SourceIP = ::/0

DestinationIP = ::/0

Action = DROP

)

FilterChain InspectChain:INSPECT (

Filters = Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 0.0.0.0/0

ProtocolID = 6

Action = PASS

ExtendedAction = inspect_tcp<>

LogEventID = "Inspect:INSPECT:tcp"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 0.0.0.0/0

ProtocolID = 17

Action = PASS

ExtendedAction = inspect_udp<>

LogEventID = "Inspect:INSPECT:udp"

Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 0.0.0.0/0

Action = PASS

)

IPv6Filters = Filter (

SourceIP = ::/0

DestinationIP = ::/0

Action = DROP

)

FilterChain IPv6Default (

Filters = Filter (

SourceIP = 0.0.0.0/0

DestinationIP = 0.0.0.0/0

Action = PASS

)

IPv6Filters = Filter (

SourceIP = ::/0

DestinationIP = ::/0

Action = DROP

)

IKEParameters(

FragmentSize = 0

)

IKERule2 IKERule2:VPN:1

(

IKEPeerIPFilter = 172.16.1.2

Proposals = n1

LocalAuth = local:IKEv2_AUTH

RemoteAuth = remote:IKEv2_AUTH

DPDMode = ONDEMAND

DPDIdleDuration = 3

Priority = 10

)

IPsecAction2 IPsecAction2:VPN:1

(

TunnelingParameters = TunnelEntry(

PeerAddress = 172.16.1.2

Prefragmentation = ENABLE

)

ContainedProposals = IKEv2_IPSEC_ALGS

MSSFixOutgoing = TRUE

DFHandling = COPY

IKERule = IKERule2:VPN:1

)

FilterChain IPsecPolicy:VPN (

Filters = Filter (

ProtocolID = 17

SourcePort = 500, 4500

Action = PASS

PacketType = LOCAL_UNICAST, LOCAL_MISDIRECTED

Filter (

SourceIP = 192.168.100.0/24

DestinationIP = 192.168.1.0/24

Action = PASS

ExtendedAction = ipsec< sa = IPsecAction2:VPN:1 >

LogEventID = "IPsec:Protect:VPN:1:IPSEC_ACL_HUB1_AND_SPOKE1"

)

NetworkInterface (

LogicalName = "GigabitEthernet0/0"

InputFilter = FilterChain:FW_INPUT_WAN

OutputFilter = InspectChain:INSPECT

IPsecPolicy = IPsecPolicy:VPN

)

NetworkInterface (

LogicalName = "GigabitEthernet0/1"

InputFilter = IPv6Default

OutputFilter = IPv6Default

)

Правила iptables: