АЛЬТЕРНАТИВА DOH\DOT С РЕЗЕРВНЫМ КАНАЛОМ

[mva113]

======================================================================
РЕЗЕРВНЫЙ DNS: РЕАЛИЗАЦИЯ ИДЕИ ИЗ ТЕМЫ ОТ 27 НОЯБРЯ 2025 
======================================================================

Тема-предложение: https://forum.keenetic.ru/topic/25831-переключение-dotdoh-на-обычный-dns/#comment-226366

В той теме я предлагал идею: если все прописанные 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-адресов.
  - Всё поднимается после перезагрузки.

Изменено 3 часа назад пользователем mva113