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

> Настройка CARP в pfSense - создание Virtual IP адресов, требования к IP-адресации, конфигурация CARP VHID и проверка работоспособности кластера

Source: https://opennix.org/docs/pfsense/high-availability/pfsense-carp-setup/


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-адреса в одной подсети.

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

| Назначение | WAN | LAN | Sync |
|---|---|---|---|
| Primary node | 198.51.100.201/24 | 192.168.1.2/24 | 172.16.1.2/24 |
| Secondary node | 198.51.100.202/24 | 192.168.1.3/24 | 172.16.1.3/24 |
| CARP VIP | 198.51.100.200/24 | 192.168.1.1/24 | - |

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

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

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

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

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

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

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

| Интерфейс | Primary | Secondary | CARP VIP |
|---|---|---|---|
| WAN | .201 | .202 | .200 |
| LAN | .2 | .3 | .1 |
| DMZ | 10.0.1.2 | 10.0.1.3 | 10.0.1.1 |
| OPT1 | 10.0.2.2 | 10.0.2.3 | 10.0.2.1 |
| Sync | 172.16.1.2 | 172.16.1.3 | - |

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

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

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

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

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

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

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

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

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

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

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

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

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

| Требование | Описание |
|---|---|
| Multicast-трафик | CARP в режиме multicast использует адрес 224.0.0.18. Коммутатор не должен блокировать или фильтровать этот трафик |
| Несколько MAC-адресов на порту | Каждый CARP VIP использует виртуальный MAC-адрес формата 00:00:5e:00:01:XX (где XX - VHID) |
| Миграция MAC-адресов | При переключении master виртуальный MAC перемещается на другой порт коммутатора |

На управляемых коммутаторах необходимо проверить, что функции 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 необходимо указать следующие параметры:

| Параметр | Описание | Рекомендация |
|---|---|---|
| **Type** | Тип виртуального IP | Выбрать CARP |
| **Interface** | Интерфейс привязки | WAN, LAN или другой интерфейс |
| **Address(es)** | IP-адрес и маска подсети | Адрес из подсети интерфейса, маска совпадает с маской интерфейса |
| **Virtual IP Password** | Пароль для аутентификации CARP | Сгенерировать случайную строку, одинаковую на обоих узлах |
| **VHID Group** | Идентификатор виртуальной группы (1-255) | Уникальный в пределах broadcast-домена |
| **Advertising Frequency** | Base и Skew для управления приоритетом | Base: 1, Skew: 0 для master |

![CARP Virtual IP на узле](/img/pfsense/pfsense-ha-carp-vips.webp)
<p style="text-align: center;">Рис. 1. Настроенные CARP Virtual IP (WAN и LAN)</p>

### Назначение VHID

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

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

| Интерфейс | Протокол | VHID |
|---|---|---|
| WAN | IPv4 | 200 |
| WAN | IPv6 | 201 |
| LAN | IPv4 | 1 |
| LAN | IPv6 | 2 |
| DMZ | IPv4 | 10 |
| OPT1 | IPv4 | 20 |

Значения 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**.

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

| Параметр | Значение |
|---|---|
| Type | CARP |
| Interface | WAN |
| Address(es) | 198.51.100.200/24 |
| Virtual IP Password | (случайная строка) |
| VHID Group | 200 |
| Advertising Frequency | Base: 1, Skew: 0 |
| Description | WAN CARP VIP |

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

### Создание LAN CARP VIP

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

| Параметр | Значение |
|---|---|
| Type | CARP |
| Interface | LAN |
| Address(es) | 192.168.1.1/24 |
| Virtual IP Password | (случайная строка) |
| VHID Group | 1 |
| Advertising Frequency | Base: 1, Skew: 0 |
| Description | LAN CARP VIP |

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

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

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

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

| Параметр | Значение |
|---|---|
| Type | CARP |
| Interface | DMZ |
| Address(es) | 10.0.1.1/24 |
| Virtual IP Password | (случайная строка) |
| VHID Group | 10 |
| Advertising Frequency | Base: 1, Skew: 0 |
| Description | DMZ CARP VIP |

### IPv6 CARP VIP

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

| Параметр | Значение |
|---|---|
| Type | CARP |
| Interface | WAN |
| Address(es) | 2001:db8::200/64 |
| VHID Group | 201 |
| Advertising Frequency | Base: 1, Skew: 0 |
| Description | WAN CARP VIP 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:

| Параметр | Primary | Secondary |
|---|---|---|
| Type | CARP | CARP |
| Interface | WAN | WAN |
| Address(es) | 198.51.100.200/24 | 198.51.100.200/24 |
| Virtual IP Password | (совпадает) | (совпадает) |
| VHID Group | 200 | 200 |
| Advertising Frequency Base | 1 | 1 |
| Advertising Frequency Skew | 0 | 100 |

Значение 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.

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

| Узел | Ожидаемый статус всех VIP |
|---|---|
| Primary | MASTER |
| Secondary | BACKUP |

Если все 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 или консоль:

```bash
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**

![Правило исходящего NAT с CARP VIP](/img/pfsense/pfsense-ha-outbound-nat.webp)
<p style="text-align: center;">Рис. 2. Правило Outbound NAT с привязкой к CARP VIP</p>

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

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

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

| Параметр | Значение |
|---|---|
| Interface | WAN |
| Destination | WAN CARP VIP (198.51.100.200) |
| Destination Port | Порт сервиса |
| Redirect Target IP | Внутренний IP сервера |

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

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

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

### DHCP-сервер

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

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

| Параметр | Значение |
|---|---|
| DNS Servers | 192.168.1.1 (LAN CARP VIP) |
| Gateway | 192.168.1.1 (LAN CARP VIP) |

Это гарантирует, что клиенты сети обращаются к виртуальному адресу, который всегда обслуживается активным узлом кластера. При указании индивидуального адреса одного из узлов клиенты потеряют доступ к шлюзу и 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 | pfSense | Примечание |
|---|---|---|
| Failover pair (active/standby) | CARP cluster (master/backup) | Аналогичная модель active/passive |
| Failover IP address | CARP VIP | Виртуальный адрес для клиентов |
| Stateful failover | pfsync | Синхронизация таблицы состояний |
| Failover link | Sync interface | Выделенный интерфейс синхронизации |
| Failover key | CARP password | Аутентификация между узлами |
| Primary/Secondary unit | Primary/Secondary node | Роли узлов в кластере |
| Monitored interfaces | CARP VIP per interface | pfSense мониторит каждый CARP VIP отдельно |
| Preempt | Skew values | Управление приоритетом через значение Skew |

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

### Fortinet FortiGate HA

| FortiGate HA | pfSense | Примечание |
|---|---|---|
| HA cluster (active-passive) | CARP cluster | Аналогичная модель |
| Virtual MAC/IP | CARP VIP + виртуальный MAC | Автоматическое назначение MAC 00:00:5e:00:01:XX |
| Heartbeat interface | Sync interface | Выделенный интерфейс |
| HA priority | CARP Skew | 0 = highest priority |
| Session pickup | pfsync | Синхронизация состояний |
| Config sync | XMLRPC | Синхронизация конфигурации |
| HA group ID | VHID | Идентификатор виртуальной группы |

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

### MikroTik VRRP

| MikroTik VRRP | pfSense CARP | Примечание |
|---|---|---|
| VRRP interface | CARP VIP | Виртуальный IP-адрес |
| VRID | VHID | Идентификатор виртуального маршрутизатора |
| Priority (0-255) | Skew (0-240) | Инвертированная логика: VRRP 255 = highest, CARP 0 = highest |
| Preempt mode | Всегда активен | pfSense CARP всегда работает в режиме preempt |
| Authentication | CARP password | Аутентификация heartbeat |
| Sync connection tracking | pfsync | MikroTik требует отдельной настройки connection tracking sync |

Ключевое различие: в 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.

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

```bash
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 выполнить:

```bash
tcpdump -i em0 proto carp
```

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

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

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

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

```bash
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-события могут быть использованы для создания правил оповещения о переключениях в кластере.

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

- [Синхронизация конфигурации](/docs/pfsense/high-availability/pfsense-config-sync/) - настройка XMLRPC и pfsync для полноценной работы кластера
- [Сценарии отказоустойчивости](/docs/pfsense/high-availability/pfsense-failover-scenarios/) - тестирование и планирование отказов
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - настройка правил для sync-интерфейса
- [Исходящий NAT](/docs/pfsense/nat/pfsense-outbound-nat/) - привязка правил NAT к CARP VIP
- [VPN в pfSense](/docs/pfsense/vpn/) - привязка VPN-туннелей к CARP VIP для отказоустойчивости