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

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

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

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

sterra_l2_4.3.23255.amd64.rar

Дополнительные файлы:

keepalived_2.0.18.3_sterra-7_amd64.rar

Введение

Данный сценарий содержит пример настойки отказоустойчивого кластера из С-Терра Шлюзов посредством Cisco-like консоли с безопасным взаимодействием между центральным офисом и филиалом на уровне 2 модели OSI (L2 VPN).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. L2 VPN.

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

Узнать о принципах его работы можно из раздела «Общая логика работы» пункта 3 сценария «Построение L2 VPN туннеля при помощи программного модуля «С-Терра L2»».

Сервис l2svc, отвечающий за инкапсуляцию фреймов, активен только на ноде, которая находится в состоянии Master.

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

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

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

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

Нода, находящаяся в состоянии Master, владеет VIP адресами в доверенном (соединение с подсетью 192.168.254.0/24) и недоверенном сегментах и обрабатывает трафик. Нода, находящаяся в состоянии Backup или Fault, не владеет VIP адресами.

По умолчанию все VRRP интерфейсы синхронизированы в группу номер ноль. Соответственно, одновременно меняют свое состояние (данное поведение отличается от Cisco IOS, где по умолчанию VRRP интерфейсы не синхронизированы). Также в данном сценарии интерфейс GigabitEthernet0/1 (интерфейс L2) настроен как трэк-интерфейс, что позволяет следить за его состоянием и в зависимости от него менять состояние ноды.

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

При переходе ноды в состояния Master происходят следующие действия:

· удаляется резервный маршрут по умолчанию через Master ноду (через интерфейс с подсетью 192.168.254.0/24);

· добавляется маршрут по умолчанию (команда vrrp ip route … в cisco-like консоли) через маршрутизатор Router1;

· запускается сервис l2svc, который захватывает фреймы канального уровня, приходящие на интерфейс Gi0/1, и инкапсулирует их в пакеты сетевого уровня.

При переходе ноды в состояния Backup или Fault происходят следующие действия:

· удаляется маршрут по умолчанию (команда vrrp ip route … в cisco-like консоли) через маршрутизатор Router1;

· останавливается сервис l2svc;

· добавляется резервный маршрут по умолчанию через Master ноду (через интерфейс с подсетью 192.168.254.0/24).

Для корректной работы интерфейсы Gi0/2 криптошлюзов Hub1-n1 и Hub1-n2 должны быть соединены через коммутатор (не прямым соединением). В противном случае при выключении одной из нод вторая будет переходить в состояние Fault, так как криптошлюз будет детектировать отсутствие несущей в канале и отключать интерфейс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· все пакеты, которые должны шифроваться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S-Terra administrative console

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

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

administrator's password:

administrator@sterragate]

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

administrator@sterragate] terminal terminal-type xterm

administrator@sterragate] terminal width 150

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

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

administrator@sterragate] system

Entering system shell...

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

root@sterragate:~# dpkg-reconfigure tzdata

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

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

Thu Jul 4 12:32:00 MSK 2019

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

root@sterragate:~# passwd

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

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

root@sterragate:~# exit

logout

Leaving system shell...

administrator@sterragate]

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

Обновление пакета keepalived

1. Перейдите в linux bash (команда system в консоли разграничения доступа S-Terra administrative console):

administrator@sterragate] system

Entering system shell...

2. Проверьте текущую версию пакета keepalived:

root@sterragate:~# dpkg -l | grep keepalived

ii keepalived 1:2.0.18.2~sterra-4 amd64 Failover and monitoring daemon for LVS clusters

Если версия 2.0.18.2~sterra-4, то требуется обновить пакет keepalived, реализующий протокол VRRP, до версии keepalived_2.0.18.3~sterra-7 (получить пакет можно на портале документации http://doc.s-terra.ru ->Типовые сценарии применения -> Версия 4.3 -> С-Терра L2).

3. Загрузите пакет keepalived_2.0.18.3~sterra-7 в директорию /root:

Если сеть еще не настроена, то доставить пакет на шлюз можно при помощи USB Flash накопителя. При подключении USB Flash накопителя он будет автоматически смонтирован в директорию /media/<ID>.

Пакет keepalived_2.0.18.3~sterra-7 уже содержит в себе все необходимое для успешной установки на криптошлюзы классов KC2/KC3, а также СофтМДЗ KC1/KC2/KC3 (за исключением пересчета хешей в АПМДЗ), поэтому процедура обновления для всех классов СКЗИ одинакова.

4. Обновите пакет:

root@sterragate:~# dpkg -i keepalived_2.0.18.3~sterra-7_amd64.deb

(Reading database ... 24998 files and directories currently installed.)

Preparing to unpack keepalived_2.0.18.3~sterra-7_amd64.deb ...

Unpacking keepalived (1:2.0.18.3~sterra-7) over (1:2.0.18.2~sterra-4) ...

Setting up keepalived (1:2.0.18.3~sterra-7) ...

Installing new version of config file /etc/keepalived/notify_common.conf ...

Installing new version of config file /etc/keepalived/scripts/notify_common ...

Reloading systemd configuration...

Processing triggers for dbus (1.10.28-0+deb9u1) ...

Processing triggers for man-db (2.7.6.1-2) ...

Выше представлен пример вывода обновления пакета для класса КС1. Для классов KC2/КС3 вывод будет отличаться.

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

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

Configuration file '/etc/keepalived/notify_common.conf'

==> Modified (by you or by a script) since installation.

==> Package distributor has shipped an updated version.

What would you like to do about it ? Your options are:

Y or I : install the package maintainer's version

N or O : keep your currently-installed version

D : show the differences between the versions

Z : start a shell to examine the situation

The default action is to keep your current version.

*** notify_common.conf (Y/I/N/O/D/Z) [default=N] ? Y

Configuration file '/etc/keepalived/scripts/notify_common'

==> Modified (by you or by a script) since installation.

==> Package distributor has shipped an updated version.

What would you like to do about it ? Your options are:

Y or I : install the package maintainer's version

N or O : keep your currently-installed version

D : show the differences between the versions

Z : start a shell to examine the situation

The default action is to keep your current version.

*** notify_common (Y/I/N/O/D/Z) [default=N] ? Y

В результате обновления статус автозагрузки сервиса сохраняется, а сам сервис будет остановлен.

5. Перейдите обратно в консоль разграничения доступа S-Terra administrative console:

root@sterragate:~# exit

logout

Leaving system shell...

administrator@sterragate]

Если у Вас «С-Терра Шлюз» с АПМДЗ, то не забудьте после обновления пакета пересчитать хеш суммы. Описание процедуры смотрите в документации производителя АПМДЗ.

Обновление пакета L2

1. Перейдите в linux bash (команда system в консоли разграничения доступа S-Terra administrative console):

administrator@sterragate] system

Entering system shell...

2. Проверьте текущую версию пакета sterra-l2:

root@sterragate:~# dpkg -l | grep sterra-l2

ii sterra-l2 4.3.21755 amd64 S-Terra level 2 tunneling utility

Если версия ниже 4.3.23255, то требуется обновить пакет sterra-l2 (получить пакет можно на портале документации http://doc.s-terra.ru -> Типовые сценарии применения -> Версия 4.3 -> С-Терра L2).

3. Загрузите пакет sterra_l2_4.3.23255 в директорию /root:

Пакет sterra_l2_4.3.23255 уже содержит в себе все необходимое для успешной установки на криптошлюзы классов KC2/KC3, а также СофтМДЗ KC1/KC2/KC3 (за исключением пересчета хешей в АПМДЗ), поэтому процедура обновления для всех классов СКЗИ одинакова.

4. Обновите пакет:

root@sterragate:~# dpkg -i sterra_l2_4.3.23255.amd64.deb

(Reading database ... 24998 files and directories currently installed.)

Preparing to unpack sterra_l2_4.3.23255.amd64.deb ...

Removing S-Terra L2...

Removed /etc/systemd/system/default.target.wants/l2svc.service.

Unpacking sterra-l2 (4.3.23255) over (4.3.21755) ...

Setting up sterra-l2 (4.3.23255) ...

Installing new version of config file /opt/l2svc/etc/global.cfg ...

Reloading systemd configuration...

Выше представлен пример вывода обновления пакета для класса КС1. Для классов KC2/КС3 вывод будет отличаться.

5. Перейдите обратно в консоль разграничения доступа S-Terra administrative console:

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 983CC3F93CC3D104

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

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

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

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

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

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

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

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

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

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

Press key: U

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

administrator@sterragate] dir media:983CC3F93CC3D104/

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

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

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

administrator@sterragate] run umount /media/983CC3F93CC3D104

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

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

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

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

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

administrator@sterragate] dir media:983CC3F93CC3D104/

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

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

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

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

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

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

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

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

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

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

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

administrator@sterragate] run cert_mgr show

Found 2 certificates. No CRLs found.

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

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

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

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

administrator@sterragate] run cert_mgr check

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

Certificate can not be verified.

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

Certificate can not be verified.

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

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

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

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

administrator@sterragate] configure

sterragate login: cscons

Password:

S-Terra Gate 4.3.XXXXX (amd64)

sterragate#

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

sterragate#configure terminal

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

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

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

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

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

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

sterragate(config)#hostname Hub1-n1

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

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

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

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

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

Hub1-n1(config)#do show interfaces

GigabitEthernet0/0 is up, line protocol is up

Hardware address is 0050.569e.b06d

MTU 1500 bytes

GigabitEthernet0/1 is up, line protocol is up

Hardware address is 0050.569e.d3c3

MTU 1500 bytes

GigabitEthernet0/2 is up, line protocol is up

Hardware address is 0050.569e.8995

MTU 1500 bytes

...

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

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

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

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

Hub1-n1(config-if)#exit

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

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

Hub1-n1(config-if)#exit

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

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

Hub1-n1(config)#do ping 172.16.100.1

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

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

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

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

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

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

--- 172.16.100.1 ping statistics ---

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

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

Hub1-n1(config)#end

Настройка L2

Настройка L2 должна происходить перед настройкой keepalived. Сервис l2vpn запускается и останавливается при помощи keepalived и поэтому не должен быть ни запущен, ни поставлен в автозагрузку.

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

Hub1-n1#exit

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

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

[license]

CustomerCode=XXXXX

ProductCode=L2VPN

LicenseNumber=XXXXX

LicenseCode=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

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

root@Hub1-n1:~# vim.tiny /opt/l2svc/etc/to_spoke1.conf

vif tap0

bridge br0

group_fwd_mask 16388

capture eth1

local 172.16.100.100

remote 172.16.1.2

port 50000

mssfix 1400

passtos

Настройка VRRP

Настройка VRRP состоит из двух этапов. Первый этап - подготовка конфигурационного файла /etc/keepalived/notify_common.conf, который отвечает за управление скриптом /etc/keepalived/scripts/notify_common. Второй этап - настройка VRRP из cisco-like консоли.

1. Приведите файл /etc/keepalived/notify_common.conf к виду:

Настройка данного конфигурационного файла требуется для того, чтобы резервная нода, находящаяся в состояниях Backup или Fault, имела доступ до заданной подсети (в данном сценарии в Интернет) через активную ноду. А также, чтобы сервис l2svc на резервной ноде не перехватывал трафик, предназначенный активной ноде.

root@Hub1-n1:~# vim.tiny /etc/keepalived/notify_common.conf

FLAG_MANAGE_ROUTES="true"

RESERVE_ROUTES="0.0.0.0/0"

RESERVE_NEXTHOP="192.168.254.100"

RESERVE_METRIC="1"

FLAG_MANAGE_SERVICES="true"

SERVICES_LIST="l2svc"

При изменении данных параметров на уже работающей ноде кластера нужно перезапускать сервис keepalived для применения изменений:
root@Hub1-n1:~# systemctl restart keepalived.service

Описание параметров:

· FLAG_MANAGE_ROUTES - флаг, который отвечает за управление резервными маршрутами, заданными в переменной RESERVE_ROUTES. Если флаг имеет значение true, то маршруты, заданные в переменной RESERVE_ROUTES, будут добавляться в таблицу маршрутизации в состояниях Backup и Fault и удаляться в состоянии Master. Если значение флага false, то управление резервными маршрутами не происходит.

· RESERVE_ROUTES - переменная, задающая маршруты, которые будут добавляться в таблицу маршрутизации в состояниях Backup и Fault и удаляться в состоянии Master. Если нужно указать несколько маршрутов, то они должны быть перечислены через пробел (например: RESERVE_ROUTES="1.1.1.1/32 192.168.1.0/24").

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

· RESERVE_METRIC - переменная, задающая метрику для маршрутов, заданных в переменной RESERVE_ROUTES. Менять значение на нуль нельзя.

· FLAG_MANAGE_SERVICES - флаг, отвечающий за управление сервисами. Перечисленные в переменной SERVICES_LIST сервисы будут запускаться в состоянии Master и останавливаться в состояниях Backup и Fault. Если значение флага false, то управление сервисами не происходит.

· SERVICES_LIST - переменная, задающая сервисы, которые будут запускаться в состоянии Master и останавливаться в состояниях Backup и Fault. Если требуется указать несколько сервисов, то они должны быть перечислены через пробел (например: SERVICES_LIST="l2svc changeroutes”).

Если функционала конфигурационного файла /etc/keepalived/notify_common.conf недостаточно, то можно самостоятельно внести изменения в скрипт /etc/keepalived/scripts/notify_common. Во избежание проблем, настоятельно рекомендуется, согласовать изменения скрипта с производителем Продукта, обратившись в техническую поддержку.

2. Настройте VRRP на внешнем интерфейсе GigabitEthernet0/0 и на интерфейсе GigabitEthernet0/2 в соответствии со схемой стенда (по умолчанию все VRRP интерфейсы синхронизированы в группу номер ноль), а также укажите GigabitEthernet0/1 в качестве трэк-интерфейса для VRID 1:

root@Hub1-n1:~# su cscons

Hub1-n1#configure terminal

Hub1-n1(config)#interface GigabitEthernet0/0

Hub1-n1(config-if)#vrrp 1 ip 172.16.100.100 255.255.255.0

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

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

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

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

Hub1-n1(config-if)#exit

Hub1-n1(config)#interface GigabitEthernet0/2

Hub1-n1(config-if)#vrrp 2 ip 192.168.254.100 255.255.255.0

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

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

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

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

Hub1-n1(config-if)#exit

Hub1-n1(config)#interface GigabitEthernet0/1

Hub1-n1(config-if)#vrrp 1 track interface

Hub1-n1(config-if)#exit

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

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

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

VRRP маршрут не должен пересекаться с обычными маршрутами, задаваемыми командой ip route.

4. Включите выполнение скрипта /etc/keepalived/scripts/notify_common при переходах между состояниями:

Hub1-n1(config)#vrrp notify common

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

Hub1-n1(config)#end

Hub1-n1#

6. Проверьте состояние VRRP:

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Master

GigabitEthernet0/2 2 Master

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

Hub1-n1#show ip route

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

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

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

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

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

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

o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.16.100.1 to network 0.0.0.0

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

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 is directly connected, GigabitEthernet0/0

C 192.168.254.0/24 is directly connected, GigabitEthernet0/2

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

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

global_defs {

enable_dbus

}

vrrp_sync_group 0 {

notify "/etc/keepalived/scripts/notify_common"

group {

eth0_1

eth2_2

}

vrrp_instance eth0_1 {

interface eth0

virtual_routes {

src 172.16.100.100 0.0.0.0/0 via 172.16.100.1 dev eth0

}

virtual_ipaddress {

172.16.100.100/24 label eth0:900

}

nopreempt

priority 100

advert_int 3

garp_master_refresh 5

virtual_router_id 1

}

vrrp_instance eth2_2 {

interface eth2

virtual_ipaddress {

192.168.254.100/24 label eth2:900

}

nopreempt

priority 100

advert_int 3

garp_master_refresh 5

virtual_router_id 2

}

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

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

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

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

Hub1-n1#configure terminal

Hub1-n1(config)#crypto isakmp identity dn

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

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

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

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

Пояснение:

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

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

Hub1-n1(config)#crypto isakmp fragmentation

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

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

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

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

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

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

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

Hub1-n1(config)#crypto isakmp policy 1

Hub1-n1(config-isakmp)#encryption gost

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

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

Hub1-n1(config-isakmp)#group vko2

Hub1-n1(config-isakmp)#exit

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

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

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

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

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

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

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

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

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

Hub1-n1(config)#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hub1-n1(config)#interface GigabitEthernet0/0

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

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

Hub1-n1(config-if)#end

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

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

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

Hub1-n1#configure terminal

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

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

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

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

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

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

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

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

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

Hub1-n1(ca-trustpoint)#end

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

Hub1-n1#run cert_mgr show

Found 2 certificates. Found 1 CRL.

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

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

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

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

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

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

Hub1#run systemctl restart getcrls.service

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

Hub1-n1#run cert_mgr check

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

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

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

Hub1-n1#exit

administrator@Hub1-n1]

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

Настройка source NAT осуществляется при необходимости доступа в Интернет резервной ноде кластера через основную ноду, например для загрузки СОС.

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

Важно:

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

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

1. Войдите в linux bash:

administrator@sterragate] system

Entering system shell...

root@Hub1-n1:~#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1. Выключите source NAT для локальных IKE/ESP/NAT-T пакетов:

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

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

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

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

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

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

7.1. Включите source NAT для транзитного IPsec трафика, использующего порты 500/4500 протокола UDP:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

root@Hub1-n1:~# conntrack -L

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

· текст конфигурационного файла /etc/keepalived/notify_common.conf;

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

· текст LSP;

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

· правила iptables.

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

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

Приоритет VRRP на интерфейсах резервной ноды должен быть ниже (50 вместо 100), чем на интерфейсах основной ноды, команда vrrp <VRID> priority 50.

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

· текст конфигурационного файла /etc/keepalived/notify_common.conf;

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

· текст LSP;

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

· правила iptables.

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

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

· настройки VRRP;

· source NAT.

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

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

· текст LSP;

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

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

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

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

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

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

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

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

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Master

GigabitEthernet0/2 2 Master

Hub1-n2#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Backup

GigabitEthernet0/2 2 Backup

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

Hub1-n1#show ip route

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

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

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

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

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

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

o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.16.100.1 to network 0.0.0.0

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

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 is directly connected, GigabitEthernet0/0

C 192.168.254.0/24 is directly connected, GigabitEthernet0/2

Hub1-n2#show ip route

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

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

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

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

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

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

o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.254.100 to network 0.0.0.0

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

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 is directly connected, GigabitEthernet0/0

C 192.168.254.0/24 is directly connected, GigabitEthernet0/2

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

Hub1-n1#run cert_mgr show

Found 2 certificates. Found 1 CRL.

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

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

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

Hub1-n2#run cert_mgr show

Found 2 certificates. Found 1 CRL.

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

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

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

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

4.1. Пустите трафик с устройства host_behind_spoke1 на устройство host_behind_hub1, который должен шифроваться, например:

root@host_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=304 ms

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

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

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

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

--- 192.168.100.100 ping statistics ---

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

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

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

Hub1-n1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

1 1 (172.16.100.100,500)-(172.16.1.2,500) active 2000 1960

IPsec connections:

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

1 1 (172.16.100.100,50000)-(172.16.1.2,50000) 17 ESP tunn 848 776

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 19 (172.16.1.2,500)-(172.16.100.100,500) active 1960 2000

IPsec connections:

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

1 122 (172.16.1.2,50000)-(172.16.100.100,50000) 17 ESP tunn 776 848

Hub1-n2#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

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

Hub1-n1#show interfaces gigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is down

Hardware address is 0050.569e.b06d

Internet address is 172.16.100.10/24

MTU 1500 bytes

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Fault

GigabitEthernet0/2 2 Fault

Hub1-n2#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Master

GigabitEthernet0/2 2 Master

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

6.1. Пустите несколько пакетов целевого трафика (трафика, который должен шифроваться) с устройства host_behind_spoke1 на устройство host_behind_hub1:

root@host_behind_spoke1:~# ping 192.168.100.100 -c 5

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

--- 192.168.100.100 ping statistics ---

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

root@host_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=442 ms

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

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

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

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

--- 192.168.100.100 ping statistics ---

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

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

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

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

Hub1-n1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

Spoke1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

1 20 (172.16.1.2,500)-(172.16.100.100,500) active 1828 1900

IPsec connections:

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

1 123 (172.16.1.2,50000)-(172.16.100.100,50000) 17 ESP tunn 904 880

Hub1-n2#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

1 1 (172.16.100.100,500)-(172.16.1.2,500) active 1900 1828

IPsec connections:

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

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

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

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

Hub1-n1#show interfaces GigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up

Hardware address is 0050.569e.b06d

Internet address is 172.16.100.10/24

MTU 1500 bytes

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Backup

GigabitEthernet0/2 1 Backup

Hub1-n1#show ip route

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

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

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

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

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

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

o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.254.100 to network 0.0.0.0

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

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 is directly connected, GigabitEthernet0/0

C 192.168.254.0/24 is directly connected, GigabitEthernet0/2

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

Проверка работы сервиса L2

В случае если нода находится в состоянии Master, сервис L2 должен быть запущен.

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

1. Узнать статус сервиса:

root@Hub1-n1:~# systemctl status l2svc

● l2svc.service - S-Terra L2 Tunneling Service

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

Active: active (exited) since Thu 2020-12-03 12:51:32 MSK; 21s ago

Process: 1618 ExecStart=/opt/l2svc/bin/l2svc.sh start (code=exited, status=0/S

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

Tasks: 0 (limit: 9830)

CGroup: /system.slice/l2svc.service

Dec 03 12:51:32 Hub1-n1 systemd[1]: Starting S-Terra L2 Tunneling Service...

Dec 03 12:51:32 Hub1-n1 l2svc[1618]: S-Terra L2 for Linux 4.3.23255

Dec 03 12:51:32 Hub1-n1 l2svc[1618]: License OK

Dec 03 12:51:32 Hub1-n1 systemd[1]: Started S-Terra L2 Tunneling Service.

2. Убедиться, что необходимые виртуальные интерфейсы (tap0 и br0) созданы:

root@Hub1-n1:~# 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:91:e2 brd ff:ff:ff:ff:ff:ff

inet 172.16.100.10/24 brd 172.16.100.255 scope global eth0

valid_lft forever preferred_lft forever

inet 172.16.100.100/24 scope global secondary eth0:900

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:b2:2e brd ff:ff:ff:ff:ff:ff

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

link/ether 00:50:56:9e:ca:5b brd ff:ff:ff:ff:ff:ff

inet 192.168.254.1/24 brd 192.168.254.255 scope global eth2

valid_lft forever preferred_lft forever

inet 192.168.254.100/24 scope global secondary eth2:900

valid_lft forever preferred_lft forever

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

link/ether ba:e1:ab:5d:19:ec brd ff:ff:ff:ff:ff:ff

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

link/ether 00:50:56:9e:b2:2e brd ff:ff:ff:ff:ff:ff

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

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

где to_spoke1 - имя конфигурационного файла.

В случае если нода находится в состоянии Backup или Fault, виртуальных интерфейсов (tap0 и br0) быть не должно.

Статистику по работе сервиса L2 можно посмотреть воспользовавшись инструкциями отсюда: https://doc.s-terra.ru/rh_output/4.3/L2/output/mergedProjects/Admin/Информация_о_текущем_состоянии_Продукта.htm

Приложение

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

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

FLAG_MANAGE_ROUTES="true"

RESERVE_ROUTES="0.0.0.0/0"

RESERVE_NEXTHOP="192.168.254.100"

RESERVE_METRIC="1"

FLAG_MANAGE_SERVICES="true"

SERVICES_LIST="l2svc"

2. Консоль 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/ARr9jQowUYR7wEbOW

Zlx61OvLi7goonOFUYhNSGV49BA.RDGEZ7oKXBA1aTRi20ElR4wtMXTl0

aaa new-model

hostname Hub1-n1

enable secret 5 PC9d7N5HlAyLrzuA3qRJvQ==

crypto isakmp policy 1

encr gost

hash gost341112-256-tc26

authentication gost-sig

group vko2

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

ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1

permit udp host 172.16.100.100 eq 50000 host 172.16.1.2 eq 50000

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.10 255.255.255.0

crypto map VPN

vrrp 1 ip 172.16.100.100 255.255.255.0

vrrp 1 timers advertise 3

vrrp 1 timers garp 5

no vrrp 1 preempt

vrrp 1 track interface

interface GigabitEthernet0/1

no ip address

vrrp 1 track interface

interface GigabitEthernet0/2

ip address 192.168.254.1 255.255.255.0

vrrp 2 ip 192.168.254.100 255.255.255.0

vrrp 2 timers advertise 3

vrrp 2 timers garp 5

no vrrp 2 preempt

crypto pki trustpoint s-terra_technological_trustpoint

revocation-check crl

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

crl download time 60

crypto pki certificate chain s-terra_technological_trustpoint

certificate 50C1541D05DFCA8D446D1B4FEAFAB8C2

...

6764E6CF7BE7433F7E6A7B56FA5F2C0DE3D5BD2508FEF8D519541F2969

quit

vrrp ip route 0.0.0.0 0.0.0.0 172.16.100.1 src 172.16.100.100

vrrp notify common

end

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

# This is automatically generated LSP

# Conversion Date/Time: Thu Apr 15 18:26:51 2021

GlobalParameters(

Title = "This LSP was automatically generated by CSP Converter at Thu Apr 15 18:26:51 2021 (user: cscons)"

Version = LSP_4_3

CRLHandlingMode = ENABLE

PreserveIPsecSA = FALSE

)

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

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"

)

NetworkInterface (

LogicalName = "GigabitEthernet0/0"

IPsecPolicy = IPsecPolicy:VPN

)

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

vif tap0

bridge br0

group_fwd_mask 16388

capture eth1

local 172.16.100.100

remote 172.16.1.2

port 50000

mssfix 1400

passtos

5. Правила iptables:

iptables -N NO_SOURCE_NAT -t nat

iptables -N SOURCE_NAT -t nat

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

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

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

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

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

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

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

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

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

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

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

FLAG_MANAGE_ROUTES="true"

RESERVE_ROUTES="0.0.0.0/0"

RESERVE_NEXTHOP="192.168.254.100"

RESERVE_METRIC="1"

FLAG_MANAGE_SERVICES="true"

SERVICES_LIST="l2svc"

2. Консоль 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$i1ZS0QYm$n/CqSuPNtDZsar8bqyFQZ41GjKFw1

Uz28DdlI6CznSrX4hMirPTKYRgy/wpHApyFEbL1yXTIlQ0puxof25sEU/

aaa new-model

hostname Hub1-n2

enable secret 5 PC9d7N5HlAyLrzuA3qRJvQ==

crypto isakmp policy 1

encr gost

hash gost341112-256-tc26

authentication gost-sig

group vko2

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

ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1

permit udp host 172.16.100.100 eq 50000 host 172.16.1.2 eq 50000

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.20 255.255.255.0

crypto map VPN

vrrp 1 ip 172.16.100.100 255.255.255.0

vrrp 1 timers advertise 3

vrrp 1 timers garp 5

no vrrp 1 preempt

vrrp 1 priority 50

vrrp 1 track interface

interface GigabitEthernet0/1

no ip address

vrrp 1 track interface

interface GigabitEthernet0/2

ip address 192.168.254.2 255.255.255.0

vrrp 2 ip 192.168.254.100 255.255.255.0

vrrp 2 timers advertise 3

vrrp 2 timers garp 5

no vrrp 2 preempt

vrrp 2 priority 50

crypto pki trustpoint s-terra_technological_trustpoint

revocation-check crl

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

crl download time 60

crypto pki certificate chain s-terra_technological_trustpoint

certificate 50C1541D05DFCA8D446D1B4FEAFAB8C2

...

6764E6CF7BE7433F7E6A7B56FA5F2C0DE3D5BD2508FEF8D519541F2969

quit

vrrp ip route 0.0.0.0 0.0.0.0 172.16.100.1 src 172.16.100.100

vrrp notify common

end

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

# This is automatically generated LSP

# Conversion Date/Time: Thu Apr 15 18:58:41 2021

GlobalParameters(

Title = "This LSP was automatically generated by CSP Converter at Thu Apr 15 18:58:41 2021 (user: cscons)"