Новая функция 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

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

Изменено 21 сентября пользователем 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?
пожалуйста, давайте без нейронок, лучше своими словами