Построение L2 VPN туннеля при помощи программного модуля «С-Терра L2»

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

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

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

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

  Архив с установочным файлом "С-Терра L2":

sterra_l2_4.3.23255.amd64.rar

Введение

Данный сценарий описывает настройку безопасного взаимодействия между центральным офисом и филиалом на уровне 2 модели OSI (L2 VPN).

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

Все остальные соединения разрешены, но защищаться при помощи IPsec не будут.

В рамках данного сценария для аутентификации партнеры будут использовать сертификаты. В качестве криптопровайдера будет использована криптографическая библиотека, разработанная компанией «С-Терра СиЭсПи». Шлюзы безопасности (или криптошлюзы) - «С-Терра Шлюз» версии 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.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.      Между криптошлюзами должна быть обеспечена IP связность.


 

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

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


 

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

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

1.1.      В центральном офисе размещаются: центр выпуска сертификатов (Certification_authority), криптошлюз С-Терра Шлюз (Hub1), управляемый коммутатор (Int_switch1_Hub1) и персональные компьютеры (host0-behind-hub1 и host1-behind-hub1).

1.2.      В филиале размещаются: криптошлюз С-Терра Шлюз (Spoke1), управляемый коммутатор (Int_switch1_Spoke1) и персональные компьютеры (host0-behind-spoke1 и host1-behind-spoke1).

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

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

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

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

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

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

3.    L2 VPN.

Общие сведения

L2 VPN реализуется при помощи модуля «С-Терра L2», который требует отдельной лицензии.

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

За работу модуля «С-Терра L2» отвечает сервис l2svc. По умолчанию данный сервис выключен и не добавлен в автозапуск:

root@sterragate:~# systemctl status l2svc

● l2svc.service - S-Terra L2 Tunneling Service

   Loaded: loaded (/lib/systemd/system/l2svc.service; disabled; vendor preset: e

   Active: inactive (dead)

Конфигурационные файлы и файл с лицензией должны располагаться в директории /opt/l2svc/etc/. Конфигурационные файлы обязательно должны иметь расширение .conf (например to_spoke1.conf). Файл с лицензией должен обязательно называться l2.lic.

Принцип работы модуля «С-Терра L2»

Рассмотрим принцип работы модуля на примере конфигурационного файла:

vif tap0

local 172.16.100.2

remote 172.16.1.2

port 50000

capture eth1

bridge br0

bridge_ip 192.168.100.1/24

mssfix 1400

passtos

·         vif <NAME> - параметр определяет имя виртуального туннельного интерфейса, который будет создан. Имя должно быть уникальным во всех конфигурационных файлах. Длина имени должна быть не более 15 символов. Фреймы с данного интерфейса инкапсулируются в UDP.

·         local <IP> - параметр определяет локальный IP адрес для инкапсулированных пакетов. Как правило, локальный IP адрес указывается такой же, как IP адрес на WAN интерфейсе С-Терра Шлюз, но если WAN интерфейсов несколько, то нужно создать loopback интерфейс и назначить на него какой-то третий произвольный IP адрес, который будет использоваться в качестве локального IP адреса (процедура создания loopback интерфейсов описана на сайте doc.s-terra.ru -> С-Терра Шлюз > С-Терра Шлюз 4.3 > Настройка шлюза > Общие настройки шлюза > Работа с интерфейсами > Добавление и удаление сетевых интерфейсов > Добавление и удаление виртуальных сетевых интерфейсов > Loopback интерфейсы).

·         remote <IP> - параметр определяет IP адрес партнера по L2 туннелю. Данный IP адрес будет является адресом назначения для инкапсулированных пакетов.

·         port <PORT> - параметр одновременно определяет номер UDP порта источника (src) и назначения (dst) инкапсулированных пакетов.

·         capture <NAME> - параметр определяет имя существующего интерфейса, на котором будет происходить захват фреймов.

·         bridge <NAME> - параметр определяет имя интерфейса виртуального коммутатора (linux kernel bridge). Имя может быть одинаковым в нескольких конфигурационных файлах. Длина имени должна быть не более 15 символов. Виртуальный коммутатор используется для объединения в L2 мост виртуального туннельного интерфейса (определяется параметром vif <NAME>) и сетевого интерфейса, с которого происходит захват фреймов (определяется параметром capture <NAME>).

·         bridge_ip <IP/MASK> - параметр определяет локальный IP адрес для интерфейса виртуального коммутатора, который задается параметром bridge <NAME>. Используется для L3 связности между устройствами в LAN сегменте и С-Терра Шлюз через интерфейс захвата фреймов (например, применимо для цели управления С-Терра Шлюз).

·         mssfix <VALUE> - параметр выставляет значение MSS в TCP пакетах. При включении данной опции поле MSS всех проходящих через туннель TCP пакетов будет выставлено в <VALUE>, если текущее значение MSS в пакете больше <VALUE>. Применимо для пакетов протокола IPv4, которые вкладываются в Ethernet/802.1Q/QinQ. Для MPLS не работает.

·         passtos - параметр включает копирование ToS байта из исходного пакета в инкапсулированный. Применимо для пакетов протокола IPv4, которые вкладываются в Ethernet/802.1Q/QinQ. Для MPLS копирование не работает.

После того, как сервис l2svc будет запущен с данным конфигурационным файлом, будут созданы интерфейсы vif <NAME> и bridge <NAME>, далее интерфейсы vif <NAME> и capture <NAME> будут добавлены в виртуальный коммутатор bridge <NAME>. На интерфейсе bridge <NAME> будет  назначен IP адрес, указанный в параметре bridge_ip, например:

root@Hub1:~# ip address show

...

3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000

    link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff

14: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000

    link/ether ca:f5:a9:b7:e5:35 brd ff:ff:ff:ff:ff:ff

15: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

    link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff

    inet 192.168.100.1/24 scope global br0

       valid_lft forever preferred_lft forever

root@Hub1:~# brctl show br0

bridge name     bridge id               STP enabled     interfaces

br0             8000.0050569e674d       no              eth1

                                                        tap0

Накладные расходы (overhead) L2 VPN

Так как оригинальный фрейм инкапсулируется в UDP, то минимальные накладные расходы инкапсуляции L2 - это 28 (20 IP+ 8 UDP) байт. Если используется параметр fragment <N> в конфигурационном файле модуля «С-Терра L2», то добавляется еще 4 байта. Не стоит забывать про накладные расходы инкапсуляции IPsec, которые для туннельного режима могут составлять от 50 до 60 байт (зависит от алгоритма шифрования и наличия NAT).

Рисунок 2. Накладные расходы (overhead) L2 + IPsec

Рисунок (см. рисунок 2) показывает минимальный и максимальный размер накладных расходов при организации L2 VPN для оригинального нетегированного, 802.1 Q и QinQ фрейма. Если шифруется MPLS, то размер оригинального фрейма может варьироваться в зависимости от количества меток в стеке, учитывайте это.

Из рисунка (см. рисунок 2) видно, что с учетом размера оригинального фрейма, а также L2 и IPsec инкапсуляций результирующий пакет может иметь размер от 1592 до 1614 байт. Если MTU на WAN интерфейсе С-Терра Шлюз имеет значение в 1500 байт (по умолчанию), то инкапсулированные пакеты будут фрагментированы, что в свою очередь приведет к снижению производительности (до 15 %). Соответственно, при наличии возможности, заказывайте нужный вам MTU у вашего провайдера на каналообразующем оборудовании, чтобы избежать фрагментации и снижения производительности.

Фрагментация, MTU и DF бит

По умолчанию размер MTU для всех интерфейсов модуля «С-Терра L2» - 1500 байт. Размер MTU можно увеличить при помощи параметра tun_mtu <N> в конфигурационном файле модуля «С-Терра L2». Например, увеличение tun_mtu используется для случая, когда MTU устройств в LAN сегменте - 9000 байт, а MTU интерфейса WAN С-Терра Шлюз - 1500 байт. В этом случае большие пакеты будут фрагментированы драйвером С-Терра VPN (фрагментация пакетов происходит после зашифрования).

DF (don’t fragment) бит с исходных пакетов на инкапсулированные не переносится (не настраивается). Используется для того, чтобы большие пакеты могли быть фрагментированы драйвером С-Терра VPN.

Если требуется выполнять фрагментацию в самом модуле «С-Терра L2» до зашифрования (используется в случае, если каналообразующее оборудование блокирует фрагментированные пакеты), то нужно использовать параметр fragment <N> в конфигурационном файле (все пакеты, большие N байт будут фрагментированы). Данный параметр добавляет дополнительные 4 байта и должен быть включен на обеих сторонах туннеля.

Защита 802.1Q трафика

Если нужно зашифровать тегированный 802.1Q трафик, то рекомендуется на каждый VLAN ID создавать отдельный конфигурационный файл модуля «С-Терра L2» и логический 802.1Q интерфейс, а с точки зрения политики безопасности IPsec туннель, - такой подход позволяет лучше контролировать защищаемый трафик (маппирование VLAN ID в IPsec туннель). Но, если топология точка-точка и трафика с различными VLAN ID больше 10, то рекомендуется настраивать один конфигурационный файл и не создавать 802.1Q интерфейсы - это позволит увеличить производительность шифрования (общее правило - чем меньше конфигурационных файлов модуля «С-Терра L2» и IPsec туннелей, тем выше производительность).

Управление С-Терра Шлюз через интерфейс захвата пакетов

Управление С-Терра Шлюз, начиная с версии 4.3, возможно через тот интерфейс, на котором происходит захват фреймов, для этого нужно задать параметр bridge_ip <IP>/<MASK> в конфигурационном файле модуля «С-Терра L2». Если данный вариант по какой-то причине не подходит - используйте выделенный сетевой интерфейс.

Пропуск фреймов протоколов LACP/LLDP

По умолчанию фреймы протоколов LACP/LLDP будут уничтожены. Чтобы они могли пройти через С-Терра Шлюз (требуется в сценарии балансировки нагрузки и резервировании при помощи внешнего коммутатора) нужно в соответствующем файле конфигурации модуля «С-Терра L2» добавить параметр group_fwd_mask со значением 16388, пример:

group_fwd_mask 16388

Копирование ToS байта из оригинального пакета в инкапсулированный

Копирование ToS байта из оригинального пакета в инкапсулированный (и, соответственно, в  ESP/NAT-Т пакеты - поведение С-Терра VPN по умолчанию) включается при помощи параметра passtos в конфигурационном файле модуля «С-Терра L2». Применимо для пакетов протокола IPv4, которые вкладываются в Ethernet/802.1Q/QinQ. Для MPLS копирование не работает.

Производительность

В модуле «С-Терра L2» есть возможность выделить определенное количество ядер под инкапсуляцию фреймов в UDP, настраивается при помощи параметра L2VPN_CORE_COUNT в файле /opt/l2svc/etc/global.cfg. По умолчанию используется только одно последнее ядро. Подробнее смотрите на сайте doc.s-terra.com -> С-Терра L2 -> С-Терра L2 4.3-> Руководство администратора -> Настройка Продукта -> Общие настройки.

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

Весь трафик (на уровне 2 модели OSI) подсетей 192.168.100.0/24 и 192.168.101.0/24, который передается между центром и филиалом, защищается с использованием алгоритмов ГОСТ и протокола IPsec в туннельном режиме.

Инициировать защищенное соединение может как трафик из филиала в центр, так и наоборот, из центра в филиал.

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

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

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

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

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

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

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

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

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

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

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

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

Int_switch1_Hub1

1.    Интерфейс gi0/0 должен быть в trunk режиме. Должно быть разрешено прохождения фреймов с VLAN ID 0 и 10.

2.    Интерфейс gi0/1 должен быть в access режиме c VLAN ID 0.

3.    Интерфейс gi0/2 должен быть в access режиме c VLAN ID 10.

Int_switch1_Spoke1

1.    Интерфейс gi0/0 должен быть в trunk режиме. Должно быть разрешено прохождения фреймов с VLAN ID 0 и 10.

2.    Интерфейс gi0/1 должен быть в access режиме c VLAN ID 0.

3.    Интерфейс gi0/2 должен быть в access режиме c VLAN ID 10.

Настройка устройства host0-behind-hub1

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

2.    Разрешите прием и отправку ICMP пакетов.

Настройка устройства host1-behind-hub1

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

2.    Разрешите прием и отправку ICMP пакетов.

Настройка устройства host0-behind-spoke1

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

2.    Разрешите прием и отправку ICMP пакетов.

Настройка устройства host1-behind-spoke1

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

2.    Разрешите прием и отправку ICMP пакетов.

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

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

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

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

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

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

S-Terra administrative console

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

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

login as: administrator

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  Thu Jul  4 10:40:32 2019  1482-7CB1

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

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

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

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

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

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

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

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

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

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

Press key: U

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

administrator@sterragate] dir media:1482-7CB1/

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

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

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

administrator@sterragate] run umount /media/1482-7CB1

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

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

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

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

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

administrator@sterragate] dir media:1482-7CB1/

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

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

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

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

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

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

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

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

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

administrator@sterragate] run cert_mgr import -f media:1482-7CB1/hub1.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

Видно, что сертификат УЦ импортирован как 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

                  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 ПАРОЛЬ

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

Настройка сетевых параметров проходит в два эта. Первый - создание 802.1Q интерфейса в linux bash. Второй - настройка IP адресов и маршрутизации в cisco-like консоли.

Первый этап.

1.    Перейдите в linux bash:

sterragate(config)#end

sterragate#exit

administrator@sterragate] system

Entering system shell...

2.    Создайте 802.1Q интерфейс eth1.10 (VLAN ID 10). Процедура создания 802.1Q интерфейсов описана на сайте doc.s-terra.ru, С-Терра Шлюз > С-Терра Шлюз 4.3 > Настройка шлюза > Общие настройки шлюза > Работа с интерфейсами > Добавление и удаление сетевых интерфейсов > Добавление и удаление виртуальных сетевых интерфейсов > 802.1Q (VLAN) интерфейсы.

Второй этап.

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

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

root@sterragate:~# exit

logout

Leaving system shell...

administrator@sterragate] configure

sterragate login: cscons

Password:

Last login: Mon Mar  2 15:00:48 MSK 2020 on pts/0

S-Terra Gate 4.3.XXXXX (amd64)

sterragate#configure terminal

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

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

sterragate(config)#hostname Hub1

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

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

Hub1(config-if-range)#no shutdown

Hub1(config-if-range)#exit

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

Hub1(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, то проверьте подключение сетевого интерфейса криптошлюза к коммутационному или прочему оборудованию.

5.    Задайте IP адрес в соответствии со схемой стенда на внешнем GigabitEthernet0/0 интерфейсе:

Hub1(config)#interface GigabitEthernet 0/0

Hub1(config-if)#ip address 172.16.100.2 255.255.255.0

Hub1(config-if)#exit

6.    Задайте маршрут по умолчанию через устройство Router1:

Hub1(config)#ip route 0.0.0.0 0.0.0.0 172.16.100.1

7.    Проверьте доступность устройства Router1 и выйдите из cisco-like консоли:

Hub1(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

Hub1(config)#end

Hub1#exit

administrator@Hub1]

Настройка L2

1.    Перейдите в linux bash:

administrator@Hub1] system

Entering system shell...

root@Hub1:~#

2.    Скопируйте Вашу лицензию на «С-Терра L2» в файл /opt/l2svc/etc/l2.lic:

root@Hub1:~# vim.tiny /opt/l2svc/etc/l2.lic

[license]

CustomerCode=XXXXX

ProductCode=L2VPN

LicenseNumber=XXXXX

LicenseCode=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

3.    Создание конфигурационных файлов «С-Терра L2» для перехвата и инкапсуляции нетегированных и тегированных (VLAN ID 10) фреймов.

3.1.      Создайте конфигурационный файл /opt/l2svc/etc/to_spoke1_nvlan.conf для нетегированных фреймов (native VLAN):

Если в качестве capture интерфейса указать физический интерфейс (например eth0), то все фреймы, пришедшие на данный интерфейс, будут перехвачены вне зависимости от их VLAN ID. Контролируйте поступающие фреймы в capture интерфейс на trunk порту коммутатора настройками VLAN фильтрации.

root@Hub1:~# vim.tiny /opt/l2svc/etc/to_spoke1_nvlan.conf

vif tap0

bridge br0

bridge_ip 192.168.100.1/24

capture eth1

local 172.16.100.2

remote 172.16.1.2

port 50000

mssfix 1400

passtos

Описание параметров представлено в главе «Общая логика работы».

3.2.      Создайте конфигурационный файл /opt/l2svc/etc/to_spoke1_vlan10.conf для тегированных фреймов VLAN ID 10:

Если в качестве capture интерфейса указать логический 802.1Q интерфейс (например eth0.10), то только фреймы с соответствующим VLAN ID, пришедшие на данный интерфейс, будут перехвачены.

root@Hub1:~# vim.tiny /opt/l2svc/etc/to_spoke1_vlan10.conf

vif tap1

bridge br1

bridge_ip 192.168.101.1/24

capture eth1.10

local 172.16.100.2

remote 172.16.1.2

port 50001

mssfix 1400

passtos

Описание параметров представлено в главе «Общая логика работы».

4.    Запустите сервис l2svc и добавьте его в автозапуск:

root@Hub1:~# systemctl start l2svc.service

root@Hub1:~# systemctl enable l2svc.service

Created symlink /etc/systemd/system/default.target.wants/l2svc.service → /lib/systemd/system/l2svc.service.

root@Hub1:~# systemctl status l2svc.service

● l2svc.service - S-Terra L2 Tunneling Service

   Loaded: loaded (/lib/systemd/system/l2svc.service; enabled; vendor preset: en

   Active: active (exited) since Wed 2020-03-04 04:43:23 MSK; 18s ago

 Main PID: 1688 (code=exited, status=0/SUCCESS)

 

Mar 04 04:43:23 Hub1 systemd[1]: Starting S-Terra L2 Tunneling Service...

Mar 04 04:43:23 Hub1 systemd[1]: Started S-Terra L2 Tunneling Service.

5.    Убедитесь, что необходимые виртуальные сетевые интерфейсы (tap0/tap1/br0/br1) созданы; capture и vif интерфейсы (tap0/tap1/eth1/eth1.10) переведены в promisc режим; выставлены IP адреса на интерфейсах br0/br1:

root@Hub1:~# ip address show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 00:50:56:9e:fb:29 brd ff:ff:ff:ff:ff:ff

    inet 172.16.100.2/24 brd 172.16.100.255 scope global eth0

       valid_lft forever preferred_lft forever

3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000

    link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff

4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000

    link/ether 00:50:56:9e:0a:06 brd ff:ff:ff:ff:ff:ff

5: eth1.10@eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue master br1 state UP group default qlen 1000

    link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff

6: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000

    link/ether 16:64:ab:2d:4a:87 brd ff:ff:ff:ff:ff:ff

7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

    link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff

    inet 192.168.100.1/24 scope global br0

       valid_lft forever preferred_lft forever

8: tap1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN group default qlen 1000

    link/ether 8e:f7:a6:06:f7:c9 brd ff:ff:ff:ff:ff:ff

9: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

    link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff

    inet 192.168.101.1/24 scope global br1

       valid_lft forever preferred_lft forever

Если по какой-то причине интерфейсы на создались или произошли другие ошибки, то можно посмотреть информацию о проблеме при помощи команды:

root@Hub1:~# journalctl -xe -u l2svc_s@<L2_CONIG_NAME>.service

где <L2_CONIG_NAME> - имя конфигурационного файла L2 без «.conf», например to_spoke1_nvlan:

root@Hub1:~# journalctl -xe -u l2svc_s@to_spoke1_nvlan.service

-- Logs begin at Tue 2020-03-10 22:49:42 MSK, end at Wed 2020-03-11 19:27:27 MSK. --

Mar 10 22:54:24 Hub1 systemd[1]: Starting S-Terra L2 Tunneling Service for to_spoke1_nvlan...

-- Subject: Unit l2svc_s@to_spoke1_nvlan.service has begun start-up

-- Defined-By: systemd

-- Support: https://www.debian.org/support

--

-- Unit l2svc_s@to_spoke1_nvlan.service has begun starting up.

Mar 10 22:54:24 Hub1 l2svc[2073]: Tue Mar 10 22:54:24 2020 l2svc: License OK

Mar 10 22:54:24 Hub1 l2svc[2073]: Tue Mar 10 22:54:24 2020 l2svc: S-Terra L2 for Linux 4.3.20285

Mar 10 22:54:24 Hub1 l2svc[2073]: Tue Mar 10 22:54:24 2020 l2svc: TAP device tap0 opened

Mar 10 22:54:24 Hub1 l2svc[2073]: Tue Mar 10 22:54:24 2020 l2svc: tunnel local (bound): 172.16.100.2:50000

Mar 10 22:54:24 Hub1 l2svc[2073]: Tue Mar 10 22:54:24 2020 l2svc: tunnel remote: 172.16.1.2:50000

Mar 10 22:54:24 Hub1 systemd[1]: Started S-Terra L2 Tunneling Service for to_spoke1_nvlan.

-- Subject: Unit l2svc_s@to_spoke1_nvlan.service has finished start-up

-- Defined-By: systemd

-- Support: https://www.debian.org/support

--

-- Unit l2svc_s@to_spoke1_nvlan.service has finished starting up.

--

-- The start-up result is done.

Mar 10 22:55:42 Hub1 l2svc[2073]: Tue Mar 10 22:55:42 2020 l2svc: Peer Connection Initiated with 172.16.1.2:50000

Mar 10 22:55:43 Hub1 l2svc[2073]: Tue Mar 10 22:55:43 2020 l2svc: Initialization Sequence Completed

6.    Перейдите в CLI разграничения доступа из linux bash и далее в режим конфигурирования cisco-like консоли:

root@Hub1:~# exit

logout

Leaving system shell...

administrator@Hub1] configure

Hub1 login: cscons

Password:

Last login: Mon Mar  2 15:00:48 MSK 2020 on pts/0

S-Terra Gate 4.3.XXXXX (amd64)

Hub1#configure terminal

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

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

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

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

Hub1(config)#crypto isakmp identity dn

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

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

Hub1(config)#crypto isakmp keepalive 3 2

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

Пояснение:

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

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

Hub1(config)#crypto isakmp fragmentation

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

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

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

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

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

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

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

Hub1(config)#crypto isakmp policy 1

Hub1(config-isakmp)# encryption gost

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

Hub1(config-isakmp)# authentication gost-sig

Hub1(config-isakmp)# group vko2

Hub1(config-isakmp)# exit

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

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

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

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

Hub1(cfg-crypto-trans)#exit

2.2.      Создайте список доступа (ACL) для трафика, который нужно защищать между центральным офисом и филиалом (в данном сценарии это инкапсулированный модулем «С-Терра L2» трафик):

Hub1(config)#ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1

Hub1(config-ext-nacl)#remark VLAN ID 0

Hub1(config-ext-nacl)#permit udp host 172.16.100.2 eq 50000 host 172.16.1.2 eq 50000

Hub1(config-ext-nacl)#remark VLAN ID 10

Hub1(config-ext-nacl)#permit udp host 172.16.100.2 eq 50001 host 172.16.1.2 eq 50001

Hub1(config-ext-nacl)#exit

Hub1(config)#

2.3.      Создайте крипто-карту (имя VPN, раздел 1):

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

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

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

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

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

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

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

2.3.4      Увеличьте лимит по трафику до максимального значения для IPsec SA:

Hub1(config-crypto-map)#set security-association lifetime kilobytes 4294967295

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

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

Hub1(config-crypto-map)#exit

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

Hub1(config)#interface GigabitEthernet0/0

Hub1(config-if)# crypto map VPN

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

Hub1(config-if)#end

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

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

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

Hub1#configure terminal

Hub1(config)# crypto pki trustpoint s-terra_technological_trustpoint

Hub1(ca-trustpoint)# revocation-check crl

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

Hub1(ca-trustpoint)# revocation-check none

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

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

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

Hub1(ca-trustpoint)# crl download time 60

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

Hub1(ca-trustpoint)#end

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

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

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

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

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

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

Hub1#run systemctl restart getcrls.service

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

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

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

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

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

·         текст LSP;

·         конфигурация «С-Терра L2».


 

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

Настройка криптошлюза Spoke1 происходит аналогично настройке Hub1.

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

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

·         текст LSP;

·         конфигурация «С-Терра L2».


 

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

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

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

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

Hub1#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=0.918 ms

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

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

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

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

 

--- 172.16.100.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.225/0.387/0.918/0.267 ms

Spoke1#ping 172.16.1.1

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

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

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

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

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

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

 

--- 172.16.1.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.244/0.368/0.771/0.202 ms

Видно, что устройство Router1 доступно по ICMP как с Hub1, так и со Spoke1.

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

Hub1#ping 172.16.1.2

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

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

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

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

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

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

 

--- 172.16.1.2 ping statistics ---

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

rtt min/avg/max/mdev = 0.393/0.509/0.802/0.149 ms

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

3.    Проверьте, что с защищаемых устройств host0-behind-hub1, host1-behind-hub1 доступны по ICMP IP адреса, заданные на интерфейсах коммутаторов (br0 и br1) криптошлюза Hub1. Для этого выполните команду ping из linux bash консоли защищаемых устройств.

root@host0-behind-hub1:~# ping 192.168.100.1 -c 5

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

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

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

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

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

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

 

--- 192.168.100.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.648/1.100/2.783/0.842 ms

root@host1-behind-hub1:~# ping 192.168.101.1 -c 5

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

64 bytes from 192.168.101.1: icmp_seq=1 ttl=64 time=1.90 ms

64 bytes from 192.168.101.1: icmp_seq=2 ttl=64 time=0.419 ms

64 bytes from 192.168.101.1: icmp_seq=3 ttl=64 time=0.403 ms

64 bytes from 192.168.101.1: icmp_seq=4 ttl=64 time=0.663 ms

64 bytes from 192.168.101.1: icmp_seq=5 ttl=64 time=0.608 ms

 

--- 192.168.101.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.403/0.799/1.902/0.560 ms

Видно, что с устройств host0-behind-hub1, host1-behind-hub1 доступны по ICMP соответствующие IP адреса, заданные на интерфейсах коммутаторов (br0 и br1) криптошлюза Hub1.

4.    Проверьте, что с защищаемых устройств host0-behind-spoke1, host1-behind-spoke1 доступны по ICMP IP адреса, заданные на интерфейсах коммутаторов (br0 и br1) криптошлюза Spoke1. Для этого выполните команду ping из linux bash консоли защищаемых устройств.

root@host0-behind-spoke1:~# ping 192.168.100.2 -c 5

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

64 bytes from 192.168.100.2: icmp_seq=1 ttl=64 time=1.55 ms

64 bytes from 192.168.100.2: icmp_seq=2 ttl=64 time=0.558 ms

64 bytes from 192.168.100.2: icmp_seq=3 ttl=64 time=0.585 ms

64 bytes from 192.168.100.2: icmp_seq=4 ttl=64 time=0.544 ms

64 bytes from 192.168.100.2: icmp_seq=5 ttl=64 time=0.546 ms

 

--- 192.168.100.2 ping statistics ---

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

rtt min/avg/max/mdev = 0.544/0.755/1.546/0.396 ms

root@host1-behind-spoke1:~# ping 192.168.101.2 -c 5

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

64 bytes from 192.168.101.2: icmp_seq=1 ttl=64 time=0.628 ms

64 bytes from 192.168.101.2: icmp_seq=2 ttl=64 time=0.501 ms

64 bytes from 192.168.101.2: icmp_seq=3 ttl=64 time=0.583 ms

64 bytes from 192.168.101.2: icmp_seq=4 ttl=64 time=0.719 ms

64 bytes from 192.168.101.2: icmp_seq=5 ttl=64 time=0.674 ms

 

--- 192.168.101.2 ping statistics ---

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

rtt min/avg/max/mdev = 0.501/0.621/0.719/0.075 ms

Видно, что с устройств host0-behind-spoke1, host1-behind-spoke1 доступны по ICMP соответствующие IP адреса, заданные на интерфейсах коммутаторов (br0 и br1) криптошлюза Spoke1.

Проверка PKI

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

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

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

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

Spoke1#run cert_mgr show

Found 2 certificates. Found 1 CRL.

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

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

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

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

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

Hub1#run cert_mgr check

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

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

Spoke1#run cert_mgr check

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

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

Видно, что на криптошлюзах Hub1 и Spoke1 статус всех сертификатов Active. Если статус Inactive, то проверьте загружен ли СОС в базу Продукта и правильность установки даты и времени.

Проверка построения защищенного соединения между Hub1 и Spoke1

IPsec туннели могут быть построены автоматически при наличии трафика, например широковещательного.

1.    Инициируйте построение защищенного соединения между криптошлюзами Hub1 и Spoke1 для Native VLAN при помощи ICMP трафика, посылаемого с устройства host0-behind-spoke1 на host0-behind-hub1 (можно и наоборот). Для этого выполните команду ping из linux bash консоли защищаемого устройства host0-behind-spoke1.

root@host0-behind-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=64 time=6.70 ms

64 bytes from 192.168.100.100: icmp_seq=2 ttl=64 time=3.97 ms

64 bytes from 192.168.100.100: icmp_seq=3 ttl=64 time=3.69 ms

64 bytes from 192.168.100.100: icmp_seq=4 ttl=64 time=2.44 ms

64 bytes from 192.168.100.100: icmp_seq=5 ttl=64 time=2.61 ms

 

--- 192.168.100.100 ping statistics ---

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

rtt min/avg/max/mdev = 2.442/3.882/6.700/1.529 ms

2.    Инициируйте построение защищенного соединения между криптошлюзами Hub1 и Spoke1 для VLAN ID 10 при помощи ICMP трафика, посылаемого с устройства host1-behind-spoke1 на host1-behind-hub1 (можно и наоборот). Для этого выполните команду ping из linux bash консоли защищаемого устройства host1-behind-spoke1.

root@host1-behind-spoke1:~# ping 192.168.101.100 -c 5

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

64 bytes from 192.168.101.100: icmp_seq=1 ttl=64 time=4.43 ms

64 bytes from 192.168.101.100: icmp_seq=2 ttl=64 time=3.70 ms

64 bytes from 192.168.101.100: icmp_seq=3 ttl=64 time=3.45 ms

64 bytes from 192.168.101.100: icmp_seq=4 ttl=64 time=2.47 ms

64 bytes from 192.168.101.100: icmp_seq=5 ttl=64 time=2.63 ms

 

--- 192.168.101.100 ping statistics ---

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

rtt min/avg/max/mdev = 2.473/3.336/4.428/0.719 ms

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

Hub1#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 2 (172.16.100.2,500)-(172.16.1.2,500) active 2292 2500

 

IPsec connections:

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

1 3 (172.16.100.2,50000)-(172.16.1.2,50000) 17 ESP tunn 904 880

2 4 (172.16.100.2,50001)-(172.16.1.2,50001) 17 ESP tunn 904 984

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 2 (172.16.1.2,500)-(172.16.100.2,500) active 2500 2292

 

IPsec connections:

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

1 3 (172.16.1.2,50000)-(172.16.100.2,50000) 17 ESP tunn 880 904

2 4 (172.16.1.2,50001)-(172.16.100.2,50001) 17 ESP tunn 984 904

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

Для дополнительной диагностики можно воспользоваться утилитой tcpdump на нужных интерфейсах (например tcpdump -i tap0 -n -e -vvv).


 

Приложение

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

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 secret 5 $6$S5mhfJOq$ytq22Q8uIXimGTo6HjkDRQIo/9NR3

P/Uf0zx3eyPHSHky2ITEhSlFyHQtqixnnJxQtHDzVU9PBuC0Svb.kGAb0

aaa new-model

!

!

hostname Hub1

enable secret 5 X03MO1qnZdYdgyfeuILPmQ==

!

!

!

!

!

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

 remark VLAN ID 0

 permit udp host 172.16.100.2 eq 50000 host 172.16.1.2 eq 50000

 remark VLAN ID 10

 permit udp host 172.16.100.2 eq 50001 host 172.16.1.2 eq 50001

!

!

crypto map VPN 1 ipsec-isakmp

 match address IPSEC_ACl_HUB1_AND_SPOKE1

 set transform-set GOST_ENCRYPT_AND_INTEGRITY

 set security-association lifetime kilobytes 4294967295

 set peer 172.16.1.2

 set dead-connection history off

!

interface GigabitEthernet0/0

 ip address 172.16.100.2 255.255.255.0

 crypto map VPN

!

interface GigabitEthernet0/1

 no ip address

!

interface GigabitEthernet0/1.10

 no ip address

!

interface GigabitEthernet0/2

 no ip address

 shutdown

!

!

ip route 0.0.0.0 0.0.0.0 172.16.100.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

...

AD4F8901771632E0A0AF83

 

quit

!

end

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

#   This is automatically generated LSP

#

#   Conversion Date/Time:   Wed Mar  4 04:31:58 2020

 

GlobalParameters(

    Title                       = "This LSP was automatically generated by CSP Converter at Wed Mar  4 04:31:58 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

        )

)

 

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   = 4294967295

    )

)

 

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

)

 

IPsecAction IPsecAction:VPN:1

(

    TunnelingParameters = TunnelEntry(

        PeerAddress = 172.16.1.2

        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 = 172.16.100.2

        DestinationIP = 172.16.1.2

        ProtocolID = 17

        SourcePort = 50000

        DestinationPort = 50000

        Action = PASS

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

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

    ),

    Filter (

        SourceIP = 172.16.100.2

        DestinationIP = 172.16.1.2

        ProtocolID = 17

        SourcePort = 50001

        DestinationPort = 50001

        Action = PASS

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

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

    )

)

 

NetworkInterface (

    LogicalName = "GigabitEthernet0/0"

    IPsecPolicy = IPsecPolicy:VPN

)

3.    Конфигурация «С-Терра L2».

3.1.      Файл /opt/l2svc/etc/to_spoke1_nvlan.conf:

vif tap0

bridge br0

bridge_ip 192.168.100.1/24

capture eth1

local 172.16.100.2

remote 172.16.1.2

port 50000

mssfix 1400

passtos

3.2.      Файл /opt/l2svc/etc/to_spoke1_vlan10.conf:

vif tap1

bridge br1

bridge_ip 192.168.101.1/24

capture eth1.10

local 172.16.100.2

remote 172.16.1.2

port 50001

mssfix 1400

passtos

Конфигурации криптошлюза 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 secret 5 $6$ERU2T4tE$pkBMDQv/riN3PMxYrd6qksnU2inW9

a.drmpKw8Nh27qsbq/WE4VwZK46v56yFTtZ490gvX4HjdAkvGzGmomqr1

aaa new-model

!

!

hostname Spoke1

enable secret 5 X03MO1qnZdYdgyfeuILPmQ==

!

!

!

!

!

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

 remark VLAN ID 0

 permit udp host 172.16.1.2 eq 50000 host 172.16.100.2 eq 50000

 remark VLAN ID 10

 permit udp host 172.16.1.2 eq 50001 host 172.16.100.2 eq 50001

!

!

crypto map VPN 1 ipsec-isakmp

 match address IPSEC_ACl_HUB1_AND_SPOKE1

 set transform-set GOST_ENCRYPT_AND_INTEGRITY

 set security-association lifetime kilobytes 4294967295

 set peer 172.16.100.2

 set dead-connection history off

!

interface GigabitEthernet0/0

 ip address 172.16.1.2 255.255.255.0

 crypto map VPN

!

interface GigabitEthernet0/1

 no ip address

!

interface GigabitEthernet0/1.10

 no ip address

!

interface GigabitEthernet0/2

 no ip address

 shutdown

!

!

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

...

AD4F8901771632E0A0AF83

 

quit

!

end

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

#   This is automatically generated LSP

#

#   Conversion Date/Time:   Wed Mar  4 14:41:21 2020

 

GlobalParameters(

    Title                       = "This LSP was automatically generated by CSP Converter at Wed Mar  4 14:41:21 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   = 4294967295

    )

)

 

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

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

        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 = 172.16.1.2

        DestinationIP = 172.16.100.2

        ProtocolID = 17

        SourcePort = 50000

        DestinationPort = 50000

        Action = PASS

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

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

    ),

    Filter (

        SourceIP = 172.16.1.2

        DestinationIP = 172.16.100.2

        ProtocolID = 17

        SourcePort = 50001

        DestinationPort = 50001

        Action = PASS

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

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

    )

)

 

NetworkInterface (

    LogicalName = "GigabitEthernet0/0"

    IPsecPolicy = IPsecPolicy:VPN

)

 

3.    Конфигурация «С-Терра L2».

3.1.      Файл /opt/l2svc/etc/to_hub1_nvlan.conf:

vif tap0

bridge br0

bridge_ip 192.168.100.2/24

capture eth1

local 172.16.1.2

remote 172.16.100.2

port 50000

mssfix 1400

passtos

3.2.      Файл /opt/l2svc/etc/to_hub1_vlan10.conf:

vif tap1

bridge br1

bridge_ip 192.168.101.2/24

capture eth1.10

local 172.16.1.2

remote 172.16.100.2

port 50001

mssfix 1400

passtos