search

bol-van / zapret

DPI bypass multi platform
8.06k stars 616 forks source link

Долго грузит видео на ютубе перед воспроизведением #373

Open nonicknoname opened 1 month ago

nonicknoname commented 1 month ago

Установил openwrt 23.05.4 на роутер, установил dnscrypt-proxy, установил запрет, подобрал стратегию, на ПК - работает все идеально, видео открываются моментально. На айфоне в ютуб-приложении прежде чем видео запустится проходит 5-10 секунд(крутится кружок) и после этого все работает и грузится, некоторые видео открываются моментально, но это довольно редко. На телевизоре также. Но, если открывать видео с браузера в ютубе - довольно быстро грузит. Тестил TLS 1.2, 1.3, quic из под винды через cygwin prompt(команды брал отсюда: https://github.com/bol-van/zapret/discussions/200?ysclid=m0vdzjfnis828740571), вот вывод:

1 команда:

$ curl -v4s -o nul -k --connect-to ::google.com -H "Host: metsalehti-staging-s4uzwwd6nq-lz.a.run.app" https://test.googlevideo.com/app/uploads/2021/11/2022-mediakortti.pdf -w %{speed_download}

  • Connecting to hostname: google.com

  • Host google.com:443 was resolved.

  • IPv6: (none)

  • IPv4: 74.125.131.100, 74.125.131.138, 74.125.131.139, 74.125.131.102, 74.125.131.113, 74.125.131.101

  • Trying 74.125.131.100:443...

  • Connected to google.com (74.125.131.100) port 443

  • ALPN: curl offers http/1.1 } [5 bytes data]

  • TLSv1.3 (OUT), TLS handshake, Client hello (1): } [512 bytes data]

  • TLSv1.3 (IN), TLS handshake, Server hello (2): { [122 bytes data]

  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): { [21 bytes data]

  • TLSv1.3 (IN), TLS handshake, Certificate (11): { [6298 bytes data]

  • TLSv1.3 (IN), TLS handshake, CERT verify (15): { [79 bytes data]

  • TLSv1.3 (IN), TLS handshake, Finished (20): { [52 bytes data]

  • TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): } [1 bytes data]

  • TLSv1.3 (OUT), TLS handshake, Finished (20): } [52 bytes data]

  • SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey

  • ALPN: server accepted http/1.1

  • Server certificate:

  • subject: CN=*.google.com

  • start date: Aug 12 06:33:49 2024 GMT

  • expire date: Nov 4 06:33:48 2024 GMT

  • issuer: C=US; O=Google Trust Services; CN=WR2

  • SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.

  • Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption

  • Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption

  • Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption

  • using HTTP/1.x } [5 bytes data] GET /app/uploads/2021/11/2022-mediakortti.pdf HTTP/1.1 Host: metsalehti-staging-s4uzwwd6nq-lz.a.run.app User-Agent: curl/8.9.0 Accept: /

  • Request completely sent off { [5 bytes data]

  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): { [288 bytes data]

  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): { [288 bytes data] < HTTP/1.1 200 OK < content-type: application/pdf < last-modified: Mon, 10 Jan 2022 15:11:19 GMT < vary: Accept-Encoding < etag: "61dc4c97-6d4968" < x-frame-options: SAMEORIGIN < accept-ranges: bytes < X-Cloud-Trace-Context: 7ba996794c203766fa2cc3be677972bb;o=1 < Date: Tue, 10 Sep 2024 19:00:18 GMT < Server: Google Frontend < Content-Length: 7162216 < Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 < { [990 bytes data]

  • Connection #0 to host google.com left intact 21302741

2 команда:

$ curl --tls-max 1.2 -v4s -o nul -k --connect-to ::google.com -H "Host: metsalehti-staging-s4uzwwd6nq-lz.a.run.app" `https://test.googlevideo.com/app/uploads/2021/11/2022-mediakortti.pdf -w %{speed_download}

  • Connecting to hostname: google.com

  • Host google.com:443 was resolved.

  • IPv6: (none)

  • IPv4: 74.125.131.100, 74.125.131.138, 74.125.131.139, 74.125.131.102, 74.125.131.113, 74.125.131.101

  • Trying 74.125.131.100:443...

  • Connected to google.com (74.125.131.100) port 443

  • ALPN: curl offers http/1.1 } [5 bytes data]

  • TLSv1.2 (OUT), TLS handshake, Client hello (1): } [229 bytes data]

  • TLSv1.2 (IN), TLS handshake, Server hello (2): { [106 bytes data]

  • TLSv1.2 (IN), TLS handshake, Certificate (11): { [6291 bytes data]

  • TLSv1.2 (IN), TLS handshake, Server key exchange (12): { [115 bytes data]

  • TLSv1.2 (IN), TLS handshake, Server finished (14): { [4 bytes data]

  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16): } [37 bytes data]

  • TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): } [1 bytes data]

  • TLSv1.2 (OUT), TLS handshake, Finished (20): } [16 bytes data]

  • TLSv1.2 (IN), TLS handshake, Finished (20): { [16 bytes data]

  • SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305 / x25519 / id-ecPublicKey

  • ALPN: server accepted http/1.1

  • Server certificate:

  • subject: CN=*.google.com

  • start date: Aug 12 06:33:49 2024 GMT

  • expire date: Nov 4 06:33:48 2024 GMT

  • issuer: C=US; O=Google Trust Services; CN=WR2

  • SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.

  • Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption

  • Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption

  • Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption

  • using HTTP/1.x } [5 bytes data] GET /app/uploads/2021/11/2022-mediakortti.pdf HTTP/1.1 Host: metsalehti-staging-s4uzwwd6nq-lz.a.run.app User-Agent: curl/8.9.0 Accept: /

  • Request completely sent off { [5 bytes data] < HTTP/1.1 200 OK < content-type: application/pdf < last-modified: Mon, 10 Jan 2022 15:11:19 GMT < vary: Accept-Encoding < etag: "61dc4c97-6d4968" < x-frame-options: SAMEORIGIN < accept-ranges: bytes < X-Cloud-Trace-Context: feb889718599585ab7d5ed185443289e;o=1 < Date: Tue, 10 Sep 2024 19:05:29 GMT < Server: Google Frontend < Content-Length: 7162216 < Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 < { [991 bytes data]

  • Connection #0 to host google.com left intact 16922791

    3 команда:

$ curl --http3-only -v4s -o nul -k --connect-to ::google.com -H "Host: metsalehti-staging-s4uzwwd6nq-lz.a.run.app" https://test.googlevideo.com/app/uploads/2021/11/2022-mediakortti.pdf -w %{speed_download}

Прикрепляю tcpdump: dump.txt

Настройки: NFQWS_OPT_DESYNC="--dpi-desync=fake,split2 --dpi-desync-autottl=1:1-10 --dpi-desync-fooling=md5sig"

Что делать, куда копать? Всю голову изломал. Подскажите, люди добрые...

eastone11 commented 1 month ago

MODE_FILTER=none?

bol-van commented 1 month ago

со скоростью все норм более 100 мбит

nonicknoname commented 1 month ago

MODE_FILTER=none?

Да

nonicknoname commented 1 month ago

со скоростью все норм более 100 мбит

Это и странно, все вроде как нормально, но почему прежде чем воспроизвести видео, оно грузит по 5-10 секунд? Когда на пк такого нет. Возможно ли как то убрать/сократить эту прогрузку?

nonicknoname commented 1 month ago

Установил mitmproxy чтобы посмотреть трафик с телефона: 57E48EF8-6AA4-4DF0-9CBB-3F978294795E 59B647B5-C6E9-4E98-BAD4-86B8294FC254

Вот ответы от googlevideo playback, загрузка видео идет по 5 секунд и он пытается скачать большой кусок видео(?)((насколько я понял)). Причем запрос идет к GGC серверам в России. Хочется снизить эту задержку до минимума. Подскажите, что не так? Спасибо за ваше внимание.

bol-van commented 1 month ago

171 мб загружать 5 секунд - это очень неплохая скорость почему так поступает приложение не знаю может пытается иначе, не может и делает как может смотреть дамп с телефона возможности нет если там нет тупняков на других запросах, то проблема не в блокировке

nonicknoname commented 1 month ago

Хм, странно, до «замедления» ютуба такой проблемы не было, даже и не знаю, что сделать то, стратегии менял, настройки менял, при любых вариантах на телефоне какое-то время крутится круг, но на компьютере в любом браузере все идеально.

Есть такая особенность, если включить впн на телефоне, зайти в ютуб приложение и выключить впн — любое видео будет летать и не будет рекламы.

Спасибо автору за ответы, если появится возможность — посмотри дамп пожалуйста, ну, или кому не лень из читающих. Я в этом не очень силен, заранее спасибо!

Может еще кто сталкивался с такой проблемой, как решали или боролись? Буду рад любым ответам.

eastone11 commented 1 month ago

nonicknoname Получается когда вы включаете VPN, у вас нет кусков видео по 170мб? PS и вопрос не по теме, вы mitmproxy прямо на openwrt поставили? если не сложно не скинете ссылку, я чё то не могу найти как её установить (вижу только что то похожее tcp-http-proxy)

nonicknoname commented 1 month ago

Не знаю что происходит после манипуляций с впн, не следил за трафиком(неужели устанавливается какое то соединение, которое фиксит эту проблему?) просто случайно заметил. Mitmproxy ставил на пк(вин11), в настройках айфона вай фая прописывал прокси-сервер и в консоль выводились запросы от телефона. https://mitmproxy.org/, еще нужен сертификат от них же, берется на mitm.it

nonicknoname commented 1 month ago

Блокировка здесь действительно не при чем, немного углубился: HTTP код при "прогрузке" видео перед воспроизведением = 206, т.е качает частями, на компьютере HTTP код 200 и все моментально грузится. Включение и выключение впна на телефоне заставляет код с 206 поменяться на 200 и все моментально грузится в приложении ютуба.

@bol-van Можно ли как-то повлиять на это без костылей в виде включения выключения впна?

eastone11 commented 1 month ago

Мне кажется чтобы знать ответ как исправить, надо понимать почему приложение начинает таким методом работать. Еще интересно это у всех так или нет, может всем пофиг на эти 5 секунд и никто не жалуется, а может тут еще какая причина.

Я на выходных смогу потестить если интересно, у вас андройд\айос? прила стандартная или нет?

bol-van commented 1 month ago

разница может быть в используемых ggc можно попробовать на рутере загасить (0.0.0.0) домен проблемного ггц чтобы он на другой полез

на эмуляторе android проверял youtube app после разблокировки 4 доменов все быстро атв версия не идет даже с впн

nonicknoname commented 1 month ago

разница может быть в используемых ggc можно попробовать на рутере загасить (0.0.0.0) домен проблемного ггц чтобы он на другой полез

на эмуляторе android проверял youtube app после разблокировки 4 доменов все быстро атв версия не идет даже с впн

Спасибо за ответ, попробую. Нюанс в том, что компьютер подключается к тем же GGC, что и айфон, но на телефоне с кодом HTTP 206, что-то ютубу не нравится в запросе. Посмотрю еще как ведет себя андроид сегодня, отпишусь здесь. Рад, что хоть какая-то зацепка появилась, буду думать что делать дальше, надеюсь это не ложная дорога)

nonicknoname commented 1 month ago

Зацепка оказалось ложной, на андроиде тоже "жует" видео, попробовал в hosts на роутере позакидывать разные GGC - не помогло, он первый раз делал запрос к ру GGC, потом переключался на какой-то США GGC и тоже не грузил его, в итоге видео вообще не запускалось. Я в замешательстве, что делать...

Dager26reg commented 1 month ago

Добрый день. Вчера что-то поменяли у наших провайдеров и перестал грузить видеопотоки ютуб, при том что сам сайт открывается, и открываются другие сайты заблокированные. Начал экспериментировать со стратегиями, оказалось что если выставить ТТЛ 2 на ГДПИ принудительно - тогда ютуб начинает грузить моментально видосы, и судя по ggc он их грузит с росийских. Но при этом не открываются некоторые заблокированные сайты. Но если выставить ТТЛ 3 или более - открываются все сайты которые заблокированы. Открывается сам ютуб но видосы перестает показывать, и щемится на америкосовские ggc Соотвествено такой вопрос - а можно ли сделать прогу так, чтоб у нее в конфиге можно было указать стратегию по умолчанию, которая рпименяется для всех доменов из autohost файла, но если после домена в автохост файле прописана цифира после домена - то применяется стратегия с этой цифирой? А в конфиге прописывать несколько стратегий под ццифрой 1,2,3 и так далее, сколько надо. ЧТоб можно было для разных доменов применять разные стратегии?

Если убрать ТТЛ в 0 и оставить только флаг badsum то ютуб работает как-то нестабильно, какие-то видосы открываются какие-то нет. Но при этом все остальные сайты нормально работают.

bol-van commented 1 month ago

есть другие ограничители fooling см доку md5sig самый безобидный

Dager26reg commented 1 month ago

md5sig стоял изначально. И все прекрасно работало. Но вчера перестал ютуб грузить видосы. И работало даже без ТТЛ. А сегодня экспериментировал и выяснил что ютуб работает без сбоев и грузит видосы быстрее чем реньше, когда ТТЛ2 фиксированно. и отключить md5sig оставив badsum, но badsum можно и убрать в принципе так как ТТЛ 2 совсем мал, но вот если поставить ТТЛ 3 то ютуб начинает работать нестабильно, видосы через одного грузиться а то и вовсе черный экран, обрубаться на пол видео, или не перематываться. Никак не могу понять что они сделали. Но с ТТЛ2 не открывается другой сайт с онлайнкинотеатром. Он открывается если ТТЛ больше 5 ставить. Если ТТЛ авто ставить от 2 до 15 то также ютуб глючит, то открывает видосы то нет. Никак не могу понять что они там сделали у провайдеров? Ведь ГДИ и запред обходит все блокировки? ПРоблема только с ютубом. Такое впечатление что именно сервакам GGC стал не нравится трафик от запрет и ГДПИ? Сам гугл у себя что-то ообновил? И еще заметил что если ТТЛ ставить 2 то видос грузится - с какхикто московкких серваков, если ставишь ТТЛ 3 и более то видео грузится с американских серваков, при том сами эти серваки пингуются но ответа от них нет. PS: Такое впечатление что когда стоит ТТЛ2 фэйк проходит шлюз прова, при том что ДПИ стоит перед шлюзом, а щза шлюзом стоят локальные кеш-серваки гугла, и вот им фейк стал не нравится. и они блокают трафик, несмотря на флаги md5sig, и badsum. Но видимо по пути к онлайнкинотеатру стоит еще один ДПИ который блокает его. Если ТТЛ ставить чтоб трафик дошел до другого ДПИ, тогда локальные серваки гугла блочат соединение к ним. Несмотря на наличие флагов плохого пакета. Что за ??????

Dager26reg commented 1 month ago

Неужели РКН сговорился с гуглом, и они обновили прошивку своих серваков так чтоб те пропускали "битые" пакеты, а соотвественно ПО принимало фейк, и на него реагировало соотвествующим образом? ПРи том что сам ДПИ провайдера трафик пропускает, и нормально "хавает" фейк? У меня другого объяснения этому нет? Почему происходит редирект на америкосовские серваки как только файкпакет проходит шлюз провайдера?

Dager26reg commented 1 month ago

Ну а вообще я за то чтоб ввести возможность добавления индивидуальной настройки стратегий для отдельных доменов. Это сделало бы программу намного гибче и универсальнее, там где не подходит общее правило прописываешь отдельное.

bol-van commented 1 month ago

если фейк доходит до сервера - это конец соединение разрушается мд5сиг заставляет только линух отбрасывать пакеты и не рушить его ттл берется минимальным из максимальных ттл не допустит фейк до большинства, но не всех серверов и он поможет от не линухов потому ттл и мд5сиг полезны вместе

bol-van commented 1 month ago

Ну а вообще я за то чтоб ввести возможность добавления индивидуальной настройки стратегий для отдельных доменов. Это сделало бы программу намного гибче и универсальнее, там где не подходит общее правило прописываешь отдельное.

это есть в плане иногда нужно но меня печалит, что народ вместо чтобы изучить вопрос и написать общую стратегию начнет злоупотреблять и писать разные ттл в разных стратегиях появятся дурные инструкции и советы основанные на копипасте без понимания

Dager26reg commented 1 month ago

В том то и дело что судя по млим исследованиям гугловские ggc стоят очень близко и они со вчерашнего дня стали принимать пакеты с флагами битой секвенции, битой чексуммы или md5 сигнатуры. И соответственно рушится запоос. Единственный шанс чтоб до гугловского кешсервака не дошел фейк. А значит нет возможности задурить дпи стоящие дальше. Конечно есть идея настроить второй демон с другим конфигом с другой стратегией на домены gcc а у первого этот домен исключить. Но пока не хватает мозгов как включить это по цепочке, и возможно ли это вообще?

ptipti23 commented 1 month ago

У меня тоже была такая проблема, что с компьютера видео показывало превосходно, на телефоне тупило. Решилось (лично у меня) добавить правило в nftables, чтобы DNS запросы IPv4 c 53 порта перенаправлялись на 77.88.8.88:1253. После этого и телефон перестал притупливать

Dager26reg commented 1 month ago

Щас у людей тупит видео по другому. Пробовал подбирать ттл без благов чтоб работал ютуб и не тупило видео. Оказалось что достаточно увеличить ттл на 1, видосы открываться пере,тают. Уменьшаешь на 1. Все норм. Уменьшаешь еще на 1, перестают открываться заблокированные сайты в том число главная страница ютуба. При этом смотрю с какого сервака тянется видос - пингую его число хопов где 7 где 9. При этом рабочий ттл 2-3. Если сделать ттл к примеру +1 и добавить любой из флагов неправильной секвенции или чексуммы или мд5 сигнатуры то видосы по прежнему не грузятся. Если убрать ттл вообще и оставить флаги сигнатуры и чексуммы - работают все все сайты кроме видео ютуба. Причем сам сайт суба открывается без проблем. Что говорит о рабочей стратегии ркн но ломаются соединения кешсерверов. Возможно я ошибаюсь но как я понял соединение к сервакам гугла проходят через кешсервер провайдера который стоит прям за шлюзом прова. И этот сервак пропускает битые пакеты. И соединение ломается даже если сам сервер видоса стоит "гдето-там дальше" По идее должно работать автоттл но не работает. Ибо как я понял ответ приходит от дальнего сервака через кешсервер. С большим ттл. Авто выставляет ттл-1 пакет идет на кешсервер и ломает соединение. По другому не могу объяснить поведение. Причем при ттл 3 видос тянется с какогото московского сервака до которого 9 хопов. Но стоит выстать ттл 4 - все. Этот сервак недоступен. Висит таймаут. 🤷‍♂️ причем вылавливал разные серваки. С разными хопами. И все они недоступны при ттл4 и все доступны и отвечают если ттл 3 у фейка.