mva113

====================================================================== РЕЗЕРВНЫЙ DNS: РЕАЛИЗАЦИЯ ИДЕИ ИЗ ТЕМЫ ОТ 27 НОЯБРЯ 2025 ====================================================================== Тема-предложение: В той теме я предлагал идею: если все прописанные DoT/DoH не отвечают N раз — переключаться на обычный DNS, пока они снова не станут доступны. Опционально, галочкой. Штатными средствами Keenetic это не решается: DoH/DoT работает по принципу «кто первый ответил», и роутер не переключается на обычный DNS автоматически, если все DoH/DoT недоступны. Поэтому я реализовал это иначе — через BIND на роутере с fallback на корневые DNS + маршрутизацию через AWG Manager и HydraRoute Neo. Ниже — полный разбор, как это собрать. ====================================================================== РЕЗЕРВНЫЙ DNS НА РОУТЕРЕ KEENETIC/NETCRAZE + АВТОМАТИЧЕСКАЯ МАРШРУТИЗАЦИЯ ЧЕРЕЗ AWG MANAGER И HYDRAROUTE NEO ====================================================================== ВАЖНО: все команды ниже выполняются в Entware (через SSH-терминал роутера, в оболочке Entware). Не в веб-интерфейсе роутера и не в системной консоли Keenetic. Если вы не уверены, что находитесь в Entware — проверьте, что команда `opkg` доступна. ====================================================================== Зачем всё это ====================================================================== Задача простая: DNS-запросы не должны уходить провайдеру и не должны зависеть от одного канала. Решение состоит из двух уровней: 1. WG-туннель — основной транспорт для DNS. 2. BIND на роутере — резерв на случай, если VPS или туннель упадут. Почему WG, а не DoH/DoT Штатный DoH/DoT в Keenetic работает по принципу «кто первый ответил». Запрос уходит на все доступные резолверы одновременно, и используется тот ответ, который пришёл раньше. Отсюда две проблемы: 1. Свой DoH не факт, что успеет первым. Публичные резолверы (Google, Cloudflare) мощнее и отвечают быстрее — часть запросов уйдёт им, а не вашему серверу. 2. Если DoH/DoT перестаёт работать — роутер не переключается на обычный DNS автоматически. Интернет просто встаёт. Поэтому мы делаем иначе: DNS идёт через WG-туннель на свой резолвер, а BIND на роутере страхует на случай, если туннель или VPS упадут. WG уже шифрует весь канал, так что наворачивать сверху TLS (DoH/DoT) — это двойная обёртка без выигрыша, лишний оверхед и потеря ~20 мс на хендшейках. ====================================================================== ЧАСТЬ 0. ПРИМЕР VPS-СТОРОНЫ (не является задачей гайда) ====================================================================== На VPS развёрнут AdGuard Home в Docker с внутренним адресом 172.19.0.205 (пример). За ним — BIND, который ходит только в корень. Это лишь пример. У вас может быть любой другой резолвер: свой BIND, unbound, AdGuard Home напрямую, публичный DNS вроде 9.9.9.9 и т.д. Главное — чтобы он был ваш и не отдавал запросы провайдеру. Схема движения запросов: клиент → ndns → BIND (роутер) → WG → AdGuard Home (VPS) → BIND (VPS) → корень если WG упал: клиент → ndns → BIND (роутер) → корень напрямую ====================================================================== ЧАСТЬ 0.5. БЭКАП ENTWARE (СДЕЛАЙ ПЕРЕД НАЧАЛОМ) ====================================================================== Прежде чем что-то менять — сделайте бэкап Entware, если у вас там уже что-то установлено и настроено. Если Entware только что поставлен и в нём ничего нет — бэкапить нечего, можно пропустить этот шаг и идти дальше. СОЗДАНИЕ БЭКАПА: В Entware (через SSH) выполните: tar cvzf /opt/entware_backup.tar.gz -C /opt . ВАЖНО: точка в конце обязательна. Она означает «упаковать содержимое текущей директории». Без неё архив будет содержать саму папку opt, что при восстановлении даст неверную структуру. Если места на /opt мало — сохраните архив сразу на внешний диск: tar cvzf /tmp/mnt/ВАШ_ДИСК/install/entware_backup.tar.gz -C /opt . ВОССТАНОВЛЕНИЕ: 1. Подготовьте чистый накопитель (отформатированный в ext4) или освободите текущий. 2. Создайте папку install в корне накопителя. 3. Положите туда ваш архив entware_backup.tar.gz. В большинстве случаев переименовывать архив не нужно — система сама распакует то, что лежит в папке install. ЕСЛИ ВОССТАНОВЛЕНИЕ НЕ СРАБОТАЛО — попробуйте переименовать архив в aarch64-installer.tar.gz (для вашей модели роутера имя может отличаться, например mips-installer.tar.gz). Полный список имён смотрите в официальной инструкции Keenetic по установке Entware для вашей модели. 4. В веб-интерфейсе роутера: Приложения → OPKG → выберите ваш накопитель → Сохранить. 5. Роутер сам распакует архив в /opt. Всё вернётся на место. ПРИМЕЧАНИЕ: архив можно положить и во внутреннюю память роутера, в папку install. Тогда восстановление пройдёт без внешнего диска. ====================================================================== ЧАСТЬ 1. УСТАНОВКА BIND НА РОУТЕРЕ ====================================================================== opkg update opkg install bind-server bind-libs bind-tools ====================================================================== ЧАСТЬ 2. СОЗДАНИЕ ПАПКИ ДЛЯ КЕША ====================================================================== BIND требует папку для кеша, иначе не стартует. mkdir -p /opt/var/cache/bind chown -R root:root /opt/var/cache/bind chmod 755 /opt/var/cache/bind ====================================================================== ЧАСТЬ 3. СОЗДАНИЕ КЛЮЧА ДЛЯ rndc ====================================================================== rndc — утилита управления BIND (сброс кеша, статистика, перезагрузка). /opt/sbin/rndc-confgen -a -c /opt/etc/bind/rndc.key ====================================================================== ЧАСТЬ 4. ОСНОВНОЙ КОНФИГ BIND ====================================================================== cat > /opt/etc/bind/named.conf << 'EOF' # ====================================================== # ОСНОВНЫЕ НАСТРОЙКИ BIND # ====================================================== options { # Рабочая директория для кеша и временных файлов directory "/opt/var/cache/bind"; # Слушаем на всех IPv4-интерфейсах (порт 53) listen-on port 53 { any; }; # IPv6 ОТКЛЮЧЁН ПОЛНОСТЬЮ: # - listen-on-v6 { none; } — не слушаем входящие IPv6-запросы # - query-source-v6 none — не отправляем исходящие IPv6-запросы # Это убирает задержки при недоступном IPv6 и шум в логах. listen-on-v6 { none; }; query-source-v6 none; # Разрешаем рекурсивные запросы только для локальных сетей. # ПРИМЕЧАНИЕ: здесь указаны базовые сети. Остальные подсети # (WG-подсети, гостевые сети, дополнительные сегменты) каждый # дописывает под свою конфигурацию. allow-recursion { 192.168.0.0/16; 127.0.0.1; }; allow-query-cache { 192.168.0.0/16; 127.0.0.1; }; allow-query { 192.168.0.0/16; 127.0.0.1; }; # Максимальный размер кеша — 16 МБ max-cache-size 16M; # Основной DNS-сервер (forwarder) — внутри WG-туннеля. # Если он недоступен — BIND автоматически идёт в корневые DNS. # # ПРИМЕЧАНИЕ: сюда подставьте адрес своего резолвера. # Это может быть локальный адрес (172.x.x.x) или публичный # (9.9.9.9, 1.1.1.1). Главное — не DNS провайдера. # В моём случае это 172.19.0.205. forwarders { 172.19.0.205; }; }; # ====================================================== # УПРАВЛЕНИЕ ЧЕРЕЗ rndc # ====================================================== include "/opt/etc/bind/rndc.key"; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; # ====================================================== # ЛОГИРОВАНИЕ — ТОЛЬКО ОШИБКИ (WARNING) # ====================================================== logging { channel main_log { syslog daemon; severity warning; print-time yes; print-severity yes; print-category yes; }; channel queries_log { null; }; category default { main_log; }; category queries { queries_log; }; category query-errors { main_log; }; }; # ====================================================== # КОРНЕВЫЕ DNS-СЕРВЕРЫ (FALLBACK) # ====================================================== zone "." { type hint; file "/opt/etc/bind/db.root"; }; EOF ====================================================================== ЧАСТЬ 5. ЗАГРУЗКА ФАЙЛА КОРНЕВЫХ DNS-СЕРВЕРОВ ====================================================================== wget -O /opt/etc/bind/db.root https://www.internic.net/domain/named.root ====================================================================== ЧАСТЬ 6. ПРОВЕРКА КОНФИГА И ПЕРВЫЙ ЗАПУСК ====================================================================== named-checkconf /opt/etc/bind/named.conf /opt/etc/init.d/S09named start ====================================================================== ЧАСТЬ 7. ПРОВЕРКА РАБОТЫ ====================================================================== ps | grep named | grep -v grep dig @127.0.0.1 google.com +short /opt/sbin/rndc status ====================================================================== ЧАСТЬ 8. АВТОЗАПУСК BIND ЧЕРЕЗ fs.d И wan.d ====================================================================== fs.d срабатывает при монтировании диска (ранний этап загрузки). wan.d срабатывает при поднятии WAN-интерфейса (дублирующий механизм). ВАЖНО: запускаем не S09named напрямую, а rc.unslung, который правильно обрабатывает все S-скрипты Entware. cat > /opt/etc/ndm/fs.d/S99bind << 'EOF' #!/bin/sh /opt/etc/init.d/rc.unslung start EOF chmod +x /opt/etc/ndm/fs.d/S99bind mkdir -p /opt/etc/ndm/wan.d cat > /opt/etc/ndm/wan.d/S99bind << 'EOF' #!/bin/sh sleep 5 /opt/etc/init.d/rc.unslung start EOF chmod +x /opt/etc/ndm/wan.d/S99bind ====================================================================== ЧАСТЬ 9. CRON ДЛЯ ОБНОВЛЕНИЯ КОРНЕВЫХ DNS-СЕРВЕРОВ ====================================================================== mkdir -p /opt/etc/cron cat > /opt/etc/cron/update_root_servers.sh << 'EOF' #!/bin/sh LOG="/opt/var/log/update_root.log" TMP_FILE="/tmp/db.root.new" DEST_FILE="/opt/etc/bind/db.root" touch "$LOG" if wget -q -O "$TMP_FILE" "https://www.internic.net/domain/named.root"; then mv "$TMP_FILE" "$DEST_FILE" echo "$(date): Корневые DNS-серверы обновлены" >> "$LOG" else echo "$(date): ОШИБКА: не удалось обновить корневые DNS-серверы" >> "$LOG" fi EOF chmod +x /opt/etc/cron/update_root_servers.sh ====================================================================== ЧАСТЬ 10. СКРИПТ АВТОЗАПУСКА CRON ====================================================================== cat > /opt/etc/init.d/S60cron << 'EOF' #!/bin/sh ENABLED=yes PROCS=crond ARGS="" PREARGS="" DESC=$PROCS PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin . /opt/etc/init.d/rc.func EOF chmod +x /opt/etc/init.d/S60cron mkdir -p /opt/var/spool/cron/crontabs /opt/etc/init.d/S60cron start crontab -l 2>/dev/null | { cat; echo "0 5 1,14,27 * * /opt/etc/cron/update_root_servers.sh"; } | crontab - crontab -l /opt/etc/cron/update_root_servers.sh cat /opt/var/log/update_root.log ====================================================================== ЧАСТЬ 11. ОПЦИОНАЛЬНО: opkg dns-override ====================================================================== opkg dns-override system configuration save Необязательный параметр. BIND работает и без него, но с ним чуть шустрее: убирается один лишний хоп в цепочке резолвинга. ВАЖНО: включается в самом роутере (не в Entware). Меняет системный резолвер роутера на то, что указано в /opt/etc/resolv.conf. После включения обязательно сохранить конфигурацию командой system configuration save — иначе настройка не применится. На работу HydraRoute Neo не влияет — проверено на практике. Отключить (если понадобится): no opkg dns-override system configuration save После отключения также обязательно сохранить конфигурацию. ====================================================================== ЧАСТЬ 11.5. МАРШРУТ ДЛЯ DNS ЧЕРЕЗ WG-ТУННЕЛЬ ====================================================================== Чтобы BIND мог достучаться до вашего резолвера на VPS через WG-туннель, нужно добавить статический маршрут в роутере: Тип маршрута: Маршрут до сети Описание: DNS Адрес сети: 172.19.0.0 ← подсеть, где живёт ваш резолвер Маска подсети: 255.255.0.0 (/16) Интерфейс: выберите ваш туннель до сервера Галочки: Добавлять автоматически Эксклюзивный маршрут ПРИМЕЧАНИЕ: адрес сети подставьте под свою конфигурацию. Если ваш резолвер — 172.19.0.205, то сеть 172.19.0.0/16 подойдёт. Если резолвер публичный (9.9.9.9) — маршрут не нужен, он и так доступен напрямую. Режим «Эксклюзивный маршрут» означает: если туннель недоступен, трафик к этой подсети не пойдёт вообще (не утечёт через WAN). Для DNS это правильно — пусть BIND уйдёт в fallback на корень, чем запросы утекут провайдеру. ====================================================================== ЧАСТЬ 11.6. УКАЗЫВАЕМ DNS РОУТЕРА В ОСНОВНОМ ПОДКЛЮЧЕНИИ ====================================================================== В веб-интерфейсе роутера: Интернет → Основное подключение → Параметры IPv4 → IPv4 DNS 1: 192.168.1.1 Либо: Интернет → Фильтры → Настройки DNS → добавить как DNS по умолчанию ПРИМЕЧАНИЕ: если у вас IP роутера другой (например, 192.168.0.1) — укажите свой. ====================================================================== ЧАСТЬ 12. ЗАЧЕМ AWG MANAGER И HYDRAROUTE NEO ====================================================================== После установки BIND штатная маршрутизация по DNS в роутере перестаёт работать. Остаётся только маршрутизация по IP — она продолжает работать как обычно. Чтобы вернуть удобную маршрутизацию по доменам (а не вручную вести списки IP-адресов), сверху ставим AWG Manager и HydraRoute Neo. ====================================================================== ЧАСТЬ 13. УСТАНОВКА AWG MANAGER ====================================================================== Способ 1 — через официальный репозиторий разработчика (используется встроенный busybox wget, curl не нужен): opkg update wget -qO- http://repo.hoaxisr.ru/install.sh | sh Способ 2 — через GitHub (HTTPS, безопаснее; нужен curl): opkg update opkg install curl curl -sL https://raw.githubusercontent.com/hoaxisr/awg-manager/develop/scripts/install.sh | sh Оба варианта — официальные, с репозитория разработчика. Ссылки на источник: https://github.com/hoaxisr/awg-manager После установки в консоли появится адрес веб-интерфейса. Открываем его в браузере. Включаем авторизацию: Настройки → продвинутый режим → авторизация. Логин/пароль — те же, что для входа в веб роутера. ====================================================================== ЧАСТЬ 14. УСТАНОВКА HYDRAROUTE NEO ====================================================================== В AWG Manager: Настройки → Интеграция → HydraRoute Neo → Установить. Откроется страница проекта на GitHub. Копируем команду установки и выполняем в терминале: opkg update && opkg install curl && curl -Ls "https://git.zerrolabs.org/Ground-Zerro/release/pages/keenetic/install-neo.sh" | sh Ждём завершения. Возвращаемся в AWG Manager — в разделе «Интеграция» появится HydraRoute Neo. ====================================================================== ЧАСТЬ 15. ВАЖНО: ПОЛИТИКА HYDRAROUTE ДОЛЖНА БЫТЬ НЕПУСТОЙ ====================================================================== Политика HydraRoute создаётся пустой. Пока в неё не добавлен интерфейс — hrneo пишет в логах: PolicyOrder: policy 'HydraRoute' not found, skipping и маршруты не строятся. Решение: добавить интерфейс в политику через веб-интерфейс роутера, в разделе «Приоритеты подключений». После этого hrneo увидит политику и начнёт строить маршруты. ====================================================================== ЧАСТЬ 15.5. ГДЕ НАСТРАИВАТЬ МАРШРУТЫ ====================================================================== Маршруты настраиваются в разделе HR Neo (вкладка «Маршрутизация»). ВАЖНО: не в NDMS и не в «IP-адресах». Эти разделы в AWG Manager относятся к другим сценариям (системные NDMS-туннели и статические IP-маршруты соответственно). Для маршрутизации по доменам используется именно HR Neo. ====================================================================== ЧАСТЬ 16. ФИНАЛЬНАЯ ПРОВЕРКА ПОСЛЕ ПЕРЕЗАГРУЗКИ ====================================================================== reboot После загрузки: ps | grep named | grep -v grep /opt/sbin/rndc status dig @127.0.0.1 google.com +short crontab -l ps | grep -E 'hrneo|awg' | grep -v grep Проверить, что маршрут строится: Открыть сайт из правила. Если показывает IP туннеля — маршрут работает. Если реальный IP — маршрут не построился, смотреть логи. ====================================================================== ИТОГ ====================================================================== Что получилось: - DNS не уходит провайдеру. - Есть резерв: если VPS/WG упал — BIND уходит в корень. - Маршрутизация по доменам работает автоматически, без ручного ведения IP-адресов. - Всё поднимается после перезагрузки.

Включен как TLS-проверка порта TCP. При отключении основного интернета продолжает показывать что инет доступен, если выключить и включить (ползунком) Подключения к интернету по Ethernet-кабелю то тогда показывает что интернета нет. Из за чего получается что автоматом на резервное подключение не уходит. Так уже несколько версий предварительной.

Уже несколько версий не горит индикация при использовании резервного подключения. При выборе Индикатор FN1 (когда используется WISP 2.4) не горит, при этом если выбрать на Индикатор FN2 то загораются сразу все индикаторы и при этом когда выбираешь на Индикатор FN2 то так же меняться и Индикатор FN1. То есть например на Индикатор FN1 стоял 2,4ГГц, а на Индикатор FN2 стоял 5ГГц то после обновление страницы на обоих будет стоят 5ГГц. В логах при смене вот: Авг 19 00:11:52 ndm Core::Peripheral::Manager: clear LED power schedule. Авг 19 00:11:52 ndm Core::Peripheral::Manager: set LED shutdown mode to "none". Авг 19 00:11:52 ndm Core::Peripheral::Manager: "WLAN/click" handler removed. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "WLAN/double-click" handler set. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "WLAN/hold" handler removed. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN1/click" handler set. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN1/double-click" handler removed. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN1/hold" handler removed. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN2/click" handler set. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN2/double-click" handler removed. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN2/hold" handler removed. Авг 19 00:11:53 ndm Network::Interface::Led: selected WAN WifiMaster0/WifiStation0. Авг 19 00:11:53 ndm Network::Interface::Led: selected WAN WifiMaster1/WifiStation0. Авг 19 00:11:53 ndm Core::Peripheral::Manager: "SelectedWan" control bound to "FN_1" LED. Авг 19 00:11:53 ndm Core::Peripheral::Manager: "SelectedWan" control bound to "FN_2" LED. Авг 19 00:11:53 ndm Core::System::StartupConfig: saving (http/rci).

И что по итогу 7 месяцев спустя? То есть получается Мы Все оказались правы в том что Вы просто выбрали модель что по возмущаются и перестанут и ни чего с принудительным обновлением делать не надо?

5.1 Beta 4 проблема ушла!

Аналогично было.

не подключает ретранслятор (kn-1610 прошивка 4.3.6.2) основной NZ-1812 на вкладке горит ошибка в виде предупреждения (к сожалению не заскринил). ретранслятор пытается переподключиться и потом уходит в перезагрузку и всё по новой. после отката на beta 2 всё нормально. UDP: 5.1 Beta 4 проблема ушла!

UDP: Проблема в доменном имени, если переключить на прямой доступ с авто то сразу начинает работать, после чего опять можно переключится на авто.

UDP: 5.1 Beta 0.2 проблема ушла

Я уже два раза пробовал одно и тоже, просто тишина. Перехожу на 5.0.8 сразу всё работает. Устройство 1812. Странно вообщем Я даже пробовал компоненте переустанавливать не помогло.

Не работает приложение Wireguard. То есть после обновления ни один пир подключится не может, при создании нового пира тоже самое. В логах ошибок нет. После отката на 5.0.8 всё заработало без каких либо манипуляций.

Не работает ping check. При отключении основного интернета на стороне провайдера показывает что интернет доступен. Стоит проверка TLS-проверка порта TCP. При переходе на предварительный канал и прошивку 5.0.7 всё работает корректно.

При редактировании политики доступа после нажатия кнопки сохранить ушёл в перезагрузку. Делал изменения в трёх политиках и сохранял всё нормально, на четвёртой политике после нажатия сохранить перезагрузка. После работает штатно, изменения на котором произошла перезагрузка не сохранил. В логах ни чего нет. (NC-1812)

Вот ещё странная вещь😂 Включил всё по максимуму на 2.4 тоже (кроме мощности там 75%) и скорость стала стабильной. (до этого было выключено OFDMA DL/UL, на приём и Target Wake Time что по идее на стандарт AC влиять не должно). Но всё заработало, скорость держит стабильно.

Опытным путём: На 2.4 поставил b/g/n, а на 5 а/n/ac и это помогло стабильно держит скорость. Если ставишь 2.4 b/g/n/ax, 5 n/ac/ax скорость начинает прыгает. Оставил 2.4 b/g/n/ax на 5 поменял на a/n/ac без изменений просаживается, а когда вернул ещё и 2.4 на b/g/n нормализовалось. То есть нормально работает при условии 2.4 b/g/n, 5 a/n/ac. Если просто выключить 2.4, а на 5 поставить a/n/ac/ax скорость прыгает, если на 5 поставить n/ac/ax/be при выключенном 2.4 скорость стабильно держится, включаешь 2.4 рухает скрость. Если устройство ограничить выбором только 5ГГц но при этом 2.4 включено то скорость всё равно падает. А вот выключаю 2.4 и нормализуется. Как 2.4 к этому подвязано не знаю телефон работает на 5ГГц в доме постоянно.