Сценарии отказоустойчивости pfSense - проектирование HA

Проектирование отказоустойчивого кластера pfSense требует учёта топологии сети, используемых сервисов и допустимого времени простоя. pfSense поддерживает кластеры из двух узлов в конфигурации active/passive. Каждый сценарий отказоустойчивости имеет свои особенности конфигурации, ограничения и порядок тестирования. В данном разделе рассмотрены типовые архитектуры HA-кластеров, процедуры планового и аварийного переключения, а также интеграция с дополнительными сервисами.

Топология Active/Passive

Active/passive - единственная официально поддерживаемая конфигурация HA-кластера pfSense. В этой схеме один узел (master) обрабатывает весь сетевой трафик, а второй узел (backup) находится в режиме горячего резерва, готовый принять нагрузку при отказе primary.

Принцип работы

Primary-узел владеет всеми CARP VIP и обрабатывает трафик. Secondary-узел получает обновления таблицы состояний через pfsync и конфигурации через XMLRPC. При потере heartbeat-сигналов от primary secondary повышает свой статус до master по каждому CARP VIP и начинает обрабатывать трафик.

Время переключения (failover time) определяется параметрами Advertising Frequency в настройках CARP:

При стандартных параметрах backup-узел обнаруживает отказ primary примерно за 3 секунды и принимает роль master. Существующие TCP-сессии сохраняются благодаря pfsync - клиенты сети не замечают переключения за исключением кратковременной задержки.

Стандартная схема

                    Internet
                       |
                   [ISP Router]
                       |
              -------- WAN --------
              |                   |
         [Primary]           [Secondary]
         master               backup
              |                   |
              -------- LAN --------
              |                   |
         [LAN Switch]        [LAN Switch]
              |
         [Clients]
              |
         ---- Sync (172.16.1.0/24) ----

В стандартной схеме оба узла подключены к одному WAN-сегменту и одному LAN-сегменту. Sync-интерфейс соединяет узлы напрямую. CARP VIP назначены на WAN и LAN интерфейсах. Клиенты используют LAN CARP VIP в качестве шлюза по умолчанию.

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

Active/Passive с Multi-WAN

Кластер pfSense с несколькими WAN-подключениями обеспечивает отказоустойчивость как на уровне каналов связи, так и на уровне оборудования. Каждый WAN-интерфейс требует собственного набора CARP VIP.

Схема с двумя WAN

         ISP1              ISP2
          |                  |
     [Router1]          [Router2]
          |                  |
     --- WAN1 ---       --- WAN2 ---
     |          |       |          |
  [Primary]  [Secondary]
     |          |
     --- LAN ---
     |
  [Clients]

Особенности конфигурации

При multi-WAN HA необходимо создать CARP VIP на каждом WAN-интерфейсе:

Правила исходящего NAT должны быть настроены отдельно для каждого WAN-интерфейса с указанием соответствующего CARP VIP в качестве адреса трансляции.

Gateway Groups в HA

Multi-WAN gateway groups работают корректно в HA-конфигурации при соблюдении следующих условий:

• Шлюзы (gateways) должны мониторить доступность через индивидуальные IP-адреса узлов, а не через CARP VIP
• Policy routing правила, использующие gateway groups, синхронизируются через XMLRPC
• При failover на secondary gateway groups продолжают работать с той же логикой приоритетов

Внимание:

При использовании gateway groups с параметром Tier для балансировки нагрузки между WAN-каналами необходимо убедиться, что оба WAN-интерфейса физически доступны с обоих узлов кластера. Потеря одного WAN-канала на secondary-узле при failover приведёт к переключению всего трафика на оставшийся канал.

HA с IPsec VPN

Интеграция IPsec-туннелей с HA-кластером требует особого подхода к конфигурации. Ключевое требование - все IPsec-туннели должны быть привязаны к CARP VIP, а не к индивидуальным адресам узлов.

Конфигурация IPsec для HA

При настройке Phase 1 (IKE) необходимо указать CARP VIP в качестве My identifier и Interface:

При переключении на backup-узел IPsec-туннель переустанавливается автоматически, поскольку CARP VIP мигрирует вместе с ролью master. Удалённая сторона продолжает обращаться к тому же IP-адресу (CARP VIP), и IKE-согласование происходит заново.

Время восстановления IPsec

В отличие от обычного TCP/UDP-трафика, IPsec-туннели не сохраняются при failover полностью. Хотя pfsync реплицирует состояния, IKE SA (Security Association) требует повторного согласования:

Для минимизации простоя IPsec при failover рекомендуется использовать DPD (Dead Peer Detection) на удалённой стороне с агрессивными таймерами (например, интервал 10 секунд, 3 попытки).

Несколько IPsec-туннелей

При наличии нескольких IPsec-туннелей каждый из них должен быть привязан к CARP VIP. Все туннели синхронизируются через XMLRPC при включённом флаге IPsec в области синхронизации. После failover каждый туннель восстанавливается независимо - некоторые могут восстановиться быстрее других в зависимости от настроек DPD на удалённых сторонах.

HA с OpenVPN

OpenVPN-серверы и клиенты в HA-кластере также требуют привязки к CARP VIP. Поведение OpenVPN при failover отличается от IPsec и зависит от используемого протокола (UDP или TCP) и режима (tun или tap).

Конфигурация OpenVPN Server для HA

При создании OpenVPN-сервера необходимо указать:

Конфигурация OpenVPN синхронизируется через XMLRPC при включённом флаге OpenVPN.

Поведение при failover

Для наилучшей совместимости с HA рекомендуется использовать режим tun с протоколом UDP. В этом случае клиенты OpenVPN автоматически обнаруживают потерю связи через механизм keepalive и переподключаются к CARP VIP, который уже обслуживается backup-узлом.

Внимание:

Сертификаты OpenVPN должны быть синхронизированы через XMLRPC (флаг Certificates, CAs). Если сертификаты различаются между узлами, клиенты не смогут подключиться к backup-узлу после failover.

HA с DHCP-сервером

DHCP-сервер в HA-кластере требует особого внимания для предотвращения конфликтов адресов при split-brain сценариях.

Стандартная конфигурация

В стандартной конфигурации DHCP-сервер привязан к LAN-интерфейсу и выдаёт адреса из единого пула. Клиенты обращаются к CARP VIP (который является их шлюзом по умолчанию), и DHCP-ответы отправляются от master-узла.

При failover DHCP-сервер на backup-узле активируется и продолжает выдачу адресов. Поскольку конфигурация DHCP синхронизирована через XMLRPC, backup-узел использует тот же пул адресов.

Предотвращение конфликтов

Для предотвращения дублирования адресов при split-brain рекомендуется одна из следующих стратегий:

При разделении пула необходимо отключить синхронизацию DHCP Server в настройках XMLRPC и сконфигурировать диапазоны вручную на каждом узле.

Статические DHCP-привязки

Статические DHCP-привязки (static mappings) синхронизируются через XMLRPC вместе с остальной конфигурацией DHCP. Эти привязки не создают конфликтов при split-brain, поскольку каждый MAC-адрес привязан к фиксированному IP-адресу.

Процедура планового переключения

Плановое переключение (maintenance failover) выполняется при необходимости обслуживания primary-узла - обновление pfSense, замена оборудования, диагностика.

Пошаговая процедура

1. Подготовка: убедиться, что secondary-узел полностью синхронизирован

   • Проверить Status > CARP (failover) - все VIP должны показывать MASTER на primary и BACKUP на secondary
   • Убедиться в отсутствии ошибок синхронизации в журнале

2. Переключение на secondary: на primary-узле перейти в Status > CARP (failover) и нажать Enter Persistent CARP Maintenance Mode

   • Все CARP VIP переходят в состояние BACKUP на primary
   • Secondary повышает статус до MASTER по всем VIP
   • Переключение занимает несколько секунд

3. Верификация: убедиться, что трафик обрабатывается secondary

   • На secondary проверить Status > CARP (failover) - все VIP должны быть в состоянии MASTER
   • Протестировать прохождение трафика через файрвол (веб-доступ, DNS, VPN)
   • Проверить работоспособность IPsec/OpenVPN туннелей

4. Обслуживание primary: выполнить необходимые работы на primary-узле

   • Обновление pfSense
   • Замена оборудования
   • Диагностика

5. Возврат на primary: на primary-узле выйти из maintenance mode через Status > CARP (failover) - нажать Leave Persistent CARP Maintenance Mode

   • Primary восстанавливает статус MASTER по всем VIP
   • Secondary возвращается в BACKUP

6. Финальная проверка: убедиться, что primary вернул роль MASTER и синхронизация работает корректно

Внимание:

Перед плановым переключением рекомендуется создать резервную копию конфигурации обоих узлов через Diagnostics > Backup & Restore. Это обеспечит возможность восстановления в случае непредвиденных проблем.

Обновление pfSense в HA-кластере

При обновлении pfSense в HA-кластере необходимо соблюдать определённый порядок:

1. Создать резервные копии конфигурации обоих узлов
2. Перевести primary в maintenance mode (трафик переключится на secondary)
3. Обновить primary-узел
4. Дождаться завершения обновления и перезагрузки
5. Убедиться, что primary запустился корректно (не выводить из maintenance mode)
6. Перевести secondary в maintenance mode на secondary-узле (трафик вернётся на обновлённый primary)
7. Обновить secondary-узел
8. Дождаться завершения обновления и перезагрузки
9. Вывести оба узла из maintenance mode
10. Проверить синхронизацию и статус CARP

Обновление secondary выполняется вторым, поскольку XMLRPC-синхронизация может быть несовместима между разными версиями pfSense. После обновления обоих узлов до одинаковой версии синхронизация восстанавливается.

Тестирование Failover

Регулярное тестирование failover - обязательная практика для production-кластеров. Тестирование следует выполнять при вводе кластера в эксплуатацию и после каждого значимого изменения конфигурации.

Тест 1: Плановое переключение

Цель: проверить работу maintenance mode.

1. Зафиксировать текущее состояние CARP VIP на обоих узлах
2. Перевести primary в maintenance mode
3. Проверить доступность сервисов (HTTP, DNS, VPN)
4. Вывести primary из maintenance mode
5. Убедиться, что primary вернул статус MASTER

Тест 2: Отказ интерфейса

Цель: проверить автоматическое переключение при потере связи.

1. Отключить сетевой кабель WAN на primary-узле
2. Наблюдать за переключением CARP VIP на WAN
3. Проверить, что LAN CARP VIP также переключился (при настройке peer IP monitoring)
4. Подключить кабель обратно
5. Убедиться, что primary вернул статус MASTER (preemption)

Внимание:

При тестировании отключения интерфейса поведение зависит от настройки CARP. По умолчанию pfSense переключает только CARP VIP на затронутом интерфейсе. Для переключения всех VIP при отказе одного интерфейса необходимо настроить IP monitoring через System > High Avail. Sync, указав IP-адреса для мониторинга (например, адрес шлюза провайдера).

Тест 3: Полный отказ узла

Цель: проверить поведение при выключении primary-узла.

1. Выключить primary-узел (power off)
2. Дождаться переключения всех CARP VIP на secondary (~3 секунды)
3. Проверить доступность всех сервисов с secondary
4. Проверить сохранность существующих TCP-сессий
5. Включить primary обратно
6. Убедиться, что primary вернул статус MASTER и синхронизация восстановилась

Тест 4: Восстановление IPsec/OpenVPN

Цель: проверить восстановление VPN-туннелей после failover.

1. Установить IPsec и/или OpenVPN-соединения через кластер
2. Выполнить плановое переключение на secondary
3. Зафиксировать время восстановления каждого туннеля
4. Проверить прохождение трафика через восстановленные туннели
5. Вернуть primary в активное состояние

Документирование результатов

Результаты каждого теста следует документировать в формате:

Мониторинг состояния HA

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

Встроенные средства мониторинга

Внешний мониторинг

Для production-кластеров рекомендуется настроить внешний мониторинг:

• SNMP: pfSense поддерживает SNMP для мониторинга через Zabbix, Nagios или аналогичные системы. Мониторить следует статус CARP VIP, количество состояний, загрузку CPU и памяти.
• Syslog: настроить отправку журналов на удалённый syslog-сервер для сохранения истории событий CARP и синхронизации.
• Wazuh: при интеграции pfSense с Wazuh журналы CARP-событий могут быть обработаны правилами детекции для генерации алертов при незапланированных переключениях.

Ключевые метрики

Ограничения HA в pfSense

При проектировании HA-кластера необходимо учитывать архитектурные ограничения платформы.

Active/Active не поддерживается

pfSense официально поддерживает только active/passive конфигурацию. Режим active/active (когда оба узла одновременно обрабатывают трафик с балансировкой нагрузки) не реализован на уровне CARP и pfsync. Попытки организовать active/active через ручное распределение CARP VIP между узлами приводят к несимметричной маршрутизации и потере состояний.

Ограничение двух узлов

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

Зависимость от Layer 2

CARP в режиме multicast требует, чтобы оба узла находились в одном broadcast-домене для каждого интерфейса с CARP VIP. Это ограничивает географическое распределение кластера - узлы не могут быть размещены в разных дата-центрах без организации L2-связности (например, через VXLAN или MPLS L2VPN).

Split-brain

При потере связности между узлами (отказ sync-интерфейса) оба узла могут перейти в состояние MASTER. Это приводит к:

• Дублированию DHCP-адресов (если пулы не разделены)
• Конфликту MAC-адресов CARP VIP в сетевом сегменте
• Несогласованности таблиц состояний

Для минимизации риска split-brain рекомендуется использовать отдельный физический линк для sync-интерфейса и мониторить его доступность.

Миграция с других платформ

Миграция с Cisco ASA Failover

При переходе с Cisco ASA Active/Standby failover на pfSense HA необходимо учитывать различия в архитектуре:

Порядок миграции:

1. Документировать текущую конфигурацию ASA failover (show failover, show running-config)
2. Спланировать адресацию для pfSense HA (три адреса на интерфейс)
3. Настроить pfSense primary и secondary как описано в документации
4. Перенести правила файрвола, NAT и VPN на primary-узел
5. Настроить XMLRPC-синхронизацию
6. Протестировать failover до переключения production-трафика
7. Переключить production-трафик на pfSense HA

Миграция с FortiGate HA Cluster

FortiGate поддерживает как active/passive, так и active/active HA. При миграции на pfSense необходимо учитывать:

При миграции с FortiGate active/active конфигурации необходимо перепроектировать архитектуру под active/passive модель pfSense. Это может потребовать изменения балансировки трафика на уровне вышестоящего маршрутизатора или коммутатора.

Порядок миграции аналогичен переходу с Cisco ASA: документация, планирование, настройка, тестирование, переключение.

Восстановление после аварии

При полном отказе обоих узлов кластера (например, при потере электропитания в серверной) процедура восстановления зависит от наличия резервных копий конфигурации.

Восстановление с резервной копией

1. Включить оба узла
2. Дождаться загрузки pfSense на обоих узлах
3. Проверить статус CARP - при корректной конфигурации primary должен стать MASTER
4. Проверить синхронизацию pfsync и XMLRPC
5. Если конфигурация повреждена, восстановить из backup через Diagnostics > Backup & Restore

Восстановление при потере одного узла

1. Backup-узел автоматически принимает роль MASTER
2. Заменить неисправный узел
3. Установить pfSense и восстановить базовую конфигурацию (hostname, IP-адреса, sync-интерфейс)
4. Настроить XMLRPC на primary для синхронизации с новым secondary
5. Инициировать полную синхронизацию через System > High Avail. Sync (нажать Save)
6. Проверить статус CARP и таблицу состояний

Связанные разделы

• CARP и Virtual IPs - настройка CARP VIP, VHID и Advertising Frequency
• Синхронизация конфигурации - детальная настройка pfsync и XMLRPC
• VPN в pfSense - конфигурация IPsec и OpenVPN для работы с CARP VIP
• NAT в pfSense - настройка исходящего NAT с CARP VIP в multi-WAN конфигурации
• Multi-WAN - gateway groups и policy routing в контексте HA