KN-3010, KeeneticOS 5.2 — нестабильная DNS-маршрутизация через Ethernet при WireGuard по умолчанию

[purrrfect]

Здравствуйте!

Прошу помочь разобраться с нестабильной работой DNS Routes на Keenetic Speedster KN-3010.

Конфигурация:

• KeeneticOS: первоначально 5.2 Alpha 11 (5.02.A.11.0-1), сейчас выполнен откат на 5.2 Alpha 10.

• Основная политика подключения: WireGuard (HungaryBudapestS7).

• Отдельная политика ISP: прямой выход через GigabitEthernet1.

• iPhone подключён к домашнему Wi-Fi, использует политику «По умолчанию» и DNS роутера 192.168.1.1.

• В DNS Routes настроен список rus, содержащий ru, su, рф и ряд конкретных доменов.

• Правило rus: GigabitEthernet1, автоматическое добавление маршрутов включено, эксклюзивность включена.

Проблема:

Некоторые российские мобильные приложения периодически не могут установить соединение либо обнаруживают VPN, хотя соответствующие домены входят в список DNS Routes.

Проблема наблюдалась на Alpha 11 и сохраняется на Alpha 10.

Примеры:

1. «Детский мир» — api.detmir.ru разрешается в 95.129.232.159. При отключении статического маршрута через Ethernet приложение перестаёт корректно работать. При включении маршрута работа восстанавливается.

2. «Аптека Апрель» — api.apteka-april.ru разрешается в 185.165.123.241. Наблюдались ошибки без статического маршрута. В одном из тестов после повторных DNS-запросов приложение заработало, а захват пакетов показал трафик через Ethernet.

3. «Магнит» — middle-api.magnit.ru разрешается в 185.65.151.87. Без статического маршрута работа непостоянна. На Alpha 10 приложение сначала выдает ошибку, но после нажатия «Повторить» сразу работает.

При переводе всего iPhone в политику ISP приложения работают нормально, но такой вариант не подходит, поскольку WireGuard должен оставаться основным подключением.

Что уже проверено:

• show sc dns-proxy route подтверждает регистрацию правила rus с auto: true, reject: true и интерфейсом GigabitEthernet1.

• DNS-запросы через nslookup к 192.168.1.1 возвращают правильные IP-адреса. Иногда первый запрос завершается двухсекундным тайм-аутом, повторный отвечает сразу.

• Перезагрузка роутера не устранила проблему.

• Отключение эксклюзивности у правила DNS Routes rus не помогло.

• Обычные статические маршруты к указанным IP обеспечивают работу приложений.

• Эксклюзивные статические маршруты в отдельных случаях переходили в состояние rejecting: true с интерфейсом ISP, хотя в конфигурации были привязаны к GigabitEthernet1. После отключения эксклюзивности у этих маршрутов состояние нормализовалось.

Прошу пояснить:

1. Является ли такое поведение DNS Routes известной проблемой KeeneticOS 5.2 или предусмотренным ограничением механизма?

2. Почему успешное разрешение домена DNS-прокси не всегда приводит к ожидаемой маршрутизации через Ethernet?

3. Может ли проблема быть связана с DNS-кешем приложений, обработкой широких доменных зон (ru, su, рф) или выбором политики маршрутизации?

4. Существует ли рекомендованная настройка для надёжного направления российских доменов через Ethernet при WireGuard по умолчанию, без ручного создания отдельных IP-маршрутов?

5. В какой версии KeeneticOS планируется исправление, если причина связана с программной ошибкой?

При необходимости могу предоставить self-test и дополнительные диагностические данные.

Спасибо!

Изменено 11 октября пользователем purrrfect

[Denis P]

47 минут назад, purrrfect сказал:

Может ли проблема быть связана с DNS-кешем приложений, обработкой широких доменных зон (ru, su, xn--p1ai) 

Может, tld использовать не стоит

Изменено 10 октября пользователем Denis P

[purrrfect]

А чем именно плохи TLD в DNS? Нагрузка на роутер, конфликты маршрутов или ограничения реализации в 5.2?

Мне очень удобно ru рф и прочее, почти не требуется дописывать домены вручную.

TLD реально могут вызывать описанный баг с отвалом DNS-маршрутов или это просто общая рекомендация?

[Denis P]

5 часов назад, purrrfect сказал:

А чем именно плохи TLD в DNS? Нагрузка на роутер, конфликты маршрутов или ограничения реализации в 5.2?

Мне очень удобно ru рф и прочее, почти не требуется дописывать домены вручную.

TLD реально могут вызывать описанный баг с отвалом DNS-маршрутов или это просто общая рекомендация?

tld могут создать огромную фоновую нагрузку. Потому что роутер периодически сам разрешает домены (и обновляет ipset'ы) которые были добавлены пользователем и к ним было хоть одно обращение, если вы посетили большое количество ресурсов для которых parent один из tld, можете примерно представать во что это выльется 

И нет, эта фича (пока что?) не отключается

Изменено 11 октября пользователем Denis P

[purrrfect]

Спасибо за ответ! Я не очень хорошо разбираюсь в этих механизмах, но более или менее понимаю, что 

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

tld могут создать огромную фоновую нагрузку

Но у меня появился ещё один вопрос по самой проблеме.

Небольшой эксперимент с тремя приложениями (которые раньше работали только при добавлении статических маршрутов), показал, что после выполнения nslookup для нужных доменов через DNS-сервер Keenetic (192.168.1.1) их IP-адреса появились в show object-group fqdn, а сами приложения заработали уже без статических маршрутов. При этом правило для всей зоны .ru у меня, как вы понимаете, было настроено изначально и не менялось.

Подскажите, пожалуйста, почему при обычном запуске приложений роутер не добавлял нужные адреса, а после ручного DNS-запроса всё заработало? Можно ли сделать так, чтобы это происходило автоматически?

 

[Denis P]

49 минут назад, purrrfect сказал:

Спасибо за ответ! Я не очень хорошо разбираюсь в этих механизмах, но более или менее понимаю, что 

Но у меня появился ещё один вопрос по самой проблеме.

Небольшой эксперимент с тремя приложениями (которые раньше работали только при добавлении статических маршрутов), показал, что после выполнения nslookup для нужных доменов через DNS-сервер Keenetic (192.168.1.1) их IP-адреса появились в show object-group fqdn, а сами приложения заработали уже без статических маршрутов. При этом правило для всей зоны .ru у меня, как вы понимаете, было настроено изначально и не менялось.

Подскажите, пожалуйста, почему при обычном запуске приложений роутер не добавлял нужные адреса, а после ручного DNS-запроса всё заработало? Можно ли сделать так, чтобы это происходило автоматически?

 

возможно ваши приложения где-то используют свои днсы, например яндекс устройства такое любят
по этому рекомендуется в настройках интернет фильтров отключить "транзит запросов" тогда они точно будут приходить на роутер (или блокироваться, если это dot/doh настроенный на клиенте)

[purrrfect]

15 часов назад, Denis P сказал:

по этому рекомендуется в настройках интернет фильтров отключить "транзит запросов"

Спасибо за наводку, транзит теперь выключен.

Но все проблемы не ушли. На конкретном примере с доменом trouver-tech.com, без использования TLD в этом правиле: IP 104.166.181.41 корректно появляется в show object-group fqdn, однако без статического маршрута через провайдера устройство теряет связь с облаком. После возвращения маршрута всё работает.

Подскажите, пожалуйста, как проверить, почему при наличии IP в группе маршрутизация не срабатывает при WireGuard по умолчанию? Какие диагностические данные нужны?

[iz07]

@purrrfect У меня вроде бы похожая проблема.

Только в качестве клиента я сейчас использую ноутбук с Ubuntu 24. Пробовал и Андроид телефон. Там та же проблема.

1. Добавил DNS-серверы вручную в роутере ( 8.8.4.4, 1.1.1.1 )

2. Добавил соединение со своим сервером Амнезии через компонент WireGuard

3. Добавил 2 политики: NL_ALL (где только VPN подключение активно) и NL_SPLIT (где 2 подключения активны - VPN и мой провайдер). Благодаря одному подключению, при NL_ALL все идет через VPN. А при NL_SPLIT через VPN идут только домены РФ сайты, благодаря маршрутизации, о которой ниже.

4. Настроил маршрутизацию указав домены ru, yandex.com, yandex.net, чтобы ко всем поддоменам шло обращение через провайдера напрямую. Прикрепил эту маршрутизацию к NL_SPLIT

5. Клиенту прикрепил политику  NL_SPLIT. Зарубежное все работает отлично. А РФ сайты открываются через раз или совсем не открываются. Причем через curl также. Не только через браузер.

 

Если клиенту прикреплять NL_ALL, то все открывается нормально. Ну разве что РФ сайты показываю заглушки про VPN.

Я пробовал сделать отдельную политику NL_DEBUG и прикрепить маршрутизацию не через домены верхнего уровня (tld), а указать конкретные домены. Но это не помогло ровным счетом ни чем.

 

Это такая же проблема как у вас? Не нашли решение?

[purrrfect]

Судя по описанию, проблема не одинакова, ибо у меня никакие сайты не ругаются на заглушки в браузере (ни на ПК/ноуте, ни на телефонах), а приложения ругаются выборочно и все мне уже известны, для них настроены исключения в виде статического маршрута.
Устройства у нас разные, настройки, стало быть, тоже разные. Например, у меня есть политика без VPN и в ней только бытовая техника LG, хотя для нее все равно потребовалось добавить исключения в виде доменов us.lgappstv.com lg.com lgthinq.com lgeapi.com lgemp-prd.net
Долгая и нудная переписка с чатом GPT дала понять, что кардинальных вариантов решения именно для меня немного:
1. Entware (который мне недоступен из-за отсутствия usb в роутере)
2. OpenWRT (который тоже мне недоступен из-за аппаратных ограничений роутера).
В общем, в моём случае только менять роутер на другой, без KeeneticOS, но по своим параметрам и бюджету пока всё печально.

[iz07]

 > ибо у меня никакие сайты не ругаются на заглушки в браузере

Не совсем понял о чем вы. Я говорил о том, что если переключиться на политику "все через VPN" для проверки, то все сайты открываются без задержек. Но сайты из белого списка РФ показывают свои заглушки типа "отключите VPN". И это ожидаемая работа. Уверен, что и у вас также работает.

> Устройства у нас разные, настройки, стало быть, тоже разные

Вы настраиваете выбор соединения (куда пойдет трафик - через VPN или напрямую) через Маршрутизация -> Маршруты DNS -> Списки доменных имен и "Правила маршрутизации" ? И там указываете список доменов (может быть, первого уровня)? Если да, то у нас похожие настройки. И я грешу именно на работу маршрутизации. Так как на политике "все через VPN"  все открывается быстро и четко.

> приложения ругаются выборочно и все мне уже известны

Очень похоже на то как работает у меня при политике с разделением трафика - часть сайтов российских открываются через раз (Макс, Яндекс Почта, Карты Роснефть).

 

 

[purrrfect]

1 час назад, iz07 сказал:

если переключиться на политику "все через VPN" для проверки, то все сайты открываются без задержек

Задержка мною даже не замерялась)) Как только было настроено соединение WireGuard, то сразу же и домены в маршрутизации, иначе да, Вы правы, не открылось бы ничего российского  Мне было важнее просто не переключать VPN вручную, посещая то или иное приложение/сайт. Так что задержка (если она и есть) гораааааздо меньше того времени, потраченного на ползунок.

1 час назад, iz07 сказал:

у нас похожие настройки. И я грешу именно на работу маршрутизации. Так как на политике "все через VPN"  все открывается быстро и четко.

да, в целом так. Но проблема у меня не в задержках/скорости

1 час назад, iz07 сказал:

часть сайтов российских открываются через раз

У меня проблемы немного другие: часть приложений (Детский мир, например) вообще не откроются без статического маршрута. Макс, Яндекс и вообще все прочие открываются стабильно. Одно время еще капризничали (т.е. висели заглушками про VPN и не пускали никуда) Аптека.Апрель, Магнит и Авито, но там скорее наложилась атака на Сасово.
И самая главная проблема в том, что в этих статических маршрутах в итоге всегда заложен как раз-таки RU домен! Вот, что обидно. Почему-то они просачиваются сквозь правила и настройки. И непонятно, какое приложение вдруг отщёлкнет следующим((

[iz07]

> да, в целом так. Но проблема у меня не в задержках/скорости

Очень похожая проблема и у меня. Проблема не в скорости. Проблема в том, что российские сайты открываются через раз или совсем не открываются. Разные по-разному.

Эта проблема с маршрутизацией, смотрю, на форуме в разных вариациях встречается.