Решение проблем

Список частых проблем и способов их диагностики. Для типовых вопросов “как это работает” см. FAQ.

Установка

Connection refused при заходе в UI

Сервис ещё не поднялся — подождите 10–20 секунд
Узнать актуальный порт: cat /opt/etc/awg-manager/settings.json, поле port
Проверить, что сервис запущен: /opt/etc/init.d/S99awg-manager status

Туннели

Статус `broken`

Туннель поднялся, но awg-manager обнаружил проблему (упал процесс, не установилась связь и т.п.). Цвет LED — оранжевый, подпись на карточке — Сломан.

Диагностика:

Журнал туннеля — страница Инструменты → вкладка Журнал, фильтр по имени туннеля
Проверки туннеля — страница Инструменты → вкладка Проверки → секция per-tunnel. Запустите Проверка соединения
Конфигурация — откройте Изменить на карточке, проверьте ключи / endpoint / параметры обфускации

Туннель `running`, но трафик не идёт

Откройте Инструменты → Проверки, запустите Проверку IP. Если IP не меняется при включённом туннеле — трафик не уходит через него
Параметры обфускации (вкладка Обфускация в редакторе): S1-S4 и H1-H4 должны совпадать с сервером, иначе пакеты отправляются, но сервер их отбрасывает (см. Управление туннелями)
AllowedIPs — если не 0.0.0.0/0, убедитесь что нужные подсети перечислены
Устройство использует свой DNS — при DoH/DoT в браузере DNS-правила не сработают (см. DNS-маршрутизация — условия)

Связь пропадает через несколько минут

Типично для NAT-провайдеров. Решение — периодический keepalive:

В поле Keepalive (редактор → вкладка Основное → секция Сервер) выставьте 25 секунд
Если не помогает, включите Мониторинг — туннель будет авто-перезапускаться при падении связности

“Адрес нельзя изменить для запущенного туннеля в режиме kernel”

Текст в редакторе. Остановите туннель (тумблер в карточке), внесите правку, запустите снова.

Маршрутизация

DNS-правила не срабатывают

Проверьте в порядке:

Устройство в политике “Политика по умолчанию” — веб-интерфейс роутера → Приоритеты подключений. Если устройство в другой политике — DNS-маршруты на него не распространяются
В качестве DNS на клиенте указан IP роутера — не 8.8.8.8, не 1.1.1.1, не DoH/DoT в браузере
Туннель запущен — если туннель в stopped или broken, NDMS не может применить маршрут
Правило включено (тумблер на карточке правила)
Keenetic OS версии 5.x — на OS 4.x вкладки NDMS нет, используйте Маршрутизацию по IP

Подробнее — DNS-маршрутизация — обязательные условия.

Не работают российские сервисы (nalog.ru, умный дом и т.п.)

Ряд сервисов для пользователей в РФ (личный кабинет ФНС и другие) перестают работать, когда роутер использует гео-DNS (Google 8.8.8.8, Cloudflare 1.1.1.1 и т.п.). Эти сервисы отдают IP в зависимости от страны запрашивающего DNS — запросы из зарубежных резолверов получают “не тот” IP.

Решение — для проблемного домена принудительно использовать DNS без гео-проверки (Yandex 77.88.8.8, NextDNS и другие).

Через Keenetic Web UI: Интернет фильтры → для конкретного домена поставить указать Yandex.DNS.

Или через CLI роутера (http://my.keenetic.net/a):

ip name-server 77.88.8.8 lkfl2.nalog.ru
system configuration save

(Замените домен на нужный.)

Через Entware (SSH):

ndmc -c ip name-server 77.88.8.8 lkfl2.nalog.ru
ndmc -c system configuration save

HR Neo — тег отключён (`oversized`)

В разделе HR NEO → служебный блок Отключённые теги. Возникает, когда количество записей в теге превысило лимит maxelem ipset.

Решения:

Использовать более узкий тег (не пытайтесь маршрутизировать весь мир)

VPN для устройств не применяется

Статический IP — проверьте, что устройству назначен статический IP в DHCP-резервациях роутера. Правило привязано к IP; при смене IP (новая аренда) оно теряет цель
Туннель запущен — если туннель упал и выбран fallback Блокировать (Kill Switch), трафик устройства блокируется (это ожидаемо)

Мониторинг

“Компонент pingcheck не установлен”

Предупреждение на вкладке Инструменты → Мониторинг. Означает, что в прошивке Keenetic отсутствует компонент ping-check.

Установите: веб-интерфейс роутера → Управление → Настройки системы → Изменить набор компонентов → включить ping-check
Это нужно только для NativeWG-туннелей. Kernel-туннели используют собственный механизм awg-manager и работают без компонента

Туннель постоянно перезапускается

Слишком строгий порог сбоев — поставьте больше Максимум сбоев / Порог ошибок, чтобы кратковременные провалы не приводили к рестарту
Проверка через заблокированную цель — если ICMP 8.8.8.8 блокируется сервером VPN, выберите другую цель или метод (например, TLS 1.1.1.1:443)
Сам туннель нестабилен — смотрите журнал туннеля и исправьте корневую причину

UI и вход

Не помню, на каком порту awg-manager

В SSH на роутере:

cat /opt/etc/awg-manager/settings.json

Поле port в JSON.

Ошибки авторизации

По умолчанию UI открыт без авторизации. Если включили в Настройках:

Используются учётные данные администратора Keenetic — те же, что для входа в http://<ip-роутера> (80 порт)
Если не подходят — сначала проверьте, что можете войти в веб-интерфейс роутера напрямую

“Не удалось подключиться” в веб-терминале awg-manager

Встроенный терминал awg-manager использует SSH к роутеру:

Убедитесь, что SSH включён в настройках Keenetic
Логин = root, пароль = пароль администратора Keenetic

Sing-box не работает

Проверь, что компонент Netfilter установлен (см. Sing-box Router → Движок sing-box).
Проверь, что движок Sing-box Router включён (панель Движок sing-box).
После любых изменений в конфигурации нажми Применить — без этого правила не активируются.

Как собрать диагностическую информацию для issue

При открытии issue на GitHub полезно приложить:

Версия awg-manager — вверху UI (v2.x.x)
Модель Keenetic + версия OS — Системный монитор в веб-интерфейсе роутера
Архитектура — opkg print-architecture
Последние 100 строк журнала — раздел Инструменты → вкладка Журнал → кнопка Копировать
Шаги воспроизведения

Что дальше?

FAQ — ответы на частые вопросы без глубокого разбора
GitHub Issues — сообщить о баге или предложить фичу