Николай У

Ответ 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 того же хоста трасса идентична, и там всё работает.

Ответ от 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) в той же политике работает нормально.

Выхватил аналогичную проблему. 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 могу приложить по запросу.