а у кого-нибудь впринципе quic работает корректно с ggc?
я у себя проверил, через curl --http3-only сервер пробивается (и в вайршарке все хорошо)
но если заходить через браузер, то , судя по вайршарку, там даже попыток лезть через quic нет, он сразу стартует с tcp и при неудачных попытках продолжает по нему долбиться. одинаково что в хроме, что в лисе
т.е даже первичного запроса по udp из браузера нет, как будто на самом ggc quic програмно выключен.
при этом весь остальной интерфейс ютуба, основной сайт, картинки итд работает по quic (но оно впринципе не фильтруется на тспу по h3)
Спойлер
если это не так, и у остальных работает, то единственное предположение, то что у меня с самого начала блокировок был quic отключен принудительно и гугло-система это запомнила
потестил немного:
с пиринговых серверов отдает по quic видео, с местных нет. но возможно, так и должно быть.
хмм тогда у меня нет идей, почему проходя через один и тот же тспу на местных у меня quic не работает, а на пиринговых в мск - работает (правда при прямом переходе тоже сваливается на tcp)
протестил из под виртуалки тоже самое, и что самое забавное из под vpn тоже самое. тоже форсится tcp, проверил на 10 разных стратегиях для quic, для которых curl проходит.
как будет свободное время, потыкаю еще запрет, но может тут что-то глобально оффнуто.
можешь еще мою стратегию с фейком проверить, она (у меня по крайней мере) работает быстро: --filter-tcp=443 --hostlist="%~dp0\youtube.txt" --dpi-desync=fake,fakedsplit --dpi-desync-split-pos=1 --dpi-desync-fake-tls=0x16030102920100028e03035672ea15594162966e8a144297c497ddace5d546af7a4a0414a946fa52023cf720b0220c217abb1db321abbf01985cf3d07c61367c2ba5eff307b0f6f042448077 --dpi-desync-ttl=4
ttl тебе нужно подобрать самому минимальный, хостлист для yt и ggc тут общий
напишу наблюдения с quic
единственный вариант при котором работает quic - если например хром запустить с параметром запуска: --origin-to-force-quic-on=rr1---sn-8ph2xajvh-3hfl.googlevideo.com:443,rr2---sn-8ph2xajvh-3hfl.googlevideo.com:443 ( обращаю внимание, что тогда tcp для них будет полностью выключен)
в этом случае по консоли и вайршарку вижу, что quic с перечисленными ggc работает
но есть некоторые странности:
при прямой ссылке по ggc quic не работает
такое ощущение, что во всех случаях, где quic не работает (например пункт1) некорректно работает запрет, потому что если указать --dpi-desync-repeats=15 , то я не вижу в шарке 15 отправленных пакетов
15 отправленных пакетов появляются например при curl или во время обычного просмотра видео
немного скринов:
не срабатывание повторов в запрете при прямом переходе на ggc:
фейк можно любой подкидывать, поведение одинаковое, что на гугло-фейке. что на вконтакте
если подскажете, как сохранить debug в файл, буду признателен, а то из cmd смотреть не удобно, но там тоже замечал что-то странное
как зафорсить лису на quic пока не знаю, в ней совсем не работает
--debug позволяет выводить подробный лог действий на консоль, в SYSLOG или в указанный файл через --debug=@/opt/zapret/log.txt. Может быть важен порядок следования опций. --debug лучше всего указывать в самом начале.
а на винде?
я попробовал указать --debug=@путь к файлу, дебаг пишется в текстовый файл, но все сайты перестают открываться dns probe
в логах шарка куча syn ack, fin ack на любой сайт
в самом debug при этом вижу множество обращений к doh
убираю --debug=@ и все сайты чудесным образом начинают открываться
крч стало открываться только после того, как убрал пустой wf tcp443
в логах следующее:
при curl хост попадает в профиль1
Спойлер
IP4: 192.168.1.101 => 89.113.122.76 proto=udp ttl=128 sport=60609 dport=443
UDP: len=1200 : CC 00 00 00 01 14 21 63 90 D1 9D F9 2C 04 77 DF AC 57 65 6D 32 CA 48 D1 08 13 14 0A 1E CE 19 EF … : …!c…,.w…Wem2.H… …
desync profile search for udp target=89.113.122.76:443 l7proto=unknown hostname=‘’
desync profile 0 matches
packet contains QUIC initial
packet contains full TLS ClientHello
hostname: rr1---sn-8ph2xajvh-3hfl.googlevideo.com
discovered l7 protocol
discovered hostname
desync profile search for udp target=89.113.122.76:443 l7proto=quic hostname=‘rr1---sn-8ph2xajvh-3hfl.googlevideo.com’
hostlist check for profile 1
при открытии страницы с ggc хост не попадает в профиль:
Спойлер
packet: id=25 len=1278 outbound IPv6=0 IPChecksum=1 TCPChecksum=1 UDPChecksum=0 IfIdx=17.0
IP4: 192.168.1.101 => 89.113.122.76 proto=udp ttl=128 sport=63495 dport=443
UDP: len=1250 : C1 00 00 00 01 08 D7 05 8D D3 07 A0 BB 74 00 00 44 D0 D9 3D 97 A1 80 FE B1 9C DA 8C B3 1A 56 9D … : …t…D…=…V. …
using cached desync profile 0
packet contains QUIC initial
packet contains full TLS ClientHello
not applying tampering to QUIC ClientHello without hostname in the SNI
попробовал указать через ipset , тогда в шарке все корректно, фейки отправляются, но страница с ggc все равно не открывается, но кстати через ипсет +только wf-udp443 видео прям очень быстро стало открываться на ютубе. вообщем вывод quic можно заставить работать, но работает он через одно место на билайне (ну и + не совсем понятно поведение запрета и не понятно, почему этой же проблеме подвержен warp)
Надо снять в шарке тот QUIC initial, на который идет сообщение “not applying tampering to QUIC ClientHello without hostname in the SNI”. Раскрыть crypto и посмотреть есть ли там SNI.
Если есть, то переслать этот дамп мне для изучения
как можно сопоставить пакет из дебага и из шарка? я не вижу совпадений кроме айпишников и порта
в шарке все пакеты имеют длину 1292 в дебаге вижу только packet len1278, udp len 1250
не против , если полные логи шарка и дебага скину в лс?) или например второй исх. пакет в шарке = второму пакету в debug?
