purrrfect

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

А чем именно плохи TLD в DNS? Нагрузка на роутер, конфликты маршрутов или ограничения реализации в 5.2? Мне очень удобно ru рф и прочее, почти не требуется дописывать домены вручную. TLD реально могут вызывать описанный баг с отвалом DNS-маршрутов или это просто общая рекомендация?

Здравствуйте! Прошу помочь разобраться с нестабильной работой 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. Примеры: «Детский мир» — api.detmir.ru разрешается в 95.129.232.159. При отключении статического маршрута через Ethernet приложение перестаёт корректно работать. При включении маршрута работа восстанавливается. «Аптека Апрель» — api.apteka-april.ru разрешается в 185.165.123.241. Наблюдались ошибки без статического маршрута. В одном из тестов после повторных DNS-запросов приложение заработало, а захват пакетов показал трафик через Ethernet. «Магнит» — 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. После отключения эксклюзивности у этих маршрутов состояние нормализовалось. Прошу пояснить: Является ли такое поведение DNS Routes известной проблемой KeeneticOS 5.2 или предусмотренным ограничением механизма? Почему успешное разрешение домена DNS-прокси не всегда приводит к ожидаемой маршрутизации через Ethernet? Может ли проблема быть связана с DNS-кешем приложений, обработкой широких доменных зон (ru, su, рф) или выбором политики маршрутизации? Существует ли рекомендованная настройка для надёжного направления российских доменов через Ethernet при WireGuard по умолчанию, без ручного создания отдельных IP-маршрутов? В какой версии KeeneticOS планируется исправление, если причина связана с программной ошибкой? При необходимости могу предоставить self-test и дополнительные диагностические данные. Спасибо!