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

Policy-based routing (PBR) в pfSense позволяет направлять трафик через определённый шлюз на основе критериев, выходящих за рамки адреса назначения. В отличие от классической маршрутизации, где путь пакета определяется исключительно таблицей маршрутов и адресом назначения, 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, что означает использование стандартной таблицы маршрутизации.

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

При выборе конкретного шлюза или 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):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 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) и триггер переключения:

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

Сценарий: Failover

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

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

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

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

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

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

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

При нормальной работе трафик распределяется между 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: созданный шлюз

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

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

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

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

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

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

При проектировании 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 потребуется ручная настройка.

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

• Статические маршруты - настройка шлюзов и статических маршрутов, просмотр таблицы маршрутизации
• Multi-WAN в pfSense - настройка нескольких WAN-подключений, тесно связанная с policy routing
• Правила файрвола - создание и управление правилами, в которых настраивается policy routing