Подробный гайд по F_STP и Failover в ViPNet

Подробный гайд по F_STP и Failover в ViPNet Аббревиатура F_STP (чаще всего встречающаяся в системных журналах как префикс <F_STP>) в экосистеме ViPNet (ViPNet Coordinator HW, ViPNet XFirewall) относится к внутренней подсистеме Failover (High Availability / Кластер горячего резервирования). За её работу отвечает специализированный демон failoverd, который обеспечивает отказоустойчивость, синхронизацию состояний и автоматическое переключение ролей между узлами кластера в случае аппаратного или сетевого сбоя.

1. Архитектура и принцип работы (F_STP / Failover)

Кластер горячего резервирования в ViPNet Coordinator HW/XFirewall обычно строится по схеме Active-Passive (Активный-Пассивный) и использует следующие компоненты:

• Демон failoverd — «мозг» кластера. Он обменивается heartbeat-пакетами с соседним узлом, отслеживает состояние интерфейсов и генерирует системные события с тегом <F_STP> (например, Command: failover stop или failover start).
• Протокол VRRP — используется для того, чтобы оба узла имели общий виртуальный MAC-адрес и IP-адрес. Шлюз по умолчанию для клиентов всегда указывает на этот виртуальный VRRP IP.
• Канал синхронизации (Sync Link) — выделенный физический интерфейс, по которому узлы обмениваются состояниями сессий (stateful failover), таблицами маршрутизации и конфигурациями.
• Watchdog-драйвер (itcswd) — аппаратно-программный сторожевой таймер, который перезагружает узел, если ядро ОС или драйвер ViPNet «зависли», чтобы пассивный узел мог перехватить управление.
• Служба iplircfg — управляет сетевыми интерфейсами и туннелями; именно её перезапускает failoverd при смене ролей узлов.

2. Подготовка к настройке кластера

1. Лицензирование: Убедитесь, что на обоих узлах установлена лицензия, поддерживающая Failover (например, ViPNet Coordinator Failover или соответствующая лицензия для XFirewall).
2. Идентичность железа и ПО: Оба устройства должны быть одной аппаратной платформы (например, оба HW1000 Q3) и с одинаковой версией прошивки/ОС.
3. Физическое подключение:
   • Настройте прямой патч-корд между выделенными портами обоих шлюзов для канала синхронизации (Sync).
   • Подключите внешние (WAN/LAN) интерфейсы к общим коммутаторам.

3. Пошаговая настройка (через Веб-интерфейс)

Настройка выполняется через веб-интерфейс ViPNet Coordinator HW (раздел Кластер или Система защиты от сбоев):

Шаг 1. Базовые параметры кластера

• Зайдите в настройки кластера на первом узле и выберите режим: Активный (Active).
• Укажите IP-адрес второго (пассивного) узла для канала синхронизации и задайте пароль для аутентификации VRRP.

Шаг 2. Настройка на втором узле

• На втором устройстве выберите режим Пассивный (Passive) и укажите IP-адрес первого узла с тем же паролем синхронизации.

Шаг 3. Настройка VRRP (Виртуальные IP)

• Для каждого критически важного интерфейса (WAN, LAN) создайте VRRP-группу и назначьте Виртуальный IP-адрес.
• Укажите приоритет (Priority): на Активном узле приоритет должен быть выше (например, 150), на Пассивном — ниже (например, 100).

Шаг 4. Настройка Test IP (Контроль линков)

Чтобы кластер переключился не только при падении самого шлюза, но и при потере связи у провайдера, настройте Test IP (мониторинговые IP-адреса). Если failoverd теряет пинг до Test IP на активном узле, он инициирует переключение на пассивный узел.

Шаг 5. Синхронизация конфигурации

• Выполните команду или нажмите кнопку «Синхронизировать конфигурацию». Настройки софта, правила МЭ и таблицы маршрутизации скопируются на пассивный узел.

4. Работа через командную строку (CLI / rvpn_shell)

При подключении по SSH или консоли вы попадаете в rvpn_shell, откуда можно управлять демоном failoverd.

• failover status — проверить текущее состояние узла (Master/Backup) и работу VRRP.
• failover start — запустить подсистему отказоустойчивости.
• failover stop — остановить демон (в логах появится syslog| <F_STP> Command: failover stop).
• failover manage — интерактивное меню или набор команд для ручного переключения ролей.

5. Диагностика и анализ логов (Тег <F_STP>)

Если происходят частые переключения (flapping) или кластер не поднимается, необходимо анализировать системный журнал:

• Просмотр логов в CLI: grep "F_STP" /var/log/syslog или tail -f /var/log/messages.
• Типичные сообщения:
  • failure detected on interface ethX — failoverd зафиксировал падение физического линка.
  • heartbeat lost — потерян канал синхронизации (риск возникновения ситуации Split-Brain).
  • transition to MASTER / transition to BACKUP — узел сменил роль.

6. Частые проблемы и Best Practices

1. Несовпадение версий: Обновление прошивки на одном узле без обновления на другом приведет к остановке синхронизации. Всегда обновляйте оба узла последовательно.
2. MTU на Sync-интерфейсе: Убедитесь, что MTU на канале синхронизации позволяет проходить служебным пакетам failoverd без фрагментации.
3. Задержки (Latency): Канал синхронизации должен иметь минимальные задержки. Использование протяженных оптоволоконных линий для Sync-линка без должной настройки таймаутов failoverd приведет к ложным срабатываниям.

Информация предоставлена в ознакомительных целях. Применение описанных настроек в системах, должно осуществляться только после согласования с ответственными за информационную безопасность и в соответствии с требованиями ФСТЭК, ФСБ и иных уполномоченных органов.