оригинальная статья в моём блоге: о замедлении ютуб
специально для РКН: ссылок на плохие ресурсы и названий вредного ПО в этой статье нет.
если кому-то кажется что НельзяНазвать совершенно не похоже на Dots Per Inch - все совпадения случайны и ответсвенность за них автор не несет.
начнем с того что фактически 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 есть простая программка с говорящим названием GoodbyeНельзяНазвать которая делает именно это.
еще один способ обхода могут применить сами инженеры гугл. нужно добавить такое имя домена которое оборудование DPI не сможет переварить, но скорей всего такие имена из подконтрольных серверов будут выпиливаться да и скорей всего придется идти на нарушение стандартов. или срочно принимать новые, что делает такое решение однозначно временным.
кстати говоря, вот какое имя я вытащил из перехватчика пакетов на роутере когда все заработало: rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com
странное не имя домена, а имя узла.
еще один способ борьбы могут применить операторы связи: нужно самим ловить ВСЕ TLS-hello и меленько их нарубать. если IPv6 не фильтруется можно транслировать адреса IPv4-IPv6 если РКН отрицает блокировку тогда и взятки гладки: да с TLS проблемы возникли — пофиксили. впрочем проблемы технического характера с фрагментацией могут возникнут, о чем я скажу ниже.
более или менее такой способ: усовершенствовать TLS — зашифровать пакет Hello. серверу нужно знать к какому сайту (на одном IP адресе может быть несколько сайтов) вы обращаетесь и поэтому он обычно передается в открытом виде.
значит нужны два сертификата для шифрования «серверный» один для всех сайтов на сервере и «сайтовый». т.е соединение устанавливается с временным серверным сертификатом, который может подписываться адресом сервера и который не нужно удостоверять третей стороне. имя сайта при этом не передается. а уже когда временное шифрованное соединение установлено выдавать «обычный» сайт-специфичный сертификат.
update:
вообще говоря "серверный" сертификат это даже не сертификат а публичный ключ. вообще говоря точно такой же как в ECH.
конечно можно сказать что можно подделать ключ, но это в общем-то "ненастоящий" сертификат и такая подделка вполне допустима. городить проверку аутентичности можно, хотя я и считаю бессмысленно. преимущество же такого подхода, что ключ легко менять достаточно часто.
как используется публичный ключ в ECH:
* в DNS распространяется публичный асимметричный ключ.
* клиент генерирует симметричный ключ, шифрует его открытым асимметричный ключом и отправляет серверу.
* сервер извлекает симметричный ключ используя для расшифровки приватный асимметричный ключ.
таким образом осуществляется обмен симметричными ключами для установки начального шифрованного соединения - почему не защищенного? аутентичность сомнительная. публичный ключ может быть получен кем угодно из DNS или атакой man-in-the-middle в случае моего решения.
тут возникает резонный вопрос зачем так сложно? для того чтобы обеспечить "безопасность в будущем". что бы перехваченные данные носили эфемерный характер (актуальны только для текущей сессии).
преимущество предлагаемого мной алгоритма состоит в том, что он не требует распространять чего-то дополнительного в DNS. тут можно правда сказать что в DNS информация тоже передается в открытом виде. я думаю что можно просто завернуть DNS в TLS RFC 7858 и RFC 8310.
однако сейчас видимо лучше решение нарубить пакеты по буквам т.е. для нашего примера передавать отдельно «А» «л» «и» «с» «а». но такой трафик впринципе выделить можно по размеру пакета. что отражено в написании слова ВСЕ.
остаётся открытым вопрос почему не блокировать по адресу назначения просто не выпилить сети google из интернета (обход возможен только с помощью того или иного вида VPN). причины я вижу две:
- не хотят. т.е. на гугл много что завязано.
- не могут. этот вопрос надо изучать. смысл в том, что IP могут принадлежать не только google. т.е. использоваться «распределенные» системы хостинга. т.е. отключать придется полмира.
стоит заметить, что с программой направленной на поломку DPI некоторые сайты могут перестать работать. это прежде связано с тем насколько качественно реализован ТСP в операционной системе.
кроме того возможен обратный случай, если пакет предварительно собрать, а уж затем подвергнуть фильтрации. хорошая новость состоит в том, что такой способ ресурсоёмкий соответственно возможен только в условиях относительно неинтенсивного трафика.
пока на IPv6 все работает — этим может объясняться то, что работают некоторые операторы связи или, что более вероятно, просто у некоторых операторов связи есть админы которые не просто так зарплату получают.
еще стоить заметить, что аналог GoodbyeНельзяНазвать можно запустить на домашнем роутере, решив проблему для всех устройств. спросите у заядлых линуксойдов — скорей всего решение уже есть. плохоя новость состоит в том, что специфичный трафик GoodbyeНельзяНазвать некоторые операторы связи блокировали, за что потеряли порядка 20% абонентов.
UPDATE
зря я гнал на TLS. к TLS 1.3 имеется расширения ESNI (Encrypted Server Name Indication) и ECH (Encrypted Client Hello) последний позволяет шифровать TLS ClientHello.
обязательно настроить настроить DoH (DNS поверх HTTPS), что в современном браузере несложно. ECH шифрует TLS ClientHello ключом который распространяется в DoH (запись HTTPS). теоретически ECH должна обходить любые DPI. но как нетрудно догадаться это расширение (весь протокол) блокируется, правда такая "блокировка" очень легко обходится
ECH включен по умолчанию в FireFox 119 и выше. с последней версией FireFox просто надо настроить DoH. на данный момент для трубы это не работает - нет поддержки со стороны сервера.
P.S.
я не знаю как GoodbyeНельзяНазвать с IPv6 работает. на IPv4 это должно работать. единственное, надо заметить, что после 10 сентября некоторые отмечали, что пришлось изменить ключ в сценарии запуска. кроме того блокируется все сайты использующее ECH.
я вдруг подумал, а может в этом и есть план? согнать всех на IPv6? а IPv6 легче контролировать, адресов много и их принадлежность к сервису однозначная. т.е. можно смело блокировать по IP. единственный метод обхода такой блокировки VPN который кстати хотели запретить.
господь всемогущий благослови ПТУшников.
P.P.S.
после ~20.12.2024 нужна еще фейковая длина фрагментов. сбылись мрачные прогнозы про фильтрацию по длине пакета. GoodbyeНельзяНазвать работать не будет. отца русской демократии спасает такой скрипт:
> cat /usr/local/etc/rc.d/dvtws
#!/bin/sh
# PROVIDE: dvtws
# REQUIRE: DAEMON
# KEYWORD: shutdown
. /etc/rc.subr
name="dvtws"
rcvar="${name}_enable"
load_rc_config "$name"
command="/usr/local/bin/dvtws"
procname=${command}
pidfile="/var/run/${name}.pid"
command_args="--user=nobody --daemon --pidfile=$pidfile --port=900 --dpi-desync=multisplit --dpi-desync-split-seqovl=652 --dpi-desync-split-pos=2,149,154"
run_rc_command "$1"
публикации по теме:
P.P.P.S.
проблема усугубляется тем, что позорное ведомство пытается блокировать TLS 1.3 и под раздачу попадают многие ресурсы и CDN использующие эту технологию. сейчас практически весь интернет httpS, скоро весь https станет TLS 1.3. подробности читайте в заметке "на какие три буквы идёт РКН". стоит правда заметить что предлагаемое решение может ломать виндовые сайты. к счастью таких сайтов очень мало.
никто за вас ваши проблемы решать не будет.
либо платите за VPN либо продолжайте выть какой РКН плохой.
