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