mva113

Наверное в кой нибудь из beta сборки с предварительного канала ближе к релизу. Есть конечно шанс что так задумано и это просто останется, но не думаю так как их тогда ТП завалят с криками что всё пропало, красный треугольник горит. 😂

А, то есть это с самого начала так. Я то только сейчас альфу поставил не было времени до этого.

Я так предполагаю что получается в альфа-версии система по какой-то причине неверно определяет, что используется SAE-EXT, когда выбран только обычный WPA3-PSK. Это уже не просто «шум» — это баг валидации совместимости между контроллером и ретранслятором. При этом функционально всё работает (устройства подключаются и к Ultra, и к Air), а в смешанном режиме WPA2+WPA3 предупреждение исчезает — видимо, потому что проверка совместимости в этом случае идёт по другому, более «мягкому» сценарию. P.S. Хотелось бы понять: это баг валидации в альфе или так и задумано, что при чистом WPA3-PSK контроллер считает ретранслятор несовместимым? Если баг — ждём фикса, если нет — хотелось бы, чтобы предупреждение не пугало пользователей зря

Я не проверял WPA3-SAE-EXT, у Меня включен WPA3-PSK

Всем привет. После перехода на 5.2 Alpha 11 на ретрансляторе Air (NC-1613) в Mesh с Ultra (NC-1812) висит предупреждение: «Контроллер использует защиту сети расширенным ключом SAE (WPA3 SAE-EXT), не поддерживаемую данным ретранслятором» При этом Air в сети, устройства к нему подключаются нормально, скорость в порядке — функционально всё работает. Как воспроизводится: На Ultra стоит только WPA3-PSK → предупреждение есть. Ставишь WPA2-PSK + WPA3-PSK → предупреждение исчезает. Похоже, что «SAE-EXT» — это внутренний расширенный режим SAE для транспортной (backhaul) сети Mesh, который включается автоматически и не имеет отдельной галочки. Air его не поддерживает, отсюда и предупреждение. В смешанном режиме согласование идёт по другому пути, и до этого расширенного SAE дело не доходит. Учитывая, что это Alpha, скорее всего либо отладочный шум, либо известное ограничение совместимости между разными моделями на альфе. Вопрос: это просто косметика альфа-версии, или за этим стоит реальная потеря функций (например, бесшовного роуминга между Ultra и Air)? Стоит ли ждать фикса?

====================================================================== РЕЗЕРВНЫЙ 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. Странно вообщем Я даже пробовал компоненте переустанавливать не помогло.