Построение отказоустойчивого решения с применением технологии RRI (reverse route injection)

Введение

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

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

В рамках данного сценария для аутентификации партнеры будут использовать сертификаты. В качестве криптопровайдера будет использована криптографическая библиотека, разработанная компанией «С-Терра СиЭсПи». Шлюзы безопасности (или криптошлюзы) - «С-Терра Шлюз» версии 4.3. VPN-клиент - «С-Терра Клиент» версии 4.3.

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

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

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

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

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

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

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

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

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

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

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

1.3 Устройство host-behind-hub1.

1.3.1 На компьютере, устройство host-behind-hub1, расположенным в защищаемой сети центрального офиса, должна быть установлена ОС, поддерживающая стек протоколов TCP/IP.

1.4 АРМ администратора.

1.4.1 На АРМ администратора, устройство Admin_workstation, должна быть установлена ОС Windows (поддерживаемые версии 8/8.1/10).

1.5 Устройство Router1.

1.5.1 На устройстве Router1 должна быть установлена ОС, поддерживающая стек протоколов TCP/IP.

1.5.2 Устройство Router1 должно уметь работать со статической маршрутизацией.

1.5.3 Устройство Router1 должно уметь работать с протоколом динамической маршрутизации BGP (в данном случае только internal BGP или iBGP).

1.6 Коммутаторы Int_switch1_Hub1 и Ext_switch2_Hub1.

1.6.1 В данном сценарии к коммутаторам особых требований не предъявляется.

1.7 Устройство Client1.

1.7.1 На компьютере пользователя (устройство Client1) должна быть установлена ОС Windows (поддерживаемые версии 8/8.1/10).

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

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

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

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

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

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

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

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

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

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

1.2. В неконтролируемом сегменте (синее облако на схеме взаимодействия (см. рисунок 1)) размещаются: HTTP сервер для распространения списка отозванных сертификатов (CRL_distribution_point), маршрутизаторы (Core-ISP, Client-ISP);

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

1.4. За пределами сети центрального офиса размещается компьютер пользователя с ПО «С-Терра Клиент» (Client1).

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

2.В данном сценарии для эмуляции сети Интернет используются маршрутизаторы Core-ISP и Client-ISP.

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

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

2.3. Компьютер пользователя Client1 подключается к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизатор Client-ISP);

2.4. На маршрутизаторе Client-ISP происходит трансляция сетевых адресов (source NAT) в IP-адрес внешнего сетевого интерфейса (ens224);

В данном сценарии предполагается, что в центральном офисе не известно о том, в какой IP-адрес будут транслироваться запросы с компьютера пользователя Client1, так как устройство Client1 может находиться в любой части сети Интернет.

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

Весь IP трафик между подсетью центрального офиса и филиалом, а также между подсетью центрального офиса и компьютером пользователя защищается с использованием алгоритмов ГОСТ и протокола IPsec в туннельном режиме. Доступа со стороны компьютера пользователя к сети филиала в данном сценарии не предусмотрено.

Компьютеру пользователя (Client1), на специальный виртуальный сетевой интерфейс, будет назначен IP-адрес посредством IKECFG из пула (192.168.255.1 - 127 в случае соединения с Hub1-n1 или 192.168.255.128 - 254 в случае соединения с Hub1-n2, данные пулы задаются на Hub1-n1 и на Hub1-n2 в Cisco-like консоли). Все взаимодействия между компьютером пользователя и защищаемой подсетью центрального офиса будут осуществляться от этого IP-адреса, а не от IP-адреса, который пользователю был назначен по DHCP от маршрутизатора Client-ISP. Данная настройка используется для того, чтобы избежать совпадения IP-адресов у удаленных клиентов в случае отсутствия возможности осуществлять контроль над адресным пространством компьютеров удаленных клиентов. Инициировать защищенное соединение возможно только со стороны компьютера пользователя.

Шлюз Spoke1 может построить защищенный туннель как со шлюзом Hub1-n1, так и со шлюзом Hub1-n2. При построении защищенного туннеля шлюз (Hub1-n1 или Hub1-n2) добавляет в свою таблицу маршрут до удаленной подсети при помощи механизма RRI (reverse route injection, краткое описание работы механизма будет рассмотрено далее), а затем передает этот маршрут маршрутизатору Router1 при помощи протокола BGP. В случае если внешний сетевой интерфейс шлюза или сам шлюз, с которым было установлено соединение выходят из строя, туннель от Spoke1 устанавливается до другого шлюза, который в свою очередь анонсирует маршрут на Router1 посредством BGP. На внутренние интерфейсы Hub1-n1 и Hub1-n2 отказоустойчивость не распространяется.

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

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

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

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

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

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

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

4. Логика работы RRI.

1. Пулы IKECFG не должны пересекаться на центральных шлюзах.
2. В фильтрах шифрования не должны быть указаны протоколы, отличные от IP.

На примере IPsec соединения филиала с центральным офисом рассмотрим работу механизма RRI.

Механизм RRI после построения IPsec SA вычисляет маршрут (на устройстве Hub1-n1 или Hub1-n2):

· Диапазон защищаемых адресов партнера (то, что указано в IPsec ACL) преобразуется в адрес и маску подсети. В данном случае диапазоном будет являться вся защищаемая подсеть 192.168.1.0/24.

· В таблице маршрутизации производится поиск туннельного адреса SA партнера. При соединении «филиал - центральный офис» таким адресом будет являться 172.16.1.2.

· В случае если маршрут до туннельного адреса SA партнера был найден, то в таблицу маршрутизации будет добавлен маршрут до подсети партнера с тем же next-hop, что и у туннельного адреса SA. В данном сценарии туннельный адрес SA криптошлюза Spoke1 доступен через маршрут по умолчанию, next-hop’ом которого является адрес 172.16.100.1.

Таким образом, после построения IPsec SA в таблицу маршрутизации добавится маршрут (kernel) до подсети 192.168.1.0/24 с next-hop 172.16.100.1. В случае если по той или иной причине IPsec SA пропадет, маршрут будет автоматически удален.

Аналогичным образом работает механизм RRI с удаленным VPN-клиентом (Client1).

Инициировать защищенное соединение в данном сценарии можно только со стороны удаленного VPN-клиента и филиального криптошлюза.

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

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

1. Настройте IP адрес - 172.16.100.1 и маску - 255.255.255.0 на сетевом интерфейсе ens224.

2. Настройте IP адрес - 172.16.1.1 и маску - 255.255.255.0 на сетевом интерфейсе ens192.

3. Настройте IP адрес - 172.16.2.1 и маску - 255.255.255.0 на сетевом интерфейсе ens256.

4. Разрешите прохождение IP трафика.

Настройка устройства Client-ISP

1. Настройте IP адрес - 172.16.2.2 и маску - 255.255.255.0 на сетевом интерфейсе ens224.

2. Настройте IP адрес - 192.168.2.1 и маску - 255.255.255.0 на сетевом интерфейсе ens192.

3. Настройте NAT (SNAT либо маскарадинг), транслирующий все адреса сети 192.168.2.0/24 в адрес внешнего интерфейса ens224.

4. Настройте на интерфейсе ens192 DHCP сервер, раздающий доступные IP адреса из подсети этого интерфейса (192.168.2.2 - 192.168.2.254) и требуемые сетевые настройки.

5. Настройте маршрут по умолчанию с next-hop через Core-ISP.

6. Разрешите прохождение IP трафика.

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

1. Настройте IP адрес - 192.168.100.1 и маску - 255.255.255.0 на сетевом интерфейсе ens224.

2. Настройте IP адрес - 192.168.200.1 и маску - 255.255.255.0 на сетевом интерфейсе ens192.

3. Настройте BGP для приема маршрутов от криптошлюзов Hub1-n1 и Hub1-n2. По сценарию шлюзы, как и устройство Router1, должны находиться в одной автономной системе (AS). В Приложении для примера представлены настройки демона маршрутизации FRR.

4. В данном сценарии не подразумевается, наличие на Router1 маршрута по умолчанию.

5. Разрешите прохождение IP трафика.

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

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

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

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

Дата и время на всех криптошлюзах (Hub1-n1, Hub1-n2 и Spoke1) и компьютере пользователя (Client1) должны быть одинаковы, так как для аутентификации используются цифровые сертификаты, в которых зафиксированы дата и время начала их действия и окончания. Также одинаковые дата и время на всей инфраструктуре облегчают поиск неисправностей по лог-файлам.

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

S-Terra administrative console

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

Пользователь и пароль по умолчанию: administrator, s-terra. Обязательно смените пароль для пользователя administrator при помощи команды change user password.

administrator's password:

administrator@sterragate]

2. Установите правильный тип терминала (для putty тип терминала xterm) и требуемую ширину (для удобства работы), например:

administrator@sterragate] terminal terminal-type xterm

administrator@sterragate] terminal width 150

3. Установите нужную временную зону и правильные дату и время на криптошлюзе, используя консоль linux bash. Для этого выполните следующие команды.

3.1. Войдите в linux bash.

administrator@sterragate] system

Entering system shell...

3.2. Установите нужную временную зону:

root@sterragate:~# dpkg-reconfigure tzdata

3.3. Установите правильное время и дату (формат - месяц/день/год часы:минуты):

root@sterragate:~# date -s "07/04/2019 12:32"

Thu Jul 4 12:32:00 MSK 2019

4. Установите надежный пароль для пользователя root (под данным пользователем осуществляется доступ по SSH в linux bash):

root@sterragate:~# passwd

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

5. Выйдите из linux bash обратно в CLI разграничения доступа:

root@sterragate:~# exit

logout

Leaving system shell...

administrator@sterragate]

Начальные настройки завершены.

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

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

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

Аутентификация по предопределенным ключам запрещена и возможна только в тестовых целях.

Закрытый ключ для сертификата криптошлюза будет сгенерирован при помощи утилиты cert_mgr с использованием биологического датчика случайных чисел (БИО ДСЧ). Если на криптошлюзе установлен аппаратный датчик случайных чисел, то для выработки случайных чисел по умолчанию будет использоваться аппаратный датчик. Закрытый ключ может храниться либо на файловой системе устройства, либо на защищенном ключевом носителе (токен). В данном сценарии закрытый ключ будет располагаться в специальном контейнере на файловой системе устройства. Если требуется, чтобы контейнер располагался на токене, то смотрите описание параметра create утилиты cert_mgr на портале документации http://doc.s-terra.ru.

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

Настройка осуществляется в CLI разграничения доступа.

При выполнении сторонних команд в CLI разграничения доступа/консоли cisco-like перед командой нужно указывать ключевое слово run. Автодополнение для команд, указываемых после run, не поддерживается.

1. Генерация закрытого ключа и запроса на сертификат криптошлюза.

1.1. Вставьте USB Flash накопитель в свободный USB порт криптошлюза (накопитель будет автоматически примонтирован).

1.2. Определите имя (идентификатор) USB Flash накопителя на криптошлюзе:

administrator@sterragate] dir media:

1 dr-x 4096 Wed Mar 4 11:14:41 2020 C4349870349866E8

Имя (идентификатор) USB Flash накопителя - C4349870349866E8.

1.3. Запустите процесс генерации закрытого ключа и запроса на сертификат криптошлюза с сохранением файла запроса на USB Flash накопителе (закрытый ключ остается на криптошлюзе):

administrator@sterragate] run cert_mgr create -subj "C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1-n1" -GOST_R341012_256 -fb64 media:C4349870349866E8/hub1-n1.request

· ключ -subj задает отличительное имя сертификата (Distinguished Name, DN);

Отличительное имя сертификата должно быть уникальным для каждого устройства.

· ключ -GOST_R341012_256 задает использование алгоритма подписи - ГОСТ Р 34.10-2012 (ключ 256 бит).

На УЦ для поддержки алгоритма ГОСТ Р 34.10-2012 (ключ 256 бит) должно быть установлено СКЗИ «КриптоПро CSP» версии 4.0 или новее.

· ключ -fb64 задает месторасположение и формат представления запроса на сертификат; будет использован формат представления BASE64 с сохранением файла запроса в корень USB Flash накопителя под именем hub1-n1.request.

Нажимайте предлагаемые клавиши на клавиатуре для инициализации БИО ДСЧ:

Progress: [********* ]

Press key: U

После завершения работы БИО ДСЧ файл запроса будет сохранен в корне USB Flash накопителя:

administrator@sterragate] dir media:C4349870349866E8/

1 -rwx 473 Thu Jul 4 10:40:32 2019 hub1-n1.request

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

1.4. Отмонтируйте и извлеките USB Flash накопитель (посмотреть точки монтирования можно при помощи команды run mount):

administrator@sterragate] run umount /media/C4349870349866E8

2. Выпуск сертификата криптошлюза на УЦ и импортирование сертификатов УЦ и криптошлюза в базу Продукта.

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

2.2. Скопируйте выпущенный сертификат для криптошлюза под именем hub1-n1.cer и сертификат УЦ под именем ca.cer в корень USB Flash накопителя.

2.3. Вновь вставьте USB Flash накопитель, содержащий файлы сертификатов, в свободный порт USB на криптошлюзе.

2.4. Убедитесь в наличии сертификатов на USB Flash накопителе:

administrator@sterragate] dir media:C4349870349866E8/

1 -rwx 592 Thu Jul 4 10:40:32 2019 ca.cer

2 -rwx 804 Thu Jul 4 10:40:32 2019 hub1-n1.cer

3 -rwx 473 Thu Jul 4 10:40:32 2019 hub1-n1.request

Сохраняйте сертификаты. Они могу понадобиться в случае восстановления криптошлюза при отказе HDD/SSD диска.

2.5. Импортируйте сертификат УЦ в базу Продукта:

administrator@sterragate] run cert_mgr import -f media:C4349870349866E8/ca.cer -t

· ключ -f задает месторасположение файла сертификата;

· ключ -t используется для импортирования доверенного (trusted) сертификата УЦ.

2.6. Импортируйте сертификат криптошлюза в базу Продукта:

administrator@sterragate] run cert_mgr import -f media:C4349870349866E8/hub1-n1.cer

2.7. Убедитесь, что сертификаты успешно импортированы в базу Продукта:

administrator@sterragate] run cert_mgr show

Found 2 certificates. No CRLs found.

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=Hub1-n1

Видно, что сертификат УЦ импортирован как trusted, а сертификат криптошлюза как local (local означает, что для данного сертификата есть соответствующий ключевой контейнер).

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

administrator@sterragate] run cert_mgr check

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

Certificate can not be verified.

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

Certificate can not be verified.

Видно, что все сертификаты имеют статус Inactive (неактивный) с пометкой: «Certificate can not be verified» (сертификат не может быть проверен). Причиной этому является включенный по умолчанию в консоли cisco-like механизм проверки списка отозванных сертификатов (далее СОС или CRL). Так как в базе Продукта СОС отсутствует, поэтому проверка не может быть осуществлена. Далее будет описан процесс настройки автоматической загрузки СОС и импортирование его в базу Продукта. Загрузка СОС осуществляется по протоколу HTTP с заданной периодичностью.

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

1. Войдите в cisco-like консоль из CLI разграничения доступа:

Пользователь и пароль по умолчанию cscons, csp. Обязательно смените пароль для пользователя cscons, так как под этим пользователем осуществляется доступ по SSH в cisco-like консоль. Также не забудьте сменить enable пароль.

administrator@sterragate] configure

sterragate login: cscons

Password:

S-Terra Gate 4.3.XXXXX (amd64)

sterragate#

2. Смените пароль для пользователя cscons и на enable:

sterragate#configure terminal

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

sterragate(config)#username cscons secret 0 ПАРОЛЬ

sterragate(config)#enable secret 0 ПАРОЛЬ

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

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

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

sterragate(config)#hostname Hub1-n1

2. Включите внешний GigabitEthernet0/0 и внутренний GigabitEthernet0/1 интерфейсы:

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

Hub1-n1(config-if-range)#no shutdown

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

3. Убедитесь, что интерфейсы административно включены и line protocol (способность интерфейса передавать пакеты в данный момент) находится в состоянии up:

Hub1-n1(config)# do show interfaces

GigabitEthernet0/0 is up, line protocol is up

Hardware address is 0050.569e.b06d

MTU 1500 bytes

GigabitEthernet0/1 is up, line protocol is up

Hardware address is 0050.569e.d3c3

MTU 1500 bytes

...

Если line protocol находится в состоянии down, то проверьте подключение сетевого интерфейса криптошлюза к коммутационному или прочему оборудованию.

4. Задайте IP адреса в соответствии со схемой стенда (см. рисунок 1) на внешнем GigabitEthernet0/0 и внутреннем GigabitEthernet0/1 интерфейсах:

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)#exit

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

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

Hub1-n1(config-if)#exit

5. Задайте маршрут по умолчанию через устройство Core-ISP и маршрут до защищаемой подсети через за Router1:

Hub1-n1(config)#ip route 0.0.0.0 0.0.0.0 172.16.100.1

Hub1-n1(config)#ip route 192.168.100.0 255.255.255.0 192.168.200.1

6. Проверьте доступность устройства Core-ISP:

Hub1-n1(config)#do 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.13 ms

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

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

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

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

--- 172.16.100.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.192/0.411/1.131/0.362 ms

7. Проверьте доступность устройства Router1:

Hub1-n1(config)#do ping 192.168.200.1

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

108 bytes from 192.168.200.1: icmp_seq=1 ttl=64 time=1.11 ms

108 bytes from 192.168.200.1: icmp_seq=2 ttl=64 time=0.346 ms

108 bytes from 192.168.200.1: icmp_seq=3 ttl=64 time=0.357 ms

108 bytes from 192.168.200.1: icmp_seq=4 ttl=64 time=0.262 ms

108 bytes from 192.168.200.1: icmp_seq=5 ttl=64 time=1.06 ms

--- 192.168.200.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.262/0.627/1.110/0.375 ms

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

1. Параметры IKE.

1.1. Укажите в качестве типа идентификатора, используемого в рамках протокола IKE, отличительное имя (Distinguished Name, DN):

Hub1-n1(config)#crypto isakmp identity dn

По умолчанию отличительное имя будет взято из сертификата устройства, например, для Hub1-n1 это «C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1-n1».

1.2. Настройте параметры DPD (dead peer detection):

Hub1-n1(config)#crypto isakmp keepalive 3 2

Hub1-n1(config)#crypto isakmp keepalive retry-count 5

Пояснение:

Если в течение 3 секунд отсутствует входящий трафик в IPsec туннеле, то с интервалом в 2 секунды посылается 5 keepalive пакетов в рамках IKE туннеля, чтобы удостовериться в работоспособности туннеля. Если партнер не отвечает на keepalive пакеты, то соответствующий IKE туннель и связанные с ним IPsec туннели уничтожаются. В случае наличия исходящего защищаемого трафика происходит попытка создания новых IKE/IPsec туннелей.

1.3. Включите фрагментацию IKE пакетов:

Hub1-n1(config)#crypto isakmp fragmentation

1.4. Включите случайный разброс времени жизни IKE и IPsec SA, чтобы снизить нагрузку на шлюз (позволяет избежать единовременного массового пересоздания SA):

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

1.5. Увеличьте допустимое количество одновременно инициируемых IKE сессий (не путать с общим количеством IKE сессий) для всех партнёров (значение по умолчанию 30):

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

1.6. Увеличьте допустимое количество одновременных IKE обменов, проводимых шлюзом со всеми партнерами в качестве ответчика (не путать с общим количеством IKE сессий; значение по умолчанию 20):

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

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

Hub1-n1(config)#crypto isakmp policy 1

Hub1-n1(config-isakmp)#encryption gost

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

Hub1-n1(config-isakmp)#authentication gost-sig

Hub1-n1(config-isakmp)#group vko2

Hub1-n1(config-isakmp)#exit

Рекомендуется использовать одну политику для IKE туннелей. Несколько политик может потребоваться в том случае, если необходимо обеспечить совместимость со старыми версиями Продуктов, в которых нет поддержки новых алгоритмов.

2. Параметры IPsec.

2.1. Задайте комбинированный алгоритм шифрования и имитозащиты (набор преобразований) для трафика:

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

Hub1-n1(cfg-crypto-trans)#exit

2.2. Задайте IKECFG пул из которого будут выдаваться IP адреса VPN клиентам:

Hub1-n1(config)#ip local pool IKECFG_POOL 192.168.255.1 192.168.255.127

2.3. Создайте расширенные списки доступа (ACL) для трафика, который требуется защищать:

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

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

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

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

Hub1-n1(config)#

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

Hub1-n1(config)#crypto dynamic-map DMAP 1

2.4.1 Укажите список доступа для защищаемого трафика:

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

2.4.2 Укажите при помощи какого набора алгоритмов нужно защищать трафик:

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

2.4.3 Укажите IKECFG пул:

Hub1-n1(config-crypto-map)#set pool IKECFG_POOL

2.4.4 Если в сети центрального офиса есть DNS сервер, укажите его адрес в динамической криптокарте, чтобы у удаленного клиента была возможность им воспользоваться:

Hub1-n1(config-crypto-map)#set dns <IP_адрес_DNS_сервера>

2.4.5 Включите механизм RRI (reverse route injection):

Hub1-n1(config-crypto-map)#reverse-route

2.4.6 Обязательно отключите историю удаленных туннелей (если не отключить, то могут быть проблемы с построением IPsec туннелей с устройствами, которые находятся за NAT):

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

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

2.5. Создайте статическую криптокарту для подсети филиала (имя VPN, раздел 1):

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

2.5.1 Укажите список доступа для защищаемого трафика:

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

2.5.2 Укажите при помощи какого набора алгоритмов нужно защищать трафик:

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

2.5.3 Укажите IP адрес партнера по IPsec, в данном сценарии это внешний IP адрес устройства Spoke1:

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

2.5.4 Отключите историю удаленных туннелей

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

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

2.6. Привяжите динамическую криптокарту DMAP ко второму разделу статической:

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

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

Hub1-n1(config)#interface GigabitEthernet0/0

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

Hub1-n1(config-if)#exit

Hub1-n1(config)#

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

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

1. Включите проверку СОС:

Hub1-n1(config)#crypto pki trustpoint s-terra_technological_trustpoint

Hub1-n1(ca-trustpoint)#revocation-check crl

Если по обоснованным причинам использование СОС невозможно, то выключите проверку СОС и не включайте автоматическую загрузку СОС:

Hub1-n1(ca-trustpoint)#revocation-check none

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

Hub1-n1(ca-trustpoint)#crl download group ROOTCA http://172.16.101.15/certcrl.crl

3. Настройте периодичность загрузки СОС в 60 минут (по умолчанию 24 часа):

Hub1-n1(ca-trustpoint)#crl download time 60

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

Hub1-n1(ca-trustpoint)#end

5. Проверьте загружен ли СОС в базу Продукта:

Hub1-n1#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=Hub1-n1

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

Если СОС не загрузился, то проверьте файл журнала, например:

Hub1-n1#run grep getcrls_daemon /var/log/cspvpngate.log

Примечание: чтобы не ждать следующего периода загрузки СОС можно перезапустить сервис getcrls вручную:

Hub1-n1#run systemctl restart getcrls.service

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

Hub1-n1#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=Hub1-n1

7. Настройка криптошлюза Hub1-n1 в Cisco-like консоли завершена. Наберите exit чтобы выйти из Cisco-like консоли, затем наберите system для перехода в linux bash и дальнейшего конфигурирования:

Hub1-n1#exit

administrator@Hub1-n1] system

Entering system shell...

root@Hub1-n1:~#

Настройка динамической маршрутизации (iBGP или internal BGP) в FRR

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

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

root@hub1:~# systemctl enable frr.service

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

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

root@hub1:~# systemctl start frr.service

При старте в файле /var/log/error.log могут возникать следующие сообщения:

Apr 15 23:28:49 Hub1-n1 watchfrr[2705]: [EC 268435457] zebra state -> down : initial connection attempt failed

Apr 15 23:28:49 Hub1-n1 watchfrr[2705]: [EC 268435457] bgpd state -> down : initial connection attempt failed

Apr 15 23:28:49 Hub1-n1 watchfrr[2705]: [EC 268435457] ripd state -> down : initial connection attempt failed

Apr 15 23:28:49 Hub1-n1 watchfrr[2705]: [EC 268435457] ospfd state -> down : initial connection attempt failed

Apr 15 23:28:49 Hub1-n1 watchfrr[2705]: [EC 268435457] pbrd state -> down : initial connection attempt failed

Apr 15 23:28:49 Hub1-n1 watchfrr[2705]: [EC 268435457] staticd state -> down : initial connection attempt failed

Apr 15 23:28:49 Hub1-n1 watchfrr[2705]: [EC 100663303] Forked background command [pid 2706]: /usr/lib/frr/watchfrr.sh restart all

Apr 15 23:28:49 Hub1-n1 watchfrr.sh: Cannot stop zebra: pid file not found

Apr 15 23:28:49 Hub1-n1 watchfrr.sh: Cannot stop ospfd: pid file not found

Apr 15 23:28:49 Hub1-n1 watchfrr.sh: Cannot stop bgpd: pid file not found

Apr 15 23:28:49 Hub1-n1 watchfrr.sh: Cannot stop ripd: pid file not found

Apr 15 23:28:49 Hub1-n1 watchfrr.sh: Cannot stop pbrd: pid file not found

Apr 15 23:28:49 Hub1-n1 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. Настройте BGP (см. описание http://docs.frrouting.org):

3.1. Перейдите в режим конфигурации:

Hub1-n1# configure terminal

3.2. Добавьте правила фильтрации для маршрутов, распространяемых при помощи протокола BGP:

Hub1-n1(config)# access-list ROUTE_FILTER_OUT seq 10 permit 192.168.255.0/25

Hub1-n1(config)# access-list ROUTE_FILTER_OUT seq 5 permit 192.168.1.0/24

Данные правила позволяют фильтровать маршруты, распространяемые при помощи команды redistribute kernel (см. пункт 3.7). В данном случае позволяется распространять только маршруты до защищаемых подсетей 192.168.255.0/25 и 192.168.1.0/24.

3.3. Перейдите в режим конфигурирования работы протокола BGP (команда router bgp <номер автономной системы (AS)>):

Hub1-n1(config)# router bgp 64512

3.4. Настройте router-id:

Hub1-n1(config-router)# bgp router-id 192.168.200.10

3.5. Добавьте адрес и номер AS соседа. В данном случае нужно, чтобы информация о маршрутах передавалась только маршрутизатору Router1:

Hub1-n1(config-router)# neighbor 192.168.200.1 remote-as 64512

3.6. Перейдите в режим настройки address family:

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

3.7. Включите редистрибуцию kernel маршрутов в BGP (в дальнейшем эти маршруты будут отфильтрованы при помощи правил фильтрации (ROUTE_FILTER_OUT)):

Hub1-n1(config-router-af)# redistribute kernel

3.8. Укажите, что при передаче маршрута маршрутизатору Router1 следует менять next-hop на адрес интерфейса, с которого был анонсирован маршрут (по умолчанию iBGP не делает этого):

Hub1-n1(config-router-af)# neighbor 192.168.200.1 next-hop-self

3.9. Примените созданные ранее (см. пункт 3.2) правила фильтрации к взаимодействию с Router1. Таким образом можно сделать так, чтобы на Router1 отправлялись только необходимые маршруты, а не все kernel маршруты:

Hub1-n1(config-router-af)# neighbor 192.168.200.1 distribute-list ROUTE_FILTER_OUT out

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

3.10. Настройка FRR завершена. При помощи команд представленных ниже выйдите из режима конфигурирования и сохраните получившуюся конфигурацию (команда write):

Hub1-n1(config-router-af)# exit-address-family

Hub1-n1(config-router)# end

Hub1-n1# write

Note: this version of vtysh never writes vtysh.conf

Building Configuration...

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

[OK]

Выйти из vtysh можно при помощи команды exit.

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

· текст конфигураций Cisco-like;

· текст конфигураций LSP;

· текст конфигураций vtysh.

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

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

1. В Cisco-like консоли:

1.1. Адреса интерфейсов отличаются (gi0/0 - 172.16.100.20/24, gi0/1 - 192.168.200.20/24);

1.2. Пул IKECFG должен содержать непересекающийся диапазон адресов (в данном случае 192.168.255.128 - 254);

1.3. Списки доступа для защищаемого трафика должны соответствовать пулу (следует поменять ACL IPSEC_ACL_HUB1_AND_CLIENTS);

2. В настройках FRR (в vtysh):

2.1 Выставить router-id отличный от указанного на Hub1-n1 (в данном примере 192.168.200.20);

2.2 Заменить запись, связанную с IKECFG адресами в списке доступа (в ROUTE_FILTER_OUT поменять запись 192.168.255.0/25 на 192.168.255.128/25).

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

· текст конфигураций Cisco-like;

· текст конфигураций LSP;

· текст конфигураций vtysh.

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

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

1. В Cisco-like консоли:

1.1. Адреса интерфейсов отличаются (gi0/0 - 172.16.1.2/24, gi0/1 - 192.168.1.1/24);

1.2. Отсутствуют IKECFG пул и настройки, связанные с динамической криптокартой;

1.3. Списки доступа для защищаемого трафика должны соответствовать схеме взаимодействия. Следует создать список доступа с соответствующим названием:

Spoke1(config)#ip access-list extended IPSEC_ACL_SPOKE1_AND_HUB1

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

1.4. В статической криптокарте должен быть указан правильный список доступа. Должно быть указано два партнера по IPsec соединению. Механизм RRI на Spoke1 не требуется:

Spoke1(config)#crypto map VPN 1 ipsec-isakmp

Spoke1(config-crypto-map)#match address IPSEC_ACL_SPOKE1_AND_HUB1

Spoke1(config-crypto-map)#set transform-set GOST_ENCRYPT_AND_INTEGRITY

Spoke1(config-crypto-map)#set peer 172.16.100.10

Spoke1(config-crypto-map)#set peer 172.16.100.20

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

2. Настройки FRR отсутствуют.

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

· текст конфигураций Cisco-like.

· текст конфигураций LSP.

Создание установочного пакета «С-Терра Клиент» и настройка компьютера пользователя Client1

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

· установить приложение AdminTool на компьютере администратора;

· получить запрос на сертификат (на основе нового контейнера с ключами) на компьютере администратора;

· перенести запрос на УЦ, получить сертификат из запроса и перенести сертификат на компьютер администратора;

· сформировать установочный пакет для целевого клиентского компьютера с помощью AdminTool;

· перенести пакет и установить его на компьютер пользователя.

Предполагается, что формирование установочного пакета будет происходить на компьютере администратора. Контейнеры с ключами будут генерироваться также на компьютере администратора. На базе сгенерированных ключей будут выпускаться запросы на сертификаты. Запросы на сертификаты будут переданы на УЦ и на их основе будут получены сертификаты.

Настройка АРМ администратора Admin_workstation

Установка С-Терра AdminTool

1. Вставьте носитель с дистрибутивом ПО «С-Терра Клиент» (должен быть в комплекте поставки) в дисковод.

2. Создайте директорию с именем S-Terra_Client_ST_KC1_KC2 на диске C:\.

3. Перейдите в директорию S-Terra_Client_ST_KC1_KC2, расположенную в корне носителя с дистрибутивом, и разархивируйте архив S-Terra_Client_ST_KC1_KC2.zip в созданную ранее директорию C:\S-Terra_Client_ST_KC1_KC2.

4. Прейдите в директорию C:\S-Terra_Client_ST_KC1_KC2 и запустите setup.exe.

5. В появившемся окне нажмите кнопку Next.

6. В окне License Agreement установите переключатель в положение в I accept the license agreement и нажмите кнопку Next.

7. В окне Destination Folder нажмите кнопку Next.

8. В окне Ready to install the Application нажмите кнопку Next.

9. В окне Random Number Generation вводите предлагаемые символы.

10. Дождитесь завершения установки и нажмите кнопку Finish.

Установка С-Терра AdminTool на АРМ администратора завершена.

Генерация ключевой пары и запроса на сертификат

1. Создайте запрос на сертификат с помощью утилиты excont_mgr, входящей в состав AdminTool.

1.1. Запустите командую строку от имени Администратора.

1.2. Перейдите в директорию, где установлен AdminTool:

cd "C:\Program Files (x86)\S-Terra Client AdminTool st"

1.3. Создайте запрос на сертификат. При этом будет создан новый контейнер с ключами.

C:\Program Files (x86)\S-Terra Client AdminTool st> .\excont_mgr.exe create_req -subj "C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Client1" -GOST_R341012_256 -kc file_p15://Client1 -kcp 1234 -fo C:\Client1.req

· ключ create_req - создает запрос на сертификат;

· ключ -subj задает отличительное имя сертификата (Distinguished Name, DN);

· ключ -GOST_R341012_256 задает использование алгоритма подписи - ГОСТ Р 34.10-2012 (ключ 256 бит);

· -kc <имя контейнера> - задает имя контейнера;

· -kcp <PIN> - задает пароль на контейнер;

· -fo <путь до файла> - указывает путь, по которому будет сохранен запрос на сертификат.

Ключ -GOST_R341012_256 предполагает использование ГОСТ 2012. На УЦ для его поддержки должно быть установлено СКЗИ «КриптоПро CSP» версии 4.0 или новее. При необходимости, можно воспользоваться более старым ключом -GOST_R3410EL.

Получение сертификатов

Созданный запрос перенесите на УЦ и получите на его основе пользовательский сертификат. Также получите сертификат данного УЦ. Перенесите сертификат УЦ и пользовательский сертификат на компьютер администратора.

Сертификат УЦ должен доставляться доверенным способом.

Создание установочного пакета для Client1

1. Запустите установленное приложение Package Maker из пакета AdminTool.

2. Во вкладке Auth выполните следующие действия (см. рисунок 2):

Рисунок 2. Вкладка Auth утилиты AdminTool

2.1. В данном сценарии используется метод аутентификации на сертификатах - переключатель установлен на Use certificate по умолчанию.

2.2. Укажите путь к сертификату УЦ (CA certificate) и пользовательскому сертификату (User certificate).

2.3. Отметьте флаг Check consistency now и нажмите кнопку "..." рядом с полем Container name, где выберите созданный ранее контейнер. Если при создании запроса на сертификат указывался пароль на контейнер, введите его в поле password.

2.4. Отметьте флаг Use container from admin computer. Указанный в запросе на сертификат контейнер (п.1.3) будет помещен в установочный пакет.

2.5. Задайте имя контейнера в поле User container name. В данном случае указано - file_p15://Client1. Данное поле указывает, по какому пути искать контейнер при работе. Контейнер, указанный в поле Container name будет скопирован по указанному пути. Пароль в поле password можно указать отличный от указанного рядом с Container name.

2.6. В поле User identity type необходимо использовать DistiguishedName (выбрано по умолчанию).

3. Во вкладке Firewall Rules (см. рисунок 3) можно настроить правила фильтрации трафика. В данном сценарии оставьте настройки по умолчанию - разрешать весь трафик.

Рисунок 3. Вкладка Firewall Rules утилиты AdminTool

4. Вкладка IPsec Rules:

4.1. Добавьте правило для трафика, подлежащего шифрованию. Нажмите кнопку Add… и в открывшемся окне Add Rule проведите следующие настройки (см. рисунок 4):

4.1.1 В разделе Remote IP Address укажите адрес 192.168.100.0 и маску - 255.255.255.0 (выбрав Custom).

4.1.2 В разделе Action выберите из списка Protect using IPsec, нажмите кнопку Add… и укажите адреса шлюзов Hub1-n1 и Hub1-n2 (172.16.100.10 и 172.16.100.20) и отметьте флаги Request IKECFG address и Use random address order.

Рисунок 4. Окно Add Rule вкладки IPsec Rules утилиты AdminTool

4.1.3 Добавленное правило поднимите вверх (см. рисунок 5).

Рисунок 5. Вкладка IPsec Rules утилиты AdminTool

5. Во вкладке IKE по умолчанию установлены нужные настройки (см. рисунок 6). При необходимости можно поднять в приоритете используемое правило.

Рисунок 6. Вкладка IKE утилиты AdminTool

6. Во вкладке IPsec по умолчанию установлены нужные настройки (см. рисунок 7). При необходимости можно поднять в приоритете используемое правило.

Рисунок 7. Вкладка IPsec утилиты AdminTool

7. Во вкладке LSP (см. рисунок 8) нажмите кнопку Advanced..., выберите двойным нажатием параметр Prefer IKECFG address и поменяйте с Last used address на No preferred address (см. рисунок 9).

Рисунок 8. Вкладка LSP утилиты AdminTool

Рисунок 9. Вкладка Advanced LSP Settings утилиты AdminTool

8. Во вкладке License введите лицензию на продукт «С-Терра Клиент» версии 4.3.

9. Сохраните файл созданного проекта, на тот случай, если захотите в будущем сделать похожий клиентский пакет. Для этого в меню File выберите Save project.

10. Создайте установочный exe-файл для «С-Терра Клиент», нажав кнопку Make package.... В случае если все параметры до данного момента введены верно, появится окно Package parameters, в котором можно будет выбрать параметры установочного пакета (https://doc.s-terra.ru/rh_output/4.3/Client_st/Output/mergedProjects/Admin/Создание_инсталляционного_файла.htm).

Установка на компьютер пользователя

1. Установите на клиентском компьютере полученный exe-файл.

2. В области уведомлений появится иконка «С-Терра Клиент» (см. рисунок 10). Для начала работы необходимо пройти процедуру аутентификации (см. рисунок 11). Имя пользователя по умолчанию - user. Пароль по умолчанию отсутствует, в дальнейшем его нужно установить.

Рисунок 10. Иконка «С-Терра Клиент»

Рисунок 11. Окно аутентификации ПО «С-Терра Клиент»

В приложении представлен текст LSP конфигурации для Client1.

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

Проверка соединения между удаленным VPN клиентом (Client1) и сетью центрального офиса

Проверка работы IPsec туннеля

После того, как настройка всех устройств завершена и произведена аутентификация в «С-Терра Клиент» следует проверить работу RRI. Для этого сначала следует убедиться, что IPsec туннель успешно создан (он должен создаваться сразу после аутентификации в «С-Терра Клиент»). Сделать это можно на устройстве Client1 в окне VPN SA Monitor ПО «С-Терра Клиент» (см. рисунок 12 и рисунок 13):

Рисунок 12. Запуск окна VPN SA Monitor ПО «С-Терра Клиент»

Рисунок 13. Окно VPN SA Monitor ПО «С-Терра Клиент» (соединение с Hub1-n1)

Теперь (исходя из параметра Partner IP Addresses (см. рисунок 13)) известно, что соединение установлено и известно, что оно установлено с Hub1-n1 (оно могло установиться с Hub1-n2, в таком случае следует проводить проверку на Hub1-n2).

Следует убедиться в том, что криптошлюз Hub1-n1 сформировал RRI маршрут и добавил его в свою таблицу маршрутизации. Выполним на Hub1-n1 в linux bash команду ip route:

root@Hub1-n1:~# ip route

default via 172.16.100.1 dev eth0

172.16.100.0/24 dev eth0 proto kernel scope link src 172.16.100.10

192.168.100.0/24 via 192.168.200.1 dev eth1

192.168.200.0/24 dev eth1 proto kernel scope link src 192.168.200.10

192.168.255.1 via 172.16.100.1 dev eth0

Из вывода команды видно, что в таблице маршрутизации появился маршрут до IKECFG адреса Client1 (192.168.255.1).

После этого следует убедиться в том, что нужный маршрут оказался (был передан устройством Hub1-n1 при помощи BGP) в таблице маршрутизации устройства Router1:

root@Router1:~# ip route

192.168.100.0/24 dev ens224 proto kernel scope link src 192.168.100.1

192.168.200.0/24 dev ens192 proto kernel scope link src 192.168.200.1

192.168.255.1 via 192.168.200.10 dev ens192 proto bgp metric 20

Теперь, выполните на устройстве Client1 команду ping, проверив таким образом соединение:

C:\Users\Administrator> ping 192.168.100.100

Обмен пакетами с 192.168.100.100 по с 32 байтами данных:

Ответ от 192.168.100.100: число байт=32 время=33мс TTL=62

Ответ от 192.168.100.100: число байт=32 время=1мс TTL=62

Статистика Ping для 192.168.100.100:

Пакетов: отправлено = 4, получено = 4, потеряно = 0

(0% потерь)

Приблизительное время приема-передачи в мс:

Минимальное = 1мсек, Максимальное = 33 мсек, Среднее = 9 мсек

Проверка отказоустойчивости

Для того чтобы убедиться в работе отказоустойчивости запустите с устройства Client1 бесконечный ping (с параметром -t) и сымитируйте отказ устройства, с которым было построено IPsec соединение (в данном случае Hub1-n1).

Через некоторое время (около трех минут) соединение IPsec перестроится через другое устройство (в данном случае Hub1-n2). Это можно отследить как на Client1 (см. рисунок 14), так и на Hub1-n2 (при помощи sa_mgr show).

Рисунок 14. Окно VPN SA Monitor ПО «С-Терра Клиент» (соединение с Hub1-n2)

root@Hub1-n2:~# sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

1 13 (172.16.100.20,4500)-(172.16.2.2,4500) active 1936 2904

IPsec connections:

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

1 29 (192.168.100.0-192.168.100.255,*)-(192.168.255.129,*) * ESP nat-t3-tunn 640 640

Следует убедиться в том, что криптошлюз Hub1-n2 сформировал маршрут и добавил его в свою таблицу маршрутизации. Выполним на Hub1-n2 в linux bash команду ip route:

root@Hub1-n2:~# ip route

default via 172.16.100.1 dev eth0

172.16.100.0/24 dev eth0 proto kernel scope link src 172.16.100.20

192.168.100.0/24 via 192.168.200.1 dev eth1

192.168.200.0/24 dev eth1 proto kernel scope link src 192.168.200.20

192.168.255.129 via 172.16.100.1 dev eth0

После перестроения маршрута на устройстве Router1 пропадет маршрут через Hub1-n1 и появится маршрут через Hub1-n2:

root@Router1:~# ip route

192.168.100.0/24 dev ens224 proto kernel scope link src 192.168.100.1

192.168.200.0/24 dev ens192 proto kernel scope link src 192.168.200.1

192.168.255.129 via 192.168.200.20 dev ens192 proto bgp metric 20

Проверка соединения между сетью филиала и сетью центрального офиса

Проверка работы IPsec туннеля

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

Для этого на устройстве host_behind_spoke1 воспользуемся командой ping:

root@host-behind-spoke1:~# ping 192.168.100.100

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

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

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

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

64 bytes from 192.168.100.100: icmp_seq=5 ttl=61 time=1.58 ms

64 bytes from 192.168.100.100: icmp_seq=6 ttl=61 time=1.24 ms

64 bytes from 192.168.100.100: icmp_seq=7 ttl=61 time=1.25 ms

--- 192.168.100.100 ping statistics ---

7 packets transmitted, 6 received, 14.2857% packet loss, time 43ms

rtt min/avg/max/mdev = 1.128/1.364/1.693/0.204 ms

После этого факт установления соединения можно также подтвердить при помощи команды sa_mgr show (в выводе с Hub1-n2 видно также и соединение с удаленным VPN клиентом):

root@Spoke1:~# sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

1 36 (172.16.1.2,500)-(172.16.100.20,500) active 1908 1836

IPsec connections:

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

1 41 (192.168.1.0-192.168.1.255,*)-(192.168.100.0-192.168.100.255,*) * ESP tunn 616 528

root@Hub1-n2:~# sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

1 14 (172.16.100.20,4500)-(172.16.2.2,4500) active 1936 2904

2 15 (172.16.100.20,500)-(172.16.1.2,500) active 1836 1908

IPsec connections:

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

1 32 (192.168.100.0-192.168.100.255,*)-(192.168.255.129,*) * ESP nat-t3-tunn 640 640

2 33 (192.168.100.0-192.168.100.255,*)-(192.168.1.0-192.168.1.255,*) * ESP tunn 528 616

На устройстве Router1 также должен появиться маршрут до сети филиала:

root@Router1:~# ip route

192.168.1.0/24 via 192.168.200.20 dev ens192 proto bgp metric 20

192.168.100.0/24 dev ens224 proto kernel scope link src 192.168.100.1

192.168.200.0/24 dev ens192 proto kernel scope link src 192.168.200.1

192.168.255.129 via 192.168.200.20 dev ens192 proto bgp metric 20

Проверка отказоустойчивости

Для того чтобы убедиться в работе отказоустойчивости запустите с устройства host_behind_spoke1 бесконечный ping и сымитируйте отказ устройства, с которым было построено IPsec соединение (в данном случае Hub1-n2).

Через некоторое время (около трех минут) соединение IPsec перестроится через другое устройство (в данном случае Hub1-n1). Это можно отследить как на Spoke1, так и на Hub1-n1:

root@Spoke1:~# sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

1 38 (172.16.1.2,500)-(172.16.100.10,500) active 1908 1836

IPsec connections:

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

1 42 (192.168.1.0-192.168.1.255,*)-(192.168.100.0-192.168.100.255,*) * ESP tunn 2464 1760

root@Hub1-n1:~# sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

1 20 (172.16.100.10,500)-(172.16.1.2,500) active 1836 1908

2 21 (172.16.100.10,4500)-(172.16.2.2,4500) active 1936 2904

IPsec connections:

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

1 29 (192.168.100.0-192.168.100.255,*)-(192.168.1.0-192.168.1.255,*) * ESP tunn 1760 2464

2 30 (192.168.100.0-192.168.100.255,*)-(192.168.255.1,*) * ESP nat-t3-tunn 768 768

Логирование на компьютере пользователя (Client1)

Для дополнительной диагностики на компьютере пользователя можно воспользоваться средствами логирования.

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

1. Перейти в директорию установленного ПО «С-Терра Клиент»:

cd "C:\Program Files (x86)\S-Terra Client"

2. Выполнить следующую команду:

C:\Program Files (x86)\S-Terra Client> .\log_mgr.exe set-filelog -y enable

Filelog parameters are set successfully

Теперь можно просматривать логи в окне Show Log.. ПО «С-Терра Клиент» (см. рисунок 15 и рисунок 16)

Рисунок 15. Запуск окна просмотра логов ПО «С-Терра Клиент»

Рисунок 16. Окно просмотра лога ПО «С-Терра Клиент»

Приложение

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

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

version 12.4

no service password-encryption

crypto ipsec df-bit copy

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 password 0 csp

aaa new-model

hostname Hub1-n1

enable password csp

crypto isakmp policy 1

encr gost

hash gost341112-256-tc26

authentication gost-sig

group vko2

ip local pool IKECFG_POOL 192.168.255.1 192.168.255.127

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

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 IPSEC_ACL_HUB1_AND_CLIENTS

permit ip 192.168.100.0 0.0.0.255 192.168.255.0 0.0.0.127

crypto dynamic-map DMAP 1

match address IPSEC_ACL_HUB1_AND_CLIENTS

set transform-set GOST_ENCRYPT_AND_INTEGRITY

set pool IKECFG_POOL

reverse-route

set dead-connection history off

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

reverse-route

set dead-connection history off

crypto map VPN 2 ipsec-isakmp dynamic DMAP

interface GigabitEthernet0/0

ip address 172.16.100.10 255.255.255.0

crypto map VPN

interface GigabitEthernet0/1

ip address 192.168.200.10 255.255.255.0

ip route 0.0.0.0 0.0.0.0 172.16.100.1

ip route 192.168.100.0 255.255.255.0 192.168.200.1

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

30820227308201D4A003020102021058E026BFD6D625BE4582C16C6189C18330

...

ADE9BB6B223814A76CEC9E9BD24ECA72A6AE472E96144F5AAA08F9CDC3DA5457

AD4F8901771632E0A0AF83

quit

end

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

# This is automatically generated LSP

# Conversion Date/Time: Thu Apr 16 22:10:03 2020

GlobalParameters(

Title = "This LSP was automatically generated by CSP Converter at Thu Apr 16 22:10:03 2020 (user: cscons)"

Version = LSP_4_3

CRLHandlingMode = ENABLE

PreserveIPsecSA = FALSE

)

RoutingTable(

Routes =

Route(

Destination = 0.0.0.0/0

Gateway = 172.16.100.1

Route(

Destination = 192.168.100.0/24

Gateway = 192.168.200.1

)

FirewallParameters(

TCPSynSentTimeout = 30

TCPFinTimeout = 5

TCPClosedTimeout = 30

TCPSynRcvdTimeout = 30

TCPEstablishedTimeout = 3600

TCPHalfOpenLow = 400

TCPHalfOpenMax = 500

TCPSessionRateLow = 400

TCPSessionRateMax = 500

)

IKETransform crypto:isakmp:policy:1

(

CipherAlg = "G2814789CPRO1-K256-CBC-65534"

HashAlg = "GR341112_256TC26-65128"

GroupID = VKO2_1B

RestrictAuthenticationTo = GOST_SIGN

LifetimeSeconds = 86400

)

ESPProposal GOST_ENCRYPT_AND_INTEGRITY:ESP

(

Transform* = ESPTransform

(

CipherAlg* = "G2814789CPRO2-K288-CNTMAC-253"

LifetimeSeconds = 3600

LifetimeKilobytes = 4608000

)

AddressPool IKECFG_POOL

(

IPAddresses = 192.168.255.1..192.168.255.127

)

IKEParameters(

FragmentSize = 576

SALifetimeDelta = 50

InitiatorSessionsMax = 100

ResponderSessionsMax = 100

)

AuthMethodGOSTSign GOST:Sign

(

LocalID = IdentityEntry( DistinguishedName* = USER_SPECIFIC_DATA )

SendRequestMode = ALWAYS

SendCertMode = ALWAYS

)

IKERule IKERule:VPN:1

(

IKEPeerIPFilter = 172.16.1.2

Transform = crypto:isakmp:policy:1

AggrModeAuthMethod = GOST:Sign

MainModeAuthMethod = GOST:Sign

DPDIdleDuration = 3

DPDResponseDuration = 2

DPDRetries = 5

Priority = 10

)

IKERule IKERule:VPN:2:DMAP:1

(

Transform = crypto:isakmp:policy:1

AggrModeAuthMethod = GOST:Sign

MainModeAuthMethod = GOST:Sign

IKECFGPool = IKECFG_POOL

DPDIdleDuration = 3

DPDResponseDuration = 2

DPDRetries = 5

Priority = 100

)

IPsecAction IPsecAction:VPN:1

(

TunnelingParameters = TunnelEntry(

PeerAddress = 172.16.1.2

DFHandling=COPY

Assemble=TRUE

)

ContainedProposals = ( GOST_ENCRYPT_AND_INTEGRITY:ESP )

ReverseRoute = TRUE

NoDeadConnectionHistory = TRUE

IKERule = IKERule:VPN:1

)

IPsecAction IPsecAction:VPN:2:DMAP:1

(

TunnelingParameters = TunnelEntry(

DFHandling=COPY

Assemble=TRUE

)

ContainedProposals = ( GOST_ENCRYPT_AND_INTEGRITY:ESP )

ReverseRoute = TRUE

NoDeadConnectionHistory = TRUE

IKERule = IKERule:VPN:2:DMAP: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 = IPsecAction:VPN:1 >

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

Filter (

Label = "VPN:2:DMAP:1:IPSEC_ACL_HUB1_AND_CLIENTS"

SourceIP = 192.168.100.0/24

DestinationIP = 192.168.255.0/25

Action = PASS

ExtendedAction = ipsec< sa = IPsecAction:VPN:2:DMAP:1 >

LogEventID = "IPsec:Protect:VPN:2:DMAP:1:IPSEC_ACL_HUB1_AND_CLIENTS"

)

NetworkInterface (

LogicalName = "GigabitEthernet0/0"

IPsecPolicy = IPsecPolicy:VPN

)

3. Конфигурация vtysh (FRR):

frr version 7.3

frr defaults traditional

hostname Hub1-n1

log syslog informational

service integrated-vtysh-config

router bgp 64512

bgp router-id 192.168.200.10

neighbor 192.168.200.1 remote-as 64512

address-family ipv4 unicast

redistribute kernel

neighbor 192.168.200.1 next-hop-self

neighbor 192.168.200.1 distribute-list ROUTE_FILTER_OUT out

exit-address-family

access-list ROUTE_FILTER_OUT seq 10 permit 192.168.255.0/25

access-list ROUTE_FILTER_OUT seq 5 permit 192.168.1.0/24

line vty

end

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

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

version 12.4

no service password-encryption

crypto ipsec df-bit copy

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 password 0 csp

aaa new-model

hostname Hub1-n2

enable password csp

crypto isakmp policy 1

encr gost

hash gost341112-256-tc26

authentication gost-sig

group vko2

ip local pool IKECFG_POOL 192.168.255.128 192.168.255.254

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

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 IPSEC_ACL_HUB1_AND_CLIENTS

permit ip 192.168.100.0 0.0.0.255 192.168.255.128 0.0.0.127

crypto dynamic-map DMAP 1

match address IPSEC_ACL_HUB1_AND_CLIENTS

set transform-set GOST_ENCRYPT_AND_INTEGRITY

set pool IKECFG_POOL

reverse-route

set dead-connection history off

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

reverse-route

set dead-connection history off

crypto map VPN 2 ipsec-isakmp dynamic DMAP

interface GigabitEthernet0/0

ip address 172.16.100.20 255.255.255.0

crypto map VPN

interface GigabitEthernet0/1

ip address 192.168.200.20 255.255.255.0

ip route 0.0.0.0 0.0.0.0 172.16.100.1

ip route 192.168.100.0 255.255.255.0 192.168.200.1

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

30820227308201D4A003020102021058E026BFD6D625BE4582C16C6189C18330

...

ADE9BB6B223814A76CEC9E9BD24ECA72A6AE472E96144F5AAA08F9CDC3DA5457

AD4F8901771632E0A0AF83

quit

end

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

# This is automatically generated LSP

# Conversion Date/Time: Thu Apr 16 22:15:43 2020

GlobalParameters(

Title = "This LSP was automatically generated by CSP Converter at Thu Apr 16 22:15:43 2020 (user: cscons)"

Version = LSP_4_3

CRLHandlingMode = ENABLE

PreserveIPsecSA = FALSE

)

RoutingTable(

Routes =

Route(

Destination = 0.0.0.0/0

Gateway = 172.16.100.1

Route(

Destination = 192.168.100.0/24

Gateway = 192.168.200.1

)

FirewallParameters(

TCPSynSentTimeout = 30

TCPFinTimeout = 5

TCPClosedTimeout = 30

TCPSynRcvdTimeout = 30

TCPEstablishedTimeout = 3600

TCPHalfOpenLow = 400

TCPHalfOpenMax = 500

TCPSessionRateLow = 400

TCPSessionRateMax = 500

)

IKETransform crypto:isakmp:policy:1

(

CipherAlg = "G2814789CPRO1-K256-CBC-65534"

HashAlg = "GR341112_256TC26-65128"

GroupID = VKO2_1B

RestrictAuthenticationTo = GOST_SIGN

LifetimeSeconds = 86400

)

ESPProposal GOST_ENCRYPT_AND_INTEGRITY:ESP

(

Transform* = ESPTransform

(

CipherAlg* = "G2814789CPRO2-K288-CNTMAC-253"

LifetimeSeconds = 3600

LifetimeKilobytes = 4608000

)

AddressPool IKECFG_POOL

(

IPAddresses = 192.168.255.128..192.168.255.254

)

IKEParameters(

FragmentSize = 576

SALifetimeDelta = 50

InitiatorSessionsMax = 100

ResponderSessionsMax = 100

)

AuthMethodGOSTSign GOST:Sign

(

LocalID = IdentityEntry( DistinguishedName* = USER_SPECIFIC_DATA )

SendRequestMode = ALWAYS

SendCertMode = ALWAYS

)

IKERule IKERule:VPN:1

(

IKEPeerIPFilter = 172.16.1.2

Transform = crypto:isakmp:policy:1

AggrModeAuthMethod = GOST:Sign

MainModeAuthMethod = GOST:Sign

DPDIdleDuration = 3

DPDResponseDuration = 2

DPDRetries = 5

Priority = 10

)

IKERule IKERule:VPN:2:DMAP:1

(

Transform = crypto:isakmp:policy:1

AggrModeAuthMethod = GOST:Sign

MainModeAuthMethod = GOST:Sign

IKECFGPool = IKECFG_POOL

DPDIdleDuration = 3

DPDResponseDuration = 2

DPDRetries = 5

Priority = 100

)

IPsecAction IPsecAction:VPN:1

(

TunnelingParameters = TunnelEntry(

PeerAddress = 172.16.1.2

DFHandling=COPY

Assemble=TRUE

)

ContainedProposals = ( GOST_ENCRYPT_AND_INTEGRITY:ESP )

ReverseRoute = TRUE

NoDeadConnectionHistory = TRUE

IKERule = IKERule:VPN:1

)

IPsecAction IPsecAction:VPN:2:DMAP:1

(

TunnelingParameters = TunnelEntry(

DFHandling=COPY

Assemble=TRUE

)

ContainedProposals = ( GOST_ENCRYPT_AND_INTEGRITY:ESP )

ReverseRoute = TRUE

NoDeadConnectionHistory = TRUE

IKERule = IKERule:VPN:2:DMAP: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 = IPsecAction:VPN:1 >

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

Filter (

Label = "VPN:2:DMAP:1:IPSEC_ACL_HUB1_AND_CLIENTS"

SourceIP = 192.168.100.0/24

DestinationIP = 192.168.255.128/25

Action = PASS

ExtendedAction = ipsec< sa = IPsecAction:VPN:2:DMAP:1 >

LogEventID = "IPsec:Protect:VPN:2:DMAP:1:IPSEC_ACL_HUB1_AND_CLIENTS"

)

NetworkInterface (

LogicalName = "GigabitEthernet0/0"

IPsecPolicy = IPsecPolicy:VPN

)

3. Конфигурация vtysh (FRR):

frr version 7.3

frr defaults traditional

hostname Hub1-n2

log syslog informational

service integrated-vtysh-config

router bgp 64512

bgp router-id 192.168.200.20

neighbor 192.168.200.1 remote-as 64512

address-family ipv4 unicast

redistribute kernel

neighbor 192.168.200.1 next-hop-self

neighbor 192.168.200.1 distribute-list ROUTE_FILTER_OUT out

exit-address-family

access-list ROUTE_FILTER_OUT seq 10 permit 192.168.255.0/24

access-list ROUTE_FILTER_OUT seq 5 permit 192.168.1.0/24

line vty

end

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

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

version 12.4

no service password-encryption

crypto ipsec df-bit copy

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 password 0 csp

aaa new-model

hostname Spoke1

enable password csp

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_SPOKE1_AND_HUB1

permit ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255

crypto map VPN 1 ipsec-isakmp

match address IPSEC_ACL_SPOKE1_AND_HUB1

set transform-set GOST_ENCRYPT_AND_INTEGRITY

set peer 172.16.100.10

set peer 172.16.100.20

set dead-connection history off

interface GigabitEthernet0/0

ip address 172.16.1.2 255.255.255.0

crypto map VPN

interface GigabitEthernet0/1

ip address 192.168.1.1 255.255.255.0

ip route 0.0.0.0 0.0.0.0 172.16.1.1

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

30820227308201D4A003020102021058E026BFD6D625BE4582C16C6189C18330

...

ADE9BB6B223814A76CEC9E9BD24ECA72A6AE472E96144F5AAA08F9CDC3DA5457

AD4F8901771632E0A0AF83

quit

end

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

# This is automatically generated LSP

# Conversion Date/Time: Thu Apr 16 22:31:45 2020

GlobalParameters(

Title = "This LSP was automatically generated by CSP Converter at Thu Apr 16 22:31:45 2020 (user: cscons)"

Version = LSP_4_3

CRLHandlingMode = ENABLE

PreserveIPsecSA = FALSE

)

RoutingTable(

Routes =

Route(

Destination = 0.0.0.0/0

Gateway = 172.16.1.1

)

FirewallParameters(

TCPSynSentTimeout = 30

TCPFinTimeout = 5

TCPClosedTimeout = 30

TCPSynRcvdTimeout = 30

TCPEstablishedTimeout = 3600

TCPHalfOpenLow = 400

TCPHalfOpenMax = 500

TCPSessionRateLow = 400

TCPSessionRateMax = 500

)

IKETransform crypto:isakmp:policy:1

(

CipherAlg = "G2814789CPRO1-K256-CBC-65534"

HashAlg = "GR341112_256TC26-65128"

GroupID = VKO2_1B

RestrictAuthenticationTo = GOST_SIGN

LifetimeSeconds = 86400

)

ESPProposal GOST_ENCRYPT_AND_INTEGRITY:ESP

(

Transform* = ESPTransform

(

CipherAlg* = "G2814789CPRO2-K288-CNTMAC-253"

LifetimeSeconds = 3600

LifetimeKilobytes = 4608000

)

IKEParameters(

FragmentSize = 576

SALifetimeDelta = 50

InitiatorSessionsMax = 100

ResponderSessionsMax = 100

)

AuthMethodGOSTSign GOST:Sign

(

LocalID = IdentityEntry( DistinguishedName* = USER_SPECIFIC_DATA )

SendRequestMode = ALWAYS

SendCertMode = ALWAYS

)

IKERule IKERule:VPN:1

(

IKEPeerIPFilter = 172.16.100.10, 172.16.100.20

Transform = crypto:isakmp:policy:1

AggrModeAuthMethod = GOST:Sign

MainModeAuthMethod = GOST:Sign

DPDIdleDuration = 3

DPDResponseDuration = 2

DPDRetries = 5

Priority = 10

)

IPsecAction IPsecAction:VPN:1

(

TunnelingParameters = TunnelEntry(

PeerAddress = 172.16.100.10

DFHandling=COPY

Assemble=TRUE

TunnelEntry(

PeerAddress = 172.16.100.20

DFHandling=COPY

Assemble=TRUE

)

ContainedProposals = ( GOST_ENCRYPT_AND_INTEGRITY:ESP )

NoDeadConnectionHistory = TRUE

IKERule = IKERule:VPN:1

)

FilterChain IPsecPolicy:VPN (

Filters = Filter (

ProtocolID = 17

SourcePort = 500, 4500

Action = PASS

PacketType = LOCAL_UNICAST, LOCAL_MISDIRECTED

Filter (

SourceIP = 192.168.1.0/24

DestinationIP = 192.168.100.0/24

Action = PASS

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

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

)

NetworkInterface (

LogicalName = "GigabitEthernet0/0"

IPsecPolicy = IPsecPolicy:VPN

)

Конфигурации Router1

1. Конфигурация vtysh (FRR):

frr version 7.2

frr defaults traditional

hostname Router1

log syslog informational

no ipv6 forwarding

service integrated-vtysh-config

router bgp 64512

neighbor 192.168.200.10 remote-as 64512

neighbor 192.168.200.20 remote-as 64512

line vty

end

Конфигурации Client1

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

GlobalParameters (

Title = "This LSP was automatically generated by S-Terra Client AdminTool (st) at 2020.04.17 12:29:15"

Version = LSP_4_3

CRLHandlingMode = BEST_EFFORT

)

LDAPSettings (

ResponseTimeout = 200

HoldConnectTimeout = 60

DropConnectTimeout = 5

)

IdentityEntry auth_identity_01(

DistinguishedName *= CertDescription(

Subject *= COMPLETE,"C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Client1"

)

CertDescription local_cert_dsc_01(

Subject *= COMPLETE,"C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Client1"

Issuer *= COMPLETE,"C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA"

SerialNumber = "2F000002C8D2ED7AFEE9AC62DA0000000002C8"

FingerprintMD5 = "4EF6856A679E83C79FDBF6FD2A671812"

)

CertDescription partner_cert_dsc_01(

)

AuthMethodGOSTSign auth_method_01(

LocalID = auth_identity_01

LocalCredential = local_cert_dsc_01

RemoteCredential = partner_cert_dsc_01

SendRequestMode = AUTO

SendCertMode = AUTO

)

IKEParameters (

DefaultPort = 500

SendRetries = 5

RetryTimeBase = 1

RetryTimeMax = 30

SessionTimeMax = 60

InitiatorSessionsMax = 30

ResponderSessionsMax = 20

BlacklogSessionsMax = 16

BlacklogSessionsMin = 0

BlacklogSilentSessions = 4

BlacklogRelaxTime = 120

IKECFGPreferDefaultAddress = TRUE

IKECFGDefaultAddress = 0.0.0.0

)

IKETransform ike_trf_01(

LifetimeSeconds = 28800

CipherAlg *= "G2814789CPRO1-K256-CBC-65534"

HashAlg *= "GR341112_256TC26-65128"

GroupID *= VKO2_1B

)

IKETransform ike_trf_02(

LifetimeSeconds = 28800

CipherAlg *= "GR341215K-K256-CFB-65528"

HashAlg *= "GR341112_256TC26-65128"

GroupID *= VKO2_1B

)

IKETransform ike_trf_03(

LifetimeSeconds = 28800

CipherAlg *= "G2814789CPRO1-K256-CBC-65534"

HashAlg *= "GR341194CPRO1-65534"

GroupID *= VKO_1B

)

IKETransform ike_trf_04(

LifetimeSeconds = 28800

CipherAlg *= "G2814789CPRO1-K256-CBC-65534"

HashAlg *= "GR341194CPRO1-65534"

GroupID *= MODP_1536

)

ESPTransform esp_trf_01(

CipherAlg *= "G2814789CPRO2-K288-CNTMAC-253"

LifetimeSeconds = 3600

LifetimeKilobytes = 4608000

)

ESPProposal esp_proposal_01(

Transform *=esp_trf_01

)

ESPTransform esp_trf_02(

CipherAlg *= "GR341215K-K352-MGM-251"

LifetimeSeconds = 3600

LifetimeKilobytes = 4608000

)

ESPProposal esp_proposal_02(

Transform *=esp_trf_02

)

ESPTransform esp_trf_03(

CipherAlg *= "G2814789CPRO1-K256-CBC-254"

IntegrityAlg *= "GR341194CPRO1-H96-HMAC-65534"

LifetimeSeconds = 3600

LifetimeKilobytes = 4608000

)

ESPProposal esp_proposal_03(

Transform *=esp_trf_03

)

IKERule ike_rule_with_ikecfg_01(

DoNotUseDPD = FALSE

DPDIdleDuration = 60

DPDResponseDuration = 5

DPDRetries = 3

MainModeAuthMethod *= auth_method_01

Transform *= ike_trf_01,ike_trf_02,ike_trf_03,ike_trf_04

IKECFGRequestAddress = TRUE

)

IPsecAction ipsec_action_01(

PersistentConnection = TRUE

TunnelingParameters *=

TunnelEntry(

PeerAddress = 172.16.100.10

Assemble = TRUE

ReRoute = FALSE

TCPEncapsulation = FALSE

TunnelEntry(

PeerAddress = 172.16.100.20

Assemble = TRUE

ReRoute = FALSE

TCPEncapsulation = FALSE

)

ShuffleTunnelEntries = TRUE

ContainedProposals *= (esp_proposal_01),(esp_proposal_02),(esp_proposal_03)

IKERule = ike_rule_with_ikecfg_01

)

FilterChain filter_chain_input(

Filters *= Filter(

ProtocolID *= 17

DestinationPort *= 500

Action = PASS

LogEventID = "pass_action_02_01"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

ProtocolID *= 17

DestinationPort *= 4500

Action = PASS

LogEventID = "pass_action_02_02"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

SourceIP *= 172.16.100.10,172.16.100.20

ProtocolID *= 50

Action = PASS

LogEventID = "pass_action_03_01"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

SourceIP *= 172.16.100.10,172.16.100.20

ProtocolID *= 51

Action = PASS

LogEventID = "pass_action_03_02"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

Action = PASS

LogEventID = "pass_action_04"

)

FilterChain filter_chain_output(

Filters *= Filter(

ProtocolID *= 17

SourcePort *= 500

Action = PASS

LogEventID = "pass_action_05_01"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

ProtocolID *= 17

SourcePort *= 4500

Action = PASS

LogEventID = "pass_action_05_02"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

DestinationIP *= 172.16.100.10,172.16.100.20

ProtocolID *= 50

Action = PASS

LogEventID = "pass_action_06_01"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

DestinationIP *= 172.16.100.10,172.16.100.20

ProtocolID *= 51

Action = PASS

LogEventID = "pass_action_06_02"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

Action = PASS

LogEventID = "pass_action_07"

)

FilterChain filter_chain_classification_input(

Filters *= Filter(

Action = PASS

LogEventID = "pass_action_08"

)

FilterChain filter_chain_classification_output(

Filters *= Filter(

Action = PASS

LogEventID = "pass_action_09"

)

FilterChain filter_chain_ipsec(

Filters *= Filter(

ProtocolID *= 17

SourcePort *= 500

Action = PASS

LogEventID = "pass_action_10_01"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

ProtocolID *= 17

SourcePort *= 4500

Action = PASS

LogEventID = "pass_action_10_02"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

DestinationIP *= 172.16.100.10,172.16.100.20

ProtocolID *= 50

Action = PASS

LogEventID = "pass_action_11_01"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

DestinationIP *= 172.16.100.10,172.16.100.20

ProtocolID *= 51

Action = PASS

LogEventID = "pass_action_11_02"

PacketType = LOCAL_UNICAST,LOCAL_MISDIRECTED

),Filter(

DestinationIP *= 192.168.100.0/24

Action = PASS

ExtendedAction *= ipsec<sa=ipsec_action_01>

LogEventID = "ipsec_action_01"

),Filter(

Action = PASS

LogEventID = "pass_action_12"

)

NetworkInterface(

InputFilter = filter_chain_input

OutputFilter = filter_chain_output

InputClassification = filter_chain_classification_input

OutputClassification = filter_chain_classification_output

IPsecPolicy = filter_chain_ipsec

)