Как подобрать стратегию одновременно для discord и для ютуба?
Товарищи, у меня что-то очень сложный случай.
Запрет стоит на Openwrt, подключение по PPPoE.
Блокчекаю сервера, которые выкидывает в консоли. например, вот эти:
rr1---sn-0ahjg0-gv8e.googlevideo.com
rr2---sn-0ahjg0-gv8e.googlevideo.com
rr8---sn-ug5onuxaxjvh-n8vs.googlevideo.com
На пару десятков серверов блокчек выдает одинаковые стратегии:
- checking nfqws --dpi-desync=syndata,split2 --wssize 1:6 --dpi-desync-split-pos=1 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=1 --dpi-desync-autottl=1 --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=1 --dpi-desync-autottl=2 --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=split2 --dpi-desync-split-seqovl=49 --dpi-desync-split-pos=50 --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=split2 --dpi-desync-split-seqovl=9 --dpi-desync-split-pos=10 --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=split2 --dpi-desync-split-seqovl=3 --dpi-desync-split-pos=4 --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=split2 --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=3 --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=split2 --dpi-desync-split-seqovl=1 --dpi-desync-split-pos=2 --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=split2 --dpi-desync-split-seqovl=1 --dpi-desync-split-tls=sniext --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=split2 --dpi-desync-split-seqovl=1 --dpi-desync-split-tls=sni --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=fake,split --dpi-desync-fooling=badseq --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=fake,split2 --dpi-desync-fooling=badseq --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=syndata,split2 --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=4 --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
- checking nfqws --dpi-desync=fake,split2 --dpi-desync-fooling=badseq --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
Общий паттерн следующий - везде есть --wssize 1:6 (кстати, вопрос - в блокчеке он без “=”, в readme.txt с “=”. Но я пробовал оба варианта, разницы не нашел).
Если брать следующие стратегии, то соединение бесконечное.
--dpi-desync=fake,split2 --dpi-desync-fooling=badseq --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
или
--dpi-desync=fake,split2 --dpi-desync-fooling=md5sig --wssize 1:6 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin
или любой с
--dpi-desync-autottl=
Если сделать конструкцию с --dpi-desync-ttl=4, либо --dpi-desync-ttl=4 --dpi-desync-fooling=md5sig(badseq), то в консоли соединение быстро дропается.
Но объеденяет все стратегии то, что ни одна из них не дается соединиться с кеширующими серверами. Подставлять кастомные tls от гуглдрайва, эппла или еще чего-то результата не дает.
Помогите.
У вас только из summary не работают или вообще все? Из summary могут не работать, потому что там доп. фейки не указаны --dpi-desync-fake-tls=tls_clienthello_www_google_com.bin --dpi-desync-fake-quic=quic_initial_google_com.bin Попробуйте их просто добавить в конец стратегии.
Это в гудчеке? Странно, там curl же в сборку входит. Вы полностью весь архив распаковали в папку с zapret-winws?
Предлагаю попробовать готовую сборку KDS Сборка YTDisBystro на основе Zapret: Тестирование и обсуждение (Не пишите сюда ни про какие ошибки не прочитав 1-й пост темы) В ней как раз стратегия и для ютуба и для дискорда. Если сработает, то ничего подбирать не нужно.
А какое у вас конечное устройство, на чем вы смотрите ютуб?
amd64, Windows 10, Firefox, Chromium Gost и Yandex браузер.
Включение и отключение Kyber в Firefox погоды не делает.
Пару недель назад были стратегии, где все работало на всех устройствах и с любой комбинацией браузеров. Сейчас - нигде кэширующий сервера не работают.
Странно конечно, что не работает, хотя блокчек выдал столько рабочих стратегий. Даже не знаю, что тут можно сделать… Единственное, что приходит в голову - это какое-нибудь перенаправление попробовать. На одном форуме был такой совет:
За видеороликами ютуба нас всегда направляло на сети 208.65.152.0/22 и 208.117.224.0/19 обе эти сети находятся в US. Направили пакеты к местному GGC.
iptables -t nat -I PREROUTING -s 10.X.Y.Z/NET -d 208.65.152.0/22 -p tcp --dport http -j DNAT --to-destination 89.218.72.76
iptables -t nat -I PREROUTING -s 10.X.Y.Z/NET -d 208.117.224.0/19 -p tcp --dport http -j DNAT --to-destination 89.218.72.76
Что если вам наоборот попробовать? С ваших подсетей перенаправить на 208.65.152.0/22 и 208.117.224.0/19. Ну так, в порядке эксперимента…
Не не, это было про тот скрипт, который незабаненные айпи в забугорных днсах находит. нашёл посвежее курл для вин7) сейчас работает
del
Вопрос по-прежнему актуален
Подскажите, а можно просто через curl проверить доступен какой нибудь rr1---sn-gvnuxaxjvh-aome.googlevideo.com или нет?
чтобы когда zapret не работает, тогда бы и показывал что сервер недоступен.
Запрет не расширяет твою видимость. Он лишь снимает ограничение провайдера . Если хост недоступен изначально, то он так и останется недоступен и ты это узнаешь лишь по консоли, курлу и тд.
В данный момент имеются 3 варианта GGC у любого провайдера и почему-то гугл не подозревает о них:
1 - Доступные хорошие
2 - Доступные “обманки”
3 - Бывшие сервера (которые убрали, но маршрут до них остался)
Так-же техника запрета запросов к “плохим” серверам помогает улучшить отзывчивость яндекса ютуба (через блокировку рекламу, сам браузер или hosts ). Отображаться запросы будут в консоле, но уже будет что-то типо “block”. А то если их не убирать, “тормозить” яндекса ютуб будет, пока тайм-аут не наступит. Причем тайм-аут может быть выставлен отличный от стандартных 30с…
Конечно данные хосты можно накидать и в исключение запрета… Но он самый невиновный
Простой вариант:
curl -m 2 -so NUL -w "code: %{response_code}%{onerror}\nerror: %{errormsg}" https://rr1---sn-gvnuxaxjvh-aome.googlevideo.com
Вариант all-in-one:
curl -so NUL -m 2 -w "\nRequested URL: %{url}\nRedirect URL: %{redirect_url}\nIP: %{remote_ip}\nHTTP Ver.: %{scheme}/%{http_version}\nSSL Check (0=ok): %{ssl_verify_result}\n\nTime - DNS: %{time_namelookup} sec\nTime - Connection: %{time_connect} sec\nTime - Handshake: %{time_appconnect} sec\nTime - Receiving Data: %{time_starttransfer} sec\nData sent in request: %{size_request} bytes\nData received in headers: %{size_header} bytes\n\nResponse Code: %{response_code}\nExit Code: %{exitcode}\n%{onerror}Error Message: %{errormsg}" https://rr1---sn-gvnuxaxjvh-aome.googlevideo.com
Фактически, важно наличие респонс кода.
благодарю
Я из донецкого региона, где гугл ком не работает, есть ли альтернативы файлам типа *google_com.bin?
Найди на данном сайте архивы сборок и распакуй их
Большинство из них можно найти там.
И да… Называй их пейлоадми
Для ютуба - нет. Пэйлоады делают на основе гугла, как раз из-за того, что у большинства он не заблочен и при этом является смежным для ютуба. Как следствие, его не останавливают блокировщики. Если он у вас забанен (и если забанены все поддомены, типа fonts.google.com drive.google.com и др.) - то толку, скорее всего, с кастомных пэйлоадов не будет. Проще сразу искать стратегию без них.
Всем привет! Пытался подобрать стратегию для запрета, но скрипт выдал такой результат:
Такого результата в теме не встречал. Можете подсказать в чем причина? Или тспу у провайдера мощная? Гудчек тоже выдает не обнадёживающие результаты. Провайдер ростелеком.
Еще были ошибки о том, что невозможно записать во временную папку:
Ниже txt с тем, что выдало после п.8 пп(!)
blockcheck.log (598,6 КБ)
Домен надо указывать без хттпс://