Перейти к содержимому
Устранение неполадок

Устранение неполадок

Начните с симптома, который наблюдаете. Каждый раздел начинается с простых проверок; если они не помогают — переходите к расширенной диагностике.

Сервис не запускается

  1. Убедитесь, что файл конфигурации находится в стандартном месте для вашей платформы.
    • Для OpenWRT/Debian это /etc/keen-pbr/config.json
    • Для Keenetic/NetCraze это /opt/etc/keen-pbr/config.json
  2. Перезапустите сервис keen-pbr.
    • Для OpenWRT/Debian выполните service keen-pbr restart
    • Для Keenetic/NetCraze выполните /opt/etc/init.d/S80keen-pbr restart
  3. Если вы недавно редактировали файл конфигурации, проверьте его на отсутствующие запятые, сломанный JSON или неверные пути.
  4. Если вы используете полный пакет, убедитесь, что вы случайно не отключили сервис и не заменили конфигурацию примером только для headless.
Расширенные проверки

Используйте эти, если сервис всё ещё не запускается:

  1. Валидируйте JSON в файле конфигурации вашей платформы, например: jq . /etc/keen-pbr/config.json
  2. Убедитесь, что каталог для daemon.pid_file существует и доступен для записи.
  3. Убедитесь, что daemon.cache_dir существует и доступен для записи.
  4. Если API включён, убедитесь, что настроенные адрес прослушивания и порт ещё не используются.

Сайты не идут через VPN

  1. Убедитесь, что сайт находится в правильном списке.
  2. Убедитесь, что правило маршрутизации для этого списка указывает на ваш VPN outbound.
  3. Убедитесь, что ваше VPN-соединение действительно работает.
  4. Убедитесь, что устройство пользователя использует DNS роутера.
    • Откройте http://<ip-роутера>:12121/ и посмотрите на виджет проверки DNS. Там должно быть сказано “DNS-запрос из браузера достиг dnsmasq”.
    • Альтернативно, выполните эту команду с вашего ПК: nslookup check.keen.pbr. Должен вернуться 127.0.0.88.
  5. Запустите тест маршрутизации:
    • Откройте http://<ip-роутера>:12121/, прокрутите до самого низа и введите google.com (или ваш IP/домен) в виджет “Куда пойдёт этот трафик?”.
    • Альтернативно, выполните эту команду с роутера: keen-pbr test-routing google.com

Если ожидаемый и фактический outbound различаются, правило или настройка DNS ещё не завершены.

Расширенные проверки

Если вам нужна более глубокая диагностика, проверьте здоровье маршрутизации:

bash
keen-pbr status

Ищите записи со "status": "missing" или "status": "mismatch".

Только если вы намеренно используете пользовательские низкоуровневые настройки маршрутизации, также проверьте, что fwmark.start, fwmark.mask и iproute.table_start не конфликтуют с существующими правилами:

bash
ip rule list
ip route show table <номер_таблицы>

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

  1. Убедитесь, что имя списка в dns.rules соответствует имени списка в lists.
  2. Убедитесь, что DNS-правило указывает на правильный тег DNS-сервера.
  3. Если DNS-сервер использует detour, убедитесь, что этот outbound работает.
  4. Перезапустите keen-pbr после редактирования раздела DNS.
Расширенные проверки
  1. Убедитесь, что generate-resolver-config производит корректный вывод:
    bash
    keen-pbr generate-resolver-config dnsmasq-nftset
  2. Убедитесь, что конфигурация dnsmasq включает соответствующую строку conf-file=/conf-script=.
  3. Перезапустите dnsmasq после изменения этой строки.

Веб-сайты не открываются: DNS_PROBE_FINISHED_NXDOMAIN / ERR_NAME_NOT_RESOLVED

  1. Убедитесь, что dns.fallback настроен и указывает как минимум на один рабочий тег DNS-сервера.
  2. Убедитесь, что сам fallback DNS-сервер достижим с роутера. Если этот DNS-сервер использует detour, убедитесь, что выбранный outbound работает.
  3. Убедитесь, что устройство пользователя использует DNS роутера.
  4. Перезапустите keen-pbr после изменения конфигурации DNS.

Пример:

config.json
{
  "dns": {
    "servers": [
      {
        "tag": "default_dns",
        "address": "1.1.1.1"
      }
    ],
    "fallback": ["default_dns"]
  }
}

Без dns.fallback домены, которые не соответствуют ни одной записи dns.rules, могут не разрешиться.

Веб-сайты не открываются: DNS_PROBE_FINISHED_BAD_CONFIG

Это обычно означает, что dnsmasq не запущен или не смог применить свою конфигурацию.

  1. Проверьте логи роутера на ошибки dnsmasq.
  2. Убедитесь, что dnsmasq запущен.
  3. Если вы недавно изменили настройки DNS, перезапустите keen-pbr и dnsmasq.

Полезные команды:

bash
# для OpenWRT:
logread | grep dnsmasq

# для Keenetic/NetCraze
ndmc -c "show log once" | grep dnsmasq

# для Debian
journalctl -u dnsmasq

Удалённые списки не обновляются

  1. Выполните на роутере: keen-pbr download
  2. Если список всё ещё не обновляется, проверьте, достижим ли URL с роутера.
  3. Если вы используете автоматическое обновление, проверьте, что lists_autoupdate.cron установлен на нужное расписание.
Расширенные проверки

Если вам нужно принудительно выполнить полную перезагрузку:

bash
kill -HUP $(cat /var/run/keen-pbr.pid)

Также подтвердите, что daemon.cache_dir доступен для записи.

urltest всегда показывает деградирован

  1. Убедитесь, что тестовый url достижим и возвращает хороший HTTP-ответ (напр. 200 OK или 204 No content).
  2. Убедитесь, что дочерние outbounds работают.
  3. Дождитесь следующего цикла проверки или временно уменьшите interval_ms во время тестирования.
Расширенные проверки
Проверьте GET /api/health/service на состояние circuit breaker. Если дочерний элемент находится в состоянии "open", дождитесь истечения circuit_breaker.timeout_ms.

Правила фильтра портов/адресов не сопоставляются

Если вы используете отрицание в полях src_addr / dest_addr, отрицание применяется сразу ко всем указанным в этом поле IP/подсетям. Смешивание записей с отрицанием и без отрицания в одном списке невозможно. Как альтернатива, вы можете создать два отдельных правила.

Это же применимо и к src_port / dest_port.

Если правила не сопоставляются как ожидается:

  • Убедитесь, что proto установлен корректно (null (для любых протоколов), "tcp", "udp" или "tcp/udp")
  • Проверьте, что имя списка в правиле точно совпадает (с учётом регистра) с ключом в lists

Конфликты низкоуровневой маршрутизации (расширенные)

Если вы изменили настройки fwmark или iproute, или другой инструмент также управляет расширенной маршрутизацией на той же системе, пакеты могут быть неправильно направлены или отброшены.

Проверьте на конфликты:

bash
ip rule list
nft list ruleset | grep mark

Настройте на неконфликтующий диапазон:

{
  "fwmark": {
    "start": "0x00020000",
    "mask": "0x00FF0000"
  }
}

mask должна состоять ровно из двух смежных hex-нибблов. Используйте hex-строки, например "0x00FF0000" и "0x00020000".