Маршрутизация по политикам OpenWrt позволяет направить одно устройство LAN в разрешённый туннель, оставив другое на WAN. Сохраните обычный маршрут по умолчанию через WAN, закрепите идентификаторы устройств и отдельно проверьте DNS, IPv6 и отказ туннеля. Успешное открытие страницы по IPv4 не заменяет эти проверки.

Ключевые выводы

Совпадение зависит от идентификатора устройства и порядка политик.

Запрос самого маршрутизатора не представляет запрос клиента LAN.

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

DNS, пересылаемый маршрутизатором, становится отдельным локальным запросом.

Сохраните исключения управления и отменяйте только изменения этой процедуры.

Когда подходит маршрутизация по политикам OpenWrt?

Процедура предназначена для стабильной OpenWrt 25.12, fw4/nftables и pbr 1.2.2 в обычном режиме динамических таблиц маршрутизации. Официальный репозиторий выпуска содержит 1.2.2; перед установкой проверьте пакет именно для своей архитектуры и прошивки. Предварительная интеграция с netifd описана отдельно: здесь она и интеграция нескольких WAN не включаются.［1］［2］

Инструкция основана на официальных документах и настройках пакета; полное сквозное испытание на устройствах не проводилось. Ниже приведены критерии приёмки читателем, а не наблюдавшиеся результаты. Назначьте ответственных за восстановление и обслуживание по списку обязанностей владельца сети.

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

Шаг 1: закрепите два устройства и отдельный доступ управления

Выберите устройство A для туннеля и B для WAN. Зарезервируйте их существующие адреса IPv4 в DHCP, например 192.168.8.10 и 192.168.8.20, затем проверьте активные аренды. Запишите использование случайного MAC и нескольких адаптеров: они могут изменить идентификатор. Третий компьютер для проводного управления оставьте вне обеих политик.

Сохраните /etc/config/pbr, /etc/config/network, /etc/config/dhcp и /etc/config/firewall в защищённом месте вне маршрутизатора. Если pbr раньше не был установлен, зафиксируйте отсутствие, а не выдуманную исходную конфигурацию. Запишите исходное состояние автозапуска и существующие политики, чтобы при откате не отключить чужую маршрутизацию.

Сначала проверьте интерфейс клиента WireGuard и обратный путь. В примере работающий интерфейс называется wg_test. Разрешите тестовой LAN необходимую пересылку в него. Сервер должен принимать пересылаемый трафик с явно выбранной трансляцией IPv4 либо обратным маршрутом.

Для доступа в интернет в AllowedIPs узла может потребоваться 0.0.0.0/0, но Route Allowed IPs должен быть отключён, чтобы не устанавливать конкурирующий глобальный маршрут по умолчанию. Заменяйте или удаляйте лишь свои прежние тестовые маршруты. Разобраться поможет связь AllowedIPs и системных маршрутов. Сохраните WAN-путь к конечной точке туннеля и существующий непосредственно подключённый маршрут LAN.［3］

Шаг 2: проверьте пакеты выпуска и поддерживаемый механизм

Устанавливайте пакеты только на разрешённый маршрутизатор из его настроенных доверенных репозиториев 25.12. Убедитесь, что предлагается pbr 1.2.2 и зависимости совместимы с прошивкой. При несовпадении остановитесь; не устанавливайте старый пакет принудительно и не меняйте прошивку в рамках этого примера.［1］［2］

apk update
apk list pbr
apk add pbr luci-app-pbr
apk list --installed pbr

До включения откройте Services → PBR и изучите состояние. Подтвердите fw4/nftables, обнаруженный WAN и wg_test. Если уже используются расширения netifd, mwan4 или другой менеджер маршрутов, остановитесь: миграция такой системы выходит за рамки двух устройств.

Для политик по исходному адресу без доменов выберите resolver_set: none. Заменять dnsmasq ради совпадения по IP не нужно. Явно сохраните strict_enforcement: 1; для наблюдения включите nft_rule_counter: 1, записав прежние значения. В конфигурации выпуска счётчики по умолчанию выключены. Поддержка IPv6 также выключена до осознанной настройки.［2］［4］

Шаг 3: настройте VPN для отдельных устройств OpenWrt

Добавьте следующие фрагменты через LuCI или в существующий файл pbr. Это не замена всего файла. Используйте свободные имена разделов и реальные логические интерфейсы. Сохраните прежние разрешённые политики и проверьте их пересечение с тестовыми адресами.［2］

config policy 'sh26_local'
        option name 'SH26 local management destinations'
        option src_addr '192.168.8.10 192.168.8.20'
        option dest_addr '192.168.8.0/24'
        option interface 'ignore'

config policy 'sh26_tunnel'
        option name 'SH26 device A'
        option src_addr '192.168.8.10'
        option interface 'wg_test'

config policy 'sh26_wan'
        option name 'SH26 device B'
        option src_addr '192.168.8.20'
        option interface 'wan'

Поместите локальное исключение выше общих политик устройств. Расположенные выше политики имеют больший приоритет. ignore оставляет совпавшие запросы обычной маршрутизации, но не разрешает доступ через межсетевой экран. Добавляйте другие сети управления только при их реальном наличии и разрешении владельца. Слишком широкое исключение частных сетей способно вывести предназначенный туннелю удалённый частный трафик наружу.［2］

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

Как работает маршрутизация DNS pbr отдельно от браузера?

Сначала выберите схему. Клиент может напрямую запрашивать разрешённый резолвер, и его пакеты последуют политике устройства. Либо клиент спрашивает маршрутизатор, а тот отдельно обращается к вышестоящему DNS. Во втором случае запрос не наследует автоматически туннельную политику A. Запишите адрес резолвера и путь исходящих запросов.

Необязательные политики DNS pbr используют name, src_addr и dest_dns. Назначением может быть резолвер либо интерфейс с настроенным DNS. Не подставляйте вымышленный адрес. Перехват касается совпавших DNS-запросов, а не всех приложений с шифрованным DNS; он также может обходить обработку доменных наборов dnsmasq. Начальный пример по исходному IP не использует доменные политики.［2］

Запросите новое имя под своим контролем с A и B, а поведение резолвера самого маршрутизатора изучите отдельно. Учтите DoH браузера, частный DNS системы и уже установленный VPN конечного устройства. Не отключайте постороннее ПО ради внешне чистого результата. При исчезновении настроек после обновления аренды или перезагрузки сначала выполните проверки сохранения DNS маршрутизатора, затем добавляйте новые политики.

Что происходит с IPv6 и отказавшим туннелем?

Политики источника IPv4 не доказывают охват IPv6. Временный адрес IPv6 может меняться независимо от резервирования DHCPv4. Для приёмки двух стеков включите IPv6 в pbr, подготовьте поддерживаемый туннель IPv6 и обратный маршрут. Затем настройте соответствующие IPv6-идентификаторы либо подходящий поддерживаемый способ выбора устройства. Проверьте все текущие адреса A и B: одного фиксированного адреса недостаточно без проверки.［2］［4］

Если эта ветка недоступна, используйте уже существующий тестовый сегмент только с IPv4 либо остановитесь, прежде чем называть схему VPN всего устройства. Не отключайте IPv6 во всей общей сети. Выход IPv6 через WAN является отказом при требовании направлять весь трафик устройства в туннель. Он допустим только как заранее явно согласованное исключение.

Строгое применение должно делать совпавший трафик недоступным, когда целевой интерфейс переходит в down. Оно не доказывает обнаружение случая, когда интерфейс остаётся up, но удалённый узел молчит. Оно также не охватывает несовпавший IPv6, DNS маршрутизатора и время остановки службы. Проверяйте интерфейс down и отсутствие ответа узла при интерфейсе up как разные отказы.［2］

Метод проверки	Ожидаемое наблюдение	Действие при отказе
Создать новые публичные запросы с A и B	A использует разрешённый выход туннеля, B — WAN	Проверить идентификаторы, порядок, метки и таблицы
Проверить pbr и включённые счётчики nft	Счётчики соответствующей политики меняются для устройства	Подтвердить прохождение пакетов через маршрутизатор, не доверять одному статусу
Сравнить прямой DNS клиента и DNS маршрутизатора	Каждый следует описанной схеме	Восстановить резолверы и отделить этот поток
Повторить запросы IPv6 с обоих устройств	Результат соответствует явному решению по IPv6	Прекратить приёмку при непредусмотренном обходе через WAN
Отключить только `wg_test`	Совпавшие запросы A блокируются; B и управление работают	Проверить несовпавший трафик и конфликтующие политики
Восстановить туннель и выполнить разрешённый перезапуск	Политики и идентификаторы сохраняются, новые запросы снова совпадают	Восстановить исходное состояние и проверить сохранённые параметры

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

Шаг 4: восстановите политики и проверьте управление

Удалите необязательные политики DNS и только три добавленные политики sh26_. Верните сохранённые параметры pbr и прежнее состояние службы, затем перезагрузите конфигурацию штатным способом её владельца. Если pbr установлен только для опыта, остановите и отключите его перед удалением. Если он обслуживал существующие правила, сохраните службу и загрузите оставшуюся конфигурацию.

Верните изменённые специально здесь параметры маршрутов WireGuard, резервирования, резолверы и разрешения тестового межсетевого экрана. Не очищайте nftables, не удаляйте все таблицы политик и не заменяйте файл целиком старой копией поверх более поздних изменений. Проверьте новые WAN-запросы A и B, обычный DNS и новое проводное подключение управления.

По документации, прерывание обработки службы способно оставить пересылку LAN–WAN отключённой. service pbr enable_forward — документированное действие восстановления, не универсальное исправление. Сначала подтвердите именно эту неисправность, восстановите безопасную исходную конфигурацию межсетевого экрана и политик, затем решите, разрешён ли резервный WAN. Иначе остановитесь и восстанавливайте локально, не открывая путь незаметно.［2］

Итоги

Закрепите идентификаторы устройств и узкое исключение управления.
Оставьте динамические таблицы pbr, а обычный маршрут по умолчанию — WAN.
Раздельно проверьте DNS, IPv6 и два варианта отказа туннеля.
Отменяйте только политики и параметры, изменённые в этой процедуре.

Часто задаваемые вопросы (FAQ)

Можно проверить политику устройства запросом с маршрутизатора?

Нет. Локальный запрос имеет другой источник и путь обработки. Создавайте новый трафик на самом устройстве LAN и сопоставляйте его с данными политики.

Какая политика важнее: первая или последняя?

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

Нужен ли dnsmasq-full для политик исходного IP?

Здесь не требуется обработка доменных наборов: используется resolver_set: none. У доменных политик отдельные требования. Не заменяйте работающий DNS только ради выбора адреса устройства.

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

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

Почему A меняет путь после переподключения к Wi-Fi?

Могли измениться активный IP, случайный MAC или адаптер. До правки таблиц сравните текущую аренду и адреса IPv6 с условиями выбора в политике.

Можно намеренно разрешить резервный WAN?

Да, если владелец явно принимает и проверяет такое поведение при отказе. Запишите разрешённые устройства, семейства адресов и DNS-запросы; не называйте эту схему строгой блокировкой.

Нужно ли очищать все правила nftables для восстановления?

Нет. Это удаляет защиты других служб и не восстанавливает владельца конфигурации. Удалите разделы примера, верните сохранённые параметры и проверьте новое подключение управления.

Источники:

OpenWrt 25.12 — pbr release package definition — https://raw.githubusercontent.com/openwrt/packages/openwrt-25.12/net/pbr/Makefile
MOSSDeF — pbr 1.2.2 documentation — https://docs.mossdef.org/pbr/1.2.2/
OpenWrt — Policy-based routing — https://openwrt.org/docs/guide-user/network/routing/pbr
OpenWrt 25.12 — pbr default configuration — https://raw.githubusercontent.com/openwrt/packages/openwrt-25.12/net/pbr/files/etc/config/pbr

Sources checked 11 октября 2026 г.

Рекомендуемые статьи:

Маршрутизация по политикам OpenWrt: VPN для устройств