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

> Настройка балансировки нагрузки между интернет-каналами в pfSense - Gateway Groups, весовые коэффициенты, мониторинг шлюзов и NAT для Multi-WAN

Source: https://opennix.org/docs/pfsense/multi-wan/pfsense-multi-wan-load-balancing/


Балансировка нагрузки 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 секунд.

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

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

| Статус | Условие | Влияние на балансировку |
|---|---|---|
| **Online** | Потери ниже порога warning, задержка в норме | Шлюз участвует в балансировке |
| **Warning** | Потери или задержка превысили порог warning | Шлюз участвует в балансировке (зависит от настройки Trigger Level) |
| **Down** | Потери превысили порог down | Шлюз исключён из балансировки |
| **Pending** | Сбор начальных данных | Шлюз не участвует |

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

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

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

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

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

| Параметр | Значение | Описание |
|---|---|---|
| **Group Name** | `WAN_LoadBalance` | Имя группы (латиница, без пробелов) |
| **Gateway Priority** | WAN1_DHCP = Tier 1, WAN2_DHCP = Tier 1 | Оба шлюза на одном уровне для балансировки |
| **Trigger Level** | Packet Loss | Условие переключения статуса шлюза |
| **Description** | Load balance across WAN1 and WAN2 | Описание назначения группы |

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

### Параметр Trigger Level

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

| Значение | Поведение |
|---|---|
| **Member Down** | Шлюз исключается только при статусе Down |
| **Packet Loss** | Шлюз исключается при статусе Down или при превышении порога потерь |
| **High Latency** | Шлюз исключается при статусе Down или при превышении порога задержки |
| **Packet Loss or High Latency** | Шлюз исключается при любом из перечисленных условий |

Для балансировки рекомендуется использовать **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.

| Канал | Пропускная способность | Weight | Доля трафика |
|---|---|---|---|
| WAN1 | 100 Мбит/с | 2 | ~67% |
| WAN2 | 50 Мбит/с | 1 | ~33% |

> **Внимание**:
>
> Весовые коэффициенты влияют на распределение количества соединений, а не на объём трафика. Если через 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**.

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

| Параметр | Значение |
|---|---|
| **Action** | Pass |
| **Interface** | LAN |
| **Protocol** | Any |
| **Source** | LAN net |
| **Destination** | Any |
| **Gateway** | WAN_LoadBalance |

Для более гранулярного управления можно создать несколько правил с различными 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:

| Интерфейс | Источник | Трансляция | Порт |
|---|---|---|---|
| WAN1 | 192.168.1.0/24 | WAN1 address | * |
| WAN2 | 192.168.1.0/24 | WAN2 address | * |
| WAN1 | 127.0.0.0/8 | WAN1 address | 500 (ISAKMP) |
| WAN2 | 127.0.0.0/8 | WAN2 address | 500 (ISAKMP) |

## 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](/docs/pfsense/multi-wan/pfsense-multi-wan-failover/) - настройка автоматического переключения на резервный канал
- [Исходящий NAT](/docs/pfsense/nat/pfsense-outbound-nat/) - настройка правил NAT для нескольких WAN-интерфейсов
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание правил с назначением Gateway Group