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

Начните с логов и статуса сервисов, затем переходите к DNS, firewall, таблицам маршрутизации и интерфейсам. В keen-pbr 3.x демон активно пишет причины ошибок в системный журнал, поэтому логи почти всегда быстрее угадывания по симптомам.

Быстрый порядок диагностики

Проверьте системный журнал на ошибки keen-pbr и dnsmasq.
Проверьте, что сервисы keen-pbr и dnsmasq запущены.
Если keen-pbr падает при запуске, запустите его вручную в foreground-режиме, чтобы увидеть больше логов: keen-pbr --log-level verbose service.
Проверьте DNS: устройство должно использовать DNS роутера, а dnsmasq должен отвечать локально.
Проверьте firewall: правила keen-pbr должны быть в KeenPbrTable.
Проверьте policy routing: fwmark должен вести в нужную таблицу маршрутизации.
Проверьте интерфейсы и VPN-туннели.
Если проблема остаётся, проверьте удалённые списки, urltest, фильтры правил и конфликты низкоуровневой маршрутизации.

Системный журнал

Это первое место для диагностики. Ищите сообщения keen-pbr, dnsmasq, а также уровни [E] и [W]: так keen-pbr помечает ошибки и предупреждения. Если не хватает библиотек iptables / nftables, не найден интерфейс, занят порт API или сломан JSON, причина обычно будет написана именно здесь.

В веб-интерфейсе Keenetic откройте Диагностика → Системный журнал.

Из консоли можно прочитать журнал так:

bash

ndmc -c "show log once" | grep -E 'keen-pbr|dnsmasq|\[E\]|\[W\]|error|warn|warning'

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

В этом сценарии не начинайте с редактирования конфигурации вслепую. Сначала проверьте статус и сразу откройте логи.

Убедитесь, что конфигурация существует:
bash
```
ls -l /opt/etc/keen-pbr/config.json
```
Перезапустите keen-pbr:
bash
```
/opt/etc/init.d/S80keen-pbr restart
```
Проверьте статус keen-pbr:
bash
```
/opt/etc/init.d/S80keen-pbr status
```
Проверьте статус dnsmasq:
bash
```
/opt/etc/init.d/S56dnsmasq status
```

Прочитайте системный журнал:

bash

ndmc -c "show log once" | grep -E 'keen-pbr|dnsmasq|\[E\]|\[W\]|error|warn|warning'

Убедитесь, что конфигурация существует:
bash
```
ls -l /etc/keen-pbr/config.json
```
Перезапустите keen-pbr:
bash
```
service keen-pbr restart
```
Проверьте статус keen-pbr:
bash
```
service keen-pbr status
```
Проверьте статус dnsmasq:
bash
```
service dnsmasq status
```

Прочитайте системный журнал:

bash

logread | grep -E 'keen-pbr|dnsmasq|\[E\]|\[W\]|error|warn|warning'

Убедитесь, что конфигурация существует:
bash
```
ls -l /etc/keen-pbr/config.json
```
Перезапустите keen-pbr:
bash
```
systemctl restart keen-pbr
```
Проверьте статус keen-pbr:
bash
```
systemctl status keen-pbr
```
Проверьте статус dnsmasq:
bash
```
systemctl status dnsmasq
```
Прочитайте системный журнал:
bash
```
journalctl -u keen-pbr -u dnsmasq -b
```

Если keen-pbr не остаётся запущенным, остановите managed service и запустите демон вручную в foreground-режиме с подробными логами. Так ошибка появится прямо в консоли.

bash

/opt/etc/init.d/S80keen-pbr stop
keen-pbr --log-level verbose service

Ожидаемо, foreground-команда не вернёт prompt, пока демон работает. Если она сразу завершилась, последняя ошибка в выводе обычно и есть причина.

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

Проверьте JSON:

bash

jq . /opt/etc/keen-pbr/config.json

Убедитесь, что каталог для daemon.pid_file существует и доступен для записи.
Убедитесь, что daemon.cache_dir существует и доступен для записи.
Если API включён, проверьте, что адрес и порт из api.listen не заняты другим процессом.
Если в логах есть ошибка про firewall backend, проверьте установку iptables / ipset или nftables для вашей платформы.
Если keen-pbr жив, но Web UI не открывается, убедитесь, что конфигурация не заменена headless-примером и в config.json есть секция api.

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

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

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

DNS и dnsmasq

DNS должен пройти всю цепочку: клиент использует DNS роутера, dnsmasq запущен, сгенерированный конфиг keen-pbr подключён, домены попадают в ipset или nftset, а обычные домены уходят в dns.fallback.

Проверка DNS с устройства пользователя

Откройте http://<ip-роутера>:12121/ и проверьте DNS Check. Если Web UI недоступен, выполните с клиентского устройства:

bash

nslookup check.keen.pbr

Ожидаемый ответ: 127.0.0.88. Если ответа нет, устройство не использует DNS роутера или dnsmasq не отвечает.

Проверка dnsmasq на роутере или сервере

bash

/opt/etc/init.d/S56dnsmasq status
nslookup google.com 127.0.0.1

Если DNS-запросы клиентов не доходят до Entware dnsmasq, проверьте уникальную для Keenetic настройку:

bash

opkg dns-override

После изменения сохраните конфигурацию Keenetic:

bash

system configuration save

bash

service dnsmasq status
nslookup google.com 127.0.0.1

Для domain-based routing нужен dnsmasq-full. Если в логах есть ошибки про неподдерживаемые ipset / nftset, проверьте установленный пакет:

bash

opkg list-installed | grep dnsmasq

Ожидаемо, nslookup <домен> 127.0.0.1 возвращает IP-адреса. Если видите Connection refused, dnsmasq не запущен или слушает не на 127.0.0.1:53.

Проверка сгенерированного resolver config

Выберите backend, который используется на вашей системе.

bash

keen-pbr generate-resolver-config dnsmasq-ipset

Ожидаемо, вывод содержит директивы вида ipset=/example.com/<set>.

Команда не должна завершаться ошибкой. Если она пишет, что кэш удалённого списка отсутствует, выполните:

bash

keen-pbr download

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

Убедитесь, что имя списка в dns.rules точно совпадает с именем списка в lists.
Убедитесь, что DNS-правило указывает на правильный тег DNS-сервера.
Если DNS-сервер использует detour, убедитесь, что выбранный outbound работает.
Убедитесь, что конфигурация dnsmasq подключает generated config через conf-file= или conf-script=.
Перезапустите keen-pbr и dnsmasq, затем снова проверьте логи.

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

Убедитесь, что dns.fallback настроен и указывает как минимум на один рабочий тег DNS-сервера.
Убедитесь, что fallback DNS-сервер достижим с роутера или сервера. Если этот DNS-сервер использует detour, проверьте выбранный outbound.
Убедитесь, что устройство пользователя использует DNS роутера.
Перезапустите 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 не запущен или не смог применить свою конфигурацию.

Проверьте логи dnsmasq.
Проверьте статус dnsmasq.
Если вы недавно меняли DNS-настройки, перезапустите keen-pbr и dnsmasq.

bash

ndmc -c "show log once" | grep dnsmasq
/opt/etc/init.d/S56dnsmasq status

Firewall и `KeenPbrTable`

Если DNS работает и домен резолвится, но трафик всё равно идёт мимо VPN, проверьте firewall. keen-pbr создаёт изолированную цепочку или таблицу KeenPbrTable; трафик должен попадать туда, сопоставляться со списками и получать нужный fwmark.

Сначала выполните общий self-check:

bash

keen-pbr status

Ищите проверки firewall со статусом missing, mismatch или ERROR.

Проверка правил firewall

bash

iptables-save | grep KeenPbrTable
ip6tables-save | grep KeenPbrTable

Ожидаемо, есть переход из PREROUTING в KeenPbrTable и правила маркировки пакетов. Пример признака корректного правила:

-A KeenPbrTable -m set --match-set <set> dst -j MARK --set-xmark <mark>/<mask>

Чтобы проверить наполнение set:

bash

ipset list
ipset test <название_сета> <IP-адрес>

Ожидаемый ответ для совпадения: IP находится в указанном set.

bash

nft -t list ruleset

Если нужен полный вывод вместе с содержимым sets:

bash

nft list ruleset

Ожидаемо, есть таблица inet KeenPbrTable, hook prerouting, правила сопоставления с sets и действие meta mark set ....

Backend зависит от того, как установлен firewall на вашей системе. Проверьте оба варианта или тот, который указан в логах keen-pbr.

bash

iptables-save | grep KeenPbrTable
ip6tables-save | grep KeenPbrTable
nft -t list ruleset

Если KeenPbrTable отсутствует, вернитесь к логам keen-pbr: обычно причина в недоступном backend, правах, отсутствующих пакетах или ошибке конфигурации.

Таблицы маршрутизации и `fwmark`

Если firewall маркирует пакеты, но сайт бесконечно грузится или открывается через провайдера, проверьте policy routing. ОС должна увидеть fwmark, применить ip rule и отправить пакет в таблицу маршрутизации нужного outbound.

Проверьте состояние, которое ожидает keen-pbr:
bash
```
keen-pbr status
```
Ищите строки со статусами missing, mismatch или ERROR.
Проверьте конкретный домен или IP:
bash
```
keen-pbr test-routing google.com
```
Ожидаемо, expected и actual outbound совпадают.
Проверьте policy rules:
bash
```
ip rule show
```
Ожидаемо, есть правило вида fwmark <mark> lookup <table>.
Проверьте таблицу маршрутизации:
bash
```
ip route show table <номер_таблицы>
```
Ожидаемо, в таблице есть маршрут через нужный VPN-интерфейс или gateway. Для blackhole outbound ожидаемым результатом будет blackhole route.

Если таблица пустая, интерфейс не найден или правило ведёт не туда, проверьте имя outbound, имя интерфейса и конфликты fwmark / iproute.table_start.

Интерфейсы и VPN-туннели

Если DNS, firewall и policy routing выглядят правильно, проверьте, что сам интерфейс существует, поднят и может отправлять трафик.

Откройте http://<ip-роутера>:12121/ и проверьте runtime-состояние outbounds и интерфейсов.
Получите список интерфейсов через REST API:
bash
```
curl http://127.0.0.1:12121/api/runtime/interfaces
```
Сверьте системное состояние:
bash
```
ip link show
ip addr show
ip route
```
Проверьте выход через конкретный VPN-интерфейс:
bash
```
curl -v --interface <имя_интерфейса> https://ifconfig.co/json
```

Ожидаемо, curl возвращает внешний IP VPN. Если команда зависает или завершается ошибкой, проблема ниже keen-pbr: туннель не поднят, нет маршрута, недоступен gateway или блокируется исходящий трафик.

Если используется urltest или fallback

Проверьте, что дочерние outbounds имеют корректные интерфейсы или таблицы.
Проверьте GET /api/health/service и runtime-состояние outbounds в Web UI.
Если circuit breaker находится в состоянии "open", дождитесь истечения circuit_breaker.timeout_ms или исправьте недоступный child outbound.
Если резервный интерфейс не включается, сначала проверьте доступность каждого child outbound отдельно через curl --interface.

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

Выполните на роутере или сервере:
bash
```
keen-pbr download
```
Если список всё ещё не обновляется, проверьте, достижим ли URL с этой же системы.
Если список должен скачиваться через VPN, проверьте lists[].detour и соответствующий outbound.
Если используется автоматическое обновление, проверьте lists_autoupdate.cron.
После ошибки снова прочитайте логи keen-pbr.

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

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

bash

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

Если в конфигурации задан другой daemon.pid_file, используйте его путь. Также подтвердите, что daemon.cache_dir доступен для записи.

`urltest` всегда показывает degraded

Убедитесь, что тестовый url достижим и возвращает хороший HTTP-ответ, например 200 OK или 204 No Content.
Для пользовательских проверок настоятельно рекомендуется использовать HTTP-адреса вместо HTTPS. HTTPS-проверки могут работать нестабильно из-за устаревших сертификатов, неполной цепочки доверия или особенностей TLS на роутере. Успешным для urltest считается финальный HTTP-код 2xx.
Рекомендуемый адрес по умолчанию: https://www.gstatic.com/generate_204.
Убедитесь, что дочерние outbounds работают по отдельности.
Проверьте интерфейсы через curl --interface <имя_интерфейса> https://ifconfig.co/json.
Дождитесь следующего цикла проверки или временно уменьшите interval_ms во время диагностики.
Проверьте GET /api/health/service на состояние circuit breaker. Если child outbound находится в состоянии "open", дождитесь circuit_breaker.timeout_ms.

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

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

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

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

Убедитесь, что proto установлен корректно: null для любых протоколов, "tcp", "udp" или "tcp/udp".
Проверьте, что имя списка в правиле точно совпадает с ключом в lists, включая регистр.
Запустите keen-pbr test-routing <domain-or-ip> и сравните expected / actual.
Проверьте keen-pbr status, чтобы увидеть, созданы ли firewall rules для этого правила.

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

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

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

bash

keen-pbr status
ip rule show
ip route show table all

Для firewall marks:

bash

iptables-save | grep -E 'MARK|CONNMARK|KeenPbrTable'
ip6tables-save | grep -E 'MARK|CONNMARK|KeenPbrTable'

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

config.json

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

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

FAQ Поддержать проект

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

Быстрый порядок диагностики

Системный журнал

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

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

DNS и dnsmasq

Проверка DNS с устройства пользователя

Проверка dnsmasq на роутере или сервере

Проверка сгенерированного resolver config

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

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

Firewall и KeenPbrTable

Проверка правил firewall

Таблицы маршрутизации и fwmark

Интерфейсы и VPN-туннели

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

urltest всегда показывает degraded

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

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

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

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

Firewall и `KeenPbrTable`

Таблицы маршрутизации и `fwmark`

`urltest` всегда показывает degraded