о замедлении YouTube

Aug 11, 2024 16:32


#блокировкаyoutube #замедлениеработыyoutube #tls #sni #ech

начнем с того что фактически YouTube не замедляли. вернее возможно замедляли, или замедляли поначалу, но это точно было не главное, скорее отвлекающий маневр или просто сначала врубили дорогое оборудование, а сейчас подтянули остальной хлам. но труба работает плохо -  что же происходит? ведь везде используется https т.е. содержимое пакета зашифровано.

а все довольно банально. для установки защищенного соединения клиенту необходимо передать в открытом виде имя домена к которому он обращается - Server Name Indication (SNI). как нетрудно догадаться именно эти пакеты и блокируют для определенных доменов при помощи DPI (может определять пакет по его содержимому). т.е. прям внутри пакета находят имя домена и такой пакет отбрасывается или  поначалу отбрасывался с некой вероятностью. в РКН сделали man DUMMYNET ?

видимо «оживляшки»  YouTube связаны с тем что инженеры гугл что-то подкручивали - изменяли имена доменов, заставляли вести систему нестандартно, иногда помогало простое переключение на hhtp3. сейчас так просто проблему не решить. т.е. простое переключение на TLS 1.3 (Transport Layer Security обеспечивает защищенное соединение) не поможет т.к. имя домена передается в открытом виде.

но, как видите, все просто и  логично т.е. сейчас в большинстве случаев если у вас видео начало воспроизводится, то  неважно в каком разрешении вы его запросили принципиальных тормозов не будет до установки нового соединения т.к. блокируется паркет TLS ClientHello видимо по имени домена googlevideo.com.

как бороться с такой фильтрацией? элементарно свернуть мозги DPI, что не так сложно т.к. система рассчитанная на большой объем трафика интеллектом не блещет. суть состоит в том что надо изголяться над передаваемыми пакетами оставаясь в рамках стандартов, чтобы сервер этот пакет понял. это кстати законно - к поломке оборудования это не приводит и не является каким либо видом VPN.

пусть DPI выделяет в пакете слово «Алиса». как с этим бороться? передать слово «Алиса» в два приема: например сначала «А» а следующим пакетом «лиса». туповатый DPI не поймет где его на...ли.

для windows есть простая программка с говорящим названием GoodbyeDPI которая делает именно это. кроме того мне подсказали еще один проект который делает примерно тоже самое.

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

кстати говоря, вот какое имя я вытащил из перехватчика пакетов на роутере когда все заработало: rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com
странное не имя домена, а имя узла.

еще один способ борьбы могут применить операторы связи: нужно самим ловить ВСЕ TLS-hello и меленько их нарубать. если IPv6 не фильтруется можно транслировать адреса IPv4-IPv6 если РКН отрицает блокировку тогда и взятки гладки: да с TLS проблемы возникли - пофиксили. впрочем проблемы технического характера с фрагментацией могут возникнут, о чем я скажу ниже.

более или менее такой способ: усовершенствовать TLS - зашифровать пакет Hello. серверу нужно знать к какому домену вы обращаетесь и поэтому он обычно передается в открытом виде.

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

преимущество такого способа состоит в том, что он не требует распространять чего-то дополнительного в DNS. тут можно правда сказать что в DNS информация тоже передается в открытом виде. я думаю что можно просто завернуть DNS в TLS RFC 7858 и RFC 8310.

однако сейчас видимо лучше решение нарубить пакеты по буквам т.е. для нашего примера передавать отдельно «А» «л» «и» «с» «а». но  такой трафик впринципе выделить можно по размеру пакета. что отражено в написании слова ВСЕ.

остаётся открытым вопрос почему не блокировать по адресу назначения просто не выпилить сети google из интернета (обход возможен только с помощью того или иного вида VPN). причины я вижу две:

  • не хотят. т.е. на гугл много что завязано.
  • не могут. этот вопрос надо изучать. смысл в том, что IP могут принадлежать не только google. т.е. использоваться «распределенные» системы хостинга. т.е. отключать придется полмира.

стоит заметить, что с программой направленной на поломку DPI некоторые сайты могут перестать работать. это прежде связано с тем насколько качественно реализован ТСP в операционной  системе.

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

пока на IPv6 все работает - этим может объясняться то, что работают некоторые операторы связи или, что более вероятно, просто у некоторых операторов связи есть админы которые не просто так зарплату получают.

еще стоить заметить, что аналог GoodbyeDPI можно запустить на домашнем роутере, решив проблему для всех устройств. спросите у заядлых линуксойдов - скорей всего решение уже есть. плохоя новость состоит в том, что специфичный трафик GoodbyeDPI некоторые операторы связи блокировали, за что потеряли порядка 20% абонентов.

UPDATE

еще очень рекомендую эту статью. суть в том, что зря я гнал на TLS. к TLS 1.3 имеется расширения ESNI (Encrypted Server Name Indication) и ECH (Encrypted Client Hello) последний позволяет шифровать TLS ClientHello.

обязательно настроить настроить DoH (DNS поверх HTTPS), что в современном браузере несложно. ECH шифрует TLS ClientHello ключом который распространяется в DoH (запись HTTPSSVC). теоретически ECH должна обходить любые DPI.

ECH включен по умолчанию в FireFox 119 и выше. я не могу проверить как это работает, но скорей всего вам с последней версией FireFox просто надо настроить DoH. к сожалению не заработать это тоже может - например нет поддержки со стороны сервера и т.п.

у меня в 115 FireFox не заработало, хоть тесты на использование ECH браузер проходит. кстати  чтобы включить в 115 версии FireFox нужно:

в about:config

network.dns.echconfig.enabled
network.dns.http3_echconfig.enabled
security.tls.ech.grease_http3

установить в true

P.S.

я не знаю как GoodbyeDPI с IPv6 работает. на IPv4 это должно работать. единственное, надо заметить, что после 10 сентября некоторые отмечали, что пришлось изменить ключ в сценарии запуска. в РКН доперли отбрасывать пакеты с битыми чексуммами/неправильной последовательнстью?

я вдруг подумал, а может в этом и есть план? согнать всех на IPv6?  а IPv6 легче контролировать,  адресов много и их принадлежность к сервису однозначная. т.е. можно смело блокировать по IP. единственный метод обхода такой блокировки VPN который кстати хотели запретить.

господь всемогущий благослови ПТУшников.

#tls, #замедление, #sni, #замедлениеработыyoutube, #ech, #блокировкаyoutube, Мысли в слух

Previous post Next post
Up