Построение отказоустойчивого решения на базе протокола VRRP с настройкой через cisco-like консоль

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

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

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

Введение

Данный сценарий содержит пример настойки отказоустойчивого кластера из С-Терра Шлюзов посредством cisco-like консоли.

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

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

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

Для переноса запросов и сертификатов между криптошлюзами и центром выпуска сертификатов требуется 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. Отказоустойчивый кластер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инициировать защищенное соединение может как трафик из подсети 192.168.1.0/24 в 192.168.100.0/24 (из филиала в центр), так и наоборот, из центра в филиал.

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.1.1 и маску - 255.255.255.0 на сетевом интерфейсе ens32.

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

3. Разрешите прохождение 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-n1 (основная нода кластера)

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

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

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

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

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

S-Terra administrative console

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

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

administrator's password:

administrator@sterragate]

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

administrator@sterragate] terminal terminal-type xterm

administrator@sterragate] terminal width 150

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

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

administrator@sterragate] system

Entering system shell...

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

root@sterragate:~# dpkg-reconfigure tzdata

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

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

Thu Jul 4 12:32:00 MSK 2019

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

root@sterragate:~# passwd

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

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

root@sterragate:~# exit

logout

Leaving system shell...

administrator@sterragate]

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

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

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

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

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

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

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

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

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

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

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

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

administrator@sterragate] dir media:

1 dr-x 4096 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. Включите внешний GigabitEthernet0/0 и внутренний GigabitEthernet0/1 интерфейсы:

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

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

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

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

Hub1-n1(config)#do show interfaces

GigabitEthernet0/0 is up, line protocol is up

Hardware address is 0050.569e.b06d

MTU 1500 bytes

GigabitEthernet0/1 is up, line protocol is up

Hardware address is 0050.569e.d3c3

MTU 1500 bytes

...

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

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

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

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

Hub1-n1(config-if)#exit

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

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

Hub1-n1(config-if)#exit

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

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

Настройка VRRP

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

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

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

Hub1-n1#run nano /etc/keepalived/notify_common.conf

FLAG_MANAGE_ROUTES="true"

RESERVE_ROUTES="0.0.0.0/0"

RESERVE_NEXTHOP="192.168.100.1"

RESERVE_METRIC="1"

При изменении данных параметров на уже работающей ноде кластера нужно перезапускать сервис keepalived:
Hub1-n1# run 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. Менять значение на нуль нельзя.

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

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

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

Hub1-n1(config)#interface GigabitEthernet0/1

Hub1-n1(config-if)# vrrp 2 ip 192.168.100.1 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)#

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. Примените настройки (настройки VRRP и IPsec применяются по выходе из режима конфигурирования):

Hub1-n1(config)#end

Hub1-n1#

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

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Master

GigabitEthernet0/1 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.100.0/24 is directly connected, GigabitEthernet0/1

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

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

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

global_defs {

enable_dbus

}

vrrp_sync_group 0 {

group {

eth0_1

eth1_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 eth1_2 {

interface eth1

virtual_ipaddress {

192.168.100.1/24 label eth1:900

}

nopreempt

priority 100

advert_int 3

garp_master_refresh 5

virtual_router_id 2

}

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

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 ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255

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

Hub1-n1(config)#

2.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 туннелей с устройствами, которые находятся за 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

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

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

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

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

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:

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

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;

· правила iptables.

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

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

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

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

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

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

· правила iptables.

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

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

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

· source NAT.

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

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

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

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

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

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

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

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

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

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Master

GigabitEthernet0/1 2 Master

Hub1-n2#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Backup

GigabitEthernet0/1 2 Backup

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

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.100.0/24 is directly connected, GigabitEthernet0/1

Hub1-n2#show ip route

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

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

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

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

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

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

o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.100.1 to network 0.0.0.0

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

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 is directly connected, GigabitEthernet0/0

C 192.168.100.0/24 is directly connected, GigabitEthernet0/1

3. Убедитесь, что основная 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_b_spoke1:~# ping 192.168.100.100 -c 5

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

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

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

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

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

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

--- 192.168.100.100 ping statistics ---

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

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

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

IPsec connections:

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

1 1 (192.168.100.0-192.168.100.255,*)-(192.168.1.0-192.168.1.255,*) * ESP tunn 440 440

Spoke1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

1 3 (172.16.1.2,500)-(172.16.100.100,500) active 1788 1820

IPsec connections:

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

1 3 (192.168.1.0-192.168.1.255,*)-(192.168.100.0-192.168.100.255,*) * ESP tunn 440 440

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/1 2 Fault

Hub1-n2#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Master

GigabitEthernet0/1 2 Master

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

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

root@Host_b_spoke1:~# ping 192.168.100.100 -c 5

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

--- 192.168.100.100 ping statistics ---

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

root@Host_b_spoke1:~# ping 192.168.100.100 -c 5

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

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

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

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

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

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

--- 192.168.100.100 ping statistics ---

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

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

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

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 4 (172.16.1.2,500)-(172.16.100.100,500) active 1788 1716

IPsec connections:

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

1 4 (192.168.1.0-192.168.1.255,*)-(192.168.100.0-192.168.100.255,*) * ESP tunn 440 440

Hub1-n2#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

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

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

IPsec connections:

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

1 1 (192.168.100.0-192.168.100.255,*)-(192.168.1.0-192.168.1.255,*) * ESP tunn 440 440

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

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

Hub1-n1#show interfaces GigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up

Hardware address is 0050.569e.b06d

Internet address is 172.16.100.10/24

MTU 1500 bytes

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Backup

GigabitEthernet0/1 2 Backup

Hub1-n1#show ip route

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

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

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

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

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

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

o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.100.1 to network 0.0.0.0

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

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.100.0 is directly connected, GigabitEthernet0/0

C 192.168.100.0/24 is directly connected, GigabitEthernet0/1

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

Особые случаи

1. Изменение IP адреса на интерфейсе, на котором настроен VRRP.

Если требуется изменить IP адрес на интерфейсе, на котором настроен VRRP, то нужно выполнить эту процедуру определенным образом.

Пример. VRRP настроен на двух интерфейсах. На интерфейсе gigabitEthernet0/0 нужно изменить IP адрес.

1.1. Текущие настройки:

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

interface GigabitEthernet0/1

ip address 192.168.100.10 255.255.255.0

vrrp 2 ip 192.168.100.1 255.255.255.0

vrrp 2 timers advertise 3

vrrp 2 timers garp 5

no vrrp 2 preempt

...

vrrp ip route 0.0.0.0 0.0.0.0 172.16.100.1 src 172.16.100.100

...

1.2. Удалите VRRP маршруты, связанные с интерфейсом gigabitEthernet 0/0, выключите VRRP на gigabitEthernet0/0 и выйдете из режима конфигурирования:

Hub1-n1#configure terminal

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

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

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

Hub1-n1(config-if)#end

Hub1-n1#

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/1 2 Master

Hub1-n1#show ip interface gigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up

Internet address is 172.16.100.10/24

MTU is 1500 bytes

Outgoing access list is not set

Inbound access list is not set

1.3. Задайте на интерфейсе gigabitEthernet0/0 новый IP адрес, после чего верните VRRP настройки:

Hub1-n1#configure terminal

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

Hub1-n1(config-if)#ip address 172.16.100.11 255.255.255.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)# no vrrp 1 preempt

Hub1-n1(config-if)#exit

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

Hub1-n1(config)#end

Hub1-n1#

Hub1-n1#show vrrp

Interface VRID State

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

GigabitEthernet0/0 1 Master

GigabitEthernet0/1 2 Master

Hub1-n1#show ip interface gigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up

Internet address is 172.16.100.11/24

MTU is 1500 bytes

Secondary address 172.16.100.100/24 (dynamic)

Outgoing access list is not set

Inbound access list is not set

1.4. Перезапустите сервис keepalvied:

Если этого не сделать, то в служебных пакетах VRRP будет старый IP адрес.

Hub1-n1# run systemctl restart keepalived.service

Приложение

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

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

FLAG_MANAGE_ROUTES="true"

RESERVE_ROUTES="0.0.0.0/0"

RESERVE_NEXTHOP="192.168.100.1"

RESERVE_METRIC="1"

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

version 12.4

no service password-encryption

crypto ipsec df-bit clear

crypto isakmp identity dn

crypto isakmp fragmentation

crypto isakmp security-association lifetime delta 50

crypto isakmp initiator-sessions-max 100

crypto isakmp responder-sessions-max 100

crypto isakmp keepalive 3

crypto isakmp keepalive retry-count 5

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

Zlx61OvLi7goonOFUYhNSGV49BA.RDGEZ7oKXBA1aTRi20ElR4wtMXTl0

aaa new-model

hostname Hub1-n1

enable secret 5 PC9d7N5HlAyLrzuA3qRJvQ==

crypto isakmp policy 1

encr gost

hash gost341112-256-tc26

authentication gost-sig

group vko2

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

ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1

permit ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255

crypto map VPN 1 ipsec-isakmp

match address IPSEC_ACl_HUB1_AND_SPOKE1

set transform-set GOST_ENCRYPT_AND_INTEGRITY

set peer 172.16.1.2

set dead-connection history off

interface GigabitEthernet0/0

ip address 172.16.100.10 255.255.255.0

crypto map VPN

vrrp 1 ip 172.16.100.100 255.255.255.0

vrrp 1 timers advertise 3

vrrp 1 timers garp 5

no vrrp 1 preempt

interface GigabitEthernet0/1

ip address 192.168.100.10 255.255.255.0

vrrp 2 ip 192.168.100.1 255.255.255.0

vrrp 2 timers advertise 3

vrrp 2 timers garp 5

no vrrp 2 preempt

interface GigabitEthernet0/2

no ip address

shutdown

crypto pki trustpoint s-terra_technological_trustpoint

revocation-check crl

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

crl download time 60

crypto pki certificate chain s-terra_technological_trustpoint

certificate 50C1541D05DFCA8D446D1B4FEAFAB8C2

...

6764E6CF7BE7433F7E6A7B56FA5F2C0DE3D5BD2508FEF8D519541F2969

quit

vrrp ip route 0.0.0.0 0.0.0.0 172.16.100.1 src 172.16.100.100

vrrp notify common

end

3. Правила iptables:

iptables -N NO_SOURCE_NAT -t nat

iptables -N SOURCE_NAT -t nat

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

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

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

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

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

iptables -t nat -A NO_SOURCE_NAT -s 192.168.100.0/24 -d 192.168.1.0/24 -j ACCEPT -m comment --comment 'traffic which must be protected by IPsec'

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

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

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

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

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

FLAG_MANAGE_ROUTES="true"

RESERVE_ROUTES="0.0.0.0/0"

RESERVE_NEXTHOP="192.168.100.1"

RESERVE_METRIC="1"

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

version 12.4

no service password-encryption

crypto ipsec df-bit clear

crypto isakmp identity dn

crypto isakmp fragmentation

crypto isakmp security-association lifetime delta 50

crypto isakmp initiator-sessions-max 100

crypto isakmp responder-sessions-max 100

crypto isakmp keepalive 3

crypto isakmp keepalive retry-count 5

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

Uz28DdlI6CznSrX4hMirPTKYRgy/wpHApyFEbL1yXTIlQ0puxof25sEU/

aaa new-model

hostname Hub1-n2

enable secret 5 PC9d7N5HlAyLrzuA3qRJvQ==

crypto isakmp policy 1

encr gost

hash gost341112-256-tc26

authentication gost-sig

group vko2

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

ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1

permit ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255

crypto map VPN 1 ipsec-isakmp

match address IPSEC_ACl_HUB1_AND_SPOKE1

set transform-set GOST_ENCRYPT_AND_INTEGRITY

set peer 172.16.1.2

set dead-connection history off

interface GigabitEthernet0/0

ip address 172.16.100.20 255.255.255.0

crypto map VPN

vrrp 1 ip 172.16.100.100 255.255.255.0

vrrp 1 timers advertise 3

vrrp 1 timers garp 5

no vrrp 1 preempt

vrrp 1 priority 50

interface GigabitEthernet0/1

ip address 192.168.100.20 255.255.255.0

vrrp 2 ip 192.168.100.1 255.255.255.0

vrrp 2 timers advertise 3

vrrp 2 timers garp 5

no vrrp 2 preempt

vrrp 2 priority 50