Bug description

Добрый день,

Предыстория вопроса:

У нас используется модуль ядра kyoutubeUnblock.ko версии 1.0.0-rc4 на двухпроцессорном сервере с Linux Debian 12.8, ядро 6.1.0-28-amd64. Через сервер проходит (маршрутизируется) только однонаправленный исходящий трафик клиентов - 5 Gbit/s (т.е. сервер видит пакеты SYN и Client Hello). Входящий трафик, более 30 Gbit/s, идет в обход сервера, соответственно сервер не видит SYN+ACK, Server Hello и т.д. Файрволл стоит nftables. В правилах файрволла conntrack выключен и не используется (т.е. на файрволле нет правил с опцией "ct"), т.к. conntrack в Linux по факту вообще не поддерживает Unidrectional TCP flow, и в целом бесполезен на однонаправленном трафике (сессии создаются в состоянии SYN_SENT и никогда не переходят в ESTABLISHED). NAT трансляции на сервере нет, это маршрутизатор. Файрволл не имеет никаких правил для транзитного трафика, и ничего не фильтрует, кроме собственного менеджмент-трафика сервера (цепочка INPUT, без использования conntrack).

Когда мы загружаем модуль ядра kyoutubeUnblock.ko версии 1.0.0-rc4, он запускается без проблем, не требует нкаких модулей ядра и nftables, кроме установленных по умолчанию, не ругается при запуске, не требует модуля nf_conntrack. Работает тоже нормально, за исключением одного: примерно 20-30% запросов Client Hello от Chrome не распознаются модулем, не показываются в трассировке, соответственно, не обрабатываются. Как следствие, они дропаются вышестоящим "фильтрующим оборудованием". Все запросы к youtube от Chrome-based броузеров - это Client Hello версии TLSv1.3+kyber размером более 1500 байт (от 1,7 до 2,2 кбайт). (Если нужно, могу прислать дампы трафика с примерами около 100 успешных и неуспешных запросов TLSv1.3+kyber, собранных как с модулем 1.0.0-rc4, и так и с модулем 1.0.0-rc5). С модулем 1.0.0-rc4 у нас используется опция sni-detection=parse, т.к. опция sni-detection=brute в версии 1.0.0-rc4 не работает: не меняет процент дропов и не увеличивает загрузку CPU на сервере. Если в Chrome принудительно отключить либо kyber, либо TLSv1.3 (любое из двух), то дропы уходят, и все 100% видеороликов открываются с первого раза.

Опции запуска модуля: "verbosity=silent quic_drop=1 faking_ttl=2 no-ipv6=1 fake_sni_type=default faking_strategy=pastseq fake_sni_seq_len=3" + список доменов.

Мы попробовали установить новый релиз 1.0.0-rc5. Вылезли регулярные креши модуля - и под нагрузкой и без. (это и есть суть обращения). Опции запуска примерно те же: "--silent --connbytes-limit=8 --fake-sni-seq-len=3 --frag-sni-faked=0 --fake-sni-type=default --faking-strategy=pastseq --no-ipv6 --sni-detection=parse" + список доменов.

Общая картина сильно зависит от опции sni-detection:

1. С опцией "--sni-detection=parse:"

Модуль kyoutubeUnblock.ko версии 1.0.0-rc5 вообще отказывается загружаться, до тех пор пока вручную не загружен модуль ядра nf_conntrack (у нас conntrack не используется и не загружен по умолчанию). Предыдущая версия 1.0.0-rc4 запускалась и без него. Приходится добавлять nf_conntrack в /etc/modules.

После этого kyoutubeUnblock.ko загружается, работает с тем же процентом дропов Client Hello от броузера Chrome, что и версия 1.0.0-rc4 (20-30%), но сервер рандомно крешится и перезагружается под нагрузкой при работе, и при любых манипуляциях с модулем: загрузка модуля, выгрузка модуля, изменение параметров модуля (командой echo ... > /sys/module/kyoutubeUnblock/parameters/parameters). При манипуляциях - крешится после нескольких манипуляций (иногда с 1 раза), без манипуляций - тоже крешится под нагрузкой (трафиком), чаще всего через несколько минут. Любопытный факт: при смене параметров командой echo и при загрузке модуля сервер крешится мгновенно, а при выгрузке модуля (rmmod kyoutubeUnblock) = крешится секунд через 30 после выгрузки.

Для крешей с опцией parse найден странный workaround: после ребута сервера, сначала загружается модуль 1.0.0-rc4, потом он выгружается, и загружается 1.0.0-rc5. В этом случае версия 1.0.0-rc5 какое-то время работает условно стабильно и не падает сразу: ее можно выгрузить-загрузить- сконфигурить раз 20-30, прежде чем закрешится. Под нагрузкой может проработать несколько часов, несли не трогать. Но потом все равно упадет.

Если же после ребута сразу загрузить 1.0.0-rc5, без workaround, то проживет она не больше нескольких минут.

2. С опцией "--sni-detection=brute:"

Chrome начинает работать на 100% без видимых дропов, при этом загрузка CPU на сервере возрастает, т.е. модуль реально что-то делает. Но работает он под нагрузкой тоже не более нескольких минут, потом крешится. Предыдущий workaround в случае опции brute почти не помогает: дает поработать модулю на несколько минут подольше, но не более того. Без нагрузки модуль тоже рандомно падает, часто через 5 минут после ребута.

При манипуляциях (загрузка, выгрузка, изменение параметров) модуль 1.0.0-rc5 с включенной опцией brute - крешится мгновенно и в большинстве случаев с 1 раза. И с нагрузкой и без. Ничем не лечится, workaround не помогает. Т.е. сервер загружается, загружает модуль, после загрузки модуля на него подается трафик, и потом он либо сам в течение нескольких минут упадет, либо упадет при первом же действии над модулем.

Linux distribution

Debian 12.8, core: 6.1.0-28-amd64

Device architecture

x86_64

Configuration

--silent --connbytes-limit=8 --fake-sni-seq-len=3 --frag-sni-faked=0 --fake-sni-type=default --faking-strategy=pastseq --no-ipv6 --sni-detection=parse --sni-domains=googlevideo.com,ggpht.com,ytimg.com,youtube.com,play.google.com,youtu.be,googleapis.com,googleusercontent.com,gstatic.com,l.google.com,doubleclick.net,gvt1.com