Синхронизация конфигурации pfSense - pfsync и XMLRPC

Синхронизация конфигурации и состояний - фундаментальный механизм, обеспечивающий корректную работу HA-кластера pfSense. Без синхронизации резервный узел не будет располагать актуальными правилами файрвола и таблицей соединений, что приведёт к разрыву существующих сессий при переключении. В pfSense за синхронизацию отвечают два независимых механизма: pfsync для таблицы состояний и XMLRPC для конфигурации. Каждый из них решает свою задачу и настраивается отдельно.

Синхронизация таблицы состояний (pfsync)

pfsync - протокол уровня ядра FreeBSD, обеспечивающий репликацию таблицы состояний межсетевого экрана pf между узлами кластера. Таблица состояний (state table) содержит информацию обо всех активных соединениях, проходящих через файрвол: TCP-сессии, UDP-потоки, ICMP-обмены и трансляции NAT.

При каждом создании, изменении или удалении записи в таблице состояний на одном узле pfsync передаёт обновление на партнёрский узел. Благодаря этому при переключении на backup-узел существующие сессии сохраняются - клиенты сети не наблюдают разрывов соединений.

Что синхронизирует pfsync

Что НЕ синхронизирует pfsync

pfsync передаёт исключительно таблицу состояний. Следующие данные не входят в область действия pfsync:

• Правила файрвола и NAT (передаются через XMLRPC)
• Конфигурация интерфейсов
• Маршруты и таблицы ARP
• Очереди трафик-шейпера
• Содержимое таблиц pf (aliases, bogons, snort blocklist)

Механизм работы

pfsync работает на канальном уровне (Layer 2), используя протокол IP номер 240 (PFSYNC). По умолчанию обновления отправляются multicast-адресу 224.0.0.240 на указанном sync-интерфейсе. При наличии выделенного sync-линка между двумя узлами multicast-трафик остаётся в пределах этого сегмента.

Обновления отправляются пакетами (batch mode) для снижения накладных расходов. pfSense группирует несколько изменений состояний в один pfsync-пакет и отправляет их с интервалом, определяемым параметром Defer updates. При включённом отложенном обновлении (по умолчанию) система ожидает незначительное время перед отправкой, чтобы объединить несколько изменений в один пакет. Это снижает нагрузку на sync-интерфейс ценой минимальной задержки в синхронизации.

Настройка pfsync

Конфигурация pfsync выполняется на primary-узле через System > High Avail. Sync в секции State Synchronization Settings (pfsync).

Если поле pfsync Synchronize Peer IP оставлено пустым, pfsync будет отправлять обновления multicast-адресу. Указание конкретного IP-адреса переключает pfsync в режим unicast, что рекомендуется для production-кластеров.

Внимание:

На secondary-узле необходимо выполнить аналогичную настройку, указав в поле pfsync Synchronize Peer IP адрес primary-узла (например, 172.16.1.2). В отличие от XMLRPC, pfsync настраивается на обоих узлах кластера.

Оценка полосы пропускания

Объём pfsync-трафика зависит от интенсивности создания и изменения соединений. Каждое обновление состояния занимает порядка 300-400 байт. Для оценки необходимой полосы пропускания sync-интерфейса следует учитывать:

Для типовой инсталляции с 10 000 активных соединений и 500 новых соединений в секунду pfsync генерирует порядка 200-300 Кбит/с трафика на sync-интерфейсе. При высоконагруженных системах с десятками тысяч новых соединений в секунду эта величина может достигать единиц мегабит в секунду.

Для sync-интерфейса рекомендуется использовать соединение не менее 1 Гбит/с. В средах с крайне высокой нагрузкой (более 50 000 соединений в секунду) следует рассмотреть 10 Гбит/с интерфейс или разделение pfsync и XMLRPC по отдельным интерфейсам.

Синхронизация конфигурации (XMLRPC)

XMLRPC (XML Remote Procedure Call) - механизм репликации конфигурации pfSense с primary-узла на secondary. В отличие от pfsync, XMLRPC работает на прикладном уровне и передаёт не состояния соединений, а структурированные данные конфигурации - правила файрвола, NAT, VPN-туннели, алиасы и другие параметры.

Направление синхронизации

XMLRPC работает строго однонаправленно: с primary-узла на secondary. Все изменения конфигурации необходимо вносить исключительно на primary-узле. При корректной настройке каждое сохранение изменений на primary автоматически инициирует передачу обновлённой секции конфигурации на secondary.

Внимание:

Изменения, внесённые напрямую на secondary-узле, будут перезаписаны при следующей синхронизации с primary. Единственное исключение - параметры, которые явно исключены из синхронизации (hostname, IP-адреса интерфейсов, настройки CARP skew).

Настройка XMLRPC

Конфигурация XMLRPC выполняется только на primary-узле через System > High Avail. Sync в секции Configuration Synchronization Settings (XMLRPC Sync).

XMLRPC использует HTTPS (TCP 443) для передачи данных. На sync-интерфейсе secondary-узла должен быть разрешён входящий трафик на порт 443 от IP-адреса primary-узла.

Области синхронизации

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

Что НЕ следует синхронизировать

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

• Hostname и domain - каждый узел должен иметь уникальное имя для идентификации в кластере и журналах
• IP-адреса интерфейсов - индивидуальные адреса на каждом интерфейсе уникальны для каждого узла
• Настройки CARP skew - skew автоматически корректируется для обеспечения правильной иерархии приоритетов
• Параметры pfsync - конфигурация pfsync (Peer IP) различается на каждом узле

При необходимости можно отключить синхронизацию дополнительных секций. Типичный пример - DHCP Server, если диапазоны адресов на primary и secondary различаются (например, при разделении пула адресов между узлами для предотвращения конфликтов при split-brain).

Особенности синхронизации DHCP

При синхронизации DHCP-сервера оба узла получают идентичную конфигурацию диапазонов. В штатном режиме DHCP-сервер активен только на master-узле, поскольку клиенты обращаются к CARP VIP, назначенному в качестве default gateway. Однако при split-brain сценарии (оба узла считают себя master) два DHCP-сервера с одинаковыми диапазонами могут выдать один и тот же адрес разным клиентам.

Для предотвращения конфликтов при split-brain рекомендуется либо разделить DHCP-пул между узлами вручную, либо использовать DHCP Failover (ISC DHCP failover peer), если версия pfSense его поддерживает.

Выделенный интерфейс синхронизации

Как pfsync, так и XMLRPC используют sync-интерфейс для обмена данными между узлами. Выделение отдельного физического или виртуального интерфейса для синхронизации является обязательной рекомендацией для production-кластеров.

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

Почему нельзя использовать LAN или WAN

Использование LAN или WAN интерфейса для синхронизации создаёт несколько рисков:

1. Безопасность - pfsync передаёт данные в открытом виде, включая содержимое таблицы состояний. На общем сегменте эти данные доступны для перехвата.
2. Производительность - трафик синхронизации конкурирует с пользовательским трафиком, что может привести к задержкам синхронизации при высокой нагрузке.
3. Надёжность - проблемы на LAN/WAN интерфейсе (перегрузка, сбой коммутатора) одновременно нарушают и синхронизацию, и обслуживание трафика.

Конфигурация sync-интерфейса

На обоих узлах кластера необходимо:

1. Назначить физический интерфейс для синхронизации через Interfaces > Interface Assignments (если ещё не назначен)
2. Перейти в Interfaces > Sync и задать статический IP-адрес:
   • Primary: 172.16.1.2/24
   • Secondary: 172.16.1.3/24
3. Включить интерфейс (Enable Interface)
4. Не указывать шлюз - sync-интерфейс не должен иметь шлюза по умолчанию

Правила файрвола на sync-интерфейсе

На sync-интерфейсе необходимо создать правила, разрешающие трафик синхронизации. Минимальный набор правил:

Более простой вариант - создать одно правило, разрешающее весь трафик на sync-интерфейсе между адресами узлов. Поскольку sync-интерфейс изолирован от остальных сетей, это не создаёт дополнительных рисков безопасности.

Проверка работоспособности синхронизации

Проверка pfsync

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

На primary-узле выполнить через Diagnostics > States:

• Зафиксировать количество активных состояний
• Инициировать новое соединение (например, открыть веб-страницу через файрвол)
• Проверить, что новое состояние появилось в таблице

На secondary-узле выполнить аналогичную проверку:

• Перейти в Diagnostics > States
• Убедиться, что количество состояний примерно совпадает с primary
• Найти запись о том же соединении, что было создано на primary

Также можно использовать командную строку:

pfctl -s info | grep "current entries"

Значения на обоих узлах должны быть близки (допускается незначительное расхождение в десятки записей из-за задержки синхронизации).

Проверка XMLRPC

Для проверки XMLRPC-синхронизации:

1. На primary-узле создать тестовый алиас через Firewall > Aliases (например, test_sync_alias с одним IP-адресом)
2. Нажать Save и Apply Changes
3. На secondary-узле перейти в Firewall > Aliases и убедиться, что тестовый алиас появился
4. После проверки удалить тестовый алиас на primary - он должен быть удалён и на secondary

В журнале Status > System Logs > System > General на secondary-узле должны присутствовать записи об успешном получении конфигурации от primary.

Мониторинг состояния синхронизации

Состояние CARP и синхронизации можно проверить через Status > CARP (failover). Страница отображает:

• Текущий статус каждого CARP VIP (MASTER/BACKUP)
• Время последней синхронизации
• Ошибки синхронизации (если присутствуют)

Диагностика проблем синхронизации

XMLRPC sync fails

Симптом: изменения на primary не появляются на secondary.

Возможные причины и решения:

Частичная синхронизация

Симптом: некоторые области конфигурации синхронизируются, другие - нет.

Это обычно вызвано отключёнными флагами в секции XMLRPC Sync Settings. Необходимо проверить, что все требуемые области отмечены флагами на primary-узле.

Также частичная синхронизация может возникнуть при наличии конфликтов в конфигурации. Например, если на secondary-узле вручную создана запись с тем же идентификатором, что и на primary, XMLRPC может не выполнить перезапись. В таком случае рекомендуется удалить конфликтующую запись на secondary и повторно инициировать синхронизацию.

Для принудительной повторной синхронизации на primary-узле перейти в System > High Avail. Sync и нажать Save без внесения изменений - это инициирует повторную передачу всех отмеченных областей.

Проблемы с сертификатами

Симптом: XMLRPC-синхронизация завершается ошибкой SSL/TLS.

XMLRPC использует HTTPS для подключения к secondary-узлу. Если self-signed сертификат веб-интерфейса secondary истёк или повреждён, синхронизация завершится ошибкой.

Решение:

1. На secondary-узле перейти в System > Cert. Manager > Certificates
2. Найти сертификат webConfigurator default (или аналогичный)
3. Проверить срок действия - если сертификат истёк, удалить его
4. Перейти в System > Advanced > Admin Access и сгенерировать новый self-signed сертификат
5. На primary-узле повторно сохранить настройки XMLRPC для инициации синхронизации

pfsync не работает

Симптом: таблица состояний на secondary пуста или существенно отличается от primary.

Высокая задержка синхронизации

Симптом: состояния на secondary появляются с заметной задержкой (секунды).

При включённом режиме Defer updates pfsync накапливает изменения перед отправкой. Если задержка критична (например, для кластеров с агрессивным failover), режим отложенных обновлений можно отключить. Однако это увеличит нагрузку на sync-интерфейс и CPU обоих узлов.

Также задержку может вызывать перегрузка sync-интерфейса. Если pfsync-трафик превышает пропускную способность интерфейса, обновления будут отбрасываться. В этом случае необходимо увеличить скорость sync-линка или оптимизировать количество отслеживаемых состояний.

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

• CARP и Virtual IPs - настройка CARP VIP, требования к адресации и оборудованию кластера
• Сценарии отказоустойчивости - тестирование переключения, планирование обслуживания и мониторинг кластера
• Правила файрвола - настройка правил на sync-интерфейсе для разрешения трафика XMLRPC и pfsync
• VPN в pfSense - особенности синхронизации IPsec и OpenVPN в HA-кластере