Multi-WAN failover в pfSense - переключение каналов

Failover в контексте Multi-WAN - это автоматическое переключение трафика с основного интернет-канала на резервный при обнаружении отказа основного. pfSense реализует failover через механизм Gateway Groups с разделением шлюзов по уровням приоритета (tier). Шлюзы на более низком tier используются в первую очередь, а шлюзы на более высоком tier активируются только при недоступности всех шлюзов предыдущего уровня.

В отличие от балансировки нагрузки, где шлюзы работают параллельно на одном tier, failover-конфигурация назначает шлюзам разные tier, формируя цепочку приоритетов. Резервный канал находится в режиме ожидания (hot standby) и принимает трафик только при отказе основного.

Различия между failover и load balancing

Оба механизма используют Gateway Groups, но различаются логикой назначения tier:

Комбинированная конфигурация объединяет оба подхода. Например, два канала на Tier 1 обеспечивают балансировку, а третий канал на Tier 2 служит резервным для обоих:

В этой конфигурации трафик балансируется между WAN1 и WAN2. При отказе WAN1 весь трафик переходит на WAN2. При отказе обоих основных каналов активируется WAN3.

Мониторинг шлюзов для failover

Скорость и точность failover напрямую зависят от настроек мониторинга шлюзов. Агрессивные настройки обеспечивают быстрое переключение, но увеличивают риск ложных срабатываний. Консервативные настройки снижают риск ложных срабатываний, но увеличивают время обнаружения отказа.

Рекомендуемые параметры мониторинга

Для типичной failover-конфигурации рекомендуются следующие параметры:

Выбор Monitor IP

Выбор Monitor IP определяет, что именно проверяет система мониторинга:

Внимание:

Для каждого шлюза необходимо использовать уникальный Monitor IP. Если оба шлюза мониторят один и тот же адрес, отказ этого адреса (а не канала) приведёт к одновременному переключению обоих шлюзов в статус Down и полной потере связи.

Настройка dpinger

Демон dpinger выполняет мониторинг шлюзов. Его работу можно проверить через командную строку:

# Check dpinger processes
ps aux | grep dpinger

# View gateway status in real time
/usr/local/sbin/pfSsh.php playback gatewaystatus

Логи dpinger записываются в системный журнал и доступны в Status > System Logs > Gateways.

Создание Gateway Group для failover

Пошаговая настройка

1. Перейти в System > Routing > Gateway Groups.
2. Нажать Add.
3. Заполнить параметры группы:

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

Выбор Trigger Level для failover

Для failover-конфигурации выбор Trigger Level определяет чувствительность переключения:

Для production-конфигураций рекомендуется Packet Loss - этот уровень обеспечивает баланс между скоростью реакции и устойчивостью к кратковременным флуктуациям.

Применение Gateway Group к правилам файрвола

После создания Gateway Group для failover её необходимо назначить в правиле файрвола.

Настройка правила

1. Перейти в Firewall > Rules > LAN.
2. Создать или отредактировать правило для исходящего трафика.
3. В секции Extra Options нажать Display Advanced.
4. В поле Gateway выбрать WAN_Failover.
5. Нажать Save, затем Apply Changes.

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

DNS при failover

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

Настройка DNS для failover

1. В System > General Setup настроить DNS-серверы для каждого WAN:

2. В Services > DNS Resolver включить DNS Query Forwarding для использования настроенных upstream-серверов.
3. pfSense автоматически прекращает использование DNS-серверов, привязанных к недоступному шлюзу, и переключается на серверы, привязанные к доступному каналу.

Внимание:

Без DNS Query Forwarding DNS Resolver выполняет рекурсивные запросы напрямую к корневым серверам. В этом случае DNS-запросы маршрутизируются через шлюз по умолчанию. При failover шлюз по умолчанию изменяется автоматически, но переходный период может вызвать кратковременные задержки в разрешении имён.

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

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

Метод 1: физическое отключение

1. Открыть Status > Gateways для наблюдения за статусами.
2. Физически отключить кабель основного WAN-интерфейса.
3. Наблюдать за изменением статуса основного шлюза:
   • Статус должен измениться на Warning, затем на Down.
   • Время до изменения статуса зависит от настроек Time Period и порогов.
4. Проверить, что трафик переключился на резервный канал:
   • Открыть внешний сервис проверки IP (например, ifconfig.me).
   • IP-адрес должен соответствовать внешнему адресу резервного WAN.
5. Подключить кабель обратно и убедиться в возврате на основной канал.

Метод 2: блокировка Monitor IP

1. Создать временное правило файрвола на WAN-интерфейсе, блокирующее ICMP-трафик к Monitor IP основного шлюза.
2. Наблюдать за переключением в Status > Gateways.
3. После проверки удалить временное правило.

Этот метод позволяет тестировать failover без физического воздействия на оборудование.

Метод 3: изменение порогов

1. Временно установить порог Down на 0% для основного шлюза.
2. Любая потеря пакетов приведёт к немедленному переключению.
3. После проверки восстановить оригинальные пороговые значения.

Что проверять при тестировании

Поведение при восстановлении

После восстановления доступности основного шлюза pfSense автоматически возвращает трафик на основной канал (Tier 1). Поведение при восстановлении:

1. dpinger обнаруживает, что основной шлюз снова отвечает на probe-пакеты.
2. После накопления достаточного количества успешных ответов в пределах Time Period статус шлюза меняется на Online.
3. pfSense переключает новые соединения на основной канал.
4. Активные соединения через резервный канал продолжают работать до завершения.

Время восстановления определяется параметром Time Period. При значении по умолчанию (60 секунд) возврат на основной канал происходит примерно через 60-90 секунд после восстановления связи.

Внимание:

Частое переключение между каналами (flapping) указывает на нестабильность основного канала. Если основной канал восстанавливается и отказывает через короткие интервалы, активные соединения будут прерываться при каждом переключении. В этом случае следует увеличить Time Period или пороговые значения для снижения чувствительности.

VPN с failover

IPsec

При использовании IPsec VPN с failover необходимо учитывать следующие особенности:

• IPsec-туннель привязан к конкретному WAN-интерфейсу. При отказе этого интерфейса туннель разрывается.
• Для автоматического восстановления IPsec через резервный WAN необходимо создать отдельную Phase 1 конфигурацию для каждого WAN-интерфейса.
• Удалённая сторона также должна быть настроена на приём соединений с обоих IP-адресов.

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

При отказе WAN1 IPsec-туннель через WAN1 разрывается, а туннель через WAN2 устанавливается автоматически (при наличии DPD - Dead Peer Detection).

OpenVPN

OpenVPN поддерживает несколько подходов к failover:

1. Назначение Gateway Group интерфейсу OpenVPN - OpenVPN-сервер или клиент привязывается к конкретному WAN. Для failover создаются два экземпляра OpenVPN на разных WAN.
2. Floating IP - при использовании CARP VIP в качестве адреса OpenVPN-сервера переключение происходит на уровне CARP.
3. Клиентский failover - в конфигурации OpenVPN-клиента указать несколько директив remote с разными серверами. Клиент автоматически переключается на следующий сервер при разрыве соединения.

Диагностика

Failover не срабатывает

Симптом: основной канал недоступен, но трафик не переключается на резервный.

Проверки:

1. Статус шлюза - проверить Status > Gateways. Если основной шлюз всё ещё показывает статус Online, проблема в настройках мониторинга:
   • Убедиться, что Monitor IP корректен и недоступен через отказавший канал.
   • Проверить, что Monitor IP не доступен через резервный канал (routing loop).
2. Gateway Group - убедиться, что шлюзы назначены на правильные tier (основной - Tier 1, резервный - Tier 2).
3. Правило файрвола - убедиться, что Gateway Group назначена в правиле файрвола.
4. Trigger Level - проверить, что Trigger Level соответствует типу отказа (например, Member Down не реагирует на высокие потери, только на полный отказ).

Медленное обнаружение отказа

Симптом: переключение на резервный канал занимает несколько минут.

Причины и решения:

1. Time Period слишком велик - уменьшить до 30 секунд. dpinger требует накопления данных за весь Time Period перед изменением статуса.
2. Пороги слишком высоки - если порог Down установлен на 50%, шлюз должен потерять 50% пакетов, прежде чем будет отмечен как Down. Рекомендуемое значение - 10%.
3. Monitor IP на шлюзе провайдера - шлюз провайдера может продолжать отвечать при отсутствии upstream-связи. Заменить на публичный DNS.

Ложные срабатывания

Симптом: failover срабатывает при работающем основном канале.

Причины и решения:

1. Monitor IP перегружен - если Monitor IP (например, 8.8.8.8) временно не отвечает из-за rate-limiting или перегрузки, dpinger фиксирует потери. Использовать менее загруженный Monitor IP или увеличить пороги.
2. Time Period слишком мал - кратковременные флуктуации в сети провайдера вызывают переключение. Увеличить Time Period до 60-120 секунд.
3. Probe Interval слишком агрессивен - при интервале в 1 секунду и нестабильном канале потери накапливаются быстрее. Увеличить до 2-3 секунд.

Flapping (циклическое переключение)

Симптом: трафик постоянно переключается между основным и резервным каналами.

Причина: основной канал нестабилен - периодически восстанавливается и отказывает.

Решение:

1. Увеличить Time Period до 120-180 секунд для более длительного периода стабильности перед возвратом.
2. Увеличить порог Down для снижения чувствительности.
3. При невозможности устранить нестабильность основного канала рассмотреть переход на конфигурацию с балансировкой нагрузки, где оба канала используются одновременно.

Мониторинг и оповещения

pfSense записывает события переключения шлюзов в системный журнал. Для оперативного реагирования рекомендуется настроить внешний мониторинг.

Системные логи

События failover фиксируются в Status > System Logs > Gateways. Типичные записи:

dpinger: WAN1_DHCP 8.8.8.8: Alarm latency 0us stddev 0us loss 100%
dpinger: WAN1_DHCP 8.8.8.8: Clear latency 5432us stddev 312us loss 0%

SNMP-мониторинг

pfSense поддерживает SNMP для внешнего мониторинга. Статус шлюзов доступен через SNMP OID. Настройка SNMP выполняется в Services > SNMP.

Syslog

Для отправки логов на внешний syslog-сервер (Wazuh, ELK, Graylog) настроить удалённый syslog в Status > System Logs > Settings, секция Remote Logging Options.

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

• Балансировка нагрузки Multi-WAN - настройка параллельного использования нескольких каналов
• Исходящий NAT - настройка NAT для корректной работы failover
• IPsec VPN - настройка IPsec-туннелей с учётом Multi-WAN failover