Перейти к содержанию

domovoi

Участники форума
  • Постов

    6
  • Зарегистрирован

  • Посещение

Весь контент domovoi

  1. Перепроверил — пресет подставляет https://safe.dot.dns.yandex.net/dns-query, endpoint рабочий. Ошибка 404 была вызвана другой причиной. Тему можно закрыть, спасибо за проверку.
  2. Спасибо, понял про приоритет DNS-маршрутов — принято. По первому пункту: если настраивать dns-proxy route через веб-интерфейс, изменения применяются без перезагрузки? Через CLI (system configuration save) — нет, требуется reboot. Есть ли CLI-команда для применения dns-proxy маршрутов на лету?
  3. Модель: Keenetic Hopper DSL (KN-3610) Прошивка: KeeneticOS 5.0.7 Проблема: При использовании доменной маршрутизации (dns-proxy route object-group) обнаружены три взаимосвязанные проблемы. 1. dns-proxy route не применяется на лету После добавления или изменения route object-group в секции dns-proxy и выполнения system configuration save — новые маршруты не работают. dns-proxy не создаёт динамические маршруты для доменов из добавленного domain-list. Требуется system reboot. Воспроизведение: dns-proxy route object-group domain-list15 Wireguard0 exit system configuration save → домены из domain-list15 продолжают маршрутизироваться через default gateway (ISP), а не через Wireguard0. После system reboot — работает. 2. dns-proxy route конфликтует со статическими ip route Если домен присутствует в domain-list, dns-proxy перехватывает DNS-запрос и назначает маршрут по собственной логике. При этом статический ip route для IP-адреса того же домена игнорируется. Обратная ситуация тоже не работает: если для domain-list настроен только ip route (без dns-proxy route), dns-proxy всё равно перехватывает DNS-запрос, но маршрутизирует через ISP default, а не через указанный в ip route интерфейс. 3. Рабочая комбинация — только всё вместе + перезагрузка Единственный надёжный способ маршрутизировать домены через нужный интерфейс: 1. dns-proxy route object-group domain-listN InterfaceX — для DNS-резолвинга 2. ip route <subnet> InterfaceX — статические маршруты для IP-подсетей сервиса (на случай DoH/DoT клиентов, обходящих dns-proxy на порту 53) 3. system reboot — без перезагрузки dns-proxy route не подхватывается Каждый из этих элементов по отдельности не работает — только все три вместе. Ожидаемое поведение: 1. dns-proxy route должен применяться после system configuration save без перезагрузки 2. dns-proxy route и ip route не должны конфликтовать — dns-proxy route для DNS-резолвинга, ip route для маршрутизации IP-пакетов 3. Либо документация должна явно описывать необходимость перезагрузки и совместного использования обоих типов маршрутов Практический контекст: Эти ограничения критичны при настройке выборочной маршрутизации через VPN (например, отдельные сервисы через WireGuard). Каждое изменение списка доменов требует перезагрузки роутера с потерей связи для всех клиентов.
  4. Модель: Keenetic Hopper DSL (KN-3610) Прошивка: KeeneticOS 5.0.7 Проблема: В системном журнале периодически появляется ошибка: coalagent: [ArqBlock2Layer_OnSend] SlidingWindowPool_Set: No space left on device. Свободная память роутера в норме (~93 МБ из 250 МБ), swap не используется. USB-накопители не подключены. Корневая FS — squashfs (read-only). Похоже на переполнение внутреннего пула Cloud Agent, а не на нехватку физического места. Ранее была заведена похожая проблема SYS-1177 (4.2 Beta 1) — [Loss_Callback] SlidingWindowPool_Get: No such file or directory. Текущая ошибка отличается: _Set вместо _Get, ENOSPC вместо ENOENT. Вопрос: исправлен ли SYS-1177 в 5.0.x? Текущая ошибка — то же самое или новый баг?
  5. Модель: Keenetic Hopper DSL (KN-3610) Прошивка: KeeneticOS 5.0.7 Проблема: Все три Яндекс DNS пресета интернет-фильтра (yandex-safe, yandex-family, yandex-base) используют некорректные DoH-адреса: - yandex-safe → https://safe.dot.dns.yandex.net/dns-query - yandex-family → https://family.dot.dns.yandex.net/dns-query Хосты *.dot.dns.yandex.net — это DoT-серверы (порт 853). Они не поддерживают HTTP-запросы /dns-query и возвращают 404 Not Found. В системном журнале это проявляется массовыми предупреждениями: https-dns-proxy: curl response code: 404, content length: 9 DoT-часть пресетов (77.88.8.88:853, 77.88.8.7:853) работает корректно, поэтому DNS-фильтрация функционирует, но каждый запрос генерирует лишнюю ошибку по DoH. Ожидаемое поведение: Правильные DoH-адреса Яндекса: - https://dns.yandex.net/dns-query (base) - https://safe.dns.yandex.net/dns-query (safe) — нужно проверить - https://family.dns.yandex.net/dns-query (family) — нужно проверить Или единый https://dns.yandex.net/dns-query с параметрами. Воспроизведение: 1. Назначить любому устройству пресет yandex-safe или yandex-family 2. show dns-proxy → в секции proxy-https-filters виден safe.dot.dns.yandex.net/dns-query 3. В журнале — https-dns-proxy: curl response code: 404
  6. Столкнулся с той же самой проблемой. Keenetic Giga III с последней прошивкой + Samsung UE32J6300. ТВ соединён с роутером по Wi-Fi 5GHz. Через некоторое время после запуска ТВ YouTube перестаёт работать - трафик не идёт. Диагностика соединения на ТВ показывает, что Wi-Fi соединение с роутером нормальное, а канал роутер-интернет отсутствует. При этом на других устройствах, в том числе и на телефоне, подключенном по тому же 5GHz Wi-Fi, интернет есть. Похоже, какие-то баги в прошивке, которые блокируют доступ телевизору в инет. Отключение WMM не помогает. Помогает только перезагрузка роутера. Тестировал поочерёдно Keenetic и ASUS N56U, переключая туда-сюда. С Keenetic проблема всплывает постоянно через несколько минут. С ASUS проблема не возникает. Видимо, придётся вернуться на ASUS.
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.