CARP и Virtual IPs в pfSense - настройка кластера HA

CARP (Common Address Redundancy Protocol) - протокол отказоустойчивости сетевого уровня, разработанный командой OpenBSD как свободная от патентных ограничений альтернатива Cisco HSRP и стандарту VRRP. В pfSense CARP обеспечивает автоматическое переключение виртуальных IP-адресов между узлами кластера при отказе основного узла. Клиенты сети обращаются к виртуальному адресу (CARP VIP), который всегда обслуживается активным узлом - переключение происходит прозрачно, без необходимости изменения сетевых настроек на клиентских устройствах.

Каждый узел кластера периодически отправляет heartbeat-сообщения по каждому интерфейсу, на котором сконфигурирован CARP VIP. При стандартных параметрах частоты (base 1, skew 0 для master) heartbeat отправляется примерно раз в секунду. Узел с наименьшим значением skew отправляет heartbeat быстрее и принимает роль master. Если backup-узел перестаёт получать heartbeat в течение заданного интервала, он повышает свой статус до master и начинает обрабатывать трафик, направленный на CARP VIP.

Требования к IP-адресации

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

Схема адресации

Sync-интерфейс не требует CARP VIP, поскольку он используется исключительно для прямого обмена данными между узлами кластера (pfsync и XMLRPC).

Требования к размеру подсетей

Для WAN-интерфейса минимально необходима подсеть /29 (6 usable-адресов), позволяющая разместить два адреса узлов, CARP VIP и адрес шлюза провайдера. В production-средах рекомендуется использовать /28 или шире для обеспечения запаса адресов при расширении кластера или добавлении дополнительных CARP VIP.

Для LAN-интерфейса ограничений на размер подсети обычно нет - стандартная подсеть /24 предоставляет достаточный адресный ресурс.

Внимание:

CARP VIP должен находиться в той же подсети, что и индивидуальные адреса узлов на данном интерфейсе. Использование адреса из другой подсети приведёт к неработоспособности CARP на этом интерфейсе.

Адресация для дополнительных интерфейсов

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

Подготовка оборудования

Надёжность HA-кластера напрямую зависит от качества подготовки аппаратной платформы и сетевой инфраструктуры.

Требования к оборудованию узлов

Оба узла кластера должны иметь идентичную конфигурацию сетевых интерфейсов. Это критическое требование - pfSense выполняет синхронизацию конфигурации через XMLRPC на основании порядка назначения интерфейсов (interface assignment). Если порядок интерфейсов различается между узлами, синхронизация правил файрвола, NAT и других параметров приведёт к некорректным результатам.

Рекомендации по оборудованию:

• Идентичные модели сетевых адаптеров на обоих узлах для обеспечения одинакового порядка назначения интерфейсов
• Одинаковая версия pfSense на обоих узлах
• Достаточный объём оперативной памяти для хранения таблицы состояний (pfsync реплицирует все состояния)
• Раздельные источники питания для исключения единой точки отказа

Внимание:

Интерфейсы на обоих узлах должны быть назначены в строго одинаковом порядке. Если на primary-узле WAN назначен на igb0, LAN на igb1 и Sync на igb2, то на secondary-узле должно быть точно такое же соответствие. Несовпадение приведёт к некорректной синхронизации конфигурации.

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

Для обмена данными pfsync и XMLRPC между узлами необходимо выделить отдельный сетевой интерфейс. Использование LAN или WAN-интерфейса для синхронизации технически возможно, но крайне не рекомендуется по следующим причинам:

• Трафик синхронизации состояний может быть значительным при высокой нагрузке
• pfsync передаёт данные в открытом виде - перехват на общем сегменте представляет угрозу безопасности
• Выделенный интерфейс исключает влияние основного трафика на синхронизацию

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

Конфигурация коммутатора

Коммутатор, к которому подключены оба узла кластера, должен поддерживать следующие функции:

На управляемых коммутаторах необходимо проверить, что функции port security, MAC address limiting или DHCP snooping не блокируют работу CARP. Эти механизмы защиты могут интерпретировать появление нового MAC-адреса на порту или multicast-трафик CARP как аномалию.

В средах, где multicast-трафик недоступен или заблокирован (некоторые cloud-провайдеры, определённые конфигурации коммутаторов), pfSense Plus поддерживает unicast-режим CARP. В этом режиме heartbeat-сообщения отправляются напрямую на IP-адрес партнёрского узла вместо multicast-группы.

Создание Virtual IP

Виртуальные IP-адреса CARP создаются через веб-интерфейс pfSense в разделе Firewall > Virtual IPs. Настройка выполняется только на primary-узле - при корректно настроенной синхронизации XMLRPC виртуальные адреса автоматически реплицируются на secondary-узел.

Параметры CARP VIP

При создании нового Virtual IP типа CARP необходимо указать следующие параметры:

Рис. 1. Создание Virtual IP типа CARP

Назначение VHID

VHID (Virtual Host ID) - уникальный идентификатор виртуальной группы CARP в пределах одного broadcast-домена (VLAN или физического сегмента). Значение VHID находится в диапазоне от 1 до 255.

Рекомендуемая схема назначения VHID:

Значения VHID не должны пересекаться в пределах одного broadcast-домена. Если в сегменте присутствуют несколько независимых CARP-кластеров (например, два кластера pfSense на одном WAN-сегменте), каждый из них должен использовать уникальные VHID.

Внимание:

Конфликт VHID между независимыми кластерами в одном broadcast-домене приводит к непредсказуемому поведению - оба кластера будут конкурировать за одну виртуальную группу, вызывая постоянные переключения ролей master/backup.

Advertising Frequency

Параметр Advertising Frequency определяет частоту отправки CARP heartbeat и состоит из двух компонентов:

• Base - базовый интервал в секундах (по умолчанию 1)
• Skew - дополнительная задержка в единицах 1/256 секунды

Узел с наименьшим значением (base + skew/256) отправляет heartbeat чаще и становится master. На primary-узле следует использовать skew 0, на secondary - skew 100 или выше. Чем больше значение skew, тем ниже приоритет узла.

При синхронизации через XMLRPC значения skew автоматически корректируются на secondary-узле, обеспечивая правильную иерархию приоритетов.

Настройка CARP на Primary

Конфигурация CARP на основном узле выполняется в первую очередь. Все настройки впоследствии реплицируются на secondary через XMLRPC.

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

Перед созданием CARP VIP на primary-узле необходимо выполнить:

1. Назначить все сетевые интерфейсы через Interfaces > Interface Assignments
2. Сконфигурировать статические IP-адреса на каждом интерфейсе (WAN, LAN, Sync)
3. Убедиться, что primary-узел имеет сетевой доступ к шлюзу провайдера
4. Задать уникальное hostname для primary-узла через System > General Setup

Создание WAN CARP VIP

Перейти в Firewall > Virtual IPs и нажать Add.

Заполнить параметры:

Нажать Save, затем Apply Changes.

Рис. 2. Параметры WAN CARP VIP на primary-узле

Создание LAN CARP VIP

Повторить процедуру для LAN-интерфейса:

Нажать Save, затем Apply Changes.

Дополнительные интерфейсы

Для каждого дополнительного интерфейса (DMZ, OPT1, OPT2) необходимо создать отдельный CARP VIP по аналогичной процедуре. Каждый VIP должен иметь уникальный VHID в пределах своего broadcast-домена.

Пример для DMZ-интерфейса:

IPv6 CARP VIP

При использовании двойного стека (dual-stack) для каждого IPv6-адреса необходимо создать отдельный CARP VIP с собственным VHID. Процедура аналогична IPv4, но в поле Address указывается IPv6-адрес с соответствующей длиной префикса.

Настройка CARP на Secondary

Конфигурация secondary-узла выполняется после завершения настройки primary. При корректно работающей синхронизации XMLRPC CARP VIP создаются автоматически на secondary-узле. Если синхронизация ещё не настроена, виртуальные адреса необходимо создать вручную.

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

На secondary-узле необходимо выполнить:

1. Назначить интерфейсы в точно таком же порядке, как на primary
2. Задать уникальные статические IP-адреса на каждом интерфейсе (отличные от primary)
3. Указать уникальное hostname через System > General Setup
4. Убедиться в сетевой связности между узлами через sync-интерфейс

Внимание:

Не подключайте secondary-узел к LAN-коммутатору до тех пор, пока на нём не сконфигурированы уникальные адреса, отличные от адресов primary-узла. Подключение двух узлов с одинаковыми адресами к одному сегменту вызовет конфликт IP-адресов и потерю связности.

Ручное создание VIP на Secondary

Если XMLRPC-синхронизация ещё не настроена, создать CARP VIP вручную с идентичными параметрами, изменив только значение Skew:

Значение Skew 100 на secondary обеспечивает, что при штатной работе обоих узлов primary всегда будет отправлять heartbeat раньше и удерживать роль master. Чем выше значение Skew, тем ниже приоритет узла в выборах master.

Автоматическая синхронизация VIP

При настроенной XMLRPC-синхронизации CARP VIP создаются на secondary автоматически. pfSense автоматически корректирует значение Skew на secondary-узле, обеспечивая правильную иерархию приоритетов. В этом случае ручное создание VIP на secondary не требуется и не рекомендуется - дублирование может привести к конфликтам.

Проверка статуса

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

Просмотр статуса CARP

Перейти в Status > CARP (failover) на каждом узле. Страница отображает текущее состояние каждого CARP VIP.

Рис. 3. Статус CARP - primary-узел в состоянии MASTER

Корректное состояние кластера:

Если все VIP на primary отображаются как MASTER, а на secondary как BACKUP, кластер работает корректно.

Тест ручного переключения

pfSense позволяет выполнить плановое переключение без физического отключения оборудования. На странице Status > CARP (failover) primary-узла нажать кнопку Enter Persistent CARP Maintenance Mode. Это переведёт все VIP primary-узла в состояние BACKUP, и secondary примет роль MASTER.

Порядок тестирования:

1. На primary перейти в Status > CARP (failover)
2. Нажать Enter Persistent CARP Maintenance Mode
3. Убедиться, что все VIP на primary перешли в BACKUP
4. На secondary проверить, что все VIP перешли в MASTER
5. Проверить доступность сервисов через CARP VIP
6. На primary нажать Leave Persistent CARP Maintenance Mode
7. Убедиться, что primary вернул статус MASTER для всех VIP

Проверка из командной строки

Статус CARP можно проверить через SSH или консоль:

ifconfig | grep -A 2 carp

Вывод для master-узла:

carp: MASTER vhid 200 advbase 1 advskew 0
carp: MASTER vhid 1 advbase 1 advskew 0

Вывод для backup-узла:

carp: BACKUP vhid 200 advbase 1 advskew 100
carp: BACKUP vhid 1 advbase 1 advskew 100

Использование CARP VIP

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

Правила NAT

Все правила исходящего NAT (outbound NAT) должны использовать CARP VIP в качестве адреса трансляции (Translation Address). При использовании адреса интерфейса (Interface Address) трансляция будет работать только на том узле, который в данный момент является master. После переключения на secondary исходящий NAT перестанет функционировать, поскольку клиенты будут ожидать ответы с IP-адреса CARP VIP, а secondary будет транслировать через свой собственный адрес.

Настройка в Firewall > NAT, вкладка Outbound:

1. Переключить режим на Hybrid Outbound NAT rule generation
2. Создать правило:
   • Interface: WAN
   • Source: LAN Subnets (или конкретная подсеть)
   • Translation Address: выбрать CARP VIP (198.51.100.200)
3. Нажать Save, затем Apply Changes

Рис. 4. Правило Outbound NAT с привязкой к CARP VIP

Внимание:

Не используйте CARP VIP в качестве Source (адреса источника) в правилах outbound NAT для трафика самого файрвола. Это может нарушить работу протоколов, зависящих от адреса источника (DNS, NTP, обновления пакетов). Правила с CARP VIP должны применяться только к трафику внутренних подсетей.

Правила проброса портов

Правила Port Forward (Firewall > NAT > Port Forward) должны указывать CARP VIP в поле Destination:

При использовании адреса WAN-интерфейса вместо CARP VIP проброс портов будет работать только на одном узле.

Правила файрвола

Правила файрвола для входящего трафика на CARP VIP создаются автоматически при настройке Port Forward (если включена опция автоматического создания правила). Для ручных правил в качестве Destination следует указывать алиас или конкретный CARP VIP.

DHCP-сервер

Конфигурация DHCP-сервера должна использовать CARP VIP в качестве шлюза (gateway) и DNS-сервера, выдаваемых клиентам:

Настройка в Services > DHCP Server, вкладка LAN:

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

VPN-туннели

IPsec и OpenVPN-туннели следует привязывать к CARP VIP:

• IPsec: в параметрах Phase 1 указать CARP VIP в качестве Interface или Local Address
• OpenVPN: в настройках сервера или клиента указать CARP VIP в поле Interface

При использовании IPsec с CARP VIP необходимо создать отдельное правило outbound NAT для ISAKMP-трафика (порт 500/UDP) с флагом Static Port и привязкой к CARP VIP.

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

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

Cisco ASA Failover

В Cisco ASA failover-пара может выполнять автоматическое переключение как при отказе узла, так и при отказе отдельного интерфейса. В pfSense CARP работает per-interface - если на одном интерфейсе узел потерял связность, он может перейти в BACKUP только для этого интерфейса, оставаясь MASTER на остальных. Такое состояние (split master) требует дополнительного контроля через Gateway Groups или скрипты мониторинга.

Fortinet FortiGate HA

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

MikroTik VRRP

Ключевое различие: в MikroTik VRRP высокий priority (255) означает высший приоритет, в pfSense CARP низкий skew (0) означает высший приоритет. При планировании миграции необходимо инвертировать логику приоритетов.

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

Устранение неполадок

Оба узла в состоянии MASTER

Наиболее распространённая проблема - оба узла одновременно отображают статус MASTER для одних и тех же VIP. Возможные причины:

Блокировка multicast-трафика. CARP использует multicast-адрес 224.0.0.18 для heartbeat-сообщений. Если коммутатор или промежуточное сетевое оборудование блокирует multicast, узлы не получают heartbeat друг от друга и оба считают себя master.

Диагностика:

tcpdump -i em0 proto carp

Если heartbeat от второго узла не отображается, проблема в сетевой связности на уровне L2.

Несовпадение паролей CARP. Если пароли Virtual IP Password различаются между узлами, heartbeat-сообщения отклоняются как неаутентифицированные.

Решение: убедиться, что пароль CARP VIP идентичен на обоих узлах. При использовании XMLRPC-синхронизации пароль реплицируется автоматически.

Конфликт VHID. Наличие другого устройства в том же broadcast-домене с тем же VHID вызывает конкуренцию за виртуальную группу.

Решение: изменить VHID на уникальное значение, не используемое другими устройствами в сегменте.

Split brain

Состояние split brain возникает, когда оба узла являются master для разных наборов интерфейсов. Например, primary является MASTER на WAN, но BACKUP на LAN, а secondary - наоборот. Это приводит к асимметричной маршрутизации и потере связности.

Причины:

• Физический отказ одного из сетевых интерфейсов на одном узле
• Проблема с кабелем или портом коммутатора на отдельном интерфейсе
• Различные VLAN-конфигурации на портах коммутатора

Диагностика:

1. Проверить статус всех интерфейсов на обоих узлах через Status > CARP (failover)
2. Проверить физическое подключение каждого интерфейса через Status > Interfaces
3. Проверить логи CARP: Status > System Logs, вкладка System, фильтр по “carp”

Решение: устранить причину потери связности на конкретном интерфейсе. При невозможности быстрого устранения - временно перевести проблемный узел в maintenance mode для обеспечения целостности маршрутизации.

CARP не выполняет переключение

Если при отказе primary-узла secondary не принимает роль master:

Проверить heartbeat. На secondary выполнить:

tcpdump -i em0 proto carp

Если heartbeat от primary продолжает поступать, primary не в состоянии отказа - проблема в другом.

Проверить значение Skew. Если skew на secondary слишком велик (например, 240), переключение может занимать длительное время. Уменьшить skew до 100.

Проверить сетевой стек. Убедиться, что на secondary не заблокирован CARP-трафик правилами файрвола на соответствующем интерфейсе.

Проверить demotion counter. pfSense может автоматически увеличивать demotion counter при обнаружении проблем, блокируя переход в MASTER:

sysctl net.inet.carp.demotion

Значение 0 - нормальное. Ненулевое значение указывает на проблему, препятствующую принятию роли master.

Проблемы с multicast

В виртуализированных средах (VMware, Proxmox, Hyper-V) multicast-трафик CARP может блокироваться на уровне виртуального коммутатора.

VMware vSwitch/vDS:

• Включить Promiscuous Mode: Accept
• Включить Forged Transmits: Accept
• Включить MAC Address Changes: Accept

Proxmox (Linux Bridge):

• Убедиться, что мост не фильтрует multicast
• Проверить параметр multicast_snooping на мосте

Hyper-V:

• Включить MAC Address Spoofing на виртуальном адаптере
• Разрешить multicast в параметрах виртуального коммутатора

Медленное переключение

Если переключение при отказе primary занимает более 5-10 секунд:

• Уменьшить значение advbase до 1 (если ещё не установлено)
• Уменьшить skew на secondary (рекомендуется 100)
• Проверить нагрузку на CPU обоих узлов - при высокой нагрузке обработка CARP heartbeat может задерживаться
• Убедиться, что pfsync корректно синхронизирует состояния - без синхронизации secondary должен заново установить все соединения, что увеличивает время восстановления

Логирование CARP-событий

Для отслеживания переключений и диагностики проблем включить расширенное логирование CARP:

Status > System Logs > Settings:

• Log CARP State Changes: включить

События CARP записываются в системный журнал и доступны в Status > System Logs, вкладка System. При интеграции с внешней SIEM-системой (например, Wazuh) CARP-события могут быть использованы для создания правил оповещения о переключениях в кластере.

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

• Синхронизация конфигурации - настройка XMLRPC и pfsync для полноценной работы кластера
• Сценарии отказоустойчивости - тестирование и планирование отказов
• Правила файрвола - настройка правил для sync-интерфейса
• Исходящий NAT - привязка правил NAT к CARP VIP
• VPN в pfSense - привязка VPN-туннелей к CARP VIP для отказоустойчивости