Новая функция ip policy dns-proxy route object-group

[mexxtron]

Добрый день, в альфе 5.2 появилась функция назначения маршрутов FQDN пользовательским политикам доступа. Вроде разобрался, синтаксис как пример:

 ip policy Policy0 dns-proxy route object-group domain-list5 Wireguard8 auto reject

После применения:

{
	"prompt": "(config)",
	"status": [
		{
			"status": "message",
			"code": "4456748",
			"ident": "Dns::Route::Manager",
			"message": "updated the DNS route to domain-list5."
		}
	]
}

 

Где Policy0 - политика резервного соединения, куда включены несколько устройств, domain-list5 - список с именами FQDN (не будем говорить какими :), Wireguard8 - подключение с доступом в интернет.

И все равно устройства не имеют доступа к этим ресурсам. Как добиться результата?

[mexxtron]

P.S. В качестве DNS конечно прописан кинетик для всех политик доступа.

[Николай У]

Выхватил аналогичную проблему. Cloude Code её диагностировал и предложил написать сюда на форум.

Ниже его составленный текст:

---------------------------------------

Подтверждаю проблему с этой функцией, но с другим проявлением: правило применяется и маршрутизация срабатывает, однако TCP-соединения к хостам из группы «умирают» после первых пакетов.

 

Устройство: Keenetic Ultra (KN-1811), регион EA

Версия: 5.2 Alpha 10 (5.02.A.10.0-1), канал draft

 

КОНФИГУРАЦИЯ

- GigabitEthernet1 — провайдер (IPoE, адрес по DHCP), маршрут по умолчанию в системной таблице.

- Wireguard0 — VPN-подключение A.

- Wireguard3 — VPN-подключение B; его endpoint достигается через Wireguard0 (туннель в туннеле).

- Политика Policy2: permit global Wireguard3, permit global GigabitEthernet1 (резерв), остальные интерфейсы — no permit. В таблице политики 0.0.0.0/0 -> Wireguard3.

- Клиент (Windows 11) привязан к Policy2 через ip hotspot host <mac> policy Policy2. DNS у клиента — роутер (по DHCP), DoH/DoT на клиенте не используется.

- object-group fqdn domain-list0 (include site-a.example) и object-group fqdn domain-name-list-0 (include site-b.example, site-c.example).

- Правила в политике:

ip policy Policy2 dns-proxy route object-group domain-list0 Wireguard0 auto reject

ip policy Policy2 dns-proxy route object-group domain-name-list-0 GigabitEthernet1 auto reject

- Аналогичные глобальные правила dns-proxy route object-group для тех же групп тоже есть.

- ppe software и ppe hardware включены, ip conntrack max-entries 32768.

 

ОЖИДАЕТСЯ

Клиент из Policy2 ходит на домены из domain-name-list-0 через GigabitEthernet1, сайты открываются как обычно.

 

ФАКТИЧЕСКИ

Маршрутизация формально срабатывает: traceroute с клиента показывает вторым хопом шлюз провайдера, сервисы «мой IP» показывают адрес провайдера. Но соединения зависают:

- curl с клиента к https://site-b.example/ (HTML ~28 КБ): TCP connect ~30 мс, TLS-рукопожатие завершается за ~70 мс, дальше ни одного байта ответа до таймаута. Из 10 запросов подряд (пауза 1,5 с) — 9 таймаутов по 25 с, 1 успешный.

- Тот же паттерн на другом хосте из группы: первый ответ (HTTP 307) за 0,24 с, следующий запрос по тому же соединению — таймаут.

- В браузере: HTML приходит (TTFB ~130 мс), но полная загрузка страницы 7–17 с. По Performance API между fetchStart и connectStart проходит ~16 с: браузер ждёт на повисшем существующем HTTP/2-соединении, затем открывает новое.

 

ЧТО ПРОВЕРЕНО

1. Тот же хост через обычный статический маршрут (ip route <ip хоста> GigabitEthernet1 auto, домен на время убран из группы): 8 из 8 запросов по ~0,2 с, в браузере 0,3–0,6 с. Маршрут виден в таблице Policy2 (show ip policy). То есть путь провайдер -> хост исправен, проблема именно в ip policy ... dns-proxy route.

2. no ppe hardware — без изменений (8 из 8 таймаутов).

3. Правило без reject — без изменений (7 из 8 таймаутов).

4. MTU: ping -f -l 1472 до хоста через провайдера проходит без потерь.

5. Правило domain-list0 -> Wireguard0 в той же политике работает нормально, все запросы успешны. Проблема проявляется, когда целевой интерфейс DNS-маршрута — провайдер (GigabitEthernet1), а маршрут по умолчанию политики — WireGuard.

6. В show dns-proxy у экземпляра Policy2 после добавления правила появляются fqdn_mirror_path = /var/run/fqdn-dns-mirror-Policy2.sock и fqdn_delay_mark = 268434095, то есть правило применяется.

7. В show ip policy для Policy2 /32-маршруты к выученным IP не отображаются (в отличие от статического маршрута).

 

Похоже, что первые пакеты соединения обрабатываются по DNS-маршруту (GigabitEthernet1 + NAT), а последующие пакеты того же потока уходят по маршруту по умолчанию политики (Wireguard3), из-за чего соединение зависает.

 

МИНИМАЛЬНОЕ ВОСПРОИЗВЕДЕНИЕ

1. Политика PolicyN: основной выход WireGuard, GigabitEthernet1 — резервный.

2. Клиент в PolicyN, DNS — роутер.

3. object-group fqdn с любым доменом, отдающим страницу больше нескольких КБ.

4. ip policy PolicyN dns-proxy route object-group <группа> GigabitEthernet1 auto reject

5. С клиента несколько раз подряд: curl -o NUL -w "%{time_appconnect} %{time_starttransfer} %{time_total}" https://<домен>/ — TLS завершается, ответ не приходит.

 

self-test могу приложить по запросу.

[Denis P]

23 часа назад, Николай У сказал:

ip policy Policy2 dns-proxy route object-group domain-list0 Wireguard0 auto reject

ip policy Policy2 dns-proxy route object-group domain-name-list-0 GigabitEthernet1 auto reject

Тут одинаковые наборы или это опечатка или что?

Edited September 21 by Denis P

[Николай У]

22 минуты назад, Denis P сказал:

Тут одинаковые наборы или это опечатка или что?

Ответ от Cloude Code:

----------------------------------------------------------

Не опечатка — это две разные группы, имена именно такие в конфиге. Первая (domain-list0) создавалась через веб-конфигуратор ещё на 5.1.5, вторая (domain-name-list-0) — через веб-конфигуратор уже на 5.2 Alpha 10. Похоже, в 5.2 веб-интерфейс именует новые списки по другой схеме, отсюда и разные префиксы.

 

Фрагмент show running-config на момент теста (домены заменены на условные):

 

object-group fqdn domain-list0

    description "VPN-A"

    include site-a.example

!

object-group fqdn domain-name-list-0

    description "ISP"

    include site-b.example

    include site-c.example

!

ip policy Policy2

    description VPS

    permit global Wireguard3

    permit global GigabitEthernet1

    no permit global Wireguard0

    ...

    dns-proxy route object-group domain-list0 Wireguard0 auto reject

    dns-proxy route object-group domain-name-list-0 GigabitEthernet1 auto reject

!

dns-proxy

    rebind-protect auto

    route object-group domain-list0 Wireguard0 auto reject

    route object-group domain-name-list-0 GigabitEthernet1 auto reject

!

 

Наборы доменов в группах не пересекались. Проблема воспроизводится только для второго правила (в GigabitEthernet1); первое (в Wireguard0) в той же политике работает нормально.

[Denis P]

1 час назад, Николай У сказал:

 

Проблема воспроизводится только для второго правила (в GigabitEthernet1); первое (в Wireguard0) в той же политике работает нормально.

Что там вообще, за интерфейсом ge1? Другой провайдер?

З.ы. Выступать в качестве мясного прокси для нейронки - моветон

[Николай У]

36 минут назад, Denis P сказал:

Что там вообще, за интерфейсом ge1? Другой провайдер?

З.ы. Выступать в качестве мясного прокси для нейронки - моветон

Ответ Cloude:

-----------------------

За GigabitEthernet1 — единственный провайдер, домашний IPoE. Адрес на WAN выдаётся по DHCP из приватной сети 10.x.x.x/23 (шлюз 10.x.x.1, lease 300 с), то есть провайдер за CGNAT: публичный адрес (193.x.x.x) на самом порту не присутствует. DNS провайдера тоже из 10.x.x.x, по DHCP. Никакого второго провайдера, модема или WISP нет.

 

Оба WireGuard-туннеля выходят в интернет через этот же ge1: у Wireguard0 endpoint достигается через GigabitEthernet1, у Wireguard3 — через Wireguard0.

 

Traceroute с клиента к хосту из группы при DNS-маршруте в GigabitEthernet1: 192.168.1.1 -> 10.10.x.x (шлюз провайдера) -> 10.71.x.x -> 193.x.x.x (магистраль провайдера) -> ... -> хост. При обычном статическом маршруте на IP того же хоста трасса идентична, и там всё работает.

[Denis P]

1 час назад, Николай У сказал:

Ответ Cloude:

-----------------------

За GigabitEthernet1 — единственный провайдер, домашний IPoE. Адрес на WAN выдаётся по DHCP из приватной сети 10.x.x.x/23 (шлюз 10.x.x.1, lease 300 с), то есть провайдер за CGNAT: публичный адрес (193.x.x.x) на самом порту не присутствует. DNS провайдера тоже из 10.x.x.x, по DHCP. Никакого второго провайдера, модема или WISP нет.

 

Оба WireGuard-туннеля выходят в интернет через этот же ge1: у Wireguard0 endpoint достигается через GigabitEthernet1, у Wireguard3 — через Wireguard0.

 

Traceroute с клиента к хосту из группы при DNS-маршруте в GigabitEthernet1: 192.168.1.1 -> 10.10.x.x (шлюз провайдера) -> 10.71.x.x -> 193.x.x.x (магистраль провайдера) -> ... -> хост. При обычном статическом маршруте на IP того же хоста трасса идентична, и там всё работает.

т.е вы хотите пустить часть доменов через провайдера, для устройства которое находится в политике с VPN?
пожалуйста, давайте без нейронок, лучше своими словами

[server]

Netcraze Ultra NC-1812, NDMS 5.2 Beta 0 (5.02.B.0.0-0): обход WireGuard через FQDN в пользовательской политике

У меня воспроизводится похожее поведение. Проверки проводились 8–9 октября 2026 года. Ниже — наблюдения из захватов пакетов, CLI и контрольных запусков приложения.

Схема: провайдер МТС, PPPoE0, 1 Гбит/с; один активный WireGuard-клиент Wireguard6, сервер в Германии. Apple TV подключён по Ethernet и назначен политике vpn / Policy0. Основной выход этой политики — Wireguard6, резервный — PPPoE0. Требуется направлять VK Видео через PPPoE0, сохраняя VPN для остальных назначений. IPv6 отключён. В захвате DNS-запросы телевизора поступают на роутер. MTU PPPoE — 1492, WireGuard — 1280; при сравнении вариантов эти значения не менялись.

Домены VK и okcdn.ru уже присутствуют в FQDN-группе, адреса назначений есть в выученном списке этой группы. Сокращённый фрагмент конфигурации, без правил других сервисов и без временных статических маршрутов:

object-group fqdn domain-name-list-1
    description VK_MTS
    include vk.com
    include vk.ru
    include vk.me
    include userapi.com
    include vkuser.net
    include vkuseraudio.net
    include vkuseraudio.ru
    include vkuserphoto.ru
    include vkvideo.ru
    include vk-cdn.net
    include vk-portal.net
    include cdn-vk.ru
    include remote-mobile-config.studilka.ru
    include okcdn.ru
!
ip policy Policy0
    description vpn
    permit global Wireguard6
    permit global PPPoE0
    dns-proxy route object-group domain-name-list-1 PPPoE0 auto reject
!

Ожидается: соединение к адресу из этой группы целиком проходит через PPPoE0.

Наблюдается: первый запуск некоторых серий VK Видео задерживается на 20–30 секунд, иногда больше минуты; повторный запуск может быть быстрым. При временном переводе телевизора целиком на прямой МТС серии запускались сразу.

Проведён одновременный захват на LAN, PPPoE0 и Wireguard6:

1. У 12 затронутых TCP-соединений исходный SYN проходит через PPPoE0.
2. Затем 289 исходящих пакетов тех же соединений появляются на Wireguard6 с исходным IPv4-адресом PPPoE0. На WireGuard ответов для этих потоков в записи нет.
3. Все эти 289 пакетов сопоставлены с LAN телевизора по seq/ack/flags/длине TCP payload. Совпадающих копий на PPPoE0 в пределах ±100 мс не найдено.
4. CLI показывает NAT на адрес МТС, но у части зависших потоков остаётся метка основной VPN-политики 0x0ffffaaa вместо метки маршрута VK 0x0ffffaab. Это значения в моей конфигурации, не универсальные значения для других устройств.

Контрольные проверки:

— Выключение одновременно software PPE и hardware PPE задержку не устранило: первая и четвёртая серии ожидали около 20 секунд. После проверки оба ускорителя включены обратно.
— Восемь пробных статических IPv4 /32 через PPPoE0 в той же Policy0 исправили путь только для покрытых адресов. В этой записи 41 соединение к шести использованным адресам с такими маршрутами не попало в WG, но 10 соединений к другим адресам VK дали ещё 201 пакет на WG. Задержки в приложении сохранились.
— После добавления /32 для всех 136 текущих IPv4-адресов FQDN-группы VK все пять контрольных серий стартовали без задержек; ошибочных потоков VK с адресом МТС на WireGuard в этой записи не осталось.
— Во время теста группа выучила ещё шесть адресов. Итоговый временный обход — 142 отдельных /32 в Policy0 через PPPoE0, auto reject. Целые подсети не добавлялись; исходное FQDN-правило сохранено.
— Финальный пользовательский контроль с выключенным захватом и обоими включёнными PPE: семь серий без задержек. Основной VPN для остального трафика сохранён.

Таким образом, наблюдаемый сбой связан с различием пути пакетов одного TCP-потока при FQDN-правиле и при обычном статическом маршруте в той же политике. Внутреннюю причину, например конкретный дефект обработки CONNMARK, пока не утверждаю.

Подскажите, пожалуйста, известна ли такая проблема для 5.2 Beta 0 на NC-1812 и какие дополнительные данные нужны для её проверки? Хотелось бы обойтись штатным доменным правилом без постоянного обслуживания списка IP. Self-test, CLI-выводы и исходные захваты за время проверки сохранены; диагностические материалы можно подготовить отдельно по правилам форума.

[Denis P]

43 минуты назад, server сказал:

Таким образом, наблюдаемый сбой связан с различием пути пакетов одного TCP-потока при FQDN-правиле и при обычном статическом маршруте в той же политике

Это не сбой, а ожидаемое поведение. Днс маршруты работают совсем по другому принципу и никак не связаны со статик роутами

[server]

 

2 часа назад, Denis P сказал:

Это не сбой, а ожидаемое поведение. Днс маршруты работают совсем по другому принципу и никак не связаны со статик роутами

Спасибо за пояснение. Понимаю, что DNS-маршруты и статические /32 — разные механизмы, поэтому успешная работа со статическими маршрутами сама по себе ещё не доказывает ошибку DNS-маршрутизации.

Хотел бы уточнить именно наблюдение из одновременного захвата на LAN, PPPoE0 и Wireguard6: SYN уходит через PPPoE0, а последующие пакеты того же TCP-потока появляются на Wireguard6 с исходным адресом МТС после NAT. Ответов на WireGuard для этих потоков нет. Такое наблюдалось у 12 соединений; 289 пакетов сопоставлены с LAN по seq/ack/flags/длине TCP payload, совпадающих копий на PPPoE0 в пределах ±100 мс не найдено.

DNS телевизора — роутер, домены включены в FQDN-группу, PPPoE0 в момент проверки работает. Конкретную внутреннюю причину я пока не установил.

Можете пояснить, относится ли «ожидаемое поведение» только к различию механизмов или также к описанной смене выходного интерфейса одного TCP-потока с сохранением исходного адреса МТС?

И как правильно настроить эту схему штатным FQDN-правилом: основной выход устройства через WireGuard, а группа VK — через PPPoE0, без обслуживания списка /32? Если нужны дополнительные проверки или self-test, подскажите, какие данные собрать и в каком состоянии настроек.

Edited Friday at 12:26 PM by server
Забыл процитировать в ответе

[Denis P]

4 часа назад, server сказал:

 

Спасибо за пояснение. Понимаю, что DNS-маршруты и статические /32 — разные механизмы, поэтому успешная работа со статическими маршрутами сама по себе ещё не доказывает ошибку DNS-маршрутизации.

Хотел бы уточнить именно наблюдение из одновременного захвата на LAN, PPPoE0 и Wireguard6: SYN уходит через PPPoE0, а последующие пакеты того же TCP-потока появляются на Wireguard6 с исходным адресом МТС после NAT. Ответов на WireGuard для этих потоков нет. Такое наблюдалось у 12 соединений; 289 пакетов сопоставлены с LAN по seq/ack/flags/длине TCP payload, совпадающих копий на PPPoE0 в пределах ±100 мс не найдено.

DNS телевизора — роутер, домены включены в FQDN-группу, PPPoE0 в момент проверки работает. Конкретную внутреннюю причину я пока не установил.

Можете пояснить, относится ли «ожидаемое поведение» только к различию механизмов или также к описанной смене выходного интерфейса одного TCP-потока с сохранением исходного адреса МТС?

И как правильно настроить эту схему штатным FQDN-правилом: основной выход устройства через WireGuard, а группа VK — через PPPoE0, без обслуживания списка /32? Если нужны дополнительные проверки или self-test, подскажите, какие данные собрать и в каком состоянии настроек.

если я правильно понял, вы как и автор темы хотите использовать ДНС маршрутизацию не в основной политике? Поддержка этой функции  в веб интерфейсе доступна с 5.2.B0 

Edited Friday at 05:16 PM by Denis P

[server]

В 09.10.2026 в 20:15, Denis P сказал:

если я правильно понял, вы как и автор темы хотите использовать ДНС маршрутизацию не в основной политике?

Да, речь о пользовательской политике vpn (Policy0), к которой привязан Apple TV. Основной выход — Wireguard6, резервный — провайдер МТС через PPPoE0. Для группы доменов VK и okcdn.ru нужен выход через PPPoE0.

На Netcraze Ultra NC-1812 уже установлена 5.2 Beta0 (5.02.B.0.0-0). Правило настроено именно внутри Policy0:

ip policy Policy0
    description vpn
    permit global Wireguard6
    permit global PPPoE0
    dns-proxy route object-group domain-name-list-1 PPPoE0 auto reject

В этой конфигурации SYN уходит через PPPoE0, а последующие пакеты того же TCP-потока появляются на Wireguard6 с исходным адресом МТС после NAT. Это наблюдалось у 12 соединений; ответов на WireGuard для них нет. При статических /32 через PPPoE0 в той же Policy0 задержки исчезают. DNS телевизора — роутер, адреса назначений есть в выученном списке FQDN-группы.

Подскажите, корректно ли настроено FQDN-правило для такой схемы? Должно ли оно удерживать весь TCP-поток на PPPoE0? Если для проверки нужны self-test или дополнительные данные, уточните, что собрать и при каких настройках.

[Denis P]

2 минуты назад, server сказал:

Да, речь о пользовательской политике vpn (Policy0), к которой привязан Apple TV. Основной выход — Wireguard6, резервный — провайдер МТС через PPPoE0. Для группы доменов VK и okcdn.ru нужен выход через PPPoE0.

На Netcraze Ultra NC-1812 уже установлена 5.2 Beta0 (5.02.B.0.0-0). Правило настроено именно внутри Policy0:

ip policy Policy0
    description vpn
    permit global Wireguard6
    permit global PPPoE0
    dns-proxy route object-group domain-name-list-1 PPPoE0 auto reject

В этой конфигурации SYN уходит через PPPoE0, а последующие пакеты того же TCP-потока появляются на Wireguard6 с исходным адресом МТС после NAT. Это наблюдалось у 12 соединений; ответов на WireGuard для них нет. При статических /32 через PPPoE0 в той же Policy0 задержки исчезают. DNS телевизора — роутер, адреса назначений есть в выученном списке FQDN-группы.

Подскажите, корректно ли настроено FQDN-правило для такой схемы? Должно ли оно удерживать весь TCP-поток на PPPoE0? Если для проверки нужны self-test или дополнительные данные, уточните, что собрать и при каких настройках.

Задержки должны быть, да. Их специально сделали чтобы роутер успел разрешить и сложить адреса в ipset до того как пакетики побегут не туда.

В cli ничего трогать не нужно, настройка полностью в веб теперь per policy тоже

[server]

3 часа назад, Denis P сказал:

Задержки должны быть, да. Их специально сделали чтобы роутер успел разрешить и сложить адреса в ipset до того как пакетики побегут не туда.

Спасибо, про задержку перед заполнением ipset понял. Фрагмент CLI я привёл, чтобы показать правило внутри Policy0.

Хотел уточнить: у меня SYN уже уходит через PPPoE0, а следующие пакеты того же TCP-потока — через Wireguard6 с адресом МТС после NAT. То есть меняется выходной интерфейс уже начатого соединения, ответов на WireGuard для этих пакетов нет. Именно эта смена пути тоже является ожидаемым поведением?

В приложении задержки составляют 20–30 секунд, иногда больше минуты. Какая длительность задержки предусмотрена для подготовки ipset?

И подскажите, пожалуйста, какую конкретно настройку проверить в веб-интерфейсе для Policy0, чтобы весь TCP-поток к адресам из группы проходил через PPPoE0. Могу подготовить self-test и пример одного соединения с временными метками пакетов, если это поможет.