1. Убедитесь, что ruantiblock включен
Выполните в консоли:
/usr/bin/ruantiblock status
Вывод статуса не должен содержать ошибок. Если есть ошибки связанные с nftables - выполните:
/usr/bin/ruantiblock destroy
rm /var/run/ruantiblock*
rm /tmp/ruantiblock/*
И запустите заново:
/usr/bin/ruantiblock start
/usr/bin/ruantiblock update
2. Проверьте запущен ли Tor или VPN клиент
Можно увидеть в консоли:
ps | grep tor
или
ps | grep openvpn
Также убедитесь, что сервисы стартуют при запуске системы:
/etc/init.d/tor enable
или
/etc/init.d/openvpn enable
В VPN конфигурации проверьте настройки межсетевого экрана: для устройства tun0 должен быть создан интерфейс (например, с названием VPN) и добавлен в зону wan (или зону созданную специально для VPN), иначе трафик из локальной сети не сможет попасть в VPN тунель. Это относится и к VPN укзанным в настройках экземпляров записей пользователя.
3. Ошибка маршрутизации VPN (VPN ROUTING ERROR)
Такая надпись появляется в выводе статуса (/usr/bin/ruantiblock status) в том случае, если отсутствуют необходимые для работы ruantiblock записи в таблице маршрутизации. Это может быть связано, во-первых, с отсутствием VPN соединения (отключен клиент OpenVPN и пр.) у любого из VPN указанных в настройках (включая записи пользователя). Во-вторых, с тем, что при поднятом VPN соединении не добавляются правила маршрутизации: проверьте наличие скрипта /etc/hotplug.d/iface/40-ruantiblock и значение параметра определяющего используемый VPN интерфейс:
uci get ruantiblock.config.if_vpn
Для экземпляров записей пользователя настроенных в режиме VPN (примере первый экземпляр list1):
uci get ruantiblock.list1.u_if_vpn
Далее, для решения проблемы, достаточно выполнить:
/usr/bin/ruantiblock restart
4. Ошибка при обновлении блэклиста
Когда при попытке обновления командой /usr/bin/ruantiblock update в консоли (логе) появляется сообщение Error! Another instance of update is already running - это означает, что присутствует файл другого процесса обновления (/var/run/ruantiblock_update.pid), который или выполняется в данный момент, или ранее завершился некорректно. Если в данный момент обновление уже не выполняется, запустите новый процесс обновления командой (удалит старый pid-файл):
/usr/bin/ruantiblock force-update
Разумеется, можно удалить и вручную:
rm /var/run/ruantiblock_update.pid
5. Убедитесь, что корректно разрешаются DNS-имена
Провайдеры на своих DNS-серверах часто ограничивают или изменяют сторонний DNS-трафик (DNS-спуфинг). Поэтому необходима замена провайдерского DNS-сервера на сторонний и обязательное применение DNS-шифрования (dnscrypt-proxy, https-dns-proxy и пр.). Очень желательно настроить перехват стороннего DNS-трафика хостов локальной сети (в последних версиях https-dns-proxy такая опция уже встроена).
6. Проверьте попадает ли трафик к заблокированным сайтам в ruantiblock (цепочки nftables)
Выполните в консоли:
/usr/bin/ruantiblock status
Блок Nftables rules содержит счётчики правил для всех активных экземпляров записей пользователя и основного блэклиста. При запросе заблокированного сайта или IP соответствующие счётчики растут.
7. Проверьте добавляет ли dnsmasq IP адреса заблокированных доменов из своего конфига в nftset d
При запросе заблокированного домена dnsmasq разрешает доменное имя в IP адрес и помещает его в nftset. Далее, спустя некоторое время, этот IP адрес удаляется из сета.
Выполните в консоли:
nft list set ip r d
В выводе можно увидеть эти IP адреса (в блоке elements = { ... }), если они есть в данный момент. Также, можно смотреть добавляемые dnsmasq IP адреса в веб-интерфейсе на странице статистике в таблице Dnsmasq в реальном времени, в т.ч. для всех активных экземпляров записей пользователя.
Если при обращении к заблокированному домену dnsmasq не добавляет его IP адрес в свой nftset, то причиной может быть отсутствие обращений к dnsmasq (DNS-серверу) со стороны ОС вашего ПК (или другого устройства). Локальный резолвер ОС часто кэширует полученные адреса и не делает запрос, следовательно, dnsmasq не добавляет IP адрес в nftset и вы получаете "заглушку" от провайдера для данного сайта. По истечении таймаута записи в кэше всё опять работает правильно. В этой ситуации можно либо подождать пока запись будет удалена из кэша по таймауту, либо очистить DNS-кэш ОС. Для Windiows всё просто: ipconfig /flushdns, для других ОС сложнее - ищите в Google. Также, не повредит очистить кэш браузера. Попробуйте больше разных заблокированных сайтов для тестирования...
8. Если возникают проблемы с нехваткой оперативной памяти
На девайсах с оперативной памятью в 256Мб и менее может проявляться ошибка нехватки памяти при обновлении блэклиста. Размер блэклиста постоянно растёт, памяти начинает не хватать... Например, при использовании lua-парсера это выглядит как сообщение Killed:
root@OpenWrt:~# /usr/bin/ruantiblock update
ruantiblock update...
Killed
Module run attempt 1: failed [/usr/libexec/ruantiblock/ruab_parser.lua]
и приводит к краху интерпретатора. Или же роутер просто зависает. Если при обновлении блэклиста в логе роутера появляются ошибки Module error! или kernel: Out of memory с трэйсами ядра, попробуйте выполнить в консоли команду (создание конфигов без перезагрузки dnsmasq и без изменения конфигурации nftables):
/usr/bin/ruantiblock blacklist-files
Присутствие подобных ошибок или зависаний говорит о наличии проблемы. Во-первых, можно попробовать подключить SWAP-файл (или раздел) на внешнем носителе (конечно, если это возможно на вашем устройстве). Во-вторых, подобрать настройки для оптимизации работы модуля-парсера и сократить количество записей в блэклисте (подробнее здесь). Далее, если подключен внешний носитель (extroot), можно попробовать использовать python-модуль, он стабильнее работает в условиях проблем со свободной памятью. Это не является полным решением проблемы, но позволит немного сократить потребление памяти.
Минимальный размер списка блокировок можно получить используя только записи пользователя, без модуля-парсера. Можно, например, добавить ссылку https://antifilter.download/list/allyouneed.lst в удалённые записи пользователя (формат файла совместим) для загрузки во время обновления. Этот список содержит IP адреса из реестра приведённые к подсетям /24. Недостаток в том, что в этих диапазонах большое количество не заблокированных адресов, и трафик к ним будет также проходить через прокси. В общем, в случае нехватки оперативной памяти, это возможный вариант...
Ну и, естественно, можно использовать свои собственные списки заблокированных хостов и решать самостоятельно какое количество записей будет в вашем блэклисте.
9. Ошибка директории конфигов dnsmasq
Если при попытке обновления блэклиста в консоли или логе появляется сообщение:
Error! DNSMASQ_CONFDIR (/tmp/dnsmasq.d) does not exists
то необходимо задать актуальный путь к директории дополнительных конфигов dnsmasq. Это можно сделать через UCI (в примере директория /tmp/dnsmasq.cfg01411c.d), предварительно выполнив полное выключение ruantiblock:
/usr/bin/ruantiblock destroy
uci set ruantiblock.config.dnsmasq_confdir="/tmp/dnsmasq.cfg01411c.d"
uci commit ruantiblock
/usr/bin/ruantiblock start
Также, директорию конфигов dnsmasq можно задать в веб-интерфейсе: "Службы" -> "ruantiblock" -> "Служба" -> нажмите кнопку "Выключение", появится окно подтверждения в котором можно выбрать папку с конфигами dnsmasq, потом подтвердить выключение.
В версиях OpenWrt >= 24.10 изменено именование директории дополнительных конфигов dnsmasq. Теперь у каждого экземпляра dnsmasq своя отдельная директория (имя экземпляра является суффиксом в имени файла директории: /tmp/dnsmasq.ИМЯ_ЭКЗЕМПЛЯРА.d). Старая директория (/tmp/dnsmasq.d) больше не используется в конфигарации по умолчанию. Ruantiblock поддерживает оба варианта именования. Путь к директории конфигов dnsmasq задаётся в конфигурации ruantiblock в переменной UCI dnsmasq_confdir. Путь определяется автоматически init-скриптом (/etc/init.d/ruantiblock) при запуске службы и записывается в UCI при первом запуске. Обычно используется первая директория первого (дефолтового) экземпляра dnsmasq. Если в /tmp существует директория /tmp/dnsmasq.d, то будет выбрана она (вне зависимости от наличия других директорий) для совместимости с OpenWrt 23.05.