Маршрутизация DNS иногда не работает

[qmxocynjca]

В роутере (fw 5.0.0) прописан DNS от провайдера (обычный) и от Яндекса (DoT), в списке DNS маршрутизации прописан youtube.com.

Проблема: www.youtube.com не смог зароутиться куда надо. После неудачного роутинга несколько раз делал "nslookup www.youtube.com 192.168.1.1", но результата не дало - роутер упорно вёл по провайдеру.

Пробовал включить dns-proxy debug, после чего роутер почти завис секунд через 30, смог выключить эту настройку только через telnet. Кажется после этого роутинг таки заработал, но легче от этого не стало.

Наблюдения:

* провайдерные DNS возвращают 173.194.221.198 от primary и 64.233.162.198 от secondary на nslookup www.youtube.com.

* nslookup на www.youtube.com возвращает "Tracing route to wide-youtube.l.google.com", а на youtube.com возвращает "Tracing route to youtube.com".

* nslookup www.youtube.com 77.88.8.8 (обычный dns от яндекса) возвращает разные адреса на каждый запрос.

Вот как это примерно выглядит:

C:\Users\user>tracert -d -w 50 www.youtube.com

Tracing route to wide-youtube.l.google.com [173.194.220.198]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     1 ms     1 ms     1 ms  <isp_gw>
^C
C:\Users\user>nslookup www.youtube.com 192.168.1.1
Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:    wide-youtube.l.google.com
Addresses:  2a00:1450:4010:c1e::c6
          142.251.1.198
Aliases:  www.youtube.com
          youtube-ui.l.google.com


C:\Users\user>tracert -d -w 50 www.youtube.com

Tracing route to wide-youtube.l.google.com [142.251.1.198]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     1 ms     1 ms    <1 ms  <isp_gw>
^C
  
C:\Users\user>tracert -d -w 50 youtube.com

Tracing route to youtube.com [173.194.221.91]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.88.88
  2    91 ms    89 ms     *     <kvn_gw>
  

 

 

Изменено 4 ноября пользователем qmxocynjca

[Ivanero]

On 11/18/2025 at 1:26 AM, Racer X said:

Да, так и есть. Я бы сказал что заметно чаще 3-4 часов. Скорее раз в час, если не чаще. Затык и трафик в провайдера. Продолжается 1-2 мин и потом все опять работает нормально.
И могу точно сказать что это не тоннель у меня периодически отваливается. Потому что если с этим же тоннелем возвращаюсь на классический IP роутинг по подсетям, то все работает железобетонно.

Я это все наблюдаю еще с первых бет 5 версии и пока изменений такого поведения не вижу вплоть до 5.0.1.

так же подтверждаю на: KN-3812, KN-3811 (5.0.1) - оба arm64. Причем именно с YT. с Twi/X такого не наблюдается. YT витрину роликов отрисовывает но видео не загружает, хотя конечно ж googlevideo.com в списке DNS-b-R.

на массе (10+ штук) мелких Keenetic mipsel/mipsbe (Start, Starter, Lite, 4G, Carrier, Duo, GigaIII, Viva, Hero 4G+, Speedster, Runner 4G) - все работает без этих аномалий

Изменено 19 ноября пользователем Ivanero

[Racer X]

6 часов назад, Ivanero сказал:

Причем именно с YT. с Twi/X такого не наблюдается.

Да не, далеко не только с YT.
FB, Tidal и т.д. Ощущение что это со всем, что активно использует CDN и балансировку по ним с регулярной сменой IP.

[BFT]

В 05.11.2025 в 11:38, Le ecureuil сказал:

 

Версия 5.0.1. Похоже проблема маршрутами ipv6.

Спойлер

 

~ # iptables-save | grep _NDM_OGDN
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list0 dst --return-nomatch ! --update-subcounters -j MARK --set-xmark 0xffffab1/0xffffffff
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list0 dst -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list0 dst --return-nomatch ! --update-counters ! --update-subcounters -j RETURN
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list1 dst --return-nomatch ! --update-subcounters -j MARK --set-xmark 0xffffab0/0xffffffff
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list1 dst -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list1 dst --return-nomatch ! --update-counters ! --update-subcounters -j RETURN
~ # ip6tables-save | grep _NDM_OGDN
~ #

 

Спойлер

 

~ # iptables-save | grep _NDM_OGDN
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list0 dst --return-nomatch ! --update-subcounters -j MARK --set-xmark 0xffffab1/0xffffffff
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list0 dst -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list0 dst --return-nomatch ! --update-counters ! --update-subcounters -j RETURN
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list1 dst --return-nomatch ! --update-subcounters -j MARK --set-xmark 0xffffab0/0xffffffff
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list1 dst -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A _NDM_DNSRT_PREROUTING_MANGLE -m set --match-set _NDM_OGDN_4_@domain-list1 dst --return-nomatch ! --update-counters ! --update-subcounters -j RETURN
~ # ip6tables-save | grep _NDM_OGDN
-A _NDM_DNSRT_PRERT -m set --match-set _NDM_OGDN_6_@domain-list1 dst --return-nomatch ! --update-counters ! --update-subcounters -j MARK --set-xmark 0xffffab8/0xffffffff
-A _NDM_DNSRT_PRERT -m set --match-set _NDM_OGDN_6_@domain-list1 dst -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A _NDM_DNSRT_PRERT -m set --match-set _NDM_OGDN_6_@domain-list1 dst --return-nomatch ! --update-counters ! --update-subcounters -j RETURN
~ #

 

[FLK]

Ну вставлю свои 5 копеек - да, действительно иногда бывают так сказать "несработки", но говорить о том, что вообще не работает я не могу...

Если выразить в процентах, когда не работает, то выйдет 1-2%, ну по крайней мере у меня.

Уважаемый @Le ecureuil, может что-то можно еще сделать? Проблема не единичная, а функционал то нужный)

[Oleg Nekrylov]

В 18.11.2025 в 01:26, Racer X сказал:

Да, так и есть. Я бы сказал что заметно чаще 3-4 часов. Скорее раз в час, если не чаще. Затык и трафик в провайдера. Продолжается 1-2 мин и потом все опять работает нормально.
И могу точно сказать что это не тоннель у меня периодически отваливается. Потому что если с этим же тоннелем возвращаюсь на классический IP роутинг по подсетям, то все работает железобетонно.

Я это все наблюдаю еще с первых бет 5 версии и пока изменений такого поведения не вижу вплоть до 5.0.1.

На IPSet4Static (ADH) всё работает без проблем. Поэтому продолжил изыскания и первое что сделал, сбросил конфиг 5.0.1 к заводским, настроил с нуля (пока только маршрутизацию по доменам, всё остальное пока не трогал) - уже сутки работает без проблем. Пока прихожу к выводу, что может быть какой-то мусор "застрял" от предыдущих бет, который в глаза сразу и не бросается (в startup-config), но гадит знатно.

Заметил особенность работы галки эксклюзивный маршрут: если галка не стоит, локальные (Домашняя, Гостевая сеть) ПК в туннель не идут, а вот те которые пришли с наружи (из других VPN) лезут согласно маршрута. Если галку поставить, то в туннель лезут и локальные и внешние ПК.

Изменено Пятница в 14:40 пользователем Oleg Nekrylov

[Racer X]

59 минут назад, Oleg Nekrylov сказал:

Заметил особенность работы галки эксклюзивный маршрут: если галка не стоит, локальные (Домашняя, Гостевая сеть) ПК в туннель не идут, а вот те которые пришли с наружи (из других VPN) лезут согласно маршрута.

У меня нигде галка не стоит. И на двух роутерах все клиенты без проблем ходят.

Изменено Пятница в 15:32 пользователем Racer X

[Ivanero]

18 hours ago, Oleg Nekrylov said:

На IPSet4Static (ADH) всё работает без проблем. Поэтому продолжил изыскания и первое что сделал, сбросил конфиг 5.0.1 к заводским, настроил с нуля (пока только маршрутизацию по доменам, всё остальное пока не трогал) - уже сутки работает без проблем. Пока прихожу к выводу, что может быть какой-то мусор "застрял" от предыдущих бет, который в глаза сразу и не бросается (в startup-config), но гадит знатно.

Заметил особенность работы галки эксклюзивный маршрут: если галка не стоит, локальные (Домашняя, Гостевая сеть) ПК в туннель не идут, а вот те которые пришли с наружи (из других VPN) лезут согласно маршрута. Если галку поставить, то в туннель лезут и локальные и внешние ПК.

сменил на 10+ роутерах (mipsel/mipsbe/arm64) выставив Exclusive Route - на mipsel/mipsbe все помогло и стабильно работать начало, но на arm64 (KN-3811, KN-3812) продолжает "глючить"

[Racer X]

Попробовал у себя на обоих роутерах переключить все DNS маршруты в эксклюзивный маршрут. Поведение не изменилось от слова совсем. Как были периодические отвалы с трафиком мимо тоннеля во время них - так и остались.

[masyanich]

а нет ли планов вот эту киллер-фичу реализовать через веб-морду?

• Реализована возможность настройки маршрутов через разные шлюзы или интерфейсы для одной и той же группы объектов FQDN с помощью интерфейса командной строки (dns-proxy route object-group). Приоритет маршрутов определяется порядком их ввода. [NDM-4118]

 

[keenet07]

12 минут назад, masyanich сказал:

а нет ли планов вот эту киллер-фичу реализовать через веб-морду?

Так проверяйте. Возможность в веб привязывать один список к разным интерфейсам уже появилась. Главное не включайте эксклюзивный маршрут в этих правилах. В смежной теме обсуждалось, включая недоделки.

Изменено 2 часа назад пользователем keenet07

[masyanich]

8 минут назад, keenet07 сказал:

Так проверяйте. Возможность в веб привязывать один список к разным интерфейсам уже появилась

о, реально, тогда не понятно с "метрикой", вот ее бы в gui, а то что за чем идет - решительно не ясно

Изменено 2 часа назад пользователем masyanich

[FLK]

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

о, реально, тогда не понятно с "метрикой", вот ее бы в gui, а то что за чем идет - решительно не ясно

да, я как раз об этом писал в другой теме, нужны в вебе некие приоритеты - куда сначала, куда потом, если "сначала" упало

[keenet07]

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

А вообще по порядку добавления должно следовать. Можно в конфиге посмотреть. Возможно, что  в некоторых обстоятельствах последовательность может различаться с вебом.