Отказоустойчивость

VRRP

В режиме отказоустойчивости несколько устройств ARMA Стена объединяются в кластер с использованием протокола VRRP в режиме «активный/пассивный».

Протокол VRRP (Virtual Router Redundancy Protocol) предназначен для повышения доступности маршрутизаторов, выполняющих функцию шлюза по умолчанию. Это достигается путём объединения группы маршрутизаторов в один виртуальный маршрутизатор и присвоения им общего IP-адреса, который будет использоваться в качестве шлюза по умолчанию для компьютеров в сети.

Примечание

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

Идентификатор виртуального маршрутизатора и VIP-адрес

При использовании VRRP, интерфейсы физических маршрутизаторов формируют «виртуальный маршрутизатор». Виртуальный маршрутизатор — это абстрактный объект, управляемый процессом VRRP. Каждый виртуальный маршрутизатор имеет уникальный цифровой идентификатор (Virtual router ID — VRID) и виртуальный IP-адрес (Virtual IP — VIP). Узлы в сети настраиваются таким образом, чтобы направлять пакеты на VIP-адрес виртуального маршрутизатора, вместо IP-адресов физических интерфейсов. Виртуальный маршрутизатор может состоять из кластера физических и/или виртуальных интерфейсов, обеспечивающих резервирование для первичного интерфейса (мастер-интерфейса). Как правило, интерфейсы, входящие в виртуальный маршрутизатор, находятся на разных маршрутизаторах. Резервированием управляет процесс VRRP, выполняемый в системе каждого маршрутизатора, состоящего в виртуальном маршрутизаторе.

Каждому виртуальному маршрутизатору может быть назначено до 20 VIP-адресов. Для обеспечения резервирования интерфейсам в составе виртуального маршрутизатора должен быть назначен одинаковый идентификатор и VIP-адрес. IP-адреса интерфейсов и VIP-адрес группы не обязательно должны находиться в одной подсети.

Виртуальный MAC-адрес

Каждому виртуальному маршрутизатору VRRP должен быть присвоен определённый 48-битный MAC-адрес. Виртуальный MAC-адрес создаётся на основе MAC-префиксов (описанных в спецификации протокола VRRP) и идентификатора виртуального маршрутизатора. Виртуальный MAC-адрес выглядит как 0000:5E00:01xx, где xx — идентификатор виртуального маршрутизатора.

Главный маршрутизатор использует MAC-адрес виртуального маршрутизатора в качестве источника для отправляемых VRRP-пакетов. При получении статуса главного маршрутизатора, резервное устройство также начинает использовать MAC-адрес виртуального маршрутизатора.

Использование предопределённого MAC-адреса виртуального маршрутизатора позволяет не менять настройки ARP при сбое главного маршрутизатора.

Объявления VRRP и выбор главного маршрутизатора

Главный маршрутизатор использует объявления VRRP для передачи информации о своём текущем состоянии резервным маршрутизаторам. Объявления VRRP состоят из пакетов «heartbeat», которые содержат информацию о состоянии главного маршрутизатора и его приоритет. В каждом виртуальном маршрутизаторе только главный маршрутизатор отправляет периодические объявления VRRP на зарезервированный адрес 224.0.0.18. На канальном уровне в качестве MAC-адреса отправителя объявлений VRRP используется виртуальный MAC-адрес. Если резервные устройства не получают объявления VRRP в течении заданного периода (dead interval), то главный маршрутизатор считается неработоспособным, после чего статус главного маршрутизатора присваивается одному из резервных маршрутизаторов согласно выставленному значению приоритета.

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

При отказе мастер-интерфейса, дублирующий интерфейс с наибольшим значением приоритета назначается мастер-интерфейсом и ему присваивается VIP-адрес виртуального маршрутизатора. Рекомендуется устанавливать значение приоритета мастер-интерфейса равным наибольшему значению приоритета дублирующего интерфейса плюс 50. Значение приоритета дублирующего интерфейса можно оставить равным значению по умолчанию, однако при наличии двух и более дублирующих интерфейсов, следует задать им разные значения приоритета.

Вытеснение

Если параметр вытеснения включён, резервный маршрутизатор с более высоким приоритетом, чем у текущего главного маршрутизатора, будет замещать его, отправляя свои собственные объявления VRRP. Когда главный маршрутизатор обнаружит, что у дублирующего устройства установлено более высокое значение приоритета, он прекратит отправлять свои объявления VRRP. В результате дублирующий маршрутизатор с более высоким значением приоритета назначается главным маршрутизатором.

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

В системе ARMA Стена вытеснение включено по умолчанию. Это означает, что резервный маршрутизатор с более высоким приоритетом автоматически становится активным, как только переходит в рабочее состояние.

Для отключения режима вытеснения используется опция «no-preempt»:
set high-availability vrrp group <имя_группы> no-preempt
После применения данной конфигурации устройство с более высоким приоритетом не будет автоматически принимать роль активного узла, даже если оно находится в рабочем состоянии.
Для настройки временной задержки перед выполнением вытеснения предусмотрен параметр «preempt-delay». Указанный интервал позволяет избежать частых переключений активной роли в условиях нестабильной доступности одного из узлов кластера. Например, для установки задержки в 180 секунд необходимо выполнить команду:
set high-availability vrrp group <имя_группы> preempt-delay 180
Допустимый диапазон значений параметра «preempt-delay» от «1» до «1000» секунд включительно.

Возможные состояния виртуального маршрутизатора на устройствах

«MASTER» - главный маршрутизатор – это устройство, имеющее наибольший приоритет в рамках одного виртуального маршрутизатора. Отправляет на резервные маршрутизаторы объявления, содержащие в том числе, значение приоритета.

«BACKUP» - резервный маршрутизатор – это устройство, которое имеет меньший приоритет чем главный маршрутизатор. При получении объявлений сравнивает приоритет в полученном объявлении со своим значением. Если было получено объявление с меньшим приоритетом или объявления не были получены в течение установленного интервала – резервный маршрутизатор становится главным маршрутизатором.

«FAULT» - состояние ошибки. Переход в статус FAULT происходит по следующим основным причинам:

Проблемы с интерфейсом - могут возникать вследствие административного отключения интерфейса (например, командой set interfaces ethernet eth1 disable), физической потери линка (обрыв кабеля, неисправность коммутатора), отключения на системном уровне или отсутствия поднятого канального уровня (L2), как, например, в случае с PPPoE- или VLAN-интерфейсами без установленного соединения, а также при отсутствии назначенного IP-адреса на интерфейсе.

Потеря виртуального IP-адреса (VIP) - если виртуальный IP-адрес, назначенный VRRP-группе, был удалён с интерфейса вручную или по иной причине, VRRP-процесс переходит в состояние FAULT.

Проблемы с отслеживанием интерфейсов (Interface Tracking) - переход отслеживаемого интерфейса (например, WAN-линка) в состояние down приводит к активации статуса FAULT.

Срабатывание скрипта отслеживания (Track Script) - выполнение пользовательского скрипта, настроенного для мониторинга (например, проверки доступности шлюза, загрузки процессора или наличия критического процесса), завершилось с ненулевым кодом возврата, что интерпретируется как сбой.

Внутренние ошибки VRRP-демона - в редких случаях возможны сбои в работе демона keepalived (используемого в системе ARMA Стена для реализации VRRP), приводящие к переходу в состояние FAULT.

Скрипты

Функциональность VRRP возможно расширить с помощью скриптов. Система ARMA Стена поддерживает два типа скриптов: скрипты проверки работоспособности и скрипты перехода.

Скрипты проверки работоспособности выполняют пользовательские проверки в дополнение к проверке работоспособности основного маршрутизатора.
Примеры настройки запуска скрипта проверки работоспособности:

Данный пример конфигурации укажет процессу VRRP выполнять скрипт «/config/scripts/vrrp-check.sh» каждые 60 секунд. Если скрипт завершится с ненулевым статусом три раза подряд, группа VRRP «test1» будет переведена в состояние ошибки («FAULT»):
set high-availability vrrp group test1 health-check script /config/scripts/vrrp-check.sh
set high-availability vrrp group test1 health-check interval 60
set high-availability vrrp group test1 health-check failure-count 3
В случае, если группа VRRP входит в состав группы синхронизации, будет применяться только сценарий проверки работоспособности группы синхронизации. В данном примере показано, как настроить этот сценарий для группы синхронизации:
set high-availability vrrp sync-group test2 health-check script /config/scripts/vrrp-check.sh
set high-availability vrrp sync-group test2 health-check interval 60
set high-availability vrrp sync-group test2 health-check failure-count 3
Скрипты перехода выполняются при изменении состояния VRRP с основного на резервный или неисправный и наоборот. Они могут быть использованы для выполнения различных операций, таких как запуск и остановка служб, а также для изменения конфигурации системы ARMA Стена при переключении VRRP.
Примеры настройки запуска скриптов перехода при изменении состояния VRRP:
set high-availability vrrp group test transition-script master "/config/scripts/vrrp-master.sh test"
set high-availability vrrp group test transition-script backup "/config/scripts/vrrp-fail.sh test"
set high-availability vrrp group test transition-script fault "/config/scripts/vrrp-fail.sh test"
set high-availability vrrp group test transition-script master "/config/scripts/vrrp-master.sh test"
Данная конфигурация запускает выполнение файла /config/scripts/vrrp-fail.sh с аргументом test при сбое VRRP, а также файла /config/scripts/vrrp-master.sh при переходе системы в режим «MASTER».
Примечание

Скрипт должен возвращать «0» для обозначения успешного результата и значение отличное от «0» - для неудачных результатов. Система перестанет отвечать на запросы, если выполнение скрипта не завершится!

Рекомендуется сохранять скрипты в каталоге /config/scripts. Это позволит избежать потери файлов в случае обновления системы.

Алгоритм настройки VRRP-группы:

Указать IP-адреса и задать описание интерфейсов маршрутизатора.

Задать имя и описание для группы VRRP.

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

Определить приоритет маршрутизатора для группы VRRP.

Задать виртуальный VIP-адрес для группы VRRP.

Указать общий номер группы VRRP (VRID).

Выполнить аналогичные настройки на втором маршрутизаторе.

Глобальные настройки

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

Указать используемую версию протокола VRRP:

set high-availability vrrp global-parameters version <2|3>
где <2|3> - номер версии протокола VRRP. Система ARMA Стена поддерживает протокол VRRP версий 2 и 3. По умолчанию применяется протокол VRRP версии 3. Для работы с IPv6 используется протокол VRRP версии 3, который обеспечивает поддержку как IPv4, так и IPv6.

Примечание

При обновлении ARMA Стена и переносе настроек с более ранних версий системы (до версии 4.8) по умолчанию используется VRRP версии 2.

Определить задержку перед запуском экземпляра VRRP после старта Keepalived:

set high-availability vrrp global-parameters startup-delay <1-600>
где <1-600> - время ожидания в секундах, в течение которого VRRP не будет активен после запуска системы. Возможно указать значение в диапазоне от «1» до «600». Это значение помогает избежать преждевременного запуска VRRP, обеспечивая корректную инициализацию сетевых интерфейсов и других зависимых служб.

Включить экспорт состояния VRRP через SNMP:

set high-availability vrrp snmp
Данная команда активирует поддержку стандартного SNMP-мониторинга для групп VRRP. После её выполнения сведения о состоянии VRRP-групп (Master, Backup, Fault), их приоритете, идентификаторе VRID и виртуальных IP-адресах становятся доступны посредством SNMP-запросов к стандартным MIB-переменным.

Команда не включает SNMP-сервис. Для функционирования мониторинга требуется предварительная настройка SNMP-агента (см. раздел «SNMP» настроящего руководства).

Настройка Gratuitous ARP

Gratious ARP (GARP) — это механизм, используемый для обновления ARP-таблиц соседних устройств в сети. В контексте VRRP GARP помогает уведомлять сеть о том, что виртуальный маршрутизатор стал активным (MASTER). Настройка GARP в системе ARMA Стена не является обязательной, так как есть значения по умолчанию, но при необходимости их можно изменить.

Настройки GARP могут быть применены как глобально (для всех групп VRRP), так и для конкретной группы VRRP. Ниже приведены команды и их описание:

Установить задержку между отправкой сообщений GARP на интерфейс:

set high-availability vrrp global-parameters garp interval <0.000-1000>

set high-availability vrrp group <name> garp interval <0.000-1000>
где:

<0.000-1000> - значение задержки в секундах. Возможно указать значение в диапазоне от «0.000» до «1000». По умолчанию используется значение «0» - сообщения отправляются без задержки.

<name> - имя группы VRRP.

Установить задержку перед отправкой второго набора GARP после того, как маршрутизатор становится MASTER:

set high-availability vrrp global-parameters garp master-delay <1-255>

set high-availability vrrp group <name> garp master-delay <1-255>
где <1-255> - значение задержки в секундах. Возможно указать значение в диапазоне от «1» до «255». По умолчанию используется значение «5».

Установить интервал обновления GARP в состоянии MASTER:

set high-availability vrrp global-parameters garp master-refresh <1-600>

set high-availability vrrp group <name> garp master-refresh <1-600>
где <1-600> - значение временного интервала в секундах. Возможно указать значение в диапазоне от «1» до «600». По умолчанию используется значение «0» - обновление отключено.

Установить количество сообщений GARP, отправляемых за один раз в состоянии MASTER:

set high-availability vrrp global-parameters garp master-refresh-repeat <1-600>

set high-availability vrrp group <name> garp master-refresh-repeat <1-600>
где <1-600> - количество сообщений GARP, отправляемых за один раз. Возможно указать значение в диапазоне от «1» до «600». По умолчанию используется значение «1».

Установить количество сообщений GARP, отправляемых за один раз после перехода в состояние MASTER:

set high-availability vrrp global-parameters garp master-repeat <1-600>

set high-availability vrrp group <name> garp master-repeat <1-600>
где <1-600> - количество сообщений GARP, отправляемых за один раз. Возможно указать значение в диапазоне от «1» до «600». По умолчанию используется значение «5».

Примечание

Параметры, установленные для группы, обладают более высоким приоритетом по сравнению с глобальными параметрами. В случае, если параметр не определён ни на глобальном уровне, ни для группы, применяются значения по умолчанию.

Команды настройки группы VRRP

Назначение виртуального IP-адреса (VIP) для группы VRRP:

set high-availability vrrp group <имя_группы> address <address>
где:

<имя_группы> - имя группы VRRP;

<address> - формат виртуального IP-адреса зависит от версии VRRP:

VRRP версии 2

Поддерживается только IPv4. При указании адреса в формате <x.x.x.x> (без префикса) система автоматически применяет маску /32. Формат <x.x.x.x/x> также допустим, однако префикс не влияет на работу VRRPv2 и используется исключительно для внутренней маршрутизации или совместимости с конфигурацией интерфейса.

VRRP версии 3

Поддерживается как IPv4, так и IPv6. Для IPv4 допустимы форматы <x.x.x.x> и <x.x.x.x/x>. Префикс может использоваться для корректной привязки виртуального адреса к подсети. Для IPv6 допустимы форматы <h:h:h:h:h:h:h:h> и <h:h:h:h:h:h:h:h/x>. Префикс учитывается при обработке многоадресного трафика и формировании ND (Neighbor Discovery) записей.

Смешанное использование IPv4 и IPv6 в одной группе VRRP недопустимо.

Установка VRID для группы VRRP:

set high-availability vrrp group <имя_группы> vrid <1-255>
где <1-255> - целочисленное значение в диапазоне от «1» до «255», уникально определяющее виртуальный маршрутизатор в пределах одного широковещательного домена.

Указание интерфейса для группы VRRP:

set high-availability vrrp group <имя_группы> interface <имя_интерфейса>
где <имя_интерфейса> - имя физического или логического сетевого интерфейса, на котором будет работать группа VRRP.

Установка приоритета маршрутизатора в группе VRRP:

set high-availability vrrp group <имя_группы> priority <1-255>
где <1-255> - целочисленное значение приоритета узла (маршрутизатора) в рамках одной VRRP-группы. Возможно указать значение в диапазоне от «1» до «255». Это значение определяет, какой из узлов будет выступать в роли Master (активного маршрутизатора), а какие — в роли Backup (резервных). Узел с наибольшим приоритетом становится Master. По умолчанию приоритет равен «100».

Добавление описания группы VRRP:

set high-availability vrrp group <имя_группы> description <text>
где <text> - краткое текстовое описание. Допускается использование символов кириллического и латинского алфавитов. Описание не должно начинаться c последовательности «//». Запрещено использование символов «"», «'» и перенос строки. Максимальная длина значения — «127» символов. При наличии пробелов значение должно быть заключено в двойные кавычки.

Установка интервала отправки VRRP-объявлений:

set high-availability vrrp group <имя_группы> advertise-interval <interval>
где <interval> - интервал в секундах, с которым активный маршрутизатор (Master) отправляет VRRP-объявления в группе.

Для VRRP версии 2 возможно указать значение в диапазоне от «1» до «255». Значение по умолчанию - «1» секунда.

Для VRRP версии 3 поддерживается полный диапазон с точностью до микросекунды. Возможно указать значение в диапазоне от «0.010000» до «40.950000». Значение по умолчанию - «1.000000» секунда.

Настройка аутентификации в группе VRRP:

7.1 Указание типа аутентификации:
set high-availability vrrp group <имя_группы> authentication type <plaintext-password | ah>
где:

<plaintext-password> - аутентификация по паролю. Применяется в заголовке VRRPv2 для базовой проверки принадлежности узлов к одной группе. Пароль передаётся в открытом виде, криптографическая защита не обеспечивается.;

<ah> - аутентификация с использованием IPsec Authentication Header. Метод не рекомендуется к применению.
7.2 Указание пароля аутентификации:
set high-availability vrrp group <имя_группы> authentication password <пароль>
где <пароль> - пароль длиной не более 8 символов, используемый для аутентификации VRRP-пакетов между узлами.
Примечание

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

Исключение IP-адреса из проверки дублирования:

set high-availability vrrp group <имя_группы> excluded-address <IP-адрес> interface <имя_интерфейса>
где:

<IP-адрес> - IPv4 или IPv6-адрес (с префиксом или без), исключаемый из проверки на конфликт при инициализации VRRP;

<имя_интерфейса> - сетевой интерфейс, на котором данный IP-адрес может быть назначен и не должен рассматриваться как конфликтующий с виртуальным адресом VRRP.

По умолчанию перед переходом узла в состояние Master выполняется проверка наличия дублирующихся виртуальных IP-адресов в локальном сетевом сегменте с использованием ARP (для IPv4) или NDP (для IPv6). Указание адреса в данном параметре отключает проверку дублирования на соответствующем интерфейсе, что исключает ложные срабатывания в случаях, когда физический и виртуальный IP-адреса совпадают.

В VRRPv2 проверка дублирования применяется только к IPv4-адресам и осуществляется исключительно посредством ARP-запросов. В VRRPv3 поддерживается как IPv4, так и IPv6, а проверка дублирования выполняется с использованием ARP (для IPv4) и NDP (Neighbor Discovery Protocol, для IPv6). Соответственно, при использовании VRRPv3 параметр excluded-address может применяться к адресам обоих семейств, тогда как в VRRPv2 — только к IPv4.

Настройка проверки работоспособности (health check) для группы VRRP:

9.1 Указание количества неудачных проверок до перехода в состояние FAULT:
set high-availability vrrp group <имя_группы> health-check failure-count <число>
где <число> - целое положительное число, задающее, количество последовательных сбоев health-check (ping или скрипт) должно произойти, чтобы VRRP-группа перешла в состояние FAULT. Значение по умолчанию - «3».

После каждой неудачной проверки счётчик увеличивается. Если счётчик достигнет указанного значения — узел немедленно переходит в состояние FAULT. Успешная проверка сбрасывает счётчик.
9.2 Указание интервала между проверками:
set high-availability vrrp group <имя_группы> health-check interval <секунды>
где <секунды> - целое положительное число, задающее интервал в секундах между последовательными запусками health-check (ping или скрипт). Значение по умолчанию - «60».
9.3 Настройка ping-проверки:
set high-availability vrrp group <имя_группы> health-check ping <IP-адрес>
где <IP-адрес> - целевой IPv4- или IPv6-адрес для ICMP-проверки. IPv6-адреса допустимы только при использовании VRRPv3.
9.4 Указание пользовательского скрипта для проверки:
set high-availability vrrp group <имя_группы> health-check script <путь_к_скрипту>
где <путь_к_скрипту> - абсолютный путь к исполняемому файлу скрипта, который будет запускаться для проверки состояния узла.

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

исполняемый файл;

возвращает «0» при успешной проверке, иное — при сбое;

завершается быстро (рекомендуется менее 1–2 секунд);

не требует интерактивного ввода;

рекомендуется расположение - /config/scripts/, так как эта директория сохраняется при обновлениях системы.
Примечание

На одну VRRP-группу может быть настроен только один тип health-check — либо ping, либо скрипт.

Отключение режима preempt:

set high-availability vrrp group <имя_группы> no-preempt
Отключает автоматическое возвращение роли Master узлу с более высоким приоритетом после его восстановления. Режим preempt включён по умолчанию.

Указание адреса однорангового узла (peer) для unicast-режима:

set high-availability vrrp group <имя_группы> peer-address <IP-адрес>
где <IP-адрес> - IPv4- или IPv6-адрес пира, с которым осуществляется обмен VRRP-пакетами в unicast-режиме. IPv6-адреса допустимы только в VRRPv3.

По умолчанию используется multicast-адресация (224.0.0.18 для IPv4, FF02::12 для IPv6). Указание peer-address переключает группу в unicast-режим.

Установка задержки перед preemption:

set high-availability vrrp group <имя_группы> preempt-delay <0-1000>
где <0-1000> - значение задержки в секундах, добавляемое к стандартному времени ожидания перехода в состояние Master. Допустимый диапазон - от «0» до «1000». Значение по умолчанию - «0».

По умолчанию, при обнаружении активного Master-узла с более низким приоритетом, резервный узел ожидает истечения advertisement timeout, рассчитываемого по формуле:

Advert timeout= 3 × advert_int + skew_time,

где skew_time = (256−priority)/256.

Например, при advert-interval = 1 и priority = 128 advertisement timeout составляет приблизительно 3,5 секунды.

Если параметр preempt-delay установлен в значение N, общая задержка перед переходом в состояние Master увеличивается до: Advert timeout + N.

Так, при preempt-delay 2 и предыдущем примере переход произойдёт примерно через 5,5 секунд.

Параметр preempt-delay игнорируется при активированном режиме no-preempt.

Используется для предотвращения преждевременного перехода в Master при неготовности системы (например, при загрузке политик или сессий) или для подавления флаппинга.

Включение режима совместимости с RFC 3768:

set high-availability vrrp group <имя_группы> rfc3768-compatibility
RFC 3768 определяет виртуальный MAC-адрес для каждого виртуального маршрутизатора VRRP. Этот MAC-адрес используется в качестве источника во всех VRRP-объявлениях.

При активации этой опции создаётся отдельный виртуальный VRRP-интерфейс, на который автоматически назначаются:

виртуальный MAC-адрес, определённый в RFC 3768 (00:00:5e:00:01:<VRID> для IPv4);

виртуальный IP-адрес группы VRRP.

Настройка отслеживания состояния интерфейса:

set high-availability vrrp group <имя_группы> track interface <имя_интерфейса>
где <имя_интерфейса> - имя сетевого интерфейса, состояние которого будет отслеживаться.

При переходе отслеживаемого интерфейса в состояние down VRRP-группа немедленно переводится в состояние FAULT, независимо от текущего приоритета узла или состояния других интерфейсов. Это обеспечивает оперативное реагирование на отказ критически важных сетевых соединений и способствует корректному переключению роли Master на резервный узел в отказоустойчивой конфигурации.

Исключение основного VRRP-интерфейса из отслеживания:

set high-availability vrrp group <имя_группы> track exclude-vrrp-interface
Активация параметра предотвращает перевод группы в состояние FAULT при отключении основного VRRP-интерфейса.

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

set high-availability vrrp group <имя_группы> transition-script <состояние> <путь_к_скрипту>
где:

<состояние> - целевое состояние VRRP-группы, при достижении которого запускается скрипт. Допустимые значения:

master — при переходе в состояние Master;

backup — при переходе в состояние Backup;

fault — при переходе в состояние Fault;

stop — при остановке VRRP-группы.

<путь_к_скрипту> - абсолютный путь к исполняемому файлу скрипта (например, /config/scripts/vrrp-master.sh). Скрипт должен иметь права на выполнение и быть доступен в момент срабатывания события.

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

Временное отключение VRRP-группы:

set high-availability vrrp group <имя_группы> disable
Команда останавливает работу группы без удаления конфигурации. Все функции VRRP (объявления, переходы между состояниями и т.д.) приостанавливаются. Конфигурация сохраняется и может быть вновь активирована без повторной настройки.

Динамическая корректировка стоимости маршрута

Система ARMA Стена имеет возможность автоматически изменять настройки динамической маршрутизации в зависимости от текущего состояния VRRP-группы. Это позволяет исключить ситуации, когда резервный узел или узел, который находится в состоянии FAULT, продолжает объявлять маршруты или использоваться как основной. При настроенной динамической корректировке стоимости автоматически запускается служба vrrp-routing-handler. Эта служба отслеживает состояние VRRP-группы и применяет соответствующие параметры маршрутизации.

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

«OSPF»;

«OSPFv3»;

«BGP».

Команда для настройки корректировки стоимости машрутов для протокола OSPF:

set high-availability config-override vrrp group <vrrp-group> <master | backup> protocols ospf interface <interface> cost <cost>
где:

<vrrp-group> - наименование VRRP-группы, для которой будет применяться корректировка.

Примечание

VRRP-группа должна быть определена заранее с помощью команды set high-availability vrrp group (см. Команды настройки группы VRRP).

<master | backup> - состояния виртуального маршрутизатора. Состояние «BACKUP» включает в себя также состояние «FAULT».

<interface> - интерфейс, для которого будет применяться корректировка.

Примечание

Один и тот же интерфейс не может использоваться в нескольких VRRP-группах, если для них включён config-override.

<cost> - стоимость маршрута.

Команда для настройки корректировки стоимости машрутов для протокола OSPFv3:

set high-availability config-override vrrp group <vrrp-group> <master | backup> protocols ospfv3 interface <interface> cost <cost>

Команда для настройки корректировки стоимости машрутов для протокола BGP:

set high-availability config-override vrrp group <vrrp-group> <master | backup> policy route-map VRRP-BGP-OUT
Примечание

Для протокола BGP не используется атрибут стоимости «cost», вместо этого применяется «route-map». В состоянии «BACKUP» route-map VRRP-BGP-OUT активен и подавляет анонсы маршрутов. В состоянии «MASTER» route-map удаляется, а маршруты анонсируются в обычном режиме. Route-map VRRP-BGP-OUT создаётся автоматически. Для просмотра route-map используется следующая команда:
show policy route-map VRRP-BGP-OUT

Группа синхронизации VRRP

Группа синхронизации VRRP (VRRP Sync Group) объединяет несколько VRRP-групп в единый логический блок, обеспечивая синхронное изменение их состояний (MASTER / BACKUP / FAULT). При переходе любого участника группы в новое состояние все остальные участники немедленно принимают то же состояние. Данная функциональность направлена на предотвращение рассогласования ролей, что могло бы привести к ситуации, когда часть сервисов функционирует на одном узле, а другая часть — на другом.

Требования и рекомендации к конфигурированию VRRP Sync Group:

Единообразие приоритетов

Все VRRP-группы, входящие в одну VRRP Sync Group, должны иметь одинаковые значения приоритета на каждом узле. Несоблюдение данного условия может привести к нестабильности (flapping), вызванной конфликтом в выборе MASTER-ноды.

Единообразие ролей на узле

На одном узле все VRRP-группы внутри VRRP Sync Group должны быть сконфигурированы с одинаковой ролью — либо все как MASTER, либо все как BACKUP. Смешанная конфигурация (часть групп в роли MASTER, часть — в роли BACKUP) недопустима. На резервном узле роли должны быть противоположными.

Запрет циклических или перекрёстных зависимостей

Одна и та же VRRP-группа не может входить более чем в одну VRRP Sync Group. Также недопустимо создание косвенных зависимостей между sync-группами через общие интерфейсы или скрипты, которые могут вызвать взаимную блокировку или бесконечные переключения.

Команды конфигурации VRRP Sync Group:

Добавление VRRP-группы в синхронизированную группу:

set high-availability vrrp sync-group <имя_sync-группы> member <имя_группы>
где:

<имя_sync-группы> - имя синхронизированной группы;

<имя_группы> - имя ранее настроенной VRRP-группы.

Настройка скрипта, выполняемого при смене состояния синхронизированной группы:

set high-availability vrrp sync-group <имя_sync-группы> transition-script <состояние> <путь_к_скрипту>
где:

<состояние> - целевое состояние, при наступлении которого запускается скрипт. Допустимые значения:

master — при переходе в состояние Master;

backup — при переходе в состояние Backup;

fault — при переходе в состояние Fault;

stop — при остановке VRRP-группы.

<путь_к_скрипту> - абсолютный путь к исполняемому файлу скрипта (например, /config/scripts/vrrp-master.sh). Скрипт должен иметь права на выполнение и быть доступен в момент срабатывания события.

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

Настройка проверки работоспособности (health-check) на уровне VRRP Sync Group:

Проверка работоспособности, заданная на уровне синхронизированной группы, применяется ко всем входящим в неё VRRP-группам. В случае сбоя вся группа одновременно переводится в состояние FAULT.

3.1 Установка количества неудачных проверок до перехода в FAULT:
set high-availability vrrp sync-group <имя_sync-группы> health-check failure-count <число>
где <число> - целое положительное значение, определяющее количество последовательных сбоев health-check, после которого группа переходит в состояние FAULT. Значение по умолчанию - «3».

Счётчик увеличивается при каждой неудачной проверке и сбрасывается при успешной.
3.2 Задание интервала между проверками:
set high-availability vrrp sync-group <имя_sync-группы> health-check interval <секунды>
где <секунды> - интервал в секундах между последовательными запусками health-check. Значение по умолчанию - «60».
3.3 Настройка ICMP-проверки (ping):
set high-availability vrrp sync-group <имя_sync-группы> health-check ping <IP-адрес>
где <IP-адрес> - целевой IPv4- или IPv6-адрес для ICMP-запроса. Использование IPv6 допустимо только при применении протокола VRRPv3.
3.4 Указание пользовательского скрипта для проверки:
set high-availability vrrp sync-group <имя_sync-группы> health-check script <путь_к_скрипту>
где <путь_к_скрипту> - абсолютный путь к исполняемому файлу, выполняющему проверку состояния узла.

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

исполняемый файл;

возвращает «0» при успешной проверке, иное — при сбое;

завершается быстро (рекомендуется менее 1–2 секунд);

не требует интерактивного ввода;

рекомендуется расположение - /config/scripts/, так как эта директория сохраняется при обновлениях системы.
Примечание

Для одной VRRP Sync Group может быть настроен только один тип health-check: либо ping, либо script.

Health-check, настроенный на уровне VRRP Sync Group, имеет приоритет над индивидуальными проверками отдельных VRRP-групп. При достижении порога неудачных попыток (failure-count) все группы, входящие в синхронизированную группу, немедленно переходят в состояние FAULT, независимо от результатов их собственных health-check (если таковые заданы).

Синхронизация конфигурации

Функция синхронизации конфигурации (config sync) в системе ARMA Стена предназначена для автоматизации обмена параметрами конфигурации между двумя маршрутизаторами, функционирующими в режиме высокой доступности.

Основное назначение функции — исключение необходимости ручного переноса изменений конфигурации с основного маршрутизатора на резервный. Синхронизация выполняется посредством HTTP API системы ARMA Стена. Поддерживается выбор конкретных разделов конфигурации для синхронизации, а также определение режима применения изменений: замена или дополнение.

Перед настройкой синхронизации отдельных разделов конфигурации рекомендуется сначала выполнить настройку самой службы синхронизации, а затем уже конфигурировать те разделы, которые планируется включить в синхронизацию. Такой порядок действий упрощает процесс инициализации синхронизации: если сначала настроить сервис (например, webproxy или suricata) и лишь после этого добавить соответствующий раздел в список синхронизируемых, то первоначальная передача конфигурации на резервное устройство произойдёт только после внесения каких-либо изменений в этот раздел. В противном случае, при корректной последовательности (сначала — служба синхронизации, затем — конфигурация разделов), конфигурация синхронизируется сразу при настройке соответствующих параметров.

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

находиться в рабочем состоянии;

быть подключёнными к сети;

функционировать под управлением идентичной версии программного обеспечения ARMA Стена;

иметь одинаковый набор сетевых интерфейсов;

обеспечивать идентичную нумерацию физических и логических интерфейсов (например, eth0, eth1 и т.д.).

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

Поддерживается синхронизация следующих разделов конфигурации (<name>):

«firewall» — настройки правил фильтрации трафика политиками межсетевого экрана.

«interfaces» — конфигурация сетевых интерфейсов всех типов:

«bonding» — агрегированные интерфейсы (объединение нескольких физических интерфейсов в один логический).

«bridge» — создание моста между интерфейсами на канальном уровне.

«dummy» — виртуальные интерфейсы.

«ethernet» — стандартные физические Ethernet-интерфейсы.

«geneve» — туннельные интерфейсы для GENEVE (Generic Network Virtualization Encapsulation).

«input» — специальные интерфейсы для обработки входящего трафика в политике.

«l2tpv3» — интерфейсы для L2TPv3 (Layer 2 Tunneling Protocol version 3).

«loopback» — виртуальный интерфейс.

«macsec» — интерфейсы с поддержкой шифрования на канальном уровне (MACsec).

«openvpn» — интерфейсы для OpenVPN-туннелей.

«pppoe» — интерфейсы для подключения через PPPoE (например, у интернет-провайдера).

«pseudo-ethernet» — псевдо-Ethernet интерфейсы для задач виртуализации.

«sstpc» — интерфейсы SSTP-клиента (Secure Socket Tunneling Protocol).

«tunnel» — туннельные интерфейсы.

«virtual-ethernet» — виртуальные Ethernet-интерфейсы для внутренних соединений.

«vti» — виртуальные туннельные интерфейсы для IPsec.

«vxlan» — интерфейсы для VXLAN (Virtual Extensible LAN).

«wireguard» — интерфейсы для WireGuard-VPN.

«wireless» — беспроводные (Wi-Fi) интерфейсы.

«wwan» — интерфейсы для мобильной связи.

«nat» — настройки трансляции сетевых адресов для IPv4 (NAT).

«nat66» — настройки трансляции адресов для IPv6 (NAT66).

«pki» — управление сертификатами, ключами и центрами сертификации (PKI).

«policy» — политики, использующиеся для фильтрации и управления трафиком.

«protocols» — настройки сетевых протоколов маршрутизации:

«babel» — динамический протокол маршрутизации для mesh-сетей.

«bfd» — протокол быстрого обнаружения сбоев в соединениях (Bidirectional Forwarding Detection).

«bgp» — протокол граничного шлюза для межавтономных систем (Border Gateway Protocol).

«failover» — маршруты с приоритетом для резервирования соединений.

«igmp-proxy» — прокси для IGMP (управление multicast-группами).

«isis» — протокол маршрутизации IS-IS для крупных сетей.

«mpls» — настройки MPLS (Multiprotocol Label Switching).

«nhrp» — параметры протокола разрешения следующего прыжка (Next Hop Resolution Protocol).

«ospf» — протокол динамической маршрутизации OSPF для IPv4.

«ospfv3» — протокол OSPF для IPv6.

«pim» — протокол независимой многопотоковой рассылки (PIM) и IGMP.

«pim6» — протокол PIM и MLD для IPv6.

«rip» — параметры протокола маршрутизации RIP.

«ripng» — параметры протокола маршрутизации RIPng (для IPv6).

«rpki» — настройки инфраструктуры открытых ключей для ресурсов (Resource Public Key Infrastructure).

«segment-routing» — параметры технологии Segment Routing.

«static» — статические маршруты.

«qos» — настройки приоритетов для разных классов и типов трафика:

«interface» — интерфейсы, к которым применяются политики QoS.

«policy» — определения политик QoS (очереди, приоритеты, shaping).

«service» — служебные сервисы, предоставляемые устройством:

«active-sync-proxy» — настройки прокси для ActiveSync.

«console-server» — настройки сервера последовательных консолей.

«dhcp-relay» — агент ретрансляции DHCP-запросов.

«dhcp-server» — сервер динамической настройки хостов (DHCP) для IPv4.

«dhcpv6-relay» — агент ретрансляции DHCPv6-запросов.

«dhcpv6-server» — сервер DHCP для IPv6 (DHCPv6).

«dns» — сервисы, связанные с DNS.

«https» - настройки сервиса HTTPS.

«lldp» — настройки протокола LLDP.

«mdns» — параметры multicast DNS.

«monitoring» — сервисы мониторинга.

«ndp-proxy» — прокси для протокола обнаружения соседей (NDP) в IPv6.

«ntp» — настройка синхронизации времени по NTP.

«snmp» — настройки SNMP.

«tftp-server» — TFTP-сервер для передачи конфигураций и образов.

«webproxy» — настройки веб-прокси.

«suricata» — настройки системы обнаружения и предотвращения вторжений Suricata (IDS/IPS). При синхронизации данного раздела на резервное устройство также копируются все файлы правил СОВ (rule-files), указанные в конфигурации службы.

«system» — системные параметры устройства:

«conntrack» — отслеживание состояния сетевых соединений.

«flow-accounting» — учёт сетевого трафика.

«login» — параметры аутентификации пользователей.

«option» — системные параметры.

«sflow» — сбор и передача sFlow-данных для анализа трафика.

«static-host-mapping» — статическое сопоставление имён хостов и IP-адресов.

«sysctl» — настройка параметров ядра Linux в режиме реального времени.

«time-zone» — выбор часового пояса устройства.

«vpn» — настройки виртуальных частных сетей.

«vrf» — виртуальные таблицы маршрутизации (Virtual Routing and Forwarding) для изоляции сетей.

При синхронизации разделов active-sync-proxy и webproxy на резервное устройство также передаются соответствующие keytab-файлы, используемые для аутентификации в доменной инфраструктуре.

Примечание

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

Для обеспечения сохранения активных сессий при переходе (failover) рекомендуется настроить синхронизацию состояний соединений с использованием сервиса conntrack-sync. Подробная инструкция приведена в разделе «Отслеживание соединений».

Примечание

При синхронизации службы Suricata, если в параметре rule-files указаны шаблонные пути вида *.rules (например, /config/files/configuration/suricata/rule-files/*.rules), система не выполнит копирование файлов правил. В результате будет выведено сообщение об ошибке: «ERROR: vyos config sync: File not found: /config/files/configuration/suricata/rule-files/*.rules».

Для обеспечения корректной синхронизации необходимо указывать полные и точные пути к конкретным файлам правил в параметре rule-files, например: «/config/files/configuration/suricata/rule-files/custom.rules».

Команды настройки синхронизации конфигурации

Установка режима синхронизации:

set service config-sync mode <load|set>
где <load|set> - режим применения конфигурации на резервном устройстве:

load — полная замена целевой секции конфигурации на содержимое, полученное от основного устройства;

set — добавление или обновление параметров без удаления существующих настроек, отсутствующих в синхронизируемом фрагменте.

Примечание

Требуется предварительный анализ топологии и функциональных требований для корректного выбора синхронизируемых разделов. В частности, полная синхронизация компонентов «interfaces» или «service» может вызвать нарушение работы кластера.

Указание раздела конфигурации для синхронизации:

set service config-sync section <name>
где <name> - идентификатор поддерживаемого раздела (перечислены выше).

Удаление раздела конфигурации из списка синхронизации:

delete service config-sync section <name>
Примечание

Полное удаление раздела конфигурации необходимо в случае, если раздел содержит единственную или последнюю секцию для синхронизации. Например, если ранее в разделе «service» была настроена синхронизация конфигурации только для сервиса «webproxy», для удаления этого раздела необходимо выполнить команду delete service config-sync section service. Во всех остальных случаях удаление возможно с указанием пути до конкретной секции раздела.

Указание адреса резервного устройства:

set service config-sync secondary address <address>
где <address> - сетевой адрес резервного устройства, задаваемый в одном из следующих форматов:: Ipv4, Ipv6 или полное доменное имя (FQDN).

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

Настройка HTTP API-ключа аутентификации для подключения к резервному устройству:

set service config-sync secondary key <text>
где <text> - ключ API, сгенерированный для учётной записи «admin» на резервном устройстве.

Указание порта подключения к резервному устройству:

set service config-sync secondary port <port>
где <port> - номер TCP-порта. Возможно указать значение в диапазоне от «1» до «65535». По умолчанию используется порт «8082».

Примечание

Изменение порта не рекомендуется, так как может нарушить работу механизма синхронизации.

Настройка таймаута подключения к резервному устройству:

set service config-sync secondary timeout <timeout>
где <timeout> - время ожидания ответа в секундах. Возможно указать значение в диапазоне от «1» до «3600». По умолчанию используется установлено «60» секунд.

Примечание

При наличии сетевой нагрузки или большом размере конфигурационного файла рекомендуется увеличить значение до 120 или более.

Настройка интервала автоматической проверки доступности резервного устройства:

set service config-sync secondary daemon poll-interval <poll_int>
где <poll_int> - интервал проверки доступности резервного устройства в секундах. Возможно указать значение в диапазоне от «1» до «3600». По умолчанию используется значение «30».

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

Для отключения автоматического опроса используется команда:
set service config-sync secondary daemon poll-interval disable

Точечная синхронизация конфигурации

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

Точечная синхронизация доступна для следующих разделов:

protocols ospf;

protocols ospfv3;

service webproxy;

service https;

system login.

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

set service config-sync section <раздел> <путь>
Пример:
set service config-sync section protocols ospf access-list 3 export
В приведённом примере синхронизируется только подузел access-list 3 export в разделе protocols ospf. Изменения в других подузлах (например, access-list 4 или area 0) не передаются на резервное устройство.

Дополнительно реализована возможность исключения отдельных подузлов из синхронизации при выполнении полной синхронизации всего раздела. Для этого используется команда с ключевым словом exclude:

set service config-sync section <раздел>
set service config-sync section exclude <раздел> <путь_исключения>
Пример:
set service config-sync section protocols ospf
set service config-sync section exclude protocols ospf access-list 3
В данном случае выполняется синхронизация всего раздела protocols ospf, за исключением подузла access-list 3. Любые изменения внутри access-list 3 игнорируются при передаче конфигурации на резервное устройство.

Для упрощения ввода длинных и глубоко вложенных путей реализована функция автозаполнения (TAB-completion), идентичная используемой в основном CLI-интерфейсе системы ARMA Стена. Например, при вводе команды:

set service config-sync section exclude protocols ospf access-list [TAB]

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

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

Примечание

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

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

Настройка синхронизации конфигурации в отказоустойчивом кластере

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

На резервном устройстве создаётся API-ключ для учётной записи «admin»:

set service https api keys user admin key <api-key>
где <api-key> - секретный ключ (пароль) для учётной записи «admin», используемый при аутентификации через HTTP API.

Данный ключ будет использоваться основным устройством для установления соединения с резервным устройством.

Если API-ключ был задан на этапе первоначальной установки системы, повторное выполнение команды не требуется. В случае необходимости смены ключа команда выполняется с новым значением <api-key>.

На основном устройстве настраивается параметры синхронизации:

set service config-sync secondary address <slave-address>
set service config-sync secondary key <api-key>
set service config-sync mode <load|set>
set service config-sync section <name>
commit
save
где:

<slave-address> – сетевой адрес резервного устройства (в формате IPv4, IPv6 или FQDN);

<api-key> – API-ключ, созданный на резервном устройстве;

<load|set> - режим применения конфигурации;

<name> – идентификатор синхронизируемого раздела конфигурации (см. перечень поддерживаемых разделов в разделе Синхронизация конфигурации).

Примечание

При указании неверного API-ключа система сохранит конфигурацию и не выдаст ошибку на этапе выполнения «commit», однако синхронизация не будет выполнена. В журнале HTTPS-сервиса резервного устройства появится запись об ошибке аутентификации.

При последующих изменениях в синхронизируемом разделе и выполнении команды «commit» на основном устройстве будет выведено сообщение, указывающее на недоступность резервного узла, например:

An error occurred: HTTPSConnectionPool(host='х.х.х.х', port=8082): Max retries exceeded with url: /config-file (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f40eeef90d0>: Failed to establish a new connection: [Errno 111] Connection refused'))

Данное поведение обусловлено тем, что IP-адрес основного устройства был заблокирован на резервном устройстве вследствие превышения допустимого количества неудачных попыток аутентификации через HTTP API. Блокировка применяется в целях защиты от брутфорс-атак и сохраняется в течение заданного интервала времени (в зависимости от настроек системы безопасности резервного узла). До разблокировки IP-адреса или сброса счётчика попыток синхронизация оставаться недоступной.

Примечание

В случае несоответствия версий программного обеспечения основного и резервного устройств при выполнении команды «commit» будет выведено сообщение об ошибке:

ERROR:ngfwos_config_sync:The version of remote node (x.x.x.x) does not match current node's version. Cannot synchonize with it
ERROR:ngfwos_config_sync:Please, provide correct remote node and try again

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

Примечание

Если резервное устройство недоступно в момент выполнения «commit», система выведет сообщение:

Remote node is not available, status code: 401
Try sync with daemon

Особенности настройки устройств кластера

Настройка прокси-сервера ActiveSync в составе кластера

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

Настроить синхронизацию конфигураций сервиса «active-sync-proxy»:

set service config-sync section service active-sync-proxy

Настроить прокси-сервер ActiveSync на ведущей ARMA Стена (см. Группы пользователей).
После выполнения настроек на ведущей ARMA Стена в консоли будет выведена информация о том, что файл «*.keytab» скопирован в резервную ARMA Стена:

INFO:ngfwos_config_sync:Upload file '/config/files/configuration/service/active-sync-proxy/kerberos/keytab/test.keytab':
{'success': True, 'data': '/config/files/configuration/service/active-sync-proxy/kerberos/keytab/test.keytab', 'error': None}, Secondary=x.x.x.x:8082
Для проверки успешного копирования файла необходимо перейти в каталог /config/files/configuration/service/active-sync-proxy/kerberos/keytab/ на резервной ARMA Стена и найти файл «test.keytab».

Настройка сервера OpenConnect в составе кластера

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

На обоих ARMA Стена настроить виртуальный маршрутизатор и дополнительно ввести следующие команды:

set high-availability vrrp sync-group <syncname> member <nameVR>
set service conntrack-sync accept-protocol tcp
set service conntrack-sync accept-protocol udp
set service conntrack-sync accept-protocol icmp
set service conntrack-sync event-listen-queue-size 8
set service conntrack-sync failover-mechanism vrrp sync-group <syncname>
set service conntrack-sync interface <iname>
set service conntrack-sync mcast-group 225.0.0.50
set firewall global-options state-policy established action accept
где:

<syncname> – имя группы синхронизации;

<nameVR> – имя виртуального маршрутизатора;

<iname> – имя интерфейса, используемого для синхронизации;

Для настройки синхронизации конфигураций «vpn» и «pki» ввести следующие команды:

set service https api keys user <username> key <examplepassword>
set service config-sync mode load
set service config-sync secondary address [<slave-address> | <fqdn>]
set service config-sync secondary key <examplepassword>
set service config-sync section vpn
set service config-sync section pki

где <username> и <examplepassword> – учётные данные;

Настроить OpenConnect на ведущей ARMA Стена (см. OpenConnect).

Примечание

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

Пример настройки отказоустойчивого кластера

В качестве примера приведён порядок настройки ARMA Стена в режиме отказоустойчивого кластера согласно схеме, представленной на рисунке (см. Рисунок – Схема стенда для настройки режима отказоустойчивого кластера).

../../../../_images/ngfw.r.cli.high-availability_1.1.png — *Рисунок – Схема стенда для настройки режима отказоустойчивого кластера*

Для настройки работы в режиме отказоустойчивого кластера и создания виртуального маршрутизатора в сети «192.168.3.0/24» на каждом устройстве ARMA Стена необходимо выполнить следующие действия:

Включить возможность привязки сетевых приложений к IP-адресам, которые не существуют на сетевых интерфейсах или недоступным на момент инициализации служб:
set system sysctl parameter net.ipv4.ip_nonlocal_bind value 1
Назначить имя виртуального маршрутизатора и перейти к его настройке:
admin@ngfwos# set high-availability vrrp group <nameVR>
[edit]
admin@ngfwos# edit high-availability vrrp group <nameVR>
где <nameVR> – имя виртуального маршрутизатора. В качестве примера использовано имя «vr1».
Назначить интерфейс:
[edit high-availability vrrp group vr1]
admin@ngfwos# set interface eth1
где «eth1» – имя интерфейса.
Назначить идентификатор:
[edit high-availability vrrp group vr1]
admin@ngfwos# set vrid 50
где «50» – идентификатор.
Назначить виртуальный адрес:
[edit high-availability vrrp group vr1]
admin@ngfwos# set address 192.168.3.254/24
где «192.168.3.254/24» – виртуальный IP-адрес в формате CIDR.
Указать приоритет для виртуального маршрутизатора:
[edit high-availability vrrp group vr1]
admin@ngfwos# set priority 200
где «200» – величина приоритета. Возможно указать значение в диапазоне от «1» до «255», при этом значение 255 соответствует наивысшему приоритету.

По умолчанию используется значение «100».

Примечание

На резервной ARMA Стена необходимо указывать значение приоритета пониженное, относительно приоритета ведущей ARMA Стена.
Зафиксировать изменения с помощью ввода команд «commit» и «save».

Для просмотра статуса необходимо ввести команду «run show vrrp».

Для отключения виртуального маршрутизатора следует ввести команду:

set high-availability vrrp group <nameVR> disable

Пример настройки динамической корректировки стоимости маршрута

В качестве примера приведён порядок настройки динамической корректировки стоимости маршрута для протокола OSPF на двух ARMA Стена, которые работают в режиме отказоустойчивого кластера согласно схеме, представленной на рисунке (см. Рисунок – Схема стенда для настройки динамической корректировки стоимости маршрута).

../../../../_images/ngfw.r.cli.high-availability_1.2.png — *Рисунок – Схема стенда для настройки динамической корректировки стоимости маршрута*

Пример настройки для протокола OSPF

Предварительно на каждом устройстве ARMA Стена необходимо выполнить следующие действия:

Задать адреса для сетевых интерфейсов.

На ведущем устройстве ARMA Стена:

set interfaces ethernet eth3 address '10.0.0.1/30'
set interfaces ethernet eth1 address '100.96.0.1/24'
set interfaces ethernet eth2 address '192.168.2.1/24'
commit
save

На резервном устройстве ARMA Стена:

set interfaces ethernet eth3 address '10.0.0.2/30'
set interfaces ethernet eth1 address '100.96.0.2/24'
set interfaces ethernet eth2 address '192.168.2.2/24'
commit
save

Выполнить настройку VRRP-групп, параметров кластеризации и протокола OSPF:

На ведущем устройстве ARMA Стена:

set high-availability vrrp group External address 100.96.0.254/24
set high-availability vrrp group External interface 'eth1'
set high-availability vrrp group External vrid 10
set high-availability vrrp group Internal address 192.168.2.254/24
set high-availability vrrp group Internal interface 'eth2'
set high-availability vrrp group Internal vrid '20'
set high-availability vrrp sync-group CLUSTER member 'External'
set high-availability vrrp sync-group CLUSTER member 'Internal'
set protocols ospf parameters router-id 100.96.0.1
set protocols ospf area 0 network '100.96.0.0/24'
set protocols ospf area 0 network '192.168.2.0/24'
set protocols ospf interface eth2 passive
set protocols ospf interface eth1 hello-interval 1
set protocols ospf interface eth1 dead-interval 4
commit
save

На резервном устройстве ARMA Стена:

set high-availability vrrp group External address 100.96.0.254/24
set high-availability vrrp group External interface 'eth1'
set high-availability vrrp group External vrid 10
set high-availability vrrp group Internal address 192.168.2.254/24
set high-availability vrrp group Internal interface 'eth2'
set high-availability vrrp group Internal vrid '20'
set high-availability vrrp sync-group CLUSTER member 'External'
set high-availability vrrp sync-group CLUSTER member 'Internal'
set high-availability vrrp group External priority 50
set high-availability vrrp group Internal priority 50
set protocols ospf parameters router-id 100.96.0.2
set protocols ospf area 0 network '100.96.0.0/24'
set protocols ospf area 0 network '192.168.2.0/24'
set protocols ospf interface eth2 passive
set protocols ospf interface eth1 hello-interval 1
set protocols ospf interface eth1 dead-interval 4
commit
save

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

На ведущем устройстве ARMA Стена:

#Назначить корректировку стоимости маршрута через установку значения для мастер ноды для всех интерфейсов, которые используют соединение OSPF:
set high-availability config-override vrrp group External master protocols ospf interface eth1 cost 222
set high-availability config-override vrrp group Internal master protocols ospf interface eth2 cost 222

#Назначить коректировку стоимости маршрута через установку значения для бекап ноды для всех интерфейсов, которые используют соединение OSPF:
set high-availability config-override vrrp group External backup protocols ospf interface eth1 cost 22222
set high-availability config-override vrrp group Internal backup protocols ospf interface eth2 cost 22222

commit
save

На резервном устройстве ARMA Стена:

#Назначить корректировку стоимости маршрута через установку значения для мастер ноды для всех интерфейсов, которые используют соединение OSPF:
set high-availability config-override vrrp group External master protocols ospf interface eth1 cost 333
set high-availability config-override vrrp group Internal master protocols ospf interface eth2 cost 333

#Назначить коректировку стоимости маршрута через установку значения для бекап ноды для всех интерфейсов, которые используют соединение OSPF:
set high-availability config-override vrrp group External backup protocols ospf interface eth1 cost 33333
set high-availability config-override vrrp group Internal backup protocols ospf interface eth2 cost 33333

commit
save

Примечание

Настройки для протокола OSPFv3 аналогичны настройкам протокола OSPF.

Пример настройки для протокола BGP

Предварительно на каждом устройстве ARMA Стена необходимо выполнить следующие действия:

Задать адреса для сетевых интерфейсов.

На ведущем устройстве ARMA Стена:

set interfaces ethernet eth3 address '10.0.0.1/30'
set interfaces ethernet eth1 address '100.96.0.1/24'
set interfaces ethernet eth2 address '192.168.2.1/24'
commit
save

На резервном устройстве ARMA Стена:

set interfaces ethernet eth3 address '10.0.0.2/30'
set interfaces ethernet eth1 address '100.96.0.2/24'
set interfaces ethernet eth2 address '192.168.2.2/24'
commit
save

Выполнить настройку VRRP-групп, параметров кластеризации и BGP соседства:

На ведущем устройстве ARMA Стена:

set high-availability vrrp group External address 100.96.0.254/24
set high-availability vrrp group External interface 'eth1'
set high-availability vrrp group External vrid 10
set high-availability vrrp group Internal address 192.168.2.254/24
set high-availability vrrp group Internal interface 'eth2'
set high-availability vrrp group Internal vrid '20'
set high-availability vrrp sync-group CLUSTER member 'External'
set high-availability vrrp sync-group CLUSTER member 'Internal'
set protocols bgp address-family ipv4-unicast network 192.168.2.0/24
set protocols bgp neighbor 100.96.0.3 address-family ipv4-unicast
set protocols bgp neighbor 100.96.0.3 remote-as 65003
set protocols bgp neighbor 100.96.0.3 timers connect 5
set protocols bgp neighbor 100.96.0.3 timers holdtime 10
set protocols bgp neighbor 100.96.0.3 timers keepalive 3
set protocols bgp system-as 65001
commit
save

На резервном устройстве ARMA Стена:

set high-availability vrrp group External address 100.96.0.254/24
set high-availability vrrp group External interface 'eth1'
set high-availability vrrp group External vrid 10
set high-availability vrrp group Internal address 192.168.2.254/24
set high-availability vrrp group Internal interface 'eth2'
set high-availability vrrp group Internal vrid '20'
set high-availability vrrp sync-group CLUSTER member 'External'
set high-availability vrrp sync-group CLUSTER member 'Internal'
set high-availability vrrp group External priority 50
set high-availability vrrp group Internal  priority 50
set protocols bgp address-family ipv4-unicast network 192.168.2.0/24
set protocols bgp neighbor 100.96.0.3 address-family ipv4-unicast route-map
set protocols bgp neighbor 100.96.0.3 remote-as 65003
set protocols bgp neighbor 100.96.0.3 timers connect 5
set protocols bgp neighbor 100.96.0.3 timers holdtime 10
set protocols bgp neighbor 100.96.0.3 timers keepalive 3
set protocols bgp system-as 65002
commit
save

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

На ведущем устройстве ARMA Стена:

set high-availability config-override vrrp group External backup policy route-map VRRP-BGP-OUT
set high-availability config-override vrrp group External master policy route-map VRRP-BGP-OUT
set high-availability config-override vrrp group Internal backup policy route-map VRRP-BGP-OUT
set high-availability config-override vrrp group Internal master policy route-map VRRP-BGP-OUT

commit
save

На резервном устройстве ARMA Стена:

set high-availability config-override vrrp group External backup policy route-map VRRP-BGP-OUT
set high-availability config-override vrrp group External master policy route-map VRRP-BGP-OUT
set high-availability config-override vrrp group Internal backup policy route-map VRRP-BGP-OUT
set high-availability config-override vrrp group Internal master policy route-map VRRP-BGP-OUT

commit
save