Перейти к основному содержимому

Особенности платформ

Проблемы, которые относятся к одной платформе роутера, по их признакам. Сама установка описана на страницах платформ.

OpenWrt​

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

  1. Проверьте, что модули ядра установлены и загружены, см. Модули ядра.

  2. Посмотрите лог:

    logread | grep b4

Error: Could not process rule​

b4 не может добавить свои правила. Возможно, от предыдущего неудачного запуска осталась битая таблица. Чтобы удалить её и запустить b4 снова:

nft delete table inet b4_mangle 2>/dev/null
/etc/init.d/b4 restart

Низкая скорость или тормозит видео​

На некоторых устройствах на скорость работы b4 влияет Software flow offloading в разделе Network > Firewall в LuCI. Стоит попробовать оба положения переключателя.

b4 работает, но не видит трафика при включённом flow offloading​

Flow offloading переводит установленное соединение на быстрый путь, минуя хуки файрвола, с которыми работает b4. Выключение offloading это исправляет, но на слабом железе заметно снижает пропускную способность.

b4 нужны только первые пакеты соединения: по умолчанию 19 для TCP и 8 для UDP, это Лимит TCP пакетов соединения и Лимит UDP пакетов соединения в разделе Настройки > Основные > Движок пакетов. Offloading можно включать после них:

  1. В файле /usr/share/firewall4/templates/ruleset.uc найдите строку:

    meta l4proto { tcp, udp } flow offload @ft;
  2. Замените её на:

    meta l4proto { tcp, udp } ct original packets ge 40 flow offload @ft;
  3. Перезапустите файрвол:

    fw4 restart

Ограничения этого способа:

  • Порог, здесь 40, должен оставаться выше лимитов пакетов в b4. Если поднять лимит в b4 выше порога, соединения уйдут на быстрый путь раньше, чем b4 с ними закончит.
  • Правило читает счётчики conntrack. Если sysctl net.netfilter.nf_conntrack_acct возвращает 0, счётчик остаётся нулевым, и offloading не включается вообще.
  • Сет с Включить дублирование пакетов на вкладке TCP разбирает соединение целиком, для него не подходит никакой порог.
  • Файл принадлежит пакету firewall4. Обновление пакета или sysupgrade его перезаписывает.

Информация о системе в разделе Настройки > Система > Сервис и диагностика установщика показывают найденный порог и сравнивают его с лимитами b4.

Keenetic​

Лог ошибок - /var/log/b4/errors.log.

xt_connbytes kernel module is not available​

Компоненты Netfilter включены не полностью. Должны быть отмечены оба: Модули ядра подсистемы Netfilter и Пакет расширения Xtables-addons для Netfilter, см. Компоненты Netfilter.

b4 cannot copy DNS queries with NFLOG (...)​

b4 задерживает DNS-запросы в своей очереди после conntrack. Устройство, которое запрашивает IPv4- и IPv6-адреса имени одновременно, тогда часто теряет второй ответ. В скобках указана причина, например модуль xt_NFLOG или nfnetlink_log, который не загрузился.

Информация о системе показывает в разделе Возможности ядра строку DNS-запросы копируются, а не задерживаются (NFLOG) недоступной, с недостающими модулями и компонентом, который нужно включить. Исправление - в разделе Компоненты Netfilter.

В логе сообщается о пропавших правилах b4​

KeeneticOS перестраивает свой файрвол сама: при продлении UPnP-проброса, переподключении WAN, изменении политики или компонента. Каждая перестройка удаляет правила b4. Установщик кладёт 50-b4.sh в /opt/etc/ndm/netfilter.d/, и по этому хуку b4 восстанавливает правила сразу после перестройки. Без хука b4 обнаружит пропажу при следующей проверке, раз в Интервал мониторинга файрвола (секунды), по умолчанию 10.

Строка логаЗначение
Tables rules missing after a firewall rewrite, restoring..., затем Tables rules restored successfullyХук сообщил о перестройке, и b4 вернул свои правила. Штатная ситуация
Tables rules missing, restoring... уровня WARNПроверка нашла правила пропавшими без сигнала от хука. Либо нет 50-b4.sh, либо правила убрала не KeeneticOS
Expose: the rules opening ... were missing from ..., usually after the firewall was reloaded; restored themПравила Доступ из интернета возвращены на место. Строка появляется после каждой перестройки, и при работающем хуке тоже
TUN: capture chain B4_TUN lost N of M rules (removed outside b4) ...В режиме TUN цепочка захвата восстановлена. Тоже появляется после каждой перестройки

Ту же проверку можно запустить вручную:

kill -USR1 $(cat /var/run/b4.pid)

В логе сказано, что b4 копирует DNS-запросы через NFLOG​

На KeeneticOS с ядром до 4.18 (4.14 до 4.14.173) b4 не задерживает DNS-запросы. Он снимает копию каждого запроса и работает с ответом резолвера. При запуске в логе появляется строка:

IPTABLES[iptables]: KeeneticOS runs its raw table after conntrack (kernel 4.9-ndm-5), so b4 copies DNS queries with NFLOG (group 537) instead of holding them in its queue

Это штатный режим, и Информация о системе показывает строку DNS-запросы копируются, а не задерживаются (NFLOG) доступной. Что при этом меняется:

  • Резолвер роутера по-прежнему получает каждый запрос и кеширует настоящий ответ, в том числе для имени, которое сет блокирует, закрепляет или отправляет на свой резолвер. Устройства, которые спрашивают роутер, получают вместо него ответ b4.
  • Устройство, которое спрашивает резолвер за пределами роутера, получает ответ b4, только когда этот резолвер отвечает.
  • Правило nat, которое уводит DNS на другой порт, не поддерживается.
  • После перестройки файрвола запросы проходят без копии, пока b4 не восстановит свои правила, см. выше.

На более новом ядре b4 задерживает DNS-запросы в своей очереди и такой строки в лог не пишет. Разница описана на странице Как b4 обрабатывает DNS.

MikroTik​

Команды используют имена из настройки MikroTik.

Контейнер не запускается​

  1. Проверьте его статус: /container print.
  2. Посмотрите его лог: /log print where topics~"container".
  3. Проверьте, что диск отформатирован в Ext4.

Веб-интерфейс не открывается​

  1. Проверьте, что контейнер запущен: /container print.
  2. Проверьте, что RouterOS до него достаёт: /ping 192.168.210.10.

Трафик не идёт через контейнер​

  1. Проверьте список клиентов: /ip firewall address-list print where list=b4users.
  2. Проверьте правила маркировки: /ip firewall mangle print.
  3. Проверьте маршрут: /ip route print where routing-table=to_b4.
  4. Проверьте, что FastTrack ограничен немаркированными соединениями, см. шаг 4.

Адреса, направленные через контейнер, не открываются​

  1. Проверьте, что маршрут на контейнер находится в таблице to_b4, а не в основной, см. Маршрутизация выбранных адресов.
  2. Проверьте, что bridge-docker или интерфейс отдельной машины с b4 не входит в список интерфейсов LAN или что его пакеты выведены из-под правил маркировки, как показано там.

Трафик доходит до контейнера, но ничего не меняется​

В b4 выключен NAT Masquerade, и ответы сервера идут мимо контейнера. Как его включить, описано в шаге 8.

Дашборд сообщает, что движок NFQUEUE не запустился​

Причину называет ошибка на карточке дашборда. Extension NFQUEUE revision 0 not supported, missing kernel module? означает, что в ядре, на котором RouterOS запускает контейнер, нет поддержки NFQUEUE. Кнопка Переключить на TUN на той же карточке выбирает движок TUN, которому модули очереди не нужны, и перезапускает b4. См. Движок пакетов.