Действительно, зависаний сессии больше нет.
Сессия не зависает, если первым отправлять пакет с длиной 601 байт и “1” во 2-ом бите.
quicfix.bin (601 Bytes)
У меня работает такой обход
первым фейком, состоящим из нулей, пробиваем начальную проверку
далее при первом встреченном пакете с длиной >=600 и short header шлем произвольный фейк пакет тоже с short header , но другим connection id. далее можно ничего не слать, сессия похоже окончательно уходит в разрешенные
для такой хитрости сделал custom скрипт для zapret custom-nfqws-quic4all-tspu
Вариант без скриптов :
/opt/zapret/nfq/nfqws --qnum 210 --dpi-desync=fake --debug
/opt/zapret/nfq/nfqws --qnum 211 --dpi-desync=fake --dpi-desync-any-protocol --debug --dpi-desync-fake-unknown-udp=/opt/zapret/files/fake/quic_short_header.bin --dpi-desync-cutoff=d2
iptables -t mangle -I POSTROUTING -p udp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:1 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 210 --queue-bypass
iptables -t mangle -I POSTROUTING -p udp --dport 443 -m length --length 600:1500 -m u32 --u32 "0>>22&0x3C@8>>24&0xC0=0x40" -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 211 --queue-bypass
Спасибо anonymous32 за идею
На == 600 ТСПУ не переключает фазу проверки и ждет дальше.
Сперва у меня не получилось пробить висы лишь первым фейком.
Но я ошибся, использовал не тот параметр nfqws.
Все нормально. Достаточно вместо нулей послать первым фейком достаточно длинный пакет с short header. Нет нужды в дополнительных сложностях
Как-то так
nfqws --qnum=210 --user=daemon --dpi-desync-fwmark=0x40000000 --dpi-desync=fake --dpi-desync-fake-quic=/opt/zapret/files/fake/quic_short_header.bin
iptables -t mangle -I POSTROUTING -p udp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:3 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 210 --queue-bypass
В последней версии nfqws сделал по умолчанию quic fake , состоящий из 620 байт со всеми нулями, кроме первого байта - 0x40. Так что файл с содержимым пакета не нужен
Kathrin Elmenshort has done some tests and on Yota, at least, there seems to be a 2-layer filter.
https://github.com/net4people/bbs/issues/108#issuecomment-1115131376
One layer blocks all QUIC version 1, except to specific servers; and a second layer blocks QUIC version 1 with with specific SNI values, no matter the server.
The evidence for this comes from observing what happens when accessing different servers using different SNI values.
condition result Access foreign server with correct SNI blocked Access foreign server with vk.com SNI blocked Access vk.com server with vk.com SNI works Access vk.com server with www.facebook.com SNI blocked
и что как щас жить с этим, есть ли универсальное решение?
а то в браузерах то я отключил QUIC и стало норм, но не везде выходит его отключить, например в приложении спотифая никак, либо на телефоне в приложениях гугла
юзаю антизапрет на роутере через openvpn
как это на nft в openwrt будет выглядеть?
см тему whats new в разделе zapret. если руками то есть docs/nftables.txt
Сегодня на домру Ростов обнаружилась такая ситуевина.
google.com, youtube.com - quic нормально работает с curl и PC броузеров firefox, chromium (версия для Linux)
facebook.com - после пробоя блокировки TLS все то же самое, кроме chromium. С ним первый же quic initial блокируется. При попытке пробоя nfqws через fake ответ от сервера приходит, идет новый пакет от клиента, и дальше вис.
сам не проверял, но владелец подключения утверждает, что у него проблемы с quic с android/mac с броузера chrome на google.com. И для лечения он использовал nfqws, но неправильно, из-за чего он работал исключительно на блокировку QUIC. Без QUIC броузер довольно быстро выправлялся. А с ним, выходит, что застревал где-то посередине соединения. И на это жалуется не только он.
ТСПУ там тоже наблюдается. Одна из моих тор нод заблокирована. Но блокировка QUIC отличается от обычной для, скажем, tiera spb или мегафон спб.
Пробить facebook с PC хрома удалось через --dpi-desync=fake --dpi-desync-repeats=5.
То ли лимит на количество анализируемых пакетов у DPI, то ли размер буфера ограничен, но если за первые 5 пакетов бросать туда не QUIC, он отстает
Похоже, блокировка QUIC связана с попыткой блокировки программы Psiphon — она использует QUIC с разными версиями протокола и разными фингерпринтами, как один из методов обхода фильтрации.
Только вот Psiphon продолжает успешно подключаться через QUIC, хоть и не моментально, а браузеры — нет 
На моем провайдере tiera появился дополнительный DPI от gblnet
Обычный блокировщик и ТСПУ находятся на 5-м хопе.
gblnet-овский на 11м.
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=3
[attempt 1] suspicious redirection 307 to : https://tiera.ru/blocked.php
[attempt 2] suspicious redirection 307 to : https://tiera.ru/blocked.php
[attempt 3] suspicious redirection 307 to : https://tiera.ru/blocked.php
UNAVAILABLE
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=4
[attempt 1] suspicious redirection 307 to : https://tiera.ru/blocked.php
[attempt 2] suspicious redirection 307 to : https://tiera.ru/blocked.php
[attempt 3] suspicious redirection 307 to : https://tiera.ru/blocked.php
UNAVAILABLE
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=5
[attempt 1] suspicious redirection 302 to : https://gblnet.net/blocked.php
[attempt 2] suspicious redirection 302 to : https://gblnet.net/blocked.php
[attempt 3] suspicious redirection 302 to : https://gblnet.net/blocked.php
UNAVAILABLE
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=6
[attempt 1] suspicious redirection 302 to : https://gblnet.net/blocked.php
[attempt 2] suspicious redirection 302 to : https://gblnet.net/blocked.php
[attempt 3] suspicious redirection 302 to : https://gblnet.net/blocked.php
UNAVAILABLE
..........
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=11
[attempt 1] AVAILABLE
[attempt 2] AVAILABLE
[attempt 3] AVAILABLE
!!!!! AVAILABLE !!!!!
Что примечательно касаемо QUIC.
Похоже, что gblnet полностью блокирует QUIC initial пакеты на udp port 443 в stateless режиме вне зависимости от IP назначения.
Если я отсылаю сначала фейк с short header, потом initial, установив пакету ttl=8, например, то приходит TTL expired in transit. Начиная с 11 хопа не приходит ничего. То есть 5-й хоп пробивается с обычным DPI, но глобал блочит все.
Проверял на свою VPSку. initial не доходят вообще. если мешать с одним src_port, то short доходят все, initial не доходят
Как-то далеко. Есть признаки что это сеть провайдера, а не магистраль?
Может уровень супербосса блокировок достигли.
UPD:
По ссылке на сайте c блокировкой от gblnet картинка и телефон ООО “ЕТЕЛЕКОМ”, который входит вместе с ООО “ГЛОБАЛНЕТ” в холдинг ООО “ЕТ-ГРУПП”. При этом гендир у холдинга и ООО “ТИЕРА ЦЕНТР” один, но тиера не входит в холдинг.
Спецы вышли из чата, остались 1 гендир и 2 блокировщика.
11-й хоп 109.239.134.66
route: 109.239.134.0/24
descr: Butlerova7 P2P Customer Network
origin: AS31500
mnt-by: MNT-GLOBAL-NET
и редирект по http идет на сайт магистрала
получается магистралов подтянули к блокировкам
Еще немного подробностей
Что считается QUIC initial.
- udp_length >=1200
- Старший бит первого байта установлен (long header)
- Байты 1…4 uint32 в network byte order - это версия QUIC. Сечется IETF QUIC и некоторые чуть более старые версии драфта
Например, такой пакет : 80 00 00 00 01 00 00 … 00 (1200 байт)
уже не проходит
У firefox в initial используются лишь несколько сотен байт в начале, остальное - паддинг нолями. Если бы уменьшить размер UDP на передающей стороне , то оно бы прошло
chromium имеет склонность фрагментировать и раздувать до большого размера нешифрованный блок за счет паддинга и пинга, что приводит к увеличению длины используемого шифрованного блока
дропают
похоже, наши власти обьявили QUIC полную негласную войну
анализ QUIC сопряжен с алгоритмической и нагрузочной сложностью. проще рубануть.
любой внутрироссийский сервис будет вынужден отказываться от деплоймента QUIC
на мегафоне спб смотрел. Опять появились подвисания, непонятно по какому алгоритму. Пробивка short header первым пакетом уже не надежна. Где-то норм, но ютубе скатывается на http2 после небольших тормозов. Полной стателесс блокировки нет
внедрение блокиратора на магистрале - предполагаю это вынужденная антисанкционная мера в условиях острой нехватки оборудования. не все провайдеры еще с ТСПУ, а где есть, часто бывает лоад балансинг, где не все пути оборудованы этим ДПИ. Пробный шар как прокатит, тестирование на высокой нагрузке, включение щадящих CPU режимов фильтрации (stateless)
http, кстати, тоже фильтруется stateless. Надо сечь все пакеты внутри keep alive. Обычный режим rdp.ru предполагает фильтрацию stateful
Локалхост в надежных руках.
Меж тем изменения ПО/правил с июня-июля:
Дефрагментирует фреймы.
Неудачную расшифровку (в т.ч. проверку размеров) и SNI-less игнорирует.
По интересному совпадению, rdp научился понимать фрагменты CH сразу после выпуска nDPI с фиксом.
У них в планах, нарушить работу всех ваших игрушек, десинхронизирующих nDPI.
Насколько я понял, цель фрагментации CH в chrome - вовсе не обман DPI, а принуждение веб серверов к отказу от предположения, что CH пойдет один блоком. Чтобы они вынуждены были учитывать такой сценарий, а не упрощать себе жизнь, тем самым не полностью поддерживая стандарт.
Собрать разбросанные фрагменты не настолько алгоритмически сложно и CPU затратно, сколько расшифровать сам пакет. Удивительно, что этого не было сделано сразу.
Текущая ситуация по QUIC примерно такая.
Опробовано порядка 12 провайдеров в RU из разных городов.
На большинстве из них QUIC блокируется путем анализа SNI из расшифрованного QUIC initial.
Если SNI плохой, то блокируется stateful все udp “соединение”.
Анализируется только udp port 443.
Поскольку поведение у всех примерно одинаковое, то можно сказать, что блокирует ТСПУ.
Но тут есть важная оговорка. Модуль парсера кривой.
тут есть статический curl для x86_64 и arm с поддержкой nghttp3 (curl) и quiche (curlq)
Если попробовать этими 2 курлами подергать инстаграм, то видно, что curl виснет, а curlq прокатывает.
Так же firefox после пробивки TCP (чтобы он начал переходить на QUIC) спокойно берет http3, а chrome - только http2.
Можно проверить, загнав через ncat на свой VPS : блобы из zapret:files/fake. quic_initial_facebook_com.bin не доходит, а quic_initial_facebook_com_quiche.bin доходит.
То есть вывод, что парсер сечет chrome и nghttp3, но не сечет quiche и firefox.
Без обхода блокировок по TCP броузеры все равно не пойдут на QUIC, так что разницы практической мало.
Разблокируется через nfqws --fake.
Есть и исключение у провайдеров. Tiera, как обычно. Аплинк глобалнет продолжает полностью блокировать QUIC. Больше нет никаких подвисаний сессии. Тупо режут long header в обе стороны.