Отказоустойчивое решение на базе GRE-туннелей при наличии двух провайдеров

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

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

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

Введение

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

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

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

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

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

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

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

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

Администратор должен обладать обширными знаниями в области сетевой информационной безопасности, иметь опыт работы с аналогичным оборудованием/программным обеспечением, знать и понимать следующие технологии и протоколы: PKI, IPsec, NAT, Firewall, routing, GRE, OSPF, 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) и персональный компьютер (host_behind_hub1).

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

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

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

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

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

2.1. Криптошлюз Hub1 получает доступ к сети Интернет с помощью маршрутизаторов Router1 или Router2. Выбор маршрутизатора для отправки пакетов осуществляется с помощью механизма changeroutes, который будет добавлять маршруты по умолчанию через маршрутизаторы Router1 или Router2 с разными метриками. Для трафика от внешних интерфейсов Hub1 (172.16.100.2 и 172.17.100.2) до Spoke1 (172.16.1.2) используется механизм PBR. С помощью PBR для внешних интерфейсов создается своя таблица маршрутизации, которая содержит маршрут до Spoke1 через своего провайдера.

В данном сценарии настройка changeroutes не описана. Пример настройки changeroutes содержится в инструкции «Резервирование каналов связи и маршрутов при помощи changeroutes».

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

3. GRE-туннелирование.

Два GRE-туннеля строятся между внешними интерфейсами Hub1 (172.16.100.2/24 и 172.17.100.2/24) и внешним интерфейсом Spoke1 (172.16.1.2/24). Внутри GRE-туннелей пропускается защищаемый трафик, а также пакеты динамической маршрутизации OSPF.

4. Динамическая маршрутизация.

Обмен маршрутами до защищаемых подсетей между криптошлюзами центрального офиса и филиала происходит с помощью протокола динамической маршрутизации OSPF. Для того, чтобы обеспечить одновременную работу двух GRE-туннелей, необходимо создать две специальные таблицы маршрутизации. В одной таблице будет задан маршрут до шлюза Spoke1 через провайдера Router1. Во второй таблице будет задан маршрут до шлюза Spoke1 через провайдера Router2. Реализуется данная настройка при помощи технологии PBR, которая позволяет создать две таблицы маршрутизации и внести туда два разных маршрута до устройства Spoke1. Благодаря этому, протокол OSPF дополнит общую таблицу маршрутизации двумя маршрутами с одинаковыми метриками до устройства Spoke1, вследствие чего, автоматически начнёт свою работу технология ECMP, осуществляющий балансировку трафика между двумя маршрутами. По умолчанию, балансировка осуществляется на основании IP адреса получателя и отправителя. В случае сбоя одного из каналов связи обмен маршрутами по GRE-туннелю прекратится и в таблице маршрутизации останется только один маршрут. Как следствие, весь трафик будет направлен через рабочий канал связи. В сценарии, для обеспечения обменов маршрутными правилами между устройствами по протоколу OSPF, использовано свободно распространяемое программное средство FRRouting.

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

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

Инициировать защищенное соединение может как GRE трафик от шлюза центрального офиса (172.16.100.2/24 или 172.17.100.2/24) к шлюзу филиала (172.16.1.2/24), так и наоборот. Пользовательский трафик до защищаемой подсети должен инкапсулироваться в GRE и шифроваться.

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

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

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

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

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

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

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

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

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

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

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

3. Маршрут по умолчанию через 172.16.255.2.

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

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

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

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

3. Маршрут по умолчанию через 172.17.255.2.

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

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

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

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

3. Настройте IP адрес – 172.16.1.1 и маску – 255.255.255.0 на сетевом интерфейсе ens224.

4. Маршрут до сети 172.16.100.0 0.0.0.255 через 172.16.255.1.

5. Маршрут до сети 172.17.100.0 0.0.0.255 через 172.17.255.1.

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

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

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

2. Задайте маршрут по умолчанию через 192.168.100.1.

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

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

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

2. Задайте маршрут по умолчанию через 192.168.1.1.

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

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

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

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

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

Пример описания настройки changeroutes содержится в инструкции «Резервирование каналов связи и маршрутов при помощи changeroutes».

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

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

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

sterragate#configure terminal

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

sterragate(config)#hostname Hub1

Hub1(config)#

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

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

Hub1(config-if-range)#no shutdown

Hub1(config-if-range)#exit

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

Hub1(config)#do show interfaces

GigabitEthernet0/0 is up, line protocol is up

Hardware address is 0050.569e.85be

MTU 1500 bytes

GigabitEthernet0/1 is up, line protocol is up

Hardware address is 0050.569e.865b

MTU 1500 bytes

GigabitEthernet0/2 is up, line protocol is up

Hardware address is 0050.569e.6568

MTU 1500 bytes

...

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

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

Hub1(config)#interface GigabitEthernet 0/0

Hub1(config-if)#ip address 172.16.100.2 255.255.255.0

Hub1(config-if)#exit

Hub1(config)#interface GigabitEthernet 0/1

Hub1(config-if)#ip address 172.17.100.2 255.255.255.0

Hub1(config-if)#exit

Hub1(config)#interface GigabitEthernet 0/2

Hub1(config-if)#ip address 192.168.100.1 255.255.255.0

Hub1(config-if)#exit

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

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

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

Hub1(config)#do ping 172.17.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

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

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 (dead 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, чтобы снизить нагрузку на шлюз (позволяет избежать одновременного массового перестроения IKE 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) для трафика, который нужно защищать между центральным офисом и филиалом:

Hub1(config)#ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1_GRE1

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

Hub1(config-ext-nacl)#exit

Hub1(config)#ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1_GRE2

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

Hub1(config-ext-nacl)#exit

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

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

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

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

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

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

2.3.3 Укажите локальный IP адрес, с которого будет отправляться шифрованные пакеты, для взаимодействия с партнерами. В данном сценарии для VPN_GRE1 локальным IP адресом является IP адрес внешнего интерфейса GigabitEthernet0/0:

Hub1(config-crypto-map)# set local-address 172.16.100.2

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

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

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

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

Hub1(config-crypto-map)#exit

2.4. Создайте крипто-карту для построения туннелей через Router2 (имя VPN_GRE2, раздел 1):

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

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

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

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

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

2.4.3 Укажите локальный IP адрес, с которого будет отправляться шифрованные пакеты, для взаимодействия с партнерами. В данном сценарии для VPN_GRE2 локальным IP адресом является IP адрес внешнего интерфейса GigabitEthernet0/1:

Hub1(config-crypto-map)# set local-address 172.17.100.2

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

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

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

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

Hub1(config-crypto-map)#exit

3. Параметры Firewall:

Списки доступа должны фильтровать незашифрованный GRE-трафик и незашифрованный трафик до защищаемой сети Spoke1.

Hub1(config)#ip access-list extended FIREWALL_ACl_G00

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

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

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

Hub1(config-ext-nacl)#exit

Hub1(config)#ip access-list extended FIREWALL_ACl_G01

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

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

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

Hub1(config-ext-nacl)#exit

3.1. Прикрепите созданные крипто-карты и списки доступа к внешним интерфейсам. VPN_GRE1 для GigabitEthernet0/0, VPN_GRE2 для GigabitEthernet0/1:

Hub1(config)#interface GigabitEthernet0/0

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

Hub1(config-if)# crypto map VPN_GRE1

Hub1(config-if)# exit

Hub1(config)#interface GigabitEthernet0/1

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

Hub1(config-if)# crypto map VPN_GRE2

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

Hub1(config-if)#end

Настройка changeroutes

Для доступа к сети интернет доступны маршрутизаторы Router1 и Router2. В данном сценарии для выбора маршрутизатора используется пакет changeroutes (описание настройки содержится в инструкции «Резервирование каналов связи и маршрутов при помощи changeroutes»). Настройка changeroutes должна происходить до настройки политики обработки СОС (CRL), иначе не удастся загрузить список отозванных сертификатов.

В Приложении представлено содержимое /etc/changeroutes/changeroutes.ini для криптошлюза Hub1.

Настройка политики обработки СОС (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

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

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

administrator@Hub1] system

Entering system shell...

root@Hub1:~#

2. Создайте файл /etc/network/interfaces.d/gre1. Данный файл будет содержать настройки только первого GRE-туннеля. Добавьте в него следующие команды:

auto gre1

iface gre1 inet static

address 10.10.10.0

netmask 255.255.255.254

mtu 1400

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

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

pre-up ip link set gre1 type gre nopmtudisc

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

post-down ip link del gre1

Примечание:

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

address 10.10.10.0 – добавление адреса интерфейса GRE1;

netmask 255.255.255.254 – задание маски интерфейса GRE1;

mtu 1400 – ограничение mtu интерфейса GRE1;

pre-up – указание, что команду нужно выполнить перед тем как поднять интерфейс.

ip tunnel add gre1 mode gre local 172.16.100.2 remote 172.16.1.2 ttl 255 tos inherit – добавление настроек туннеля с указанием локального адреса на интерфейсе и удаленного адреса на интерфейсе устройства, с которым необходимо создать GRE-туннель;

ethtool -K gre1 tx off > /dev/null – отключает проверку контрольной суммы на интерфейсе GRE1;

ip link set gre1 type gre nopmtudisc – отключает механизм Path MTU Discovery для туннеля GRE1;

ip link set gre1 type gre ignore-df – включает сброс DF-флага в заголовке GRE-пакетов, чтобы была возможность фрагментирования пакетов;

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

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

root@Hub1:~# ifup gre1

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

Aug 6 10:25:56 sterrragate ntpdate[2094]: name server cannot be used: Temporary failure in name resolution (-3)

Данное сообщение не влияет на работу FFRouting и его можно проигнорировать.

4. Создайте файл /etc/network/interfaces.d/gre2. Данный файл будет содержать настройки только второго GRE-туннеля. Добавьте в него следующие команды:

auto gre2

iface gre2 inet static

address 10.10.11.0

netmask 255.255.255.254

mtu 1400

pre-up ip tunnel add gre2 mode gre local 172.17.100.2 remote 172.16.1.2 ttl 255 tos inherit

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

pre-up ip link set gre2 type gre nopmtudisc

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

post-down ip link del gre2

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

root@Hub1:~# ifup gre2

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

OSPF настраивается средствами консоли сервиса FRR.

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

root@Hub1:~# systemctl enable frr

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

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

root@Hub1:~# systemctl start frr

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

root@Hub1:~# vtysh

Hello, this is FRRouting (version 7.3).

Hub1#

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

Hub1# configure terminal

Hub1(config)# router ospf

Hub1(config-router)# ospf router-id 172.16.100.2

Hub1(config-router)# passive-interface eth0

Hub1(config-router)# passive-interface eth1

Hub1(config-router)# passive-interface eth2

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

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

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

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

Hub1(config-router)# do write

Hub1(config-router)# end

Hub1# exit

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

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

root@Hub1:~# systemctl restart frr

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

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

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

net.ipv4.igmp_max_memberships=40

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

sysctl -p

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

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

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

Настройка PBR

1. Добавьте PBR политику, для этого создайте файл /etc/network/if-pre-up.d/pbr и добавьте в него следующее содержимое:

#!/bin/bash

WLAN_0_INTERFACE="eth0"

WLAN_1_INTERFACE="eth1"

WLAN_0_IP="172.16.100.2"

WLAN_1_IP="172.17.100.2"

DST_IP="172.16.1.2"

GRE1_TABLE_ID="100"

GRE2_TABLE_ID="101"

PRIO="100"

RULE_WLAN_0="from $WLAN_0_IP to $DST_IP lookup $GRE1_TABLE_ID pref $PRIO"

RULE_WLAN_1="from $WLAN_1_IP to $DST_IP lookup $GRE2_TABLE_ID pref $PRIO"

if [[ $IFACE == $WLAN_0_INTERFACE ]]; then

ip rule del $RULE_WLAN_0 2>/dev/null || true

ip rule add $RULE_WLAN_0

if [[ $IFACE == $WLAN_1_INTERFACE ]]; then

ip rule del $RULE_WLAN_1 2>/dev/null || true

ip rule add $RULE_WLAN_1

exit 0

Файл /etc/network/if-pre-up.d/pbr используется для того, чтобы политики маршрутизации для интерфейсов eth0 и eth1 присутствовали в системе до перехода интерфейсов в состояние UP.

2. В данном файле присутствуют следующие параметры:

· WLAN_0_INTERFACE и WLAN_1_INTERFACE – указывают внешние интерфейсы, с которых должен отправляться трафик;

· WLAN_0_IP и WLAN_1_IP – указывают IP адреса внешних интерфейсов;

· DST_IP – указывает IP адрес внешнего интерфейса партнера;

· GRE1_TABLE_ID и GRE2_TABLE_ID – указывают номер таблицы маршрутизации для пакетов, попавших под правила;

· PRIO – указывает приоритет для заданных правил;

· RULE_WLAN_0 и RULE_WLAN_1– описывают команды, которые будет использованы.

Данный файл будет выполнять следующие команды для добавления политики PBR:

ip rule add from 172.16.100.2 to 172.16.1.2 lookup 100 pref 100;

ip rule add from 172.17.100.2 to 172.16.1.2 lookup 101 pref 100.

Данные правила создают две специальные таблицы маршрутизации. Первая таблица имеет индекс 100, вторая – 101. Для маршрутизации пакетов с IP адресом источника 172.16.100.2 и IP адресом назначения 172.16.1.2 будет использована таблица 100, а для пакетов с IP источника 172.17.100.2 и IP адресом назначения 172.16.1.2 – таблица 101.

3. Добавьте маршрут для политики PBR, для этого создайте файл /etc/network/if-up.d/pbr и добавьте в него следующее содержимое:

#!/bin/bash

WLAN_0_INTERFACE="eth0"

WLAN_1_INTERFACE="eth1"

NEXTHOP_ROUTER_1_ADDRESS="172.16.100.1"

NEXTHOP_ROUTER_2_ADDRESS="172.17.100.1"

DST_NETWORK="172.16.1.2/32"

GRE1_TABLE_ID="100"

GRE2_TABLE_ID="101"

if [[ $IFACE == $WLAN_0_INTERFACE ]]; then

ip route add $DST_NETWORK via "$NEXTHOP_ROUTER_1_ADDRESS" dev "$WLAN_0_INTERFACE" table $GRE1_TABLE_ID

if [[ $IFACE == $WLAN_1_INTERFACE ]]; then

ip route add $DST_NETWORK via "$NEXTHOP_ROUTER_2_ADDRESS" dev "$WLAN_1_INTERFACE" table $GRE2_TABLE_ID

exit 0

Файл /etc/network/if-up.d/pbr используется для того, чтобы маршрут по умолчанию добавлялся в политику PBR после перехода интерфейса eth1 в состояние UP.

В данном файле присутствуют следующие параметры:

· NEXTHOP_ROUTER_1_ADDRESS и NEXTHOP_ROUTER_2_ADDRESS – указывают адрес, на который политика PBR будет маршрутизировать трафик;

· WLAN_0_INTERFACE и WLAN_1_INTERFACE – указывают внешние интерфейсы, c которого доступен адрес, указанный в NEXTHOP_ROUTER_1_ADDRESS и NEXTHOP_ROUTER_2_ADDRESS;

· DST_NETWORK – описывает сеть назначения;

· GRE1_TABLE_ID и GRE1_TABLE_ID – задает номера таблицы маршрутизации.

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

ip route add 172.16.1.2/32 via 172.16.100.1 dev eth0 table 100;

ip route add 172.16.1.2/32 via 172.17.100.1 dev eth1 table 101.

4. После перехода интерфейсов eth0 и eth1 в состояние DOWN требуется удалить политики, созданные модулем PBR. Для этого создайте файл /etc/network/if-post-down.d/pbr и добавьте в него следующее содержимое:

#!/bin/bash

WLAN_0_INTERFACE="eth0"

WLAN_1_INTERFACE="eth1"

WLAN_0_IP="172.16.100.2"

WLAN_1_IP="172.17.100.2"

DST_IP="172.16.1.2"

GRE1_TABLE_ID="100"

GRE2_TABLE_ID="101"

PRIO="100"

RULE_WLAN_0="from $WLAN_0_IP to $DST_IP lookup $GRE1_TABLE_ID pref $PRIO"

RULE_WLAN_1="from $WLAN_1_IP to $DST_IP lookup $GRE2_TABLE_ID pref $PRIO"

if [[ $IFACE == $WLAN_0_INTERFACE ]]; then

ip rule del $RULE_WLAN_0 2>/dev/null || true

if [[ $IFACE == $WLAN_1_INTERFACE ]]; then

ip rule del $RULE_WLAN_1 2>/dev/null || true

exit 0

В данном файле присутствуют следующие параметры:

· WLAN_0_INTERFACE и WLAN_1_INTERFACE – указывают внешние интерфейсы, с которых должен отправляться трафик;

· WLAN_0_IP и WLAN_1_IP – указывают IP адреса внешних интерфейсов;

· DST_IP – указывает IP адрес внешнего интерфейса партнера;

· GRE1_TABLE_ID и GRE2_TABLE_ID – указывают номер таблицы маршрутизации для пакетов попавшие под правила;

· PRIO – указывает приоритет для заданных правил;

· RULE_WLAN_0 и RULE_WLAN_1– описывают команды, которые будет использованы.

Данный файл будет выполнять следующие команды для удаления политики PBR:

ip rule del from 172.16.100.2 to 172.16.1.2 lookup 100 pref 100;

ip rule del from 172.17.100.2 to 172.16.1.2 lookup 101 pref 100.

5. Присвойте созданным файлам права на запуск:

root@Hub1:~# chmod +x /etc/network/if-pre-up.d/pbr

root@Hub1:~# chmod +x /etc/network/if-up.d/pbr

root@Hub1:~# chmod +x /etc/network/if-post-down.d/pbr

6. Перезапустите сервис networking:

Если после начала настройки сетевых интерфейсов шлюз не перезагружался, то перезагрузите его. В таком случае перезапускать сервис networking не требуется.

root@Hub1:~# systemctlrestart networking.service

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

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

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

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

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

[Unit]

After=networking.service

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

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

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

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

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

root@Hub1:~# reboot

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

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

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

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

· содержимое /etc/changeroutes/changeroutes.ini;

· конфигурация frr;

· содержимое /etc/network/if-pre-up.d/pbr;

· содержимое /etc/network/if-up.d/pbr;

· содержимое /etc/network/if-post-down.d/pbr.

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

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

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

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

sterragate#configure terminal

sterragate(config)#hostname Spoke1

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

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

Spoke1(config-if-range)#no shutdown

Spoke1(config-if-range)#exit

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

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

...

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

Spoke1(config)#interface GigabitEthernet 0/0

Spoke1(config-if)#ip address 172.16.1.2 255.255.255.0

Spoke1(config-if)#exit

Spoke1(config)#interface GigabitEthernet 0/1

Spoke1(config-if)#ip address 192.168.1.1 255.255.255.0

Spoke1(config-if)#exit

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

Spoke1(config)#ip route 0.0.0.0 0.0.0.0 172.16.1.1

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

Spoke1(config)#do ping 172.16.1.1

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

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

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

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

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

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

--- 172.16.1.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.271/0.342/0.474/0.072 ms

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

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

Spoke1(config)#crypto isakmp identity dn

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

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

Spoke1(config)#crypto isakmp keepalive 3 2

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

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

Spoke1(config)#crypto isakmp fragmentation

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

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

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

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

Spoke1(config)#crypto isakmp policy 1

Spoke1(config-isakmp)# encryption gost

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

Spoke1(config-isakmp)# authentication gost-sig

Spoke1(config-isakmp)# group vko2

Spoke1(config-isakmp)# exit

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

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

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

Spoke1(cfg-crypto-trans)#exit

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

Spoke1(config)#ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1_GRE1

Spoke1(config-ext-nacl)#permit gre host 172.16.1.2 host 172.16.100.2

Spoke1(config-ext-nacl)#exit

Spoke1(config)#ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1_GRE2

Spoke1(config-ext-nacl)#permit gre host 172.16.1.2 host 172.17.100.2

Spoke1(config-ext-nacl)#exit

Spoke1(config)#

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

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

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

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

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

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

2.3.3 Укажите IP адрес партнера по IPsec, в данном сценарии это внешний IP адрес устройства Hub1 интерфейса eth0(172.16.100.2):

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

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

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

Spoke1(config-crypto-map)#exit

2.4. Добавьте к крипто-карте раздел для туннелей через Router2 (имя VPN_GRE, раздел 2):

Spoke1(config)#crypto map VPN_GRE 2 ipsec-isakmp

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

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

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

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

2.4.3 Укажите IP адрес партнера по IPsec, в данном сценарии это внешний IP адрес устройства Hub1 интерфейса eth1(172.17.100.2):

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

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

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

Spoke1(config-crypto-map)#exit

3. Параметры Firewall:

Списки доступа не должны пропускать фильтровать не шифрованный GRE-трафик и не шифрованный трафик до защищаемой сети Spoke1 не шифрованным.

Spoke1(config)#ip access-list extended FIREWALL_ACl

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

Spoke1(config-ext-nacl)#deny ip any 192.168.100.0 0.0.0.255

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

Spoke1(config-ext-nacl)#exit

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

Spoke1(config)#interface GigabitEthernet0/0

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

Spoke1(config-if)# crypto map VPN_GRE

Spoke1(config-if)# exit

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

Spoke1(config-if)#end

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

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

Spoke1#configure terminal

Spoke1(config)# crypto pki trustpoint s-terra_technological_trustpoint

Spoke1(ca-trustpoint)# revocation-check crl

Spoke1(ca-trustpoint)# revocation-check none

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

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

Spoke1(ca-trustpoint)# crl download time 60

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

Spoke1(ca-trustpoint)#end

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

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

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

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

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

Spoke1#run systemctl restart getcrls.service

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

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

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

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

administrator@Spoke1] system

Entering system shell...

root@Spoke1:~#

auto gre1

iface gre1 inet static

address 10.10.10.1

netmask 255.255.255.254

mtu 1400

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

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

pre-up ip link set gre1 type gre nopmtudisc

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

post-down ip link del gre1

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

root@Spoke1:~# ifup gre1

auto gre2

iface gre2 inet static

address 10.10.11.1

netmask 255.255.255.254

mtu 1400

pre-up ip tunnel add gre2 mode gre local 172.16.1.2 remote 172.17.100.2 ttl 255 tos inherit

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

pre-up ip link set gre2 type gre nopmtudisc

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

post-down ip link del gre2

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

root@Spoke1:~# ifup gre2

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

OSPF настраивается средствами консоли сервиса FRR.

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

root@Spoke1:~# systemctl enable frr

root@Spoke1:~# systemctl start frr

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

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

root@Spoke1:~# vtysh

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

Spoke1# configure terminal

Spoke1(config)# router ospf

Spoke1(config-router)# ospf router-id 172.16.1.2

Spoke1(config-router)# passive-interface eth0

Spoke1(config-router)# passive-interface eth1

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

Spoke1(config-router)# network 10.10.11.0/31 area 0.0.0.0

Spoke1(config-router)# network 192.168.1.0/24 area 0.0.0.0

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

Spoke1(config-router)# do write

Spoke1(config-router)# end

Spoke1# exit

root@Spoke1:~# systemctl restart frr

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

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

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

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

[Unit]

After=networking.service

7. Если класс защиты КС2 или КС3, то после создания файла следует выполнить команду:

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

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

root@Spoke1:~# reboot

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

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

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

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

· конфигурация frr.

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

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

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

1. Проверьте, что с криптошлюза Hub1 доступны маршрутизаторы провайдеров (Router1 и Router2), и с криптошлюза Spoke1 по ICMP доступен шлюз по умолчанию (Router3). Для этого выполните команду 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.297 ms

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

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

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

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

--- 172.16.100.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.275/0.322/0.412/0.051 ms

Hub1#ping 172.17.100.1

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

108 bytes from 172.17.100.1: icmp_seq=1 ttl=64 time=0.433 ms

108 bytes from 172.17.100.1: icmp_seq=2 ttl=64 time=0.451 ms

108 bytes from 172.17.100.1: icmp_seq=3 ttl=64 time=0.412 ms

108 bytes from 172.17.100.1: icmp_seq=4 ttl=64 time=0.331 ms

108 bytes from 172.17.100.1: icmp_seq=5 ttl=64 time=0.653 ms

--- 172.17.100.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.331/0.456/0.653/0.106 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.192 ms

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

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

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

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

--- 172.16.1.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.192/0.307/0.417/0.078 ms

Вывод команды свидетельствует о том, что устройства Router1 и Router2 доступны по ICMP с Hub1, а устройство Router3 доступно по ICMP со Spoke1.

2. Убедитесь в том, что с защищаемых устройств Host_behind_spoke1 и Host_behind_hub1 доступен по протоколу ICMP криптошлюз, являющийся шлюзом по умолчанию для данной рабочей станции. Для этого выполните команду ping из linux bash защищаемых устройств.

root@Host_b_hub1:~# ping 192.168.100.1 -c 5

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

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

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

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

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

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

--- 192.168.100.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.211/0.231/0.254/0.017 ms

root@Host_b_spoke1:~# ping 192.168.1.1 -c 5

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

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

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

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

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

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

--- 192.168.1.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.189/0.209/0.223/0.019 ms

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

3. Убедитесь в том, что с криптошлюза Spoke1 доступны интерфейсы провайдеров Router1 и Router2 направленные в сторону Hub1 (172.16.100.1/24 и 172.17.100.1/24). Для этого выполните команду ping из cisco-like консоли криптошлюза Spoke1.

Spoke1#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=63 time=0.384 ms

108 bytes from 172.16.100.1: icmp_seq=2 ttl=63 time=0.477 ms

108 bytes from 172.16.100.1: icmp_seq=3 ttl=63 time=0.526 ms

108 bytes from 172.16.100.1: icmp_seq=4 ttl=63 time=0.524 ms

108 bytes from 172.16.100.1: icmp_seq=5 ttl=63 time=0.668 ms

--- 172.16.100.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.384/0.515/0.668/0.096 ms

Spoke1#ping 172.17.100.1

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

108 bytes from 172.17.100.1: icmp_seq=1 ttl=63 time=0.459 ms

108 bytes from 172.17.100.1: icmp_seq=2 ttl=63 time=0.583 ms

108 bytes from 172.17.100.1: icmp_seq=3 ttl=63 time=0.498 ms

108 bytes from 172.17.100.1: icmp_seq=4 ttl=63 time=0.632 ms

108 bytes from 172.17.100.1: icmp_seq=5 ttl=63 time=0.413 ms

--- 172.17.100.1 ping statistics ---

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

rtt min/avg/max/mdev = 0.413/0.517/0.632/0.080 ms

Вывод консоли свидетельствует о том, что со Spoke1 доступны интерфейсы провайдеров Router1 и Router2 направленные в сторону Hub1 (172.16.100.1/24 и 172.17.100.1/24).

Проверка работы PBR

1. Убедитесь в том, что база маршрутных политик Hub1 содержит правила для пакетов, отправленных с интерфейсов 172.16.100.2 и 172.17.100.2, и применяется таблица маршрутизации 100 и 101 соответственно. Для этого выполните команду run ip rule show из cisco-like консоли криптошлюза Hub1.

Hub1#run ip rule show

0: from all lookup local

100: from 172.16.100.2 to 172.16.1.2 lookup 100

100: from 172.17.100.2 to 172.16.1.2 lookup 101

32766: from all lookup main

32767: from all lookup default

Вывод команды свидетельствует о том, что на криптошлюзе Hub1 есть правила с приоритетом 100 для пакетов с IP назначения 172.16.1.2 и с IP источника 172.16.100.2 и 172.17.100.2 применять таблицу маршрутизации 100 и 101 соответственно.

2. Убедитесь в том, что таблицы содержат маршруты до внешнего интерфейса Spoke1, проходящие через маршрутизаторы соответствующих провайдеров. Для этого выполните команду run ip route show table с номерами таблиц из cisco-like консоли криптошлюза Hub1.

Hub1#run ip route show table 100

172.16.1.2 via 172.16.100.1 dev eth0

Hub1#run ip route show table 101

172.16.1.2 via 172.17.100.1 dev eth0

Вывод команды свидетельствует о том, что таблица маршрутизации 100, применяемой для пакетов, исходящих из 172.16.100.2, содержит маршрут до 172.16.1.2 через 172.16.100.1. А таблица маршрутизации 101, применяемой для пакетов, исходящих из 172.17.100.2, содержит маршрут до 172.16.1.2 через 172.17.100.1.

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

Spoke1#ping 172.16.100.2

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

108 bytes from 172.16.100.2: icmp_seq=1 ttl=62 time=0.715 ms

108 bytes from 172.16.100.2: icmp_seq=2 ttl=62 time=1.03 ms

108 bytes from 172.16.100.2: icmp_seq=3 ttl=62 time=0.987 ms

108 bytes from 172.16.100.2: icmp_seq=4 ttl=62 time=1.06 ms

108 bytes from 172.16.100.2: icmp_seq=5 ttl=62 time=0.989 ms

--- 172.16.100.2 ping statistics ---

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

rtt min/avg/max/mdev = 0.715/0.957/1.064/0.124 ms

Spoke1#ping 172.17.100.2

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

108 bytes from 172.17.100.2: icmp_seq=1 ttl=62 time=0.897 ms

108 bytes from 172.17.100.2: icmp_seq=2 ttl=62 time=0.781 ms

108 bytes from 172.17.100.2: icmp_seq=3 ttl=62 time=0.903 ms

108 bytes from 172.17.100.2: icmp_seq=4 ttl=62 time=0.919 ms

108 bytes from 172.17.100.2: icmp_seq=5 ttl=62 time=1.06 ms

--- 172.17.100.2 ping statistics ---

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

rtt min/avg/max/mdev = 0.781/0.912/1.062/0.093 ms

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

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

1. Убедитесь в том, что на криптошлюзах Hub1 и Spoke1 имеются маршруты до защищаемой подсети соседа, полученные по протоколу OSPF.

Hub1#run ip route show

default via 172.16.100.1 dev eth0 proto changeroutes

default via 172.17.100.1 dev eth1 proto changeroutes metric 100

10.10.10.0/31 dev gre1 proto kernel scope link src 10.10.10.0

10.10.11.0/31 dev gre2 proto kernel scope link src 10.10.11.0

172.16.100.0/24 dev eth0 proto kernel scope link src 172.16.100.2

172.17.100.0/24 dev eth1 proto kernel scope link src 172.17.100.2

192.168.1.0/24 proto ospf metric 20

nexthop via 10.10.10.1 dev gre1 weight 1

nexthop via 10.10.11.1 dev gre2 weight 1

192.168.100.0/24 dev eth2 proto kernel scope link src 192.168.100.1

Spoke1#run ip route show

default via 172.16.1.1 dev eth0

10.10.10.0/31 dev gre1 proto kernel scope link src 10.10.10.1

10.10.11.0/31 dev gre2 proto kernel scope link src 10.10.11.1

172.16.1.0/24 dev eth0 proto kernel scope link src 172.16.1.2

192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1

192.168.100.0/24 proto ospf metric 20

nexthop via 10.10.10.0 dev gre1 weight 1

nexthop via 10.10.11.0 dev gre2 weight 1

Вывод команды свидетельствует о том, что на криптошлюзе Hub1 есть маршруты до 192.168.1.0/24 полученные по OSPF и на криптошлюзе Spoke1 есть маршруты до 192.168.100.0/24 полученные по OSPF. Если этого не произошло проверьте настройки FRR

2. Инициируйте построение защищенного соединения между криптошлюзами Hub1 и Spoke1 для этого потребуется отправить несколько пакетов с устройства Host_behind_spoke1 на Host_behind_hub1. (можно и наоборот). В рамках сценария использован протокол ICMPДля этого выполните команду ping из linux bash защищаемого устройства Host_behind_spoke1.

root@Host_b_spoke1:~# ping 192.168.100.100 -c 5

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

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

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

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

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

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

--- 192.168.100.100 ping statistics ---

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

rtt min/avg/max/mdev = 1.441/1.836/2.099/0.220 ms

3. Убедитесь в том, что на криптошлюзах Hub1 и Spoke1 успешно создан IPsec SA. Для этого выполните команду 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 4 (172.16.100.2,500)-(172.16.1.2,500) active 2388 2284

2 5 (172.17.100.2,500)-(172.16.1.2,500) active 1856 2000

IPsec connections:

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

1 7 (172.16.100.2,*)-(172.16.1.2,*) 47 ESP tunn 480 1040

2 8 (172.17.100.2,*)-(172.16.1.2,*) 47 ESP tunn 944 480

Spoke1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

1 4 (172.16.1.2,500)-(172.16.100.2,500) active 2384 2488

2 5 (172.16.1.2,500)-(172.17.100.2,500) active 2000 1856

IPsec connections:

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

1 7 (172.16.1.2,*)-(172.16.100.2,*) 47 ESP tunn 1424 864

2 8 (172.16.1.2,*)-(172.17.100.2,*) 47 ESP tunn 864 1328

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

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

1. Создайте на host_behind_hub1 вторичные IP адреса из сети 192.168.100.0/24. Для этого измените файл /etc/network/interfaces на host_behind_hub1 и перезапустите сервис networking:

# This file describes the network interfaces available on your system

# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

auto lo

iface lo inet loopback

auto ens160

iface ens160 inet static

address 192.168.100.100

netmask 255.255.255.0

gateway 192.168.100.1

auto ens160:0

iface ens160:0 inet static

address 192.168.100.101

netmask 255.255.255.0

gateway 192.168.100.1

auto ens160:1

iface ens160:1 inet static

address 192.168.100.102

netmask 255.255.255.0

gateway 192.168.100.1

auto ens160:2

iface ens160:2 inet static

address 192.168.100.103

netmask 255.255.255.0

gateway 192.168.100.1

auto ens160:3

iface ens160:3 inet static

address 192.168.100.104

netmask 255.255.255.0

gateway 192.168.100.1

2. При помощи ICMP трафика, посылаемого с устройства host_behind_spoke1 на IP адреса host_behind_hub1, проанализируйте сетевой трафик в GRE-туннелях. Для этого на криптошлюзе Spoke1 с помощью tcpdump перехватите пакеты с интерфейсов GRE1 и GRE2:

Spoke1#run tcpdump -i gre1 -c 5 src 192.168.1.100

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on gre1, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

13:18:17.937476 IP 192.168.1.100 > 192.168.100.100: ICMP echo request, id 985, seq 43576

13:18:17.937490 IP 192.168.1.100 > 192.168.100.104: ICMP echo request, id 989, seq 25097

13:18:17.937498 IP 192.168.1.100 > 192.168.100.103: ICMP echo request, id 988, seq 30495

13:18:17.939141 IP 192.168.1.100 > 192.168.100.100: ICMP echo request, id 985, seq 43577

13:18:17.939160 IP 192.168.1.100 > 192.168.100.104: ICMP echo request, id 989, seq 25098

5 packets captured

7 packets received by filter

0 packets dropped by kernel

Spoke1# run tcpdump -i gre1 -c 5 dst 192.168.1.100

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on gre1, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

13:18:24.937438 IP 192.168.100.102 > 192.168.1.100: ICMP echo reply, id 987, seq 39232,

13:18:24.938215 IP 192.168.100.104 > 192.168.1.100: ICMP echo reply, id 989, seq 31508,

13:18:24.939151 IP 192.168.100.102 > 192.168.1.100: ICMP echo reply, id 987, seq 39233,

13:18:24.939634 IP 192.168.100.104 > 192.168.1.100: ICMP echo reply, id 989, seq 31509,

13:18:24.940609 IP 192.168.100.102 > 192.168.1.100: ICMP echo reply, id 987, seq 39234,

5 packets captured

5 packets received by filter

0 packets dropped by kernel

Spoke1#run tcpdump -i gre2 -c 5 src 192.168.1.100

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on gre2, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

13:18:30.285790 IP 192.168.1.100 > 192.168.100.102: ICMP echo request, id 987, seq 44200

13:18:30.285797 IP 192.168.1.100 > 192.168.100.101: ICMP echo request, id 986, seq 47882

13:18:30.287592 IP 192.168.1.100 > 192.168.100.102: ICMP echo request, id 987, seq 44201

13:18:30.287627 IP 192.168.1.100 > 192.168.100.101: ICMP echo request, id 986, seq 47883

13:18:30.288838 IP 192.168.1.100 > 192.168.100.101: ICMP echo request, id 986, seq 47884

5 packets captured

5 packets received by filter

0 packets dropped by kernel

Spoke1# run tcpdump -i gre2 -c 5 dst 192.168.1.100

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on gre2, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

13:18:34.609100 IP 192.168.100.100 > 192.168.1.100: ICMP echo reply, id 985, seq 59019,

13:18:34.609500 IP 192.168.100.103 > 192.168.1.100: ICMP echo reply, id 988, seq 45985,

13:18:34.609587 IP 192.168.100.101 > 192.168.1.100: ICMP echo reply, id 986, seq 51878,

13:18:34.610752 IP 192.168.100.100 > 192.168.1.100: ICMP echo reply, id 985, seq 59020,

13:18:34.610775 IP 192.168.100.103 > 192.168.1.100: ICMP echo reply, id 988, seq 45986,

5 packets captured

9 packets received by filter

0 packets dropped by kernel

Видно, что через GRE1-туннель проходят запросы до 192.168.100.100, 192.168.100.104 и 192.168.100.103, а также ответы от 192.168.100.102 и 192.168.100.104. Через GRE2-туннель проходят запросы до 192.168.100.101 и 192.168.100.102, а также ответы от 192.168.100.100, 192.168.100.101 и 192.168.100.103. Такое поведение не постоянно и возможны случаи, когда у одного из криптошлюзов трафик уходит по обоим GRE-туннелям, но у криптошлюза партнера трафик отсылает только по одному GRE-туннелю.

Приложение

Конфигурации криптошлюза 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$tHtq8SR6$t3CWE6udI6L/ARr9jQowUYR7wEbOWZlx61OvL

i7goonOFUYhNSGV49BA.RDGEZ7oKXBA1aTRi20ElR4wtMXTl0

aaa new-model

hostname Hub1

enable secret 5 PC9d7N5HlAyLrzuA3qRJvQ==

crypto isakmp policy 1

encr gost

hash gost341112-256-tc26

authentication gost-sig

group vko2

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

ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1_GRE1

permit gre host 172.16.100.2 host 172.16.1.2

ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1_GRE2

permit gre host 172.17.100.2 host 172.16.1.2

ip access-list extended FIREWALL_ACl_G00

deny gre any any

deny ip any 192.168.1.0 0.0.0.255

permit ip any any

ip access-list extended FIREWALL_ACl_G01

deny gre any any

deny ip any 192.168.1.0 0.0.0.255

permit ip any any

crypto map VPN_GRE1 1 ipsec-isakmp

match address IPSEC_ACl_HUB1_AND_SPOKE1_GRE1

set transform-set GOST_ENCRYPT_AND_INTEGRITY

set local-address 172.16.100.2

set peer 172.16.1.2

set dead-connection history off

crypto map VPN_GRE2 1 ipsec-isakmp

match address IPSEC_ACl_HUB1_AND_SPOKE1_GRE2

set transform-set GOST_ENCRYPT_AND_INTEGRITY

set local-address 172.17.100.2

set peer 172.16.1.2

set dead-connection history off

interface GigabitEthernet0/0

ip address 172.16.100.2 255.255.255.0

ip access-group FIREWALL_ACl_G00 out

crypto map VPN_GRE1

interface GigabitEthernet0/1

ip address 172.17.100.2 255.255.255.0

ip access-group FIREWALL_ACl_G01 out

crypto map VPN_GRE2

interface GigabitEthernet0/2

ip address 192.168.100.1 255.255.255.0

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

...

AD4F8901771632E0A0AF83

quit

end

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

auto gre1

iface gre1 inet static

address 10.10.10.0

netmask 255.255.255.254

mtu 1400

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

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

pre-up ip link set gre1 type gre nopmtudisc

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

post-down ip link del gre1

3. Содержимое /etc/network/interfaces.d/gre2:

auto gre2

iface gre2 inet static

address 10.10.11.0

netmask 255.255.255.254

mtu 1400

pre-up ip tunnel add gre2 mode gre local 172.17.100.2 remote 172.16.1.2 ttl 255 tos inherit

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

pre-up ip link set gre2 type gre nopmtudisc

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

post-down ip link del gre2

4. Cодержимое /etc/changeroutes/changeroutes.ini:

IP_HOSTS="172.16.101.15"

RESERVE_ROUTES="0.0.0.0/0"

WATCH_RESERVE_ROUTES="true"

MAIN_INTERFACE="eth0"

MAIN_INTERFACE_DHCP="false"

BACKUP_INTERFACE="eth1"

BACKUP_INTERFACE_DHCP="false"

MAIN_GATEWAY="172.16.100.1"

BACKUP_GATEWAY="172.17.100.1"

RPF_STRICT_MODE="true"

FAILURE_PING_COUNT="10"

PING_INTERVAL="3"

RESTORE_PING_COUNT="10"

RESTORE_PING_INTERVAL="1"

DEBUG="false"

5. Конфигурации frr:

frr version 7.3

frr defaults traditional

hostname Hub1

log syslog informational

service integrated-vtysh-config

router ospf

ospf router-id 172.16.100.2

passive-interface eth0

passive-interface eth1

passive-interface eth2

network 10.10.10.0/31 area 0.0.0.0

network 10.10.11.0/31 area 0.0.0.0

network 192.168.100.0/24 area 0.0.0.0

line vty

6. Содержимое /etc/network/if-pre-up.d/pbr:

#!/bin/bash

WLAN_0_INTERFACE="eth0"

WLAN_1_INTERFACE="eth1"

WLAN_0_IP="172.16.100.2"

WLAN_1_IP="172.17.100.2"

DST_IP="172.16.1.2"

GRE1_TABLE_ID="100"

GRE2_TABLE_ID="101"

PRIO="100"

RULE_WLAN_0="from $WLAN_0_IP to $DST_IP lookup $GRE1_TABLE_ID pref $PRIO"

RULE_WLAN_1="from $WLAN_1_IP to $DST_IP lookup $GRE2_TABLE_ID pref $PRIO"

if [[ $IFACE == $WLAN_0_INTERFACE ]]; then

ip rule del $RULE_WLAN_0 2>/dev/null || true

ip rule add $RULE_WLAN_0

if [[ $IFACE == $WLAN_1_INTERFACE ]]; then

ip rule del $RULE_WLAN_1 2>/dev/null || true

ip rule add $RULE_WLAN_1

exit 0

7. Содержимое /etc/network/if-up.d/pbr:

#!/bin/bash

WLAN_0_INTERFACE="eth0"

WLAN_1_INTERFACE="eth1"

NEXTHOP_ROUTER_1_ADDRESS="172.16.100.1"

NEXTHOP_ROUTER_2_ADDRESS="172.17.100.1"

GRE1_TABLE_ID="100"

GRE2_TABLE_ID="101"

if [[ $IFACE == $WLAN_0_INTERFACE ]]; then

ip route add 172.16.1.2/32 via "$NEXTHOP_ROUTER_1_ADDRESS" dev "$WLAN_0_INTERFACE" table $GRE1_TABLE_ID

if [[ $IFACE == $WLAN_1_INTERFACE ]]; then

ip route add 172.16.1.2/32 via "$NEXTHOP_ROUTER_2_ADDRESS" dev "$WLAN_1_INTERFACE" table $GRE2_TABLE_ID

exit 0

8. Содержимое /etc/network/if-post-down.d/pbr:

#!/bin/bash

WLAN_0_INTERFACE="eth0"

WLAN_1_INTERFACE="eth1"

WLAN_0_IP="172.16.100.2"

WLAN_1_IP="172.17.100.2"

DST_IP="172.16.1.2"

GRE1_TABLE_ID="100"

GRE2_TABLE_ID="101"

PRIO="100"

RULE_WLAN_0="from $WLAN_0_IP to $DST_IP lookup $GRE1_TABLE_ID pref $PRIO"

RULE_WLAN_1="from $WLAN_1_IP to $DST_IP lookup $GRE2_TABLE_ID pref $PRIO"

if [[ $IFACE == $WLAN_0_INTERFACE ]]; then

ip rule del $RULE_WLAN_0 2>/dev/null || true

if [[ $IFACE == $WLAN_1_INTERFACE ]]; then

ip rule del $RULE_WLAN_1 2>/dev/null || true

exit 0

Конфигурации криптошлюза 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$tHtq8SR6$t3CWE6udI6L/ARr9jQowUYR7wEbOWZlx61OvL

i7goonOFUYhNSGV49BA.RDGEZ7oKXBA1aTRi20ElR4wtMXTl0

aaa new-model

hostname Spoke1

enable secret 5 PC9d7N5HlAyLrzuA3qRJvQ==

crypto isakmp policy 1

encr gost

hash gost341112-256-tc26

authentication gost-sig

group vko2

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

ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1_GRE1

permit gre host 172.16.1.2 host 172.16.100.2

ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1_GRE2

permit gre host 172.16.1.2 host 172.17.100.2

ip access-list extended FIREWALL_ACl

deny gre any any

deny ip any 192.168.100.0 0.0.0.255

permit ip any any

crypto map VPN_GRE 1 ipsec-isakmp

match address IPSEC_ACl_HUB1_AND_SPOKE1_GRE1

set transform-set GOST_ENCRYPT_AND_INTEGRITY

set peer 172.16.100.2

set dead-connection history off

crypto map VPN_GRE 2 ipsec-isakmp

match address IPSEC_ACl_HUB1_AND_SPOKE1_GRE2

set transform-set GOST_ENCRYPT_AND_INTEGRITY

set peer 172.17.100.2

set dead-connection history off

interface GigabitEthernet0/0

ip address 172.16.1.2 255.255.255.0

ip access-group FIREWALL_ACl out

crypto map VPN_GRE

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

...

AD4F8901771632E0A0AF83

quit

end

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

auto gre1

iface gre1 inet static

address 10.10.10.1

netmask 255.255.255.254

mtu 1400

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

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

pre-up ip link set gre1 type gre nopmtudisc

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

post-down ip link del gre1

3. Содержимое /etc/network/interfaces.d/gre2:

auto gre2

iface gre2 inet static

address 10.10.11.1

netmask 255.255.255.254

mtu 1400

pre-up ip tunnel add gre2 mode gre local 172.16.1.2 remote 172.17.100.2 ttl 255 tos inherit

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

pre-up ip link set gre2 type gre nopmtudisc

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

post-down ip link del gre2

4. Конфигурация frr:

frr version 7.3

frr defaults traditional

hostname Spoke1

log syslog informational

service integrated-vtysh-config

router ospf

ospf router-id 172.16.1.2

passive-interface eth0

passive-interface eth1

network 10.10.10.0/31 area 0.0.0.0

network 10.10.11.0/31 area 0.0.0.0

network 192.168.1.0/24 area 0.0.0.0

line vty