Построение отказоустойчивого решения на базе протокола VRRP с динамической маршрутизацией GRE/OSPF

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

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

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

Введение

Данный сценарий содержит пример настойки «С-Терра Шлюз» для построения отказоустойчивого решения на базе протокола VRRP с динамической маршрутизацией GRE/OSPF.

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

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

Предполагается, что перед началом настройки стенд собран и настроен в соответствии со сценарием «Построение отказоустойчивого решения на базе протокола VRRP с настройкой через cisco-like консоль».

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

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

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

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

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

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

1. Требования к устройствам.

1.1. «С-Терра Шлюз».

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

1.2. Центр выпуска сертификатов.

1.2.1 Должен быть настроен центр выпуска сертификатов (удостоверяющий центр, далее УЦ) для IPsec. Устройство с именем Certification_authority на схеме.

1.2.2 Для выпуска цифровых сертификатов допускается использование встроенного в OC Windows Server 2008R2 (или новее) удостоверяющего центра совместно с сертифицированным СКЗИ «КриптоПро» CSP 4.0 (или новее).

1.2.3 Для тестовых целей можно использовать тестовый УЦ от «КриптоПро» (веб-интерфейс: https://www.cryptopro.ru/certsrv/certrqxt.asp).

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

1.3. HTTP сервер для распространения списка отозванных сертификатов.

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

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

2. Требования к сетевому взаимодействию.

2.1. Коммутаторы в центральном офисе.

2.1.1 В центральном офисе необходимо установить два коммутатора (устройства с именами Int_switch1_Hub1 и Ext_switch2_Hub1 на схеме). Это требуется для разделения трафика доверенного и недоверенного сегментов по разным физическим устройствам.

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

2.1.2 На портах коммутаторов, к которым подключаются сетевые интерфейсы нод кластера, должен быть включен режим portfast. В противном случае могут происходить потери gARP пакетов при переходе ноды в состояние MASTER.

Схема взаимодействия

Рисунок 1. Схема взаимодействия

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

1. Размещение устройств.

1.1. В центральном офисе размещаются: центр выпуска сертификатов (Certification_authority), два криптошлюза «С-Терра Шлюз» (Hub1-n1 и Hub1-n2), два коммутатора (Int_switch1_Hub1 и Ext_switch2_Hub1) и персональный компьютер (host_behind_hub1).

1.2. В филиале размещаются: криптошлюз «С-Терра Шлюз» (Spoke1) и персональный компьютер (host_behind_spoke1).

1.3. В неконтролируемом сегменте (синее облако на схеме) размещаются: HTTP-сервер для распространения списка отозванных сертификатов (CRL_distribution_point), маршрутизатор (Router1).

2. Подключение к сети Интернет.

2.В данном сценарии для эмуляции сети Интернет используется маршрутизатор Router1.

Так как необходимо обеспечить периодическое обновление списка отозванных сертификатов на резервной ноде кластера, то на нодах будет настроен source NAT при помощи утилит iptables и netfilter-persistent, входящих в состав ОС.

Подключение к сети Интернет на устройствах «С-Терра Шлюз» будет считаться успешным, если по протоколу ICMP, например, при помощи утилиты «ping», будет доступен HTTP-сервер для распространения списка отозванных сертификатов (устройство CRL_distribution_point на схеме).

2.1. Кластер из криптошлюзов Hub1-n1 и Hub1-n2 подключается к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизатор Router1).

Если на кластер выделен только один публичный IP адрес, то используйте разные подсети для кластерного IP адреса и основного IP адреса на интерфейсе, где включен VRRP.

2.2. Криптошлюз Spoke1 подключается к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизатор Router1).

3. Отказоустойчивый кластер.

Криптошлюзы Hub1-n1 и Hub1-n2 объединяются в отказоустойчивый кластер, работающий на базе протокола VRRP в режиме Master/Backup. За реализацию протокола VRRP отвечает ПО «keepalived».

Криптошлюзы Hub1-n1 и Hub1-n2 являются нодами кластера.

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

Нода, находящаяся в состоянии Master, владеет VIP адресами в доверенном и недоверенном сегментах и, соответственно, обрабатывает трафик. Нода, находящаяся в состоянии Backup или Fault, не владеет VIP адресами.

По умолчанию все VRRP интерфейсы синхронизированы в группу номер ноль. Соответственно, они одновременно меняют свое состояние (данное поведение отличается от Cisco IOS, где по умолчанию VRRP интерфейсы не синхронизированы).

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

При переходе ноды в состояние Master добавляется маршрут по умолчанию (команда vrrp ip route … в cisco-like консоли) через маршрутизатор Router1 (при переходе в состояния Backup или Fault он удаляется).

При переходе ноды в состояния Backup или Fault добавляется маршрут по умолчанию через VIP адрес доверенного сегмента ноды, находящейся в состоянии Mаster (с целью получения удаленного доступа к резервной ноде через активную). Настройка добавления маршрутов происходит при помощи файла /etc/keepalived/notify_common.conf, который управляет скриптом /etc/keepalived/scripts/notify_common. Включение запуска данного скрипта при переходах между состояниями кластера осуществляется через cisco-like консоль при помощи команды vrrp notify common.

На нодах кластера выключен режим preempt mode – это значит, что нода с более высоким приоритетом не будет захватывать роль Master у рабочей ноды с более низким приоритетом. Данная настройка помогает избавиться от лишних переключений.

Кластер обрабатывает следующие типы отказов:

· отключение питания;

· выход из строя аппаратной платформы;

· отказ сетевого порта на аппаратной платформе;

· отказ сетевого порта на коммутационном оборудовании;

· отказ сервиса vpngate, обеспечивающего построение IPsec туннелей.

Среднее время переключения составляет 15 секунд.

4. Трансляция адресов источника (source NAT).

Source NAT выполняется в данном сценарии только на нодах кластера в центральном офисе (если требуется настроить source NAT на филиальном шлюзе Spoke1, то действуйте по аналогии). Трансляция адресов источника осуществляется в кластерный VIP адрес 172.16.100.100.

В общем случае предполагается, что HTTP сервер, распространяющий список отозванных сертификатов, располагается в сети Интернет. С учетом того, что требуется обеспечить периодическое обновление списка отозванных сертификатов на резервной ноде кластера, нужно, чтобы она имела выход в Интернет (примечание: нода, находящаяся в состоянии Backup или Fault, выходит в Интернет через ноду, которая находится в состоянии Master). Следовательно, на нодах должен быть настроен source NAT. Настройка осуществляется при помощи утилит iptables и netfilter-persistent, входящих в состав ОС.

Для корректной работы source NAT на «С-Терра Шлюз» реализуются следующие условия:

· Source NAT отключается для перечисленных ниже пакетов:

· локальные IKE/ESP/NAT-T пакеты;

· локальные VRRP пакеты;

· для трафика между защищаемыми сетями (от 192.168.100.0/24 до 192.168.1.0/24);

· для GRE трафика.

· Изменяются source порты пакетов IKE/NAT-T транзитного IPsec трафика третьих устройств с 500 на 40500-40540 и с 4500 на 44500-44540 (так как порты 500 и 4500 используются по умолчанию на «С-Терра Шлюз»).

5. Параметры безопасного взаимодействия.

Внутри GRE-туннелей проходит пользовательский трафик между защищаемыми подсетями, а также пакеты динамической маршрутизации OSPF. Весь GRE трафик между шлюзами центрального офиса (Hub1-n1, Hub1-n2) и шлюзом филиала (Spoke1) защищается с использованием алгоритмов ГОСТ и протокола IPsec в туннельном режиме.

Инициировать защищенное соединение может как GRE трафик от шлюза центрального офиса 172.16.100.100/24 к шлюзу филиала 172.16.1.2/24, так и наоборот. GRE-туннель строится между VIP адресом кластера (172.16.100.100/24) и адресом внешнего интерфейса филиала (172.16.1.2/24). В GRE-туннеле, благодаря протоколу OSPF, происходит обмен информации о защищённых сетях. За реализацию протокола OSPF отвечает ПО «FFRouting». При отказе GRE-туннеля или протокола OSPF трафик до защищаемой подсети партнера будет блокироваться с помощью межсетевого экрана.

5.1. Параметры протокола IKE:

· Аутентификация при помощи цифровых сертификатов, алгоритм подписи – ГОСТ Р 34.10-2012 (ключ 256 бит);

· Алгоритм шифрования – ГОСТ 28147-89 (ключ 256 бит);

· Алгоритм вычисления хеш-функции – ГОСТ Р 34.11-2012 ТК26 (ключ 256 бит);

· Алгоритм выработки общего ключа (аналог алгоритма Диффи-Хеллмана) – VKO_GOSTR3410_2012_256 (ключ 256 бит).

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

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

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

В данном сценарии будет описана настройка GRE-интерфейса, конфигурирование динамической маршрутизации OSPF, настройка трансляции адресов источника (source NAT) и изменение политики безопасности. Начальная настройка криптошлюзов, настройки PKI, паролей доступа к консоли cisco-like, сетевых параметров, VRRP, шифрования и политики обработки СОС (CRL) содержатся в сценарии «Построение отказоустойчивого решения на базе протокола VRRP с настройкой через cisco-like консоль».

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

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

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

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

1. Войдите в CLI разграничения доступа. Для этого, после появления сообщения:

S-Terra administrative console

введите логин и пароль для CLI разграничения доступа:

Пользователь и пароль по умолчанию: administrator, s-terra. Пароль мог быть изменён при настройке стенда по предшествующему сценарию «Построение отказоустойчивого решения на базе протокола VRRP с настройкой через cisco-like консоль».

administrator's password:

administrator@Hub1-n1]

2. Перейдите в linux bash, для этого выполните следующую команду в CLI разграничения доступа:

administrator@Hub1-n1] system

Entering system shell...

root@Hub1-n1:~#

3. Создайте файл /etc/network/interfaces.d/gre1 и заполните его:

auto gre1

iface gre1 inet static

address 10.10.10.0

netmask 255.255.255.254

mtu 1400

pre-up ip tunnel add gre1 mode gre local 172.16.100.100 remote 172.16.1.2 ttl 255 tos inherit

pre-up ethtool -K gre1 tx off > /dev/null

pre-up ip link set gre1 type gre nopmtudisc

pre-up ip link set gre1 type gre ignore-df

post-down ip link del gre1

Примечание:

ip tunnel add gre1 mode gre local 172.16.100.100 remote 172.16.1.2 ttl 255 tos inherit – добавляет GRE-туннель между интерфейсом с IP-адресом 172.16.100.100 до устройства с адресом 172.16.1.2 и наследование tos;

ip link set gre1 up – переводит gre1-интерфейс в состояние up;

ip link del gre1 – удаляет информацию о gre1-интерфейсе из записей об интерфейсах.

4. Переведите интерфейс gre1 в состояние up:

root@Hub1-n1:~# ifup gre1

При старте могут возникать сообщения – не обращайте на них внимание:

Nov 15 14:51:47 sterrragate ntpdate[2094]: name server cannot be used: Temporary failure in name resolution (-3)

Изменение политики безопасности

Параметры IPsec изменяются из cisco-like консоли:

1. Войдите в cisco-like консоль из linux bash:

root@Hub1-n1:~# cs_console

Hub1-n1>enable

Pssword:

Hub1-n1#

2. Удалите старый список доступа (ACL):

Hub1-n1#configure terminal

Hub1-n1(config)#no ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1

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

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

Hub1-n1(config-ext-nacl)#permit gre host 172.16.100.100 host 172.16.1.2

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

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

4. Создайте новый список доступа для фильтрации незашифрованного трафика до защищаемой подсети партнера:

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

Hub1-n1(config-ext-nacl)#deny ip any 192.168.1.0 0.0.0.255

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

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

5. Привяжите список доступа к внешнему интерфейсу:

Spoke1(config)#interface GigabitEthernet0/0

Spoke1(config-if)#ip access-group FIREWALL_HUB1_AND_SPOKE1 out

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

Hub1-n1(config-if)#end

Hub1-n1#exit

Настройка динамической маршрутизации OSPF

OSPF настраивается через консоль сервиса FRR.

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

root@Hub1-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@Hub1-n1:~# systemctl start frr

При старте могут возникать сообщения:

Nov 15 15:01:54 sterrragate watchfrr[831]: [EC 268435467] zebra state -> down : initial connection attempt failed

Nov 15 15:01:54 sterrragate watchfrr[831]: [EC 268435467] bgpd state -> down : initial connection attempt failed

Nov 15 15:01:54 sterrragate watchfrr[831]: [EC 268435467] ripd state -> down : initial connection attempt failed

Nov 15 15:01:54 sterrragate watchfrr[831]: [EC 268435467] ospfd state -> down : initial connection attempt failed

Nov 15 15:01:54 sterrragate watchfrr[831]: [EC 268435467] pbrd state -> down : initial connection attempt failedstaticd

Nov 15 15:01:54 sterrragate watchfrr[831]: [EC 268435467] zebra state -> down : initial connection attempt failed

Nov 15 15:01:54 sterrragate watchfrr[831]: [EC 100663303] Forked background command [pid 832]: /usr/lib/frr/watchfrr.sh restart all

Nov 15 15:01:54 sterrragate watchfrr.sh: Cannot stop bgpd: pid file not found

Nov 15 15:01:54 sterrragate watchfrr.sh: Cannot stop ripd: pid file not found

Nov 15 15:01:54 sterrragate watchfrr.sh: Cannot stop zebra: pid file not found

Nov 15 15:01:54 sterrragate watchfrr.sh: Cannot stop ospfd: pid file not found

Nov 15 15:01:54 sterrragate watchfrr.sh: Cannot stop pbrd: pid file not found

Nov 15 15:01:54 sterrragate watchfrr.sh: Cannot stop staticd: pid file not found

Данные сообщения не являются ошибкой при старте сервиса.

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

root@Hub1-n1:~# vtysh

Hello, this is FRRouting (version 7.3).

Hub1-n1#

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

Hub1-n1# configure terminal

Hub1-n1(config)# router ospf

Hub1-n1(config-router)# ospf router-id 172.16.100.10

Hub1-n1(config-router)# passive-interface eth0

Hub1-n1(config-router)# passive-interface eth1

Hub1-n1(config-router)# network 10.10.10.0/31 area 0.0.0.0

Hub1-n1(config-router)# network 192.168.100.0/24 area 0.0.0.0

4. Сохраните настройки сервиса FRR:

Hub1-n1(config-router)# do 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-n1(config-router)# end

Hub1-n1# exit

При добавлении в систему GRE интерфейса, при перезапуске сервисов networking и vpndrv во время работы FRR, тип сети GRE интерфейсов в FRR меняется на broadcast и получение маршрутов через GRE интерфейс приостанавливается.

Чтобы избежать проблемы нужно, после добавления нового GRE интерфейса, а также при перезапуске сервисов networking и vpndrv, перезапустить сервис FRR, чтобы использовались сохраненные в FRR настройки.

root@Hub1-n1:~# systemctl restart frr

5. В случаях, когда OSPF задействован на большом количестве интерфейсов (10 или более), на шлюзе может происходить достижение лимита MULTICAST записей на один сокет, заданного в системной переменной net.ipv4.igmp_max_memberships (значение по умолчанию – 20). В этих случаях может наблюдаться нарушение работоспособности OSPF (потери OSPF соседства), и в логе /var/log/frr/frr.log появляются сообщения об ошибке, например:

Mar 31 10:01:32 Hub1 ospfd[4174]: [V5G42-FE94B][EC 100663299] can't setsockopt IP_ADD_MEMBERSHIP (fd 15, addr 10.10.9.1, ifindex 20, AllSPFRouters): No buffer space available; perhaps a kernel limit on # of multicast group memberships has been exceeded?

В таком случае следует в конфигурационный файл /etc/sysctl.conf добавить эту переменную с увеличенным значением, например:

net.ipv4.igmp_max_memberships=40

Для применения изменений следует выполнить следующую команду из Linux консоли криптошлюза:

sysctl -p

В общем случае, значение следует выбирать в соответствии с количеством интерфейсов, задействованных в OSPF, умноженном на два. Рекомендуемое максимальное значение для данного параметра – до 150.

Посмотреть количество текущих MULTICAST записей (в контексте OSPF) на всех интерфейсах можно следующей командой в Linux консоли криптошлюза:

ip -4 -o maddress | grep "224.0.0.5\|224.0.0.6" | wc -l

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

1. Очистите настройки iptables:

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

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

2. Добавьте две цепочки в таблицу 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.

3. Добавьте правила в цепочку 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.

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

4.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 пакетов соответственно.

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

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

4.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 encapsulated'

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

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

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

5.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 пакеты за свои.

5.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

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

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

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

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

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

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

root@Hub1-n1:~# conntrack -L

Настройка порядка запуска FRR сервиса

При загрузке шлюза сервис networking запускается параллельно вместе с сервисом FRR. Поэтому может возникнуть ситуации, что FRR прочитает настройки из /etc/frr/frr.conf раньше, чем появятся GRE интерфейсы в системе. Это приведет к тому, что у GRE интерфейсов будет “ip ospf network broadcast” в настройках FRR. Для того чтобы избежать данной проблемы, следует настроить запуск FRR сервиса после сервиса networking. Настройка осуществляется из linux bash:

1. Создайте директорию "/etc/systemd/system/frr.service.d/":

root@Hub1-n1:~# mkdir -p /etc/systemd/system/frr.service.d

2. Создайте файл "/etc/systemd/system/frr.service.d/add_dependency.conf" с содержимым:

[Unit]

After=networking.service

3. Выполните пересчет хешей при выполнении любого из следующих условий:

· для любого класса СКЗИ, если доверенная загрузка Шлюза обеспечивается программными средствами (СофтМДЗ, см. файл /etc/image_version);

· для классов СКЗИ КС2 и КС3, если доверенная загрузка Шлюза обеспечивается аппаратными средствами.

root@Hub1:~# /opt/VPNagent/bin/links_verify.sh update

4. Перезапустите шлюз:

root@Hub1-n1:~# reboot

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

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

· содержимое /etc/network/interfaces.d/gre1;

· текст консоли FRR;

· содержимое /etc/keepalived/notify_common.conf;

· правила iptables.

Настройка криптошлюза Hub1-n2 (резервная нода кластера)

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

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

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

· содержимое /etc/network/interfaces.d/gre1;

· текст консоли FRR;

· содержимое /etc/keepalived/notify_common.conf;

· правила iptables.

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

Настройка криптошлюза Spoke1 производится по аналогии с Hub1-n1 с соответствующими IP-адресами.

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

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

· содержимое /etc/network/interfaces.d/gre1;

· текст консоли FRR.

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

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

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

· сервис keepalived - /tmp/keepalived.log, /tmp/keepalived_vrrp.log (также содержимое данных лог файлов присутствует в /var/log/cspvpngate.log, префикс Keepalived).

· скрипт /etc/keepalived/scripts/notify_common - /var/log/cspvpngate.log (префикс VRRP notify common script)

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

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

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Master

GigabitEthernet0/1 2 Master

Hub1-n2#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Backup

GigabitEthernet0/1 2 Backup

2. Убедитесь в том, что на основной ноде Hub1-n1 маршрут по умолчанию через Router1, а на резервной ноде Hub1-n2 через VIP адрес доверенного сегмента. Так же убедитесь, что был получен маршрут до защищенной подсети филиала Spoke1 через gre-интерфейс:

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 [1/0] via 172.16.100.1

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 is directly connected, GigabitEthernet0/0

S 192.168.1.0/24 [1/0] via 10.10.10.1

C 192.168.100.0/24 is directly connected, GigabitEthernet0/1

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.1 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 192.168.100.1

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 is directly connected, GigabitEthernet0/0

C 192.168.100.0/24 is directly connected, GigabitEthernet0/1

3. Убедитесь, что маршрут до защищаемой подсети был получен при помощи протокола OSPF через консоль FRR:

Hub1-n1# show ip route

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, D - SHARP,

F - PBR, f - OpenFabric,

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

K>* 0.0.0.0/0 [0/0] via 172.16.100.1, eth0, src 172.16.100.100, 03:58:51

O 10.10.10.0/31 [110/10] is directly connected, gre1, 05:05:45

C>* 10.10.10.0/31 is directly connected, gre1, 05:05:45

C * 172.16.100.0/24 is directly connected, eth0, 03:58:51

C>* 172.16.100.0/24 is directly connected, eth0, 05:05:45

O>* 192.168.1.0/24 [110/110] via 10.10.10.1, gre1, 03:58:34

C * 192.168.100.0/24 is directly connected, eth1, 03:58:51

O 192.168.100.0/24 [110/100] is directly connected, eth1, 05:05:45

C>* 192.168.100.0/24 is directly connected, eth1, 05:05:45

Spoke1# show ip route

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, D - SHARP,

F - PBR, f - OpenFabric,

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

K>* 0.0.0.0/0 [0/0] via 172.16.1.1, eth0, 05:09:33

O 10.10.10.0/31 [110/10] is directly connected, gre1, 05:09:35

C>* 10.10.10.0/31 is directly connected, gre1, 05:09:35

C>* 172.16.1.0/24 is directly connected, eth0, 05:09:35

O 192.168.1.0/24 [110/100] is directly connected, eth1, 05:09:35

C>* 192.168.1.0/24 is directly connected, eth1, 05:09:35

O>* 192.168.100.0/24 [110/110] via 10.10.10.0, gre1, 04:02:05

Вывод консоли свидетельствует о том, что маршрут до защищаемой подсети 192.168.1.0/24 присутствует на активной ноде, а маршрут до защищаемой подсети 192.168.100.0/24 на криптошлюзе филиала.

4. Используя cisco-like консоль, убедитесь, что основная Hub1-n1 и резервная Hub1-n2 ноды кластера успешно загрузили СОС:

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

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

5.1. Пустите трафик с устройства host_behind_spoke1 на устройство host_behind_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.

64 bytes from 192.168.100.100: icmp_seq=1 ttl=62 time=304 ms

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

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

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

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

--- 192.168.100.100 ping statistics ---

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

rtt min/avg/max/mdev = 0.707/61.409/304.034/121.312 ms

5.2. Проверьте наличие IPsec туннелей на Hub1-n1 и Spoke1 (на Hub1-n2 IPsec туннелей не должно быть):

Hub1-n1#run 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 (172.16.100.100,500)-(172.16.1.2,500) active 1820 1788

IPsec connections:

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

1 1 (172.16.100.100,*)-(172.16.1.2,*) 47 ESP tunn 440 440

Spoke1#run 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 (172.16.1.2,500)-(172.16.100.100,500) active 1788 1820

IPsec connections:

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

1 3 (172.16.1.2,*)-(172.16.100.100,*) 47 ESP tunn 440 440

Hub1-n2#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

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

Hub1-n1#show interfaces gigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is down

Hardware address is 0050.569e.b06d

Internet address is 172.16.100.10/24

MTU 1500 bytes

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Fault

GigabitEthernet0/1 2 Fault

Hub1-n2#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Master

GigabitEthernet0/1 2 Master

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

7.1. Пустите трафик с устройства host_behind_spoke1 на устройство host_behind_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 4086ms

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=442 ms

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

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

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

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

--- 192.168.100.100 ping statistics ---

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

rtt min/avg/max/mdev = 0.750/89.065/442.187/176.561 ms

Вывод консоли свидетельствует о том, что первые 5 пакетов были потеряны при перестроении IPsec туннеля. Далее, связь восстановилась.

7.2. Проверьте наличие IPsec туннелей на Hub1-n2 и Spoke1 (на Hub1-n1 IPsec туннелей не должно быть):

Hub1-n1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

Spoke1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

1 4 (172.16.1.2,500)-(172.16.100.100,500) active 1788 1716

IPsec connections:

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

1 4 (172.16.1.2,*)-(172.16.100.100,*) 47 ESP tunn 440 440

Hub1-n2#run 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 (172.16.100.100,500)-(172.16.1.2,500) active 1716 1788

IPsec connections:

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

1 1 (172.16.100.100,*)-(172.16.1.2,*) 47 ESP tunn 440 440

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

Нода 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 0050.569e.b06d

Internet address is 172.16.100.10/24

MTU 1500 bytes

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Backup

GigabitEthernet0/1 2 Backup

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.1 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 192.168.100.1

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 is directly connected, GigabitEthernet0/0

C 192.168.100.0/24 is directly connected, GigabitEthernet0/1

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

Приложение

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

1. Консоль cisco-like:

version 12.4

no service password-encryption

crypto ipsec df-bit clear

crypto isakmp identity dn

crypto isakmp fragmentation

crypto isakmp security-association lifetime delta 50

crypto isakmp initiator-sessions-max 100

crypto isakmp responder-sessions-max 100

crypto isakmp keepalive 3

crypto isakmp keepalive retry-count 5

username cscons privilege 15 secret 5 $6$tHtq8SR6$t3CWE6udI6L/ARr9jQowUYR7wEbOW

Zlx61OvLi7goonOFUYhNSGV49BA.RDGEZ7oKXBA1aTRi20ElR4wtMXTl0

aaa new-model

hostname Hub1-n1

enable secret 5 PC9d7N5HlAyLrzuA3qRJvQ==

crypto isakmp policy 1

encr gost

hash gost341112-256-tc26

authentication gost-sig

group vko2

crypto ipsec transform-set GOST_ENCRYPT_AND_INTEGRITY esp-gost28147-4m-imit

ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1

permit gre host 172.16.100.100 host 172.16.1.2

ip access-list extended FIREWALL_HUB1_AND_SPOKE1

deny ip any 192.168.1.0 0.0.0.255

permit ip any any

crypto map VPN 1 ipsec-isakmp

match address IPSEC_ACl_HUB1_AND_SPOKE1

set transform-set GOST_ENCRYPT_AND_INTEGRITY

set peer 172.16.1.2

set dead-connection history off

interface GigabitEthernet0/0

ip address 172.16.100.10 255.255.255.0

ip access-group FIREWALL_HUB1_AND_SPOKE1 out

crypto map VPN

vrrp 1 ip 172.16.100.100 255.255.255.0

vrrp 1 timers advertise 3

vrrp 1 timers garp 5

no vrrp 1 preempt

interface GigabitEthernet0/1

ip address 192.168.100.10 255.255.255.0

vrrp 2 ip 192.168.100.1 255.255.255.0

vrrp 2 timers advertise 3

vrrp 2 timers garp 5

no vrrp 2 preempt

interface GigabitEthernet0/2

no ip address

shutdown

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 50C1541D05DFCA8D446D1B4FEAFAB8C2

...

6764E6CF7BE7433F7E6A7B56FA5F2C0DE3D5BD2508FEF8D519541F2969

quit

vrrp ip route 0.0.0.0 0.0.0.0 172.16.100.1 src 172.16.100.100

vrrp notify common

end

2. Содержимое /etc/network/interfaces.d/gre1:

auto gre1

iface gre1 inet static

address 10.10.10.0

netmask 255.255.255.254

mtu 1400

pre-up ip tunnel add gre1 mode gre local 172.16.100.100 remote 172.16.1.2 ttl 255 tos inherit

pre-up ethtool -K gre1 tx off > /dev/null

pre-up ip link set gre1 type gre nopmtudisc

pre-up ip link set gre1 type gre ignore-df

post-down ip link del gre1

3. Текст консоли FRR:

frr version 7.3

frr defaults traditional

hostname Hub1-n1

log syslog informational

service integrated-vtysh-config

router ospf

ospf router-id 172.16.100.10

passive-interface eth0

passive-interface eth1

network 10.10.10.0/31 area 0.0.0.0

network 192.168.100.0/24 area 0.0.0.0

line vty

4. Файл /etc/keepalived/notify_common.conf:

FLAG_MANAGE_ROUTES="true"

RESERVE_ROUTES="0.0.0.0/0"

RESERVE_NEXTHOP="192.168.100.1"

RESERVE_METRIC="1"

5. Правила 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 incapsulated'

iptables -t nat -A NO_SOURCE_NAT -p 47 -s 172.16.100.0/24 -d 172.16.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

1. Консоль cisco-like:

version 12.4

no service password-encryption

crypto ipsec df-bit clear

crypto isakmp identity dn

crypto isakmp fragmentation

crypto isakmp security-association lifetime delta 50

crypto isakmp initiator-sessions-max 100

crypto isakmp responder-sessions-max 100

crypto isakmp keepalive 3

crypto isakmp keepalive retry-count 5

username cscons privilege 15 secret 5 $6$i1ZS0QYm$n/CqSuPNtDZsar8bqyFQZ41GjKFw1

Uz28DdlI6CznSrX4hMirPTKYRgy/wpHApyFEbL1yXTIlQ0puxof25sEU/

aaa new-model

hostname Hub1-n2

enable secret 5 PC9d7N5HlAyLrzuA3qRJvQ==

crypto isakmp policy 1

encr gost

hash gost341112-256-tc26

authentication gost-sig

group vko2

crypto ipsec transform-set GOST_ENCRYPT_AND_INTEGRITY esp-gost28147-4m-imit

ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1

permit gre host 172.16.100.100 host 172.16.1.2

ip access-list extended FIREWALL_HUB1_AND_SPOKE1

deny ip any 192.168.1.0 0.0.0.255

permit ip any any

crypto map VPN 1 ipsec-isakmp

match address IPSEC_ACl_HUB1_AND_SPOKE1

set transform-set GOST_ENCRYPT_AND_INTEGRITY

set peer 172.16.1.2

set dead-connection history off

interface GigabitEthernet0/0

ip address 172.16.100.20 255.255.255.0

ip access-group FIREWALL_HUB1_AND_SPOKE1 out

crypto map VPN

vrrp 1 ip 172.16.100.100 255.255.255.0

vrrp 1 timers advertise 3

vrrp 1 timers garp 5

no vrrp 1 preempt

vrrp 1 priority 50

interface GigabitEthernet0/1

ip address 192.168.100.20 255.255.255.0

vrrp 2 ip 192.168.100.1 255.255.255.0

vrrp 2 timers advertise 3

vrrp 2 timers garp 5

no vrrp 2 preempt

vrrp 2 priority 50

interface GigabitEthernet0/2

no ip address

shutdown

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 50C1541D05DFCA8D446D1B4FEAFAB8C2

...

6764E6CF7BE7433F7E6A7B56FA5F2C0DE3D5BD2508FEF8D519541F2969

quit

vrrp ip route 0.0.0.0 0.0.0.0 172.16.100.1 src 172.16.100.100

vrrp notify common

end

2. Содержимое /etc/network/interfaces.d/gre1:

auto gre1

iface gre1 inet static

address 10.10.10.0

netmask 255.255.255.254

mtu 1400

pre-up ip tunnel add gre1 mode gre local 172.16.100.100 remote 172.16.1.2 ttl 255 tos inherit

pre-up ethtool -K gre1 tx off > /dev/null

pre-up ip link set gre1 type gre nopmtudisc

pre-up ip link set gre1 type gre ignore-df

post-down ip link del gre1

3. Текст консоли FRR:

frr version 7.3

frr defaults traditional

hostname Hub1-n2

log syslog informational

service integrated-vtysh-config

router ospf

ospf router-id 172.16.100.20