Балансировка нагрузки Multi-WAN в pfSense - Gateway Groups

Балансировка нагрузки Multi-WAN в pfSense распределяет исходящий трафик между несколькими интернет-каналами для увеличения суммарной пропускной способности. Балансировка выполняется на уровне соединений: каждое новое TCP-соединение или UDP-поток направляется через один из доступных каналов согласно настроенной политике. Отдельное соединение не может быть разделено между каналами - весь трафик в рамках одного соединения проходит через один шлюз.

pfSense реализует балансировку через механизм Gateway Groups, где шлюзы, назначенные на один уровень (tier), участвуют в распределении трафика. При отказе одного из шлюзов трафик автоматически перераспределяется между оставшимися шлюзами того же уровня без вмешательства администратора.

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

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

Настройка мониторинга

Параметры мониторинга настраиваются для каждого шлюза индивидуально в System > Routing > Gateways. При редактировании шлюза доступны следующие параметры.

Monitor IP - адрес, на который отправляются тестовые пакеты. По умолчанию используется IP-адрес самого шлюза. Для повышения точности мониторинга рекомендуется указать публичный IP-адрес за пределами сети провайдера:

• Для WAN1: Monitor IP = 8.8.8.8 (Google DNS)
• Для WAN2: Monitor IP = 1.1.1.1 (Cloudflare DNS)

Использование разных Monitor IP для каждого шлюза предотвращает ложные срабатывания, когда оба шлюза тестируют один и тот же адрес, а этот адрес становится временно недоступен.

Probe Interval - интервал между отправками тестовых пакетов в секундах. Значение по умолчанию (1 секунда) обеспечивает быстрое обнаружение отказа. Увеличение интервала снижает нагрузку на канал, но замедляет реакцию на отказ.

Loss Interval - время ожидания ответа на один тестовый пакет в миллисекундах. Пакет, не получивший ответа за этот интервал, считается потерянным. Значение по умолчанию - 2000 мс.

Time Period - окно усреднения в секундах, за которое рассчитываются средние показатели задержки и потерь. Значение по умолчанию - 60 секунд.

Типы мониторинга

pfSense поддерживает мониторинг шлюзов с использованием ICMP-пакетов (по умолчанию). В случаях, когда провайдер или промежуточное оборудование блокирует ICMP, следует выбрать альтернативный Monitor IP, который гарантированно отвечает на ICMP-запросы.

Внимание:

Некоторые провайдеры применяют rate-limiting для ICMP-трафика на своих шлюзах. При использовании адреса шлюза провайдера в качестве Monitor IP с интервалом в 1 секунду возможны ложные срабатывания из-за отброшенных ICMP-ответов. Рекомендуется использовать публичный DNS-сервер или увеличить Probe Interval до 2-5 секунд.

Статусы шлюзов

На основании данных мониторинга каждый шлюз получает один из статусов:

Текущий статус всех шлюзов отображается в Status > Gateways.

Создание Gateway Group для балансировки

Для настройки балансировки нагрузки необходимо создать Gateway Group, в которой все участвующие шлюзы назначены на один уровень (tier).

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

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

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

Параметр Trigger Level

Trigger Level определяет, при каком состоянии шлюза группа прекращает использовать его для маршрутизации:

Для балансировки рекомендуется использовать Packet Loss or High Latency - это обеспечивает исключение деградировавшего канала из группы до его полного отказа.

Весовые коэффициенты

По умолчанию pfSense распределяет трафик между шлюзами одного уровня равномерно. При наличии каналов с различной пропускной способностью следует настроить весовые коэффициенты (weight) для пропорционального распределения.

Весовые коэффициенты настраиваются для каждого шлюза в System > Routing > Gateways при редактировании шлюза, параметр Weight (от 1 до 30).

Пример расчёта

Пусть WAN1 имеет пропускную способность 100 Мбит/с, WAN2 - 50 Мбит/с. Для пропорционального распределения:

• WAN1: Weight = 2
• WAN2: Weight = 1

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

Внимание:

Весовые коэффициенты влияют на распределение количества соединений, а не на объём трафика. Если через WAN2 устанавливается соединение для загрузки большого файла, весь трафик этого соединения пройдёт через WAN2 независимо от весов. Балансировка по объёму трафика в pfSense не поддерживается.

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

Gateway Group начинает маршрутизировать трафик только после назначения в правило файрвола. Без этого шага группа остаётся неиспользуемой.

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

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

Типичная конфигурация правила:

Для более гранулярного управления можно создать несколько правил с различными Gateway Group. Например, HTTP/HTTPS трафик балансируется между каналами, а VoIP-трафик фиксируется за каналом с низкой задержкой.

Внимание:

Правило со специфичным шлюзом (gateway) должно располагаться выше правила с gateway по умолчанию (*). В противном случае трафик будет обработан правилом по умолчанию и не попадёт в Gateway Group.

Исходящий NAT для Multi-WAN

При использовании нескольких WAN-интерфейсов необходимо убедиться, что для каждого WAN существует правило исходящего NAT. Без корректного правила NAT трафик, направленный через определённый WAN, будет отправлен с неправильным адресом источника и отброшен провайдером.

Проверка правил NAT

1. Перейти в Firewall > NAT > Outbound.
2. Убедиться, что для каждого WAN-интерфейса существуют правила трансляции для всех внутренних подсетей.

В Automatic и Hybrid режимах pfSense создаёт правила NAT для всех WAN-интерфейсов автоматически. В Manual режиме правила необходимо создать вручную для каждого WAN.

Пример набора правил для конфигурации с двумя WAN и подсетью LAN 192.168.1.0/24:

DNS в Multi-WAN

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

Рекомендации по настройке DNS

Вариант 1: DNS Resolver с Forward Mode (рекомендуется)

1. В System > General Setup указать DNS-серверы для каждого WAN:
   • DNS Server 1: 8.8.8.8 - Use gateway: WAN1_DHCP
   • DNS Server 2: 1.1.1.1 - Use gateway: WAN2_DHCP
2. В Services > DNS Resolver включить DNS Query Forwarding.
3. pfSense будет направлять DNS-запросы через оба канала и использовать первый полученный ответ.

Вариант 2: DNS Resolver без Forward Mode

DNS Resolver в стандартном режиме выполняет рекурсивные запросы напрямую к корневым DNS-серверам. В этом случае DNS-запросы маршрутизируются согласно таблице маршрутизации и не привязаны к конкретному WAN. Однако при отказе основного канала может потребоваться время для переключения маршрутов.

Вариант 3: Локальный DNS-сервер

При использовании выделенного DNS-сервера в локальной сети (например, для Active Directory) DNS-трафик от этого сервера маршрутизируется как обычный трафик через Gateway Group.

Sticky Connections

Sticky connections - механизм, привязывающий все соединения от одного клиента (по IP-адресу источника) к одному шлюзу на определённый период. Это решает проблемы с веб-сервисами, которые привязывают сессию к IP-адресу клиента.

Настройка

1. Перейти в System > Advanced > Miscellaneous.
2. В секции Gateway Monitoring установить флаг Use sticky connections.
3. Указать Sticky connections expiry - время в секундах, после которого привязка удаляется при отсутствии активных соединений. Значение по умолчанию - 0 (привязка сохраняется до перезагрузки).

Ограничения

• Привязка выполняется по IP-адресу источника, а не по назначению. Все соединения клиента направляются через один шлюз.
• При активации sticky connections эффективность балансировки снижается: клиенты, установившие привязку, не перераспределяются между каналами до истечения таймера.
• Привязка не сохраняется при перезагрузке pfSense.

Диагностика

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

Симптом: весь трафик проходит через один WAN-канал.

Проверки:

1. Правило файрвола - убедиться, что в правиле LAN указан Gateway Group, а не конкретный шлюз или значение по умолчанию (*).
2. Порядок правил - правило с Gateway Group должно быть выше правила с gateway по умолчанию.
3. Sticky connections - если sticky connections активирован, клиент может быть привязан к одному шлюзу. Временно отключить для диагностики.
4. States table - проверить привязку соединений в Diagnostics > States. Фильтровать по IP-адресу клиента и проверить, через какой интерфейс проходят соединения.
5. Статус шлюзов - проверить, что оба шлюза в статусе Online в Status > Gateways.

Асимметричная маршрутизация

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

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

Решение:

1. Убедиться, что Outbound NAT корректно настроен для обоих WAN.
2. Проверить, что pfSense выполняет трансляцию адреса источника в адрес правильного WAN-интерфейса для каждого соединения.
3. При наличии статических маршрутов убедиться, что ответный трафик возвращается через тот же WAN.

Потеря соединений при переключении

Симптом: при отказе одного шлюза активные соединения через этот шлюз прерываются.

Это ожидаемое поведение - pfSense не может перенести активное TCP-соединение между шлюзами. Новые соединения автоматически направляются через доступные шлюзы. Для минимизации влияния:

1. Уменьшить Time Period для более быстрого обнаружения отказа.
2. Настроить Trigger Level на Packet Loss or High Latency для раннего исключения деградировавшего шлюза.

Сравнение с другими платформами

Cisco PBR (Policy-Based Routing)

В Cisco IOS policy routing настраивается через route-map с set ip next-hop. pfSense использует аналогичный подход через назначение Gateway Group в правилах файрвола. Ключевое отличие: pfSense автоматически обрабатывает failover между шлюзами одного tier, тогда как в Cisco IOS требуется дополнительная настройка IP SLA для мониторинга и переключения.

FortiGate SD-WAN

FortiGate SD-WAN предоставляет встроенные SLA-мониторы с поддержкой TCP, HTTP и DNS probes. pfSense ограничен ICMP-мониторингом через dpinger. FortiGate также поддерживает балансировку по объёму трафика (volume-based), которая отсутствует в pfSense.

MikroTik PCC (Per Connection Classifier)

MikroTik использует PCC для маркировки соединений на основе хеша адресов и портов с последующей маршрутизацией через разные шлюзы. pfSense реализует аналогичную логику через Gateway Groups, но с менее гранулярным контролем хеширования. Преимущество pfSense - встроенный мониторинг шлюзов и автоматический failover, тогда как в MikroTik требуется настройка netwatch для аналогичной функциональности.

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

• Multi-WAN failover - настройка автоматического переключения на резервный канал
• Исходящий NAT - настройка правил NAT для нескольких WAN-интерфейсов
• Правила файрвола - создание правил с назначением Gateway Group