Проблема на Keenetic Giga 1011

[Gregorius-MC]

Использую B4 на роутере Keenetic Giga 1011 с Entware.

Возникла проблема с обработкой трафика LAN-клиентов: B4 крайне нестабильно определяет соединения/домены клиентов и, соответственно, не применяет к ним настроенные сеты и стратегии.

При этом трафик, созданный непосредственно на самом роутере, обрабатывается B4 стабильно и корректно.
Для тестирования использую rutracker.org, добавленный в отдельный сет с рабочей стратегией обхода.

С LAN-клиентов (Windows ПК и Android-телефон):

• в большинстве случаев сайт не открывается, соединение завершается RST;

• в панели B4 соответствующее соединение часто вообще не появляется как соединение с определённым доменом;

• в основном логе B4 видны TCP-пакеты вида:

  TCP 192.168.100.2:xxxxx → x.x.x.x:443 mac=...

  но имя домена и tls=... отсутствуют;

• иногда B4 случайным образом всё же определяет соединение/домен — в этом случае стратегия сразу срабатывает и сайт нормально открывается;

• на Android вероятность успешного срабатывания немного выше в режиме инкогнито, но результат нестабильный;

• если сайт успешно открылся, он может нормально работать в текущей вкладке до её закрытия;

• после создания нового соединения проблема возникает снова;

• иногда сразу после перезапуска сервиса B4 несколько соединений определяются успешно, после чего проблема возвращается.

Для сравнения, когда B4 успешно распознаёт TLS-соединение, в логе появляются нормальные записи вида:

TCP ... → ...:443 servers.plex.tv tls=1.3 mac=...

То есть TLS/SNI-парсер в принципе работает, но для транзитного трафика LAN-клиентов срабатывает крайне нестабильно.

Важное наблюдение: локальный трафик роутера работает

Если выполнить, например:

curl https://rutracker.org

непосредственно на самом Keenetic, всё работает стабильно.

B4:

• мгновенно видит соединение;
• корректно определяет домен;
• отображает в панели устройство с WAN-адресом роутера;
• применяет нужный сет/стратегию;
• обход работает стабильно.

Таким образом, наблюдается явная разница:

локальный OUTPUT-трафик роутера → работает стабильно
транзитный LAN → WAN трафик → домены/SNI определяются крайне редко

Что уже проверено

1. NFQUEUE и iptables работают.

Автоматически создаваемые правила B4 присутствуют, счётчики пакетов активно увеличиваются.

Используются очереди:

NFQUEUE 100:103

Пакеты TCP/443 действительно попадают в NFQUEUE.

2. Проверено с одним worker / одной очередью.

Уменьшение количества рабочих потоков до 1 проблему не решает. Поведение остаётся тем же.

Куда мне копать? Имеет ли место быть какая-либо известная проблема с обработкой транзитного (forwarded) трафика на Keenetic/Entware? Самостоятельно решить проблему пока не смог, откатился на zapret2.

[asovetov]

Привет! У меня был в точности такой же случай — Netcraze Ultra NC-1812 (он же Keenetic Ultra), Entware. Тот же симптом: трафик самого роутера обрабатывается стабильно, транзитный трафик клиентов из локальной сети — почти никогда, домен в логе не появляется.

Копнули код и нашли баг. Прошивка Keenetic помечает пакеты клиентов своей меткой ещё до цепочек b4:

_NDM_HOTSPOT_PREROUTING_MANGL ... -m mac --mac-source <MAC-клиента> -j MARK --set-xmark 0xffffaaa/0xffffffff

А в b4 проверка «это служебное соединение b4, не обрабатывать» сделана тестом одного бита (0x200000) от метки пакета. Метка 0xffffaaa этот бит содержит (0xffffaaa & 0x200000 != 0), поэтому все клиентские пакеты молча проходят мимо обработки — vc.accept() в src/nfq/handler.go, а правило -m mark --mark 0x200000/0x200000 -j RETURN в цепочке B4 их съедает ещё до NFQUEUE. Отсюда и случайность: клиенты, чьи MAC не попали в правила с меткой, обрабатываются нормально.

Подготовил PR с исправлением (точное сравнение метки по маске вместо теста одного бита): #422

Пока PR не принят, можно попробовать обойтись руками — снять бит 0x200000 с клиентских пакетов после того, как прошивка их пометила, и до цепочек b4:

iptables -t mangle -A PREROUTING -m mark --mark 0x200000/0x200000 -j MARK --set-xmark 0x0/0x200000

Правило должно идти в PREROUTING после переходов в цепочки _NDM_* (добавлять через -A, не в начало — иначе прошивка переставит метку уже после него), и его нужно восстанавливать после пересборки netfilter прошивкой (например, скриптом в /opt/etc/ndm/netfilter.d/). Собственные служебные пакеты b4 идут через OUTPUT, поэтому для них правило безопасно. Сразу оговорюсь — сам этот ручной фикс я не проверял, у нас проблема решена сборкой с патчем из PR.

[Gregorius-MC]

О, я уже и забыл про свой issue... В какой-то момент, я даже не знаю когда и на какой версии всё стало работать абсолютно нормально, и с тех пор работает до сих пор без проблем.

[asovetov]

странно я вчера свежий билд на свежий роутер начал накатывать и уперся в то что ничерта не работает с локалки но в вебморде на роутере все работает прекрасно. пришлось вот покопать код немного да иишечку привлечь =)