# Policy Routing в pfSense - маршрутизация по правилам

> Настройка policy-based routing в pfSense - маршрутизация трафика через определенный шлюз на основе источника, назначения и протокола

Source: https://opennix.org/docs/pfsense/routing/pfsense-policy-routing/


Policy-based routing (PBR) в [pfSense](/docs/pfsense/glossary/pfsense-terms/) позволяет направлять трафик через определённый шлюз на основе критериев, выходящих за рамки адреса назначения. В отличие от классической маршрутизации, где путь пакета определяется исключительно таблицей маршрутов и адресом назначения, PBR учитывает адрес источника, порт назначения, протокол и другие параметры, указанные в правилах файрвола.

pfSense реализует PBR через поле **Gateway** в правилах файрвола. Каждое правило, в котором явно указан шлюз, переопределяет стандартную таблицу маршрутизации для совпавшего трафика. Это позволяет гибко управлять путями прохождения пакетов без изменения глобальной конфигурации маршрутов.

## Принцип работы

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

Порядок обработки:

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

> **Внимание**:
>
> Policy routing применяется только к трафику, проходящему через pfSense (forwarded traffic). Трафик, генерируемый самим pfSense (DNS-запросы, обновления пакетов, NTP-синхронизация), всегда использует стандартную таблицу маршрутизации и шлюз по умолчанию. Для управления исходящим трафиком самого файрвола следует изменить шлюз по умолчанию в **System > Routing > Gateways**.

## Поле Gateway в правилах файрвола

Поле **Gateway** расположено в расширенных настройках правила файрвола (секция **Advanced Options** при создании или редактировании правила). По умолчанию установлено значение **Default**, что означает использование стандартной таблицы маршрутизации.

Доступные варианты:

| Значение | Поведение |
|---|---|
| Default | Стандартная маршрутизация по таблице |
| Конкретный шлюз (например, WAN_DHCP) | Трафик направляется через указанный шлюз |
| Gateway Group (например, MULTI_WAN_FAILOVER) | Трафик направляется через группу шлюзов с учётом приоритетов и балансировки |

При выборе конкретного шлюза или Gateway Group pfSense создаёт в pf (packet filter) правило с директивой `route-to`, принудительно направляющей пакет через указанный интерфейс и шлюз.

## Сценарии применения

### Маршрутизация определённых хостов через конкретный WAN

Задача: направить весь трафик бухгалтерии (подсеть 10.0.1.0/24) через WAN1, а трафик разработчиков (подсеть 10.0.2.0/24) через WAN2.

Конфигурация предполагает наличие двух WAN-интерфейсов с настроенными шлюзами (WAN1_GW и WAN2_GW).

**Правило 1** (на интерфейсе LAN):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | LAN |
| Protocol | Any |
| Source | 10.0.1.0/24 |
| Destination | Any |
| Gateway | WAN1_GW |
| Description | Accounting traffic via WAN1 |

**Правило 2** (на интерфейсе LAN):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | LAN |
| Protocol | Any |
| Source | 10.0.2.0/24 |
| Destination | Any |
| Gateway | WAN2_GW |
| Description | Developers traffic via WAN2 |

Порядок правил имеет значение: правила с явным шлюзом должны располагаться выше общего правила разрешения трафика (pass any). В противном случае трафик совпадёт с общим правилом и пойдёт через шлюз по умолчанию.

### Направление VoIP через низколатентный канал

Задача: направить SIP и RTP-трафик через WAN-канал с минимальной задержкой (WAN2), а остальной трафик - через основной канал (WAN1).

**Правило для SIP** (на интерфейсе LAN):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | LAN |
| Protocol | UDP |
| Source | VoIP_Phones (алиас) |
| Destination | Any |
| Destination Port | 5060-5061 |
| Gateway | WAN2_LOW_LATENCY |
| Description | SIP signaling via low-latency WAN |

**Правило для RTP** (на интерфейсе LAN):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | LAN |
| Protocol | UDP |
| Source | VoIP_Phones (алиас) |
| Destination | Any |
| Destination Port | 10000-20000 |
| Gateway | WAN2_LOW_LATENCY |
| Description | RTP media via low-latency WAN |

Для упрощения администрирования рекомендуется создать алиас `VoIP_Phones`, содержащий IP-адреса или подсеть VoIP-оборудования.

### Принудительная маршрутизация гостевой сети

Задача: весь трафик гостевой сети (интерфейс OPT1, подсеть 10.0.100.0/24) направлять через отдельного провайдера (WAN2), изолируя его от основного канала.

**Правило** (на интерфейсе OPT1):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | OPT1 (Guest) |
| Protocol | Any |
| Source | OPT1 net |
| Destination | Any |
| Gateway | WAN2_GUEST_ISP |
| Description | Guest network via dedicated ISP |

Дополнительно рекомендуется создать правила, блокирующие доступ гостевой сети к внутренним подсетям (LAN, серверные VLAN).

### Маршрутизация по протоколу и порту назначения

Задача: направить весь HTTPS-трафик (порт 443) через WAN-канал с неограниченным объёмом, а остальной трафик через основной канал с лимитированным трафиком.

**Правило для HTTPS** (на интерфейсе LAN):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | LAN |
| Protocol | TCP |
| Source | LAN net |
| Destination | Any |
| Destination Port | 443 |
| Gateway | WAN2_UNLIMITED |
| Description | HTTPS traffic via unlimited WAN |

## Создание policy route пошагово

Пошаговая инструкция по созданию policy route для направления трафика определённой подсети через конкретный шлюз.

### Шаг 1: проверка шлюзов

Открыть **System > Routing > Gateways** и убедиться, что целевой шлюз существует и имеет статус Online. Если шлюз отсутствует, создать его, указав интерфейс, IP-адрес и параметры мониторинга.

### Шаг 2: создание алиасов (при необходимости)

Если policy route применяется к группе хостов или портов, следует предварительно создать алиасы в разделе **Firewall > Aliases**. Алиасы упрощают управление и повышают читаемость правил.

Пример алиаса для хостов:

| Поле | Значение |
|---|---|
| Name | ACCOUNTING_HOSTS |
| Type | Host(s) |
| Entries | 10.0.1.10, 10.0.1.11, 10.0.1.12 |
| Description | Accounting department workstations |

### Шаг 3: создание правила файрвола

Открыть **Firewall > Rules** на интерфейсе, через который поступает трафик от источника. Нажать **Add** (стрелка вверх для добавления в начало списка).

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

1. **Action**: Pass
2. **Interface**: интерфейс источника трафика
3. **Address Family**: IPv4 (или IPv4+IPv6 при необходимости)
4. **Protocol**: Any (или конкретный протокол)
5. **Source**: адрес или алиас источника
6. **Destination**: Any (или конкретная сеть)

### Шаг 4: указание шлюза

В секции **Advanced Options** (кнопка **Display Advanced**) найти поле **Gateway**. Выбрать целевой шлюз или Gateway Group из выпадающего списка.

### Шаг 5: размещение правила

Переместить правило выше общего правила разрешения (pass any). Правила файрвола обрабатываются сверху вниз, и первое совпадение определяет обработку пакета. Если общее правило расположено выше policy route, трафик совпадёт с общим правилом и пойдёт через шлюз по умолчанию.

### Шаг 6: применение и проверка

Нажать **Save**, затем **Apply Changes**. Для проверки выполнить traceroute с хоста-источника к внешнему адресу и убедиться, что трафик проходит через ожидаемый шлюз.

## Взаимодействие с Gateway Groups

Gateway Groups добавляют дополнительный уровень гибкости к policy routing. Вместо указания одного шлюза в правиле файрвола можно выбрать группу, обеспечивающую отказоустойчивость или балансировку нагрузки.

### Создание Gateway Group

Gateway Groups настраиваются в разделе **System > Routing > Gateway Groups**. Для создания группы следует нажать **Add**.

**Group Name** - уникальное имя группы. Используется при выборе шлюза в правилах файрвола.

**Gateway Priority** - для каждого шлюза указывается приоритет (Tier 1-5) и триггер переключения:

| Tier | Поведение |
|---|---|
| Tier 1 | Шлюзы с наивысшим приоритетом. Используются при нормальной работе |
| Tier 2 | Активируются при отказе всех шлюзов Tier 1 |
| Tier 3-5 | Активируются последовательно при отказе предыдущих уровней |
| Never | Шлюз исключён из группы |

**Trigger Level** - событие, вызывающее переключение:

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

### Сценарий: Failover

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

| Шлюз | Tier | Trigger |
|---|---|---|
| WAN1_GW | Tier 1 | Packet Loss or High Latency |
| WAN2_GW | Tier 2 | Packet Loss or High Latency |

При нормальной работе весь трафик идёт через WAN1. При потере пакетов или превышении задержки на WAN1 трафик автоматически переключается на WAN2.

### Сценарий: балансировка нагрузки

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

| Шлюз | Tier | Weight | Trigger |
|---|---|---|---|
| WAN1_GW | Tier 1 | 5 | Packet Loss or High Latency |
| WAN2_GW | Tier 1 | 3 | Packet Loss or High Latency |

Оба шлюза находятся в Tier 1, поэтому используются одновременно. Вес определяет пропорцию распределения: WAN1 получает примерно 62% трафика (5/8), WAN2 - 38% (3/8). При отказе одного из шлюзов весь трафик направляется через оставшийся.

### Сценарий: Failover с балансировкой

Комбинация двух подходов: два основных канала с балансировкой и резервный канал:

| Шлюз | Tier | Weight | Trigger |
|---|---|---|---|
| WAN1_GW | Tier 1 | 5 | Packet Loss or High Latency |
| WAN2_GW | Tier 1 | 5 | Packet Loss or High Latency |
| WAN3_GW | Tier 2 | 1 | Member Down |

При нормальной работе трафик распределяется между WAN1 и WAN2. При отказе обоих каналов Tier 1 трафик переключается на WAN3.

### Использование Gateway Group в правиле файрвола

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

## Особенности и ограничения

### Взаимодействие с NAT

Policy routing применяется после входящего NAT (DNAT), но до исходящего NAT (SNAT). Это означает:

- Для входящего трафика (port forward, 1:1 NAT) policy routing работает с уже транслированным адресом назначения.
- Для исходящего трафика policy routing определяет интерфейс выхода, что влияет на выбор адреса исходящего NAT.

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

### Трафик, генерируемый pfSense

Policy routing не влияет на трафик, генерируемый самим файрволом. DNS-запросы, обновления пакетов, NTP-синхронизация и другие служебные соединения pfSense всегда используют шлюз по умолчанию. Для изменения исходящего маршрута служебного трафика необходимо изменить шлюз по умолчанию в **System > Routing > Gateways**.

### Floating Rules и policy routing

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

Для активации policy routing в floating rule необходимо установить направление (Direction) в значение **In** или **Any**. При направлении **Out** поле Gateway игнорируется.

### Sticky Connections

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

Для решения этой проблемы следует включить опцию **Sticky Connections** в разделе **System > Advanced > Miscellaneous**. Эта настройка привязывает все соединения от одного источника к одному шлюзу на определённый период времени.

## Диагностика и устранение неполадок

### Policy route не применяется

Если трафик проходит через шлюз по умолчанию вместо указанного в правиле:

1. **Проверить порядок правил**. Правило с policy route должно располагаться выше общего правила разрешения. Открыть **Firewall > Rules** на соответствующем интерфейсе и убедиться в корректном порядке.

2. **Проверить совпадение правила**. Открыть **Status > System Logs > Firewall** и убедиться, что трафик совпадает именно с правилом policy route, а не с другим правилом.

3. **Проверить состояние шлюза**. Если указанный шлюз недоступен (статус Down), pfSense может направить трафик через шлюз по умолчанию. Проверить состояние в **Status > Gateways**.

4. **Проверить существующие состояния**. Если соединение было установлено до создания policy route, оно продолжит использовать прежний маршрут. Для принудительного применения нового правила необходимо сбросить таблицу состояний: **Diagnostics > States > Reset States**. Следует учитывать, что сброс состояний разрывает все активные соединения.

5. **Убедиться в корректности интерфейса**. Policy routing применяется на входном интерфейсе. Правило для трафика из LAN должно находиться на вкладке LAN, а не на WAN или Floating.

### Предупреждение об асимметричной маршрутизации

При использовании policy routing с несколькими WAN-интерфейсами возникает риск асимметричной маршрутизации ответного трафика. Запрос уходит через WAN2, но ответ может прийти через WAN1, если удалённый маршрутизатор выбирает маршрут независимо.

Для предотвращения этой проблемы:

- Настроить правила **reply-to** (pfSense добавляет их автоматически при использовании policy routing), обеспечивающие возврат ответного трафика через тот же интерфейс.
- Проверить, что опция **Disable reply-to** не включена на правилах файрвола WAN-интерфейсов.
- При необходимости включить **Bypass firewall rules for traffic on the same interface** в **System > Advanced > Firewall & NAT**.

### Трафик не покидает pfSense через ожидаемый интерфейс

Для проверки фактического маршрута следует выполнить захват пакетов на WAN-интерфейсе:

1. Открыть **Diagnostics > Packet Capture**.
2. Выбрать WAN-интерфейс, через который ожидается прохождение трафика.
3. Указать фильтр по IP-адресу источника или назначения.
4. Инициировать трафик с хоста-источника.
5. Проверить, появляются ли пакеты на ожидаемом интерфейсе.

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

### Проблемы со Sticky Connections

Если при использовании Gateway Groups с балансировкой наблюдаются разрывы сессий:

1. Убедиться, что опция **Sticky Connections** включена в **System > Advanced > Miscellaneous**.
2. Проверить значение **Source Tracking Timeout** - по умолчанию 0 (привязка на время жизни состояния). При необходимости увеличить значение.
3. Для отдельных сервисов, не допускающих смену IP-адреса (банковские системы, корпоративные VPN), создать отдельное правило с конкретным шлюзом вместо Gateway Group.

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

### Cisco IOS PBR

В Cisco IOS policy-based routing настраивается через route-map и ip policy:

```
access-list 110 permit ip 10.0.1.0 0.0.0.255 any

route-map PBR_ACCOUNTING permit 10
  match ip address 110
  set ip next-hop 203.0.113.1

interface GigabitEthernet0/1
  ip policy route-map PBR_ACCOUNTING
```

Эквивалент в pfSense:

1. Создать шлюз с адресом 203.0.113.1 в **System > Routing > Gateways**.
2. Создать правило файрвола на LAN-интерфейсе:
   - Source: 10.0.1.0/24
   - Destination: Any
   - Gateway: созданный шлюз

Ключевые отличия:

| Аспект | Cisco IOS | pfSense |
|---|---|---|
| Механизм | Route-map + ACL | Правила файрвола + поле Gateway |
| Привязка | К интерфейсу через `ip policy` | Правило на вкладке интерфейса |
| Критерии | ACL (L3/L4) | Все поля правила файрвола |
| Failover | Через tracking objects и PBR | Через Gateway Groups |
| Локальный трафик | `ip local policy route-map` | Не поддерживается (только forwarded traffic) |

### FortiGate Policy Routes

В FortiGate policy routes настраиваются отдельно от правил файрвола:

```
config router policy
    edit 1
        set input-device "port2"
        set src "10.0.1.0/255.255.255.0"
        set dst "0.0.0.0/0.0.0.0"
        set gateway 203.0.113.1
        set output-device "port1"
    next
end
```

Ключевые отличия:

| Аспект | FortiGate | pfSense |
|---|---|---|
| Расположение | Отдельная таблица policy routes | Поле Gateway в правилах файрвола |
| Связь с файрволом | Независимые сущности | Встроено в правила файрвола |
| Критерии | IP-адреса, протокол, порт, ToS | Все параметры правила файрвола |
| SD-WAN | Интеграция с SD-WAN rules | Gateway Groups |
| Приоритет | Номер policy route | Позиция правила файрвола |

### MikroTik Routing Marks

В MikroTik PBR реализуется через routing marks в mangle и routing tables:

```
/ip firewall mangle add chain=prerouting src-address=10.0.1.0/24 \
    action=mark-routing new-routing-mark=via_ISP2

/ip route add dst-address=0.0.0.0/0 gateway=203.0.113.1 \
    routing-mark=via_ISP2
```

Ключевые отличия:

| Аспект | MikroTik | pfSense |
|---|---|---|
| Механизм | Mangle + routing marks + routing tables | Правила файрвола + поле Gateway |
| Гибкость | Отдельные routing tables для каждого mark | Один шлюз или Gateway Group на правило |
| Критерии маркировки | Все поля mangle (L2-L7) | Поля правила файрвола (L3-L4) |
| Каскадирование | Поддерживается (mark в одной цепочке, route в другой) | Не поддерживается |
| VRF | Поддерживается | Не поддерживается |

## Рекомендации по проектированию

При проектировании policy routing в pfSense следует учитывать следующие принципы:

- **Минимизировать количество policy routes**. Каждое правило с явным шлюзом добавляет сложность в диагностику. Следует группировать хосты через алиасы и создавать обобщённые правила вместо индивидуальных для каждого хоста.

- **Использовать Gateway Groups вместо конкретных шлюзов**. Даже при одном WAN-канале целесообразно создать Gateway Group с единственным участником. Это упрощает последующее добавление резервного канала без изменения правил файрвола.

- **Документировать логику маршрутизации**. Поле Description в правилах файрвола должно чётко указывать, какой трафик и через какой канал направляется. При большом количестве policy routes рекомендуется создать разделитель (separator) на вкладке правил для визуального разграничения блоков.

- **Тестировать после каждого изменения**. После добавления или изменения policy route следует выполнить traceroute с хоста-источника и убедиться, что трафик проходит через ожидаемый шлюз. Также рекомендуется проверить работу сервисов, чувствительных к смене IP-адреса.

- **Планировать обработку отказов**. При указании конкретного шлюза (а не Gateway Group) отказ шлюза может привести к полной потере связности для затронутых хостов. Рекомендуется всегда использовать Gateway Groups с резервным шлюзом.

- **Учитывать влияние на исходящий NAT**. При использовании нескольких WAN-интерфейсов необходимо проверить правила исходящего NAT для каждого интерфейса. В режиме Automatic Outbound NAT pfSense создаёт правила автоматически, но в режиме Manual потребуется ручная настройка.

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

- [Статические маршруты](/docs/pfsense/routing/pfsense-static-routes/) - настройка шлюзов и статических маршрутов, просмотр таблицы маршрутизации
- [Multi-WAN в pfSense](/docs/pfsense/multi-wan/) - настройка нескольких WAN-подключений, тесно связанная с policy routing
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание и управление правилами, в которых настраивается policy routing