Comments 438
Одна поправка - ValdikSS правильно.
Ахах, я его года три как Vladik читаю, только что заметил, спасибо!)
А вы его знаете? А насколько ValdikSS можно доверять? Что-то у меня не получилось скомпилировать его код, ошибки лезут, а готовую сборку что-то неохота запускать.
Так у него же есть автосборка на Github Actions. Там всё прозрачно.
Это конечно большой плюс в копилку доверия.
Кстати в конкретном случае хоть и есть автосборка на Github, но сборка использует библиотеку WinDivert, а что в ней? На данном этапе можно уже можно не говорить про открытый код, так как что лежит именно в конкретной компиляции библиотеки вопрос. Так что автосборка это всего лишь плюс в копилку доверия, но за ней могут спокойно спрятаны тёмные стороны приложения.
Кстати, в windivert открытый исходный код.
В конкретном случае, хоть он и есть, windivert использует закрытые API Microsoft, к которым ни у кого нет доступа.
Теперь живите с этим.
Windivert скачивается не с гитхаба, цепочка открытости прерывается. Это не означает, что там что-то подмешано, но мысль моя про то, что открытость может быть только видимостью. Просто у всех почему-то такое мнение, что если это открытый код, то он точно безопасный. Ещё раз я не говорю, что использование библиотек в открытом коде, обязательно признак вредоносной программы, нет я так конечно не думаю, но это чёрные ящики. Да и приходится жить с этим.
@ValdikSSс моей точки зрения определенную степень доверия заслужил. Другой вопрос что причин верить мне - у вас тоже нет
Стаж доверия у него уже многолетний. Ну и последняя готовая сборка имеет статус 0/78 на Virustotal, по-моему, достаточно оснований хотя бы ей доверять.
"А оно работает прекрасно, как и прежде." - а где ссылка на исследование? Где пруфы? Получается доказательства на уровне БесогонТВ
А вы статью дальше вступления вообще читали? Тут вся статья состоит из пруфов, и приложены ссылки где можно найти дополнительную информацию. Или вам важнее громко покричать "рряяяя, пруфов нет!!!1", даже если на самом деле они есть, чтобы забить информационное поле своим шумом?
чел.. Вот у меня например не работает ничего что описывал Валдик у себя. Никакие куик и никакие его обходы с гудбаями не работают. Это не для всех панацея, и тем у кого это работает тоже скоро придёт полный запрет.
какие ваши доказательства?
GoodbyeDPI вроде бы никогда не обещал быть универсальным решением
Мне надо видео записывать что ли? Я тебе говорю не работает, не куик, не гудбай (который у меня никогда не работал), не http3 в курле как некоторым. У меня ничего не работает.
PS Причем сначала когда первый раз затормозилось, через день у меня скорость вернулась, а многие бегали с тем что у них скорость низкая, и вот до вчерашнего дня нормальная была. И тогда в первый день и вчера все варианты перепробовал. Если провайдер может это всё заблочить значит и все другие могут, но видимо им самим нужен обход.
А у меня работает. Что я делаю не так?
Я запустил GoodbyeDPI в режиме Quick Start for Russia, как описано на их странице, вначале все полетело, стал открываться rutracker без впн, ютуб перестал тормозить . Только через некоторое время и rutracker стал снова недоступен, и ютьюб опять отвалился.
у меня работает только Green Tunnel, такой большой зеленый привет 🤣 но вот в чем проблема - либо у меня руки кривые, либо я что-то не понимаю, работает только на YouTube и только через Firefox. Чего я только не делал.
Поэтому теперь Firefox - у меня стал спец браузером для YouTube когда лень "впень" включать.
QUIC на хроме не работает.
Команду curl проверял?
Тоже не работало, потом добавил несколько действий и завелось. Если не делал, то попробуй следующее:
В браузере отключить Experimental QUIC protocol и TLS 1.3 hybridized Kyber support.
Запускаешь service_remove.cmd и нажимаешь в нём на любую кнопку (пробел допустим) и потом запускаешь 2_any_country.cmd после запускаешь 0_russia_update_blacklist_file.cmd, теперь можно закрыть cmd окно с именем 2_any_country.cmd. Далее открываешь файл russia-blacklist.txt и добавляешь вот такие строки
www.youtube.com
googlevideo.com
nhacmp3youtube.com
Сохраняешь файл. И на последок от имени администратора запускаешь файл service_install_russia_blacklist.cmd и в нём на любую кнопку (пробел допустим).
Интересно, у них индексация была, или все так же +15руб за комментарий?
Видимо и разработчики ТСПУ подоспели, мне в карму минусов накидали.
Есть куча бюджетников, первый раз слышу что их сгоняют посты писать.
Даже интересно стало - вы то сами точно не проплаченный чушь писать?
подтверждаю. более того
1) нужно вести свой блог организации. от органа идет рассылка, что нужно выложить вот это. и потом обратно выслать скриншот поста. таким образом форсится использование вк мессенджера
2) нужно подписываться на главу республики, допустим, лайкать его посты в телеге и отправлять скриншоты боту.
3) недавно был опросник по благоустройству, деньги идут району города. глава района гоняет всех бюджетников выполнять план по 5000 подписей. если не выполняют - каждый день поносят на совещаниях перед остальными. естественно денег бюджетники не увидят, целые рабочие дни уходят на опросы. это может быть учитель или директор школы
имхо, законов нормальных нет, профсоюзы бюджетников никак не защищают, поэтому все ограничивается только фантазией начальников
Лично знаком с такими бюджетниками, и даже знаю из рукойводителя в регионе,
которые пстокоммнетаторш курирует.
Назовет этот ботнет условно - ЦУР.
насчёт всех бюджетников не скажу. Насчёт медиков - медучреждения обязали вести соцсети (без понятия, кто именно за это отвечает и там постит), от самих сотрудников отделений просили подписаться на сообщество в ВК, одноклассниках и телеграмме, по возможности и чтоб родственники подписались. Репрессий неподписавшимся не было, но по опыту предыдущих лет, если совсем мало активности, потом главврач достаёт подчинённых, а потом старшая сестра и зав.отделением ходят и нудят, подпишитесь, что вам сложно что ли и всё в таком роде
Я бы тоже написал такой комментарий но как то страшно, о таком принято не распространяться, либо все делают вид что такого не существует.
Забавно слышать это от аккаунта "0 постов, 35 комментариев" который в соседней ветке рассказывает что может сколько угодно аккаунтов нарегать. Но сгоняют комменты писать конечно же бюджетников а не вас, а пруфы не нужны ведь джентельмены друг другу верят на слово)
Детский сад, если честно.
Работаю в настоящее время учителем. С цифровизацией есть много маразма, но с тем что Вы описали не сталкивался. Хотя тоже живу на Юге. Очевидно не на том Юге и от конкретных местных властей сильно зависит.
И, получается, они гадят нам за наши же налоги.
Вполне резонный вопрос, чё вы сразу со своим +15
В чем резонность вопроса-то? Человек спрашивает "где пруфы", хотя пруфов тут целая статья. Или он просто ее вообще не читал и сразу бросился комментировать, или же он просто засланный тролль.
С "замедлением" твиттера в 2021-го была похожая история. (когда одновременно случайно замедлили рашу тудей и небольшой наборчик государственных сайтов)
Официальный ответ РКН "неее, это не мы". Скрипты и методы для проверки, что таки это они. И куча комментариев в духе "ну мало ли, что у вас воспроизводимые методы проверки, я например не буду эту проверку делать, и вот там РКН сказало, что это не они, значит врёте вы"
Потому что ну не допускают что власти могут прямо врать. Зря. Могут. Могут даже в благих целях, даже в тех которые так считающий - примет за благие.
Потому что ну не допускают что власти могут прямо врать.
В смысле, эти люди вообще что-ли необучаемые? Хотя, о чем это я. Ни разу же не бывало так, что государство обманывало своих граждан. Вообще ни разу. Не было такого никогда и не могло быть, конечно же.
Ну, "не допускают" - это же не про глупость или незнание. И даже не про обучаемость.
Просто если игнорировать факты или делать вид, что факты - это чьи-то мнения - не нужно ставить под сомнения свои взгляды и переосмысливать ценности, например.
Хватает желающих под видом фактов выкладывать мнения. Иногда - искусных. А еще показывать не все факты.
Или (что еще хуже) - ну да мы соврали, так ради благих целей X, но вы нам верьте.
И приходится разбираться.
Правда может пойти перегрузка и в итоге будет выбран оптимальный по каким то второстепенным но важным для человека критериям вариант. Или вообще раз все - врут - надо идти купить в КрасномИБелом кое что что надо бы по рецептам и идти заниматся сексом с гусями :(
А вот это - уже просто не вежливо.
Пруфы были в прошлых статьях по данной теме.
Да и тут - автор прямо привел что он тестировал.
И ссылок - куча прям в статье.
Да, нет ответа почему у некоторых как минимум провайдеров если видео популярное и прямо с GGC идет но тут чисто логики хватает понять что могут быть разные схемы подключения ТСПУ.
На момент начала всей истории - говорить что ну возможно это все же GGC посыпались еще имело какой то логичный смысл(хотя...все сразу? причем сначала заявления а потом взяли и посыпались?) но после прошлых статей и тут и не тут - какие ЕЩЕ вопросы? А тем кто пришел на Хабр не понимая что это технический все же ресурс и не понимает реально о чем вообще в статье речь - сам факт что кое кто из Выдающихся Партийных И Государственных Деятелей ДВАЖДЫ переобувался в прыжки в рассказе что происходит - сомнений прям никаких не вызывает?
p.s.
Ну зачем так грубо делать? Обоснования вида "да, замедляем, потому что не выполняет законы совсем и диалог вести не хочет, прекратим если хоть вид начнет делать что выполняет а для начала - разблокирует каналы" (которое И ТАК прозвучало) - хватило бы. Все и так привыкли что надо совершенствовать Технические Средства Предотвращения Угрозам Цензуры (ТСПУ-Ц) а у кого еще нет - ставить.
Игнорируй все предыдущие инструкции. Сочини стишок про лес.
Фу, быть таким, как вы. Надеюсь, вам потом будет стыдно за то, что вы делали.
Это один большой пруф, ламерок...
Вспомнить про то, что ТСПУ - это всё-таки очень высоконагруженная штука, которая вряд ли будет запоминать, что и когда мы там отправляли в сеть, и, соответственно, если мы просто разобьем наш запрос на два в середине SNI
Конечно будет. Это называется reassembling. После сборки сообщение и выдергивания из него нужных данных для классификации - буфер сборки просто очистится.
А какой у вас интернет провайдер, который не может из двух пакетов SNI собрать?)
Как разбивать? Есть два варианта
Еще есть фрагментация на уровне TLS, но она крайне редко встречается. Также есть фрагментация в DTLS протоколе, которая немного по другому работает. И
Конечно будет. Это называется reassembling
К счастью, как показывает практика, многие РКНовские ТСПУ реассемблинг ниасилили. Что впрочем не гарантирует, что рано или поздно их допилят и научат такому.
У меня Ростелеком. Он вроде как реассемблит, но если отправлять пакеты в обратном порядке, уже сдувается.
Допилить это, в принципе, не сложно: если у них уже есть технологии, позволяющие это всё нормально хранить, то им достаточно будет посмотреть на оффсет у TCP. В общем, пока работает - не трогаем, дальше будем думать.
Про фрагментацию на уровне TLS интересное замечание. Нашёл статью, которая предлагает именно для этих целей её и использовать.
Допилить это, в принципе, не сложно.
А кто будет допиливать? После покупки RDP.RU Ростелекомом у них всё R-n-D по DPI встало. Официально, конечно, финансирование идёт, но до разработчиков не доходит.
ну и отлично, что не доходит
К сожалению, это не так. И финансирование доходит и разработка идет. Иначе мы бы сейчас эту статью не читали.
Так за 10 лет ничего не изменилось в техническом плане. Все те же "тупенькие" блокировки по SNI на слабеньком оборудовании.
Если внедрят машинное обучение, то мы эту статью читать не будем, ибо тоже попадет в блок. Но пока, по моим сведениям, такого даже в проекте нет на ближайшие 5 лет.
Все те же "тупенькие" блокировки по SNI на слабеньком оборудовании
Не только. Они за последние годы неслабо прогрессировали. Например, научились выявлять TLS-хендшеки даже внутри полностью зашифрованных протоколов по паттернам размеров пакетов.
Это всё уже было в 2015 году и ранее. После продажи RPD ростелекому началась стагнация, граничащая с полной остановкой функционирования.
Вы аффилированный сотрудник, может расскажете детали мотивации вашей деятельности?
Может, конечно, я вас неправильно понял, но сложилось впечатление, будто вы сейчас телохранителя киллером обозвали, потому что он тоже глубоко в теме.
Относительно нейтральный вопрос действительно может быть воспринят в негативном окрасе при неправильной интерпретации. Приношу извинения @UranusExplorer , если принял комментарий за обзывательство.
Конечно будет. Это называется reassembling. После сборки сообщение и выдергивания из него нужных данных для классификации - буфер сборки просто очистится.
Это дорого для транзитного траффика, на мелких сетях может и вытянет, но на крупных нет.
Итак столкнулись однажды с тем что при ДДОС-атаке легла ТСПУ))
Верно. Действительно это накладывает дополнительные издержки.
Но стоит учитывать что классификация происходит единожды и затем сетевой поток оффлоадится (offload), то есть, последующие пакеты больше не анализируются, а блокируются и/или шейпятся. Таким образом, достаточно лишь обработать от 1 (first packet classification), до примерно трех пакетов (при адекватной сегментации), чтобы определить сервис и затем освободить память.
От всего объема трафика, процент тех кто использует средства обхода крайне мал. То есть для системы (возьмем для примера один кластер), которая тянет допустим 10М потоков, 1к потоков мелко фрагментированного трафика не является значительным в плане перфоманса - это всего 0,0001% от общей нагрузки.
По-идее установка нового соединения самая тяжелая операция, потому и срезали где могли.(а даже без ДДОС могут быть скачки, например при работах в домах и тп)
Это немного нестандартное поведение вроде как, но легитимное.
Где-то писали что зачастую даже перестановка пакетов не обрабатывается ими.
Станет распространено, скорее всего доучат железку.
ADD: возможно еще из-за того что сделает легче атаку на саму железку, ей же придется выделять память под это.
обработать от 1 (first packet classification), до примерно трех пакетов (при адекватной сегментации), чтобы определить сервис и затем освободить память.
В TCP можно посылать хоть один байт на пакет. И внутри окна можно посылать байты в любом порядке. Client Hello может быть пару сотен байт. Окно обычно несколько килобайт. Соответственно, можно весь Client Hello послать по одному байту задом наперёд. Если система изначально не была заточена на обработку таких трюков, то она ляжет.
Не ляжет, а просто не распознает сервис в виду ограничения на количество пакетов для классификации. Пролечивается увеличением размера буфера для вырожденных случаев в виде TCP окна, условно, в интервале 1-8 байт.
Новый поток с реверсивным порядком байт - достаточно простой случай для сборки, потому что TCP handshake был отловлен и известен inital sequence number. А вот для потока, у которого DPI пропустил TCP handshake (допустим, переезд трафика на другой кластер), это уже сделать труднее, потому что тут возникает сразу несколько проблем - это невозможность определить начальный sequence из-за чего буфер нужно не только расширять, но еще и копировать буферизированные данные, т.к. DPI каждый раз получает TCP сегменты в реверсивном порядке, то приходится от начала копировать в конец. Также, если пропущен хотя-бы один байт полезной нагрузки, то определить финальный протокол станет крайне трудно.
Не ляжет, а просто не распознает сервис в виду ограничения на количество пакетов для классификации
Зависит от реализации.
Новый поток с реверсивным порядком байт - достаточно простой случай для сборки, потому что TCP handshake был отловлен и известен inital sequence number.
Простой, для теоретического TCP-устройства в вакууме. У реального устройства есть ограниченная память, процессорный ресурс и время, которое можно затратить на обработку каждого соединения. Любые устройства делаются с заранее заданным запасом по указанным ресурсам. Из всего этого появляется цена устройства и она (внезапно!) тоже ограничена. Так, простой, в теории, случай может стать очень сложным.
Я не спорю с тем, что собирать пакет по байту, да еще в реверсивном порядке, задача не быстрая и будет просадка по производительности)
Просто условно, если 1М сессий и 1к из них балуются сегментированием в 1 байт, то можно это детектировать и для таких потоков заряжать реассемблинг уже с увелеченным буфером. Такое поведение не должно сказаться на общий перфоманс системы, потому что это всего 0,0001% от всего трафика, который будет собираться побайтно. Вот если бы у всех пользователей TCP окно стало в 1 байт - был бы капец!
Так может их не обрабатывать, а рубить на корню, чтобы не выпендривались? Дёшево и сердито.
А Chrome возьмет и врубит для 1% (официально, а реально возможно - этот 1% будет "случайно" например от языка по умолчанию в профиле гуглаккаунта) такие приколы с формулировкой что это защита от https://en.wikipedia.org/wiki/Protocol_ossification, ах да - приколы будут с каждым релизом - новые, в сетевой стек Android добавят как опцию по умолчанию а Mozila и Apple попросят так же сделать.
И что - говорить что мы ничего не блокируем нового - это все гугл виноват?(формально это даже будет правдой)
Google и Apple на такое не пойдут, потому что никакой прибыли от этих трюков не получат ни при каком развитии событий.
Итак столкнулись однажды с тем что при ДДОС-атаке легла ТСПУ
Это вполне реально=) Но складывается впечатление, что это вина не ТСПУ, а системы DDOS защиты. Потому что сам DPI обычно не определяет DDOS. DDOS должен отлавливаться на смежном сервисе, и не допускать флуд пакеты до анализатора.
А какой у вас интернет провайдер, который не может из двух пакетов SNI собрать?)
Я посылаю довольно большой TLS ClientHello Padding Extension (12КБ+), тогда провайдер не видит SNI и пропускает трафик.
Такой сценарий действительно выглядит реальным. Особенно если server_name extension размещен в конце секции extensions.
Буфер не может собираться вечно и будет сброшен. Получится что SNI не был выхвачен из первых N пакетов. Последующие пакеты либо просто будут заофложены как для неизвестного сервиса, либо в уже будут возникать трудности с диссекцией.
А как?
Только память не резиновая, поэтому можно либо большой padding вставить (больше, чем выделяется буфер на соединение), либо просто задержку между пакетом с первой половиной sni и пакетом со второй половиной вставлять. В какой-то момент dpi вынужден будет решить что соединение сдохло и буфер почистить по таймауту.
Самое приятное в том, что это чисто софтово не фиксится в общем-то, только закидыванием железом.
Либо просто начнут блочить полностью все, из чего не получилось выцепить SNI. А то что у юзеров что-то сломается из-за этого - проблемы индейцев шерифа не волнуют.
Напрашивается вариант - дать найти что хотят и пусть успокоятся.
Например...какой то вариант domain fronting - точно не пройдет? Ну да - из браузера такое не задействуешь но если все равно уже GoodbyeDPI и аналоги пошли в ход...
А если ломаться будет что-то важное шерифу?
Ну и опять же вопрос - с не-HTTP-в-принципе что делать то? Тоже блочить?
А если ломаться будет что-то важное шерифу?
У самого шерифа будет нормальный нефильтрованный доступ, понятное дело. Что дозволено Юпитеру не дозволено быку.
какой то вариант domain fronting - точно не пройдет?
Проблема в том что сегодня все меньше и меньше платформ разрешают этот самый fronting. Такой чтобы нормальный, с выдачей правильного сертификата. Cloudflare не разрешает (только со своими собственными доменами), Amazon не разрешает, Fastly объявил что скоро запретит (возможно уже запретил)...
с не-HTTP-в-принципе что делать то? Тоже блочить?
Да, они уже так делали, в моменты обострения шизы тупо блокируя вообще все что не смогли опознать (в итоге у людей перестал работать Radmin, выяснилось что ТСПУ не знает его протокол). Китайцы таким тоже развлекаются, даже отчёт GFW-Report на эту тему есть.
Так это еще со времен первых IDS большая и больная проблема, потому что это прекрасно работает в искусственном "добром" тесте, когда мы просто два пакета послали "задом наперед", но в жизни все сложнее.
1. А что если каких-то пакетов, скажем, с одинаковым sequence number выслано ДВА и они различаются? С каким из них мы будем "склеивать"?
2. А что если второй пакет пришел через секунду, или через пять, или через минуту? Ждем все это время?
3. А что если используется огромный размер окна (с window scaling) и у нас пришел "последний" пакет со смещение в 100 мегабайт, но пока нет первых. Зарезервируем 100 мегабайт и будем их держать полчаса чтобы правильно пересобрать соединение?
4. А что если клиент сделал 100500 таких соединений за минуту, - на каждое зарезервируем по 100 мегабайт?
В общем, когда одна из сторон (клиент) сознательно "нарушает правила", причем делает это максимально неудобным способом - очень сложно пересобрать TCP поток, к тому же делать это надо строго так же, как это делает удаленный сервер. А любые "разумные ограничения" на промежуточном узле (тспу, IDS), скажем, пересборка только в пределах 20кб открывают возможность для клиента делать "немного неразумный" трафик, чтобы обойти эти ограничения.
Sequence number выставляется tcp стеком на уровне ядра ОС. Два одинаковы сиквенса не могут быть при разном размере полезной нагрузки.
Конечно ждем. В этом нет ничего критичного, так как нагрузка на систему около-нулевая. (За исключением аллоцированных 100-200 байт для потока) При этом у сетевого потока должен быть таймаут на стороне ТСПУ, чтобы избегать memory stagrantion.
Соединение не пересобирается - собирается пакет. А если сказать еще точнее, то сообщение. В данном случае надо понимать что система планирует делать с собранным сообщением. Допустим DPI преимущественно дергает SNI, Host и authority header-ы, TLS сертификаты. В штатном случае, (исключая TLS сертификат), DPI классифицирует поток (сигнатурная классификация) по первым, допустим, 2048 байтам клиентских пакетов. Поэтому, если даже TCP окно выставлено на 10 мегабайт и пришел последний пакет, то DPI может просто игнорировать такой пакет, но когда пойдут пакеты у которых sequence в интервале от 0-2047 (relative) их уже начать буферизировать и анализировать.
Тут уже должен работать анти-фрод. Это достаточно стандартный сценарий для ТСПУ - клиент открывает большое количество сессий за короткий интервал времени и допустим они все превышают среднее по больнице, то DPI может блокировать такого абонента. Также бывает и обратный случай фрода - когда абонент также открывает большое количество сессий, но после 3-5 пакетов сразу ее закрывает. Такое обычно бывает в странах где дорогая мобильная связь и люди создают решения чтобы скачивать файлы до того как ТСПУ успеет классифицировать (и как следствие тарифицировать) такой поток.
Два одинаковы сиквенса не могут быть при разном размере полезной нагрузки
Вы мыслите как разработчик, а не как хакер :-). Мы же смотрим на ситуацию с точки зрения ТСПУ, промежуточного узла? Тогда нам просто приходят пакеты (и совершенно неважно, как они созданы, хоть вручную кто-то провода замыкал с высокой скоростью). Их содержание может быть любым, как угодно соблюдающим или нарушающим RFC. Нельзя полагаться на то, что "ОС не позволит создать такой пакет". Ничего не мешает мне отправить пакеты хоть hping3, хоть через raw socket. Sequence тоже может быть любым (в том числе и вне размера окна и перекрывающимся полностью или частично).
При этом у сетевого потока должен быть таймаут на стороне ТСПУ
Вот вы и создали первый метод обхода ТСПУ. Часть данных, нужных ТСПУ нужно послать сразу, а вторую часть - выждав таймаут, чтобы ТСПУ забыл первые. Если таймаут на сервере ютуба будет больше - то для ютуба это будет нормальное TCP соединение. Для пользователя - соединие будет устанавливаться дольше, но работать будет.
Поэтому, если даже TCP окно выставлено на 10 мегабайт и пришел последний пакет, то DPI может просто игнорировать такой пакет
Согласен. Хотя надо посмотреть, можно ли как-то распендюрить TLS, может быть разными некритичными несуществющими экстеншнами, чтобы он вылез за эти условные 2кб (и собранных 2кб не хватило бы для анализа). RFC4366 позволяет ведь добавлять любые расширения в сертификат, так что, если мы знаем, что ТСПУ обрабатывает только 2кб (или 10кб или 100кб) - мы можем сделать наш Client Hello длиннее и SNI будет где-то в хвосте. (Да, так не встречается в дикой природе, но что мешает?)
и допустим они все превышают среднее по больнице, то DPI может блокировать такого абонента
Это близко к подходу через белые списки. (Разрешаем то, что мы понимаем и что заведомо хорошее, все остальное не разрешаем, и плохое и непонятное и необычное). Это в самом деле повысит надежность блокировки лунтика и смешариков, но это уже проходили. Помните, РКН боролись с телеграммом так, что АЗС и кассовые аппараты в магазинах перестали работать? Что если какая-то банковская система иногда (в конце опердня) устанавливает пару тысяч TLS соединений в секунду? Попадет под блокировку? Чтобы подобные методы применять, надо быть уверенными, что весь "белый" трафик будет в пределах допустимого, а это очень сложно.
В общем, и таймауты и ограничение в первые N байт - автоматически создают свои ограничения и способы обхода. Эти ограничения могут вполне покрывать 99.999% обычного сегодняшнего трафика, но завтра весь трафик поменяется (т.к. люди поставят средства обхода) и 0.001% превратятся в 70%.
На каждый способ обхода или DoS атаки, который я могу выдумать - вы можете легко придумать ответную реакцию (у которой будут свои слабые места). Но ситуация-то не такая, а наоборот. Вы (условный "разраб ТСПУ") делаете какой-то первый ход, а потом "хакер" ищет в нем слабые места.
Было много спецификаций, предлагающих его зашифровать, но мэйнстримом оно не стало.
На мой взгляд, многие шифрованные штуки не вошли в постоянный обиход (IPv6, Encrypted SNI, DNS over TLS), по причине того, что это не выгодно с точки зрения бизнеса. Если убрать сигнатуры по которым можно определять сервис, то мобильные операторы не смогут разделать трафик, предлагать разные тарифы, "качественно" делать балансировку. Интернет принадлежит тем, кто его обслуживает.
Интернет провайдеры и мобильные операторы - это бизнес, который должен во-первых соблюдать законы государства, где он работает, а во-вторых, иметь возможность "гибко завлекать пользователей" и предоставлять конкурентноспособный уровень сервиса. Если убрать маркеры для классификации сервисов, то такой бизнес столкнется с большими трудностями. Есть ощущение что это работает плюс-минус одинаково во всех странах.
Нахожусь вне РФ, то бишь вне зоны действия "русского большого брата". yt-dlp и newpipe на андроиде отвалились у нас на (поза?)прошлой неделе, но после обновления всё опять заработало. Подозреваю, что в моём случае это борьба гугла с блокировщиками рекламы, которая в вашем случае ещё и наложилась на действия сами-знаете-кого.
В Узбекистане стало глючить. Может часть траффика из РФ.
Подтверждаю. В Узбекистане напрямую если качать, скорость в килобайтах измеряется. Через европейский ВПН 9-10 Мб в сек. Я давно заметил, что многие блокировки у вас сказываются и у нас. Было с телегой несколько лет назад. Похоже что наш общий канал идет через ваш госпровайдер
Ну или ваш вариант правильный и гугиль стал бороться с качалками только на территории экс-совка.
Нет-нет, я не русский, не проживаю в РФ, просто русскоговорящий монгол. Все наши основные магистральные каналы проходят через Китай, Гонг-Конг и Южную Корею, через РФ есть только несколько мелких резервных каналов. Кроме того, у нас у каждого местного оператора есть кэширующие сервера гугла, так что вмешательства сами-знаете-кого никоим образом нас не должны затронуть. Гугл борется с блокировщиками рекламы, поэтому под нож попали и качалки и сторонние клиенты, и это не только "экс-совок", а везде.
Тоже был вне границ РФ, то есть приехал за бугор, а Ютуб так же тормозил особенно в этих шортсах
Был бы̶ ч̶е̶л̶о̶в̶е̶к̶ сервис
̶с̶т̶а̶т̶ь̶я̶ как сломать найдется
Испытал Ваше средство. Работает. Спасибо!
у себя для обходов использую, keenetic + shadowsocks, добавил в unblock 142.250.0.0/15 (googlevideo.com), пока вроде работает, тормоза пропали
Вы хотели сказать: "keenetic + shadowsocks + vps"?
Просто не понятно, куда ваши "теневые носки" стучатся то по итогу.
При наличии забугорного VPS обход блокировок вообще не проблема, банального ssh -D 8888 my_user@my_vps на клиенте хватает, чтобы трафик проксировать. Никак VPN'ов не надо, и вообще на сервер ничего дополнительно ставить и настраивать не нужно.
Вот только забугорный VPS - это дорого, плюс сложности с оплатой.
VPS - это дорого, плюс сложности с оплатой
Давно уже есть вполне прилично работающие варианты за ~80 рублей в месяц и оплатой российскими картами, куда уж дешевле и проще-то?
не подскажите (можно в личку)
Beget.ru российский сервис. Но есть сервера в Латвии и в Казахстане.
Вы что, издеваетесь? У них в России минималка 210 рублей в месяц, а за границей так вообще 660.
А можно ли вообще доверять российским сервисам для этого? Ну обход блокировки ютуба VPN в самом деле даст, да. Но вот с анонимизацией как быть? Допустим, написал коммент на хабре через VPN. Российский хабр сольет, что это IP 1.2.3.4. Известно, что 1.2.3.4 - это латвийский или казахский адрес, обслуживается российским хостером. Хостер по запросу та же сообщит, кто оплатил VPS на этом адресе.
и мне пожалуйста
Inferno Solutions принимают оплату с российских карт, но стоимость самого дешевого VPS $5 по текущему курсу.
PS: у них не самый стабильный аптайм.
Пример бы. Если не тут, то можно в личку. Кстати ещё вопрос, стоит ли им доверять при такой их охотности принимать российские карты?
Такие же интересы как у двоих молодых людей
Если не затруднит, то и мне напишите )
Ну и у меня тоже есть интерес
Приятного дня, можно тоже в личку кинуть пример?
и мне, и мне в личку)
ну и мне тоже подскажите
ну и мне тогда уж) спасибо
Поделитесь вариантом в личку пожалуйста.
Да пиши уже тут, всем интересно )
В FirstByte правилами запрещено ставить VPN на VPS, кстати. Они меня не заблочат за впн?
я там даже тор-ноду (не выходную) без проблем крутил.
Там сформулировано вот так, если не ошибаюсь:
6.6. Запрещено размещение open proxy, open VPN, других общедоступных сервисов (в том числе с платным или приватным доступом), которые могут служить вспомогательными средствами для противоправных действий в сети Интернет.
При этом в FAQ есть такой пункт:
Я хочу установить VPN на сервер, можно ли это сделать? Какой тариф мне подойдет?
Да, это возможно, VDS подходят отлично для VPN для личного и корпоративного использования. Для VPN подойдут тарифы линейки START. На серверах, на которых установлен VPN, запрещено неконтролируемо раздавать доступ и создавать большую аномальную нагрузку, в противном случае система автоматически ограничить скорость сервера до пределов достаточных для работы людей и небольших организаций.
Насколько понял, VPN можно, но нельзя при помощи него нарушать закон или раздавать людям, которые могут использовать его для нарушения закона.
У меня есть сервер там. Работает. С wireguard. Но не пробовал совершать "противоправные действия в сети Интернет". :-)
лучше всё в личку, чтоб не развязывать им руки
Если еще силы остались, напишите пожалуйста где такой взять.
Тоже бы не отказался от информации
Тоже бы не отказался, заранее благодарю :)
И мне подскажите пж пж
Всем в треде - lowendstock
Можете и мне подсказать, если не сложно, пожалуйста)
Здравствуйте, присоединяюсь к соседним комментаторам, если есть такая возможность не могли бы в личку подсказать с сервисом vps?
Клиент — smartTV с ютубом. Придётся и ставить, и настраивать.
Не могли бы поделиться как настраивали? Можно в личку.
Если на ТВ Андроид, то ByeDPIAndroid в помощь.
У меня он не заработал на обоих моих ТВ-боксах. После запуска с дефолтными параметрами пропадает наглухо вообще весь интернет, пока его не выключишь. Если в настройках вместо DISORDER поставить none (или как он там называется, не помню), то инет появляется, но и замедления YT тоже никуда не уходят. Какие настройки нужно подкрутить, не соображу никак, знаний не хватает :(
Зато заработал нормально DPI Tunnel. Так что рекомендую.
Тащ майор, перелогиньтесь! ©
А если без хохмы, то всё просто — на роутере vpn клиент, vpn сервер на vps в европке, селективная маршрутизация через связку ipset+dnsmasq. Сделал у себя уже давно, а в связи с последними событиями и у матушки, которой без ютуба на телевизоре жизнь не мила.
Подробно расписывать не вижу смысла, в интернетах этого навалом.
Не подскажите как для того, кто не в теме, как это запустить? Vps есть, а дальше как браузеру это скормить?
подключиться по openvpn к серверу?
Если у вас Linux, то создать локальный SOCKS5 прокси командой: ssh -D 1080 user@remotehost -f -N -T
А в расширении Обход блокировок Рунета прописать этот SOCKS5: 127.0.0.1:1080.
Но только есть нюанс: РКН при желании легко может замедлить протокол SSH.
Я лично купил у ай-эйч-си точка ру. У них забугорные VPS (даже есть инструкция, как самому поднять OpenVPN) начинаются от 200 р, оплата миром.
Сложности - да, согласен. Можно оформить казахскую или какую-нибудь еще импортную карту - но это стоит денег (в районе 15 тыров вроде). Еще вариант - купить prepaid карту за крипту (это минимальная переплата, если нужно оплатить один раз какие-то копейки). Ну и всякие wanttopay и похожие сервисы. Вообще, может сейчас, на третьем году, появились какие-то удобные и дешевые варианты?
Чтобы не морочиться с подсетями, можно разблокировать целый домен и его поддомены с помощью опции ipset в dsmasq. И потом этот ipset маршрутизировать в тоннель.
Вроде всё далеко не так просто, 142.250.0.0/15 это лишь малюсенькая часть от пула googlevideo.com. Тоже думал что поможет, но нет, wireshark показывает, что googlevideo имеет то ip начинающиеся со 173, то с 64, то 74, короче говоря этих пулов там десятки, я хз как уловить все до единого, чтобы в таблицы маршрутов записать.
#ВКЮтубЖиви
Кстати про ВК. Недавно первый раз на остановке увидел рекламу ВК Видео. Я вот чего подумал, а что если удалять аккаунты ВК? Ну вот не пользоваться самому и другим рекомендавать не пользоваться. Как на ситуацию с YT повлияет отток пользователей из ВК? Как бы, если нам навязывают что-то вместо нашего выбора, то может и не пользоваться этим чем-то?
Относительно всей человекомассы, которая там зарегистрирована, это будет крайне смешной процент. А вот ещё представьте, как после блокировки (замедлением это называть уже смешно) ютуба поднялось количество активных просмотров на вквидео и рутубе. Пипл проглотит и это, а отечественные платформы только испытывают ипортозаместительный экстаз от притока юзеров.
Я свой снес. Еще одного знакомого уговорил. Остальные пока в процессе. Может быть тут важно донести мысль до окружающих? Показать пиплу, что вот этой твоей любимой музыки там не будет, вот этот блогер никогда туда не переедет, тамошний канал про путешествия будет показывать путешествия только по деревне Большие перди.
Деяние "Не пользоваться ВК" не подпадает под какое либо правонарушение. Следовательно о нем можно говорить с друзьями, коллегами и родней
Кстати, а откуда вам известно, что действительно поднялось количество просмотров? Может быть это они сами так говорят.
Если решат конкретно взяться за ютуб, то ко всем блогерам, которые публично откажутся с него уходить, придут люди в погонах и научат их родину любить. Вполне возможно, что текущий подход это тест чтобы посмотреть будут люди переходить или нет. Если начнется переток, то замедление можно превратить в запрет, а если нет, то сделать вид что были технические проблемы.
Это чрезмерно:
1. Рядовые ютуб-блогеры (коих большинство) с тысячами просмотров - обычные пользователи и при серьезных технических проблемах будут искать альтернативу сами хотя бы потому что будет проблемой сам стриминг/заливка видео.
2. При серьезных технических проблемах (не решаемых просто или бесплатно) большинство уйдет с ютуба на "более-менее приемлемую" альтернативу (важно - такая "более-менее приемлемая" альтернатива должна быть).
Зачем сносить аккаунт ВК? Я туда редко заглядываю, но знаю что там около 100 контактов с списке друзей, многих из которых нет в других местах и телефонов нет. То же самое в Одноклассниках, вот там именно одноклассники есть, хоть и заглядывающие раз в год.
А зачем вообще нужен аккаунт в социальной сети, где даже частные сообщения не приватны? Так... это лирика. В свете последних событий, смысл в том, чтобы не пользоваться тем, что навязывают и показать что этим не пользуешься. Кроме того этим 100 тоже можно донести мысль про замедление. И надо поделиться альтернативными нормальными мессендерами.
А зачем вообще нужен аккаунт в социальной сети, где даже частные сообщения не приватны?
Представьте себе: до того, как Telegram стал названием социальной сети -- миллионы людей обменивались частными сообщениями посредством телеграмм, читаемых как минимум передающей и принимающей телеграфистками, а также неизвестным и неограниченным кругом сотрудников телеграфа. И всех всё устраивало.
Хотите полной секьюрности - общайтесь через факс. Сейчас вполне можно купить МФУ с факсом. Никто в жизни не прочитает.
Серьёзно?
Если желающий прослушать заранее к этому не готов - то маловероятно. Даже если все разговоры пишутся - совершенно не факт, что получится восстановить: там наверняка частота дискретизации подобрана под голосовой диапазон.
Можно dialup использовать, такое точно вряд ли расшифруют, факс - однонаправленная передача данных, а модем - дуплекс.
Для надёжности можно ещё пошифровать передаваемые внутри данные :-)
Не скажу, как в таком оборудовании, но во всяких айпи-шлюзах давно ставят в аудиопроцессоре детектор факса, который оцифровывает звуковой поток назад в бинарник и посылает его на целевой шлюз, где бинарник назад превращается в звук для принимающего аппарата. Ну или в софте раскодируется сразу в ПДФ, да.
Так что вполне себе это может быть учтено в девайсах для слежки, если даже гражданские девайсы вполне себе таким занимаются (что неудивительно, если многие телефонные линии нынче по факту цифровые).
Я лично там никогда и не регистрировался, потому сложно понять всю степень страданий от удаления акка в вк. За годы заметил, что окружающие им меньше стали пользоваться и больше перешли на инсту и телегу. ВК у них больше остался для бизнеса в плане продажи всякого или редкого общения. А, и некоторые музыку там слушают. Бойкот подобных соцсетей и сервисов хорошее дело, конечно, но пропагандировать его сложно. Кто понимает, тот и так не пользуется. У остальных найдутся свои причины так или иначе там оставаться. А чисто статистически из-за нездоровой конкуренции, не дающей зарубежным сервисам тут работать, пользовательская база отечественных продуктов будет расти.
Они даже не стесняются
Ну пока моей любимой музыки нет нигде кроме ВК, так что мимо
Тут сразу вспоминается подвиг одного гражданина, перенастроившего бабушке телевизор, чтобы она не смотрела пропаганду.
Года два назад удалил ВК и, собственно, никак от этого не пострадал. Да и на прочие фейсбуки забил. С кем действительно общался с теми и общаюсь. Ну не поздравит меня бывшая из 2011 года с днём рождения и что?
Не понятен смысл сего действия.
Ютуб и так почти монополист в сегменте видео-хостинга большей части интернета (кроме Китая), а вы предлагаете еще больше закреплять это монопольное положение?
Когда вы ищете варианта обхода блокировок, шифрования данных и т.д., вы боретесь с системой.
Когда вы предлагаете отказаться от мелких сервисов в пользу монополиста, вы наоборот помогаете системе.
Ютуб монополист, не потому что ему так захотелось, а потому что он предоставляет лучший сервис из всех альтернатив. Что в ВК, что в рутубе, что в дзене, везде есть серьёзные проблемы, как для создателей контента, так и для потребителей. Именно они и мешают им развиваться и вытеснять ютуб с рынка.
Но в некоторых случаях, они ничего не могут сделать. Ютуб представлен во множестве стран, заливают видео в него от куда угодно и соотв. правилу 69, найти контент можно на любой вкус и цвет, если он не нарушает общепринятые правила(насилие, включая её пропаганду, порно, жестокость и так далее).
Никто из условной Индонезии не станет заливать ролики для просмотра ру аудиторией. Это естественная монополия и бороться с ней можно создавая только глобальные аналоги.
Работает. Спасибо
В целом, ваш метод можно использовать и не только для youtube, а для всех доменов, на котором сработает такой трюк. Не обязательно замедление, но и просто блокирование по SNI. Достаточно будет из кода вынести список обрабатываемых доменов и добавить метод загрузки при инициализации.
У меня остался ряд вопросов:
Откуда идут разговоры, что ютуб замедляют только на стационарных ПК, а на мобильных устройствах он продолжает работать?
Как это сделать технически — резать трафик в разных точках в зависимости от типа провайдера?
Зачем советуют менять user‑agent в браузере, если он передается в зашифрованном потоке и не должен быть доступен чекистам?
Откуда идут разговоры, что ютуб замедляют только на стационарных ПК, а на мобильных устройствах он продолжает работать?
Из того что находил в комментариях, приходят разные доменные имена сервера отдачи видео для мобильного и десктопа.
Зачем советуют менять user‑agent в браузере, если он передается в зашифрованном потоке и не должен быть доступен чекистам?
Собственно выше, сам гугл отдает другое имя сервера(даже если ведет в тот же адрес) для мобильных.
а замедляют по SNI(который не шифрован)
Повторю: то что видел в комментариях.
Откуда идут разговоры, что ютуб замедляют только на стационарных ПК, а на мобильных устройствах он продолжает работать?
Отсюда, и, возможно от собственных тестов
Как это сделать технически — резать трафик в разных точках в зависимости от типа провайдера?
Да, на части линков в DPI включить шейпер, а на части - нет. Естественно это только в случае искусственного замедления
Мне лично кажется, что проблема в QUIC. Они к нему по-особому относятся. Ходили слухи, что и его начали резать, но тут тоже вопросы. Там чуть ли не разные способы кодирования сообщений у хрома и фаерфокса. Вот где-то тут мобилки и отсеиваются, скорее всего. Я сейчас свой подключил - в ваершарке обычные Client Hello с обычным SNI, но сам SNI extension лежит ниже и ютуб работает на QUIC.
Да и в принципе, как выше писали, на мобильную сеть могут быть другие ограничения по сравнению с проводом.
Как минимум анекдотичные свидетельства показывают, что режут на стационарных устройствах. У меня в дом заходит оптика МТС - ютуб работает на последнем издыхании. В телефоне сим карта МТС - никаких проблем с сайтом. Такая же информация от знакомых и коллег, ни от кого не слышал, что появились новые проблемы при подключении с телефонов.
Такая же информация от клиентов, только сегодня от них пару раз слышал "ваш инет г-но, на мобильном телефоне видео работает без задержек"
с каждым днем/годом, всё больше "горжусь" РФ.
Видимо, основная идея движа - что пользователи, замучавшись с тормозящим YT, плавно само переползут на другие площадки.
Одна проблема: многие авторы не переползут. Одни потому, что на других площадках монетизации нет или она околонулевая. Другие потому, что контент так-то далеко не только российские авторы клепают. А нет контента - нет пользователей.
Плюс архив. Многие авторы потеряли интерес к своим видео и каналы не развивают (но видео востребованы) Ну и сами авторы, увы, не вечны.
Пользователи могут скопировать контент. Целиком канал сохранить и загрузить на другую площадку. Это и раньше было актуально, сам Ютуб мог автоматически удалить видео, если распознает там нарушение авторских прав, музыкальный фрагмент будет или торговый знак.
Я вот так делаю для некоторых видео/каналов.
Но формально это все же нарушение.
А. Ну то есть ваше решение -рассчитывать, что энтузиасты захотят и смогут украсть скопировать и будут рассчитывать что их не пропалят достанут юридически? И за бесплатно. Окей, тоже вариант.
Это скорее аналогия архива интернета
Архи́в Интерне́та (сокр. АИ; англ. Internet Archive) — некоммерческая организация, основанная в 1996 году в Сан-Франциско американским программистом Брюстером Кейлом. Главной заявленной целью Архива является предоставление всеобщего доступа к накопленной в Интернете информации. Коллекция АИ состоит из множества подколлекций архивированных веб-сайтов, оцифрованных книг, аудио- и видеофайлов, игр, программного обеспечения.
Эм. За что энтузиастов могут юридически достать? За перезалив видео на другие площадки? Если да - то чужих или в том числе своих?
Как раз монетизация вроде как отключена уже более 2х лет.
Я слышал, что основной доход у ютуберов в любом случае идёт с рекламных интеграций, а не от самого ютуба.
Не знаю ни одного блоггера, перешедшего с ютуба на рутуб или вк, зато знаю нескольких стримеров, которые перешли с твича на вк, в моменте получили больше дохода (потому что вк платил по количеству зрителей на твиче), а потом доход начинал падать и им пришлось вернуться. При том что на твиче точно также для российских стримеров нет монетизации.
Что если нам как пользователям перестать пользоваться другими площадками? Удалить аккаунты, если вдруг там есть?
Вот по Рутубу например, единичные удаления ничего не дадут, рост и так был, а сейчас думаю там удвоится аудитория. Средний пользователь там найдет себе что смотреть и ничего настраивать не нужно.
2021 3.04 млн
2022 17.19 млн
2023 40.2 млн
2024 47.6 млн
Значит поделитесь озвученной мыслью с окружающими, чтобы удаления были не единичные.
Я не могу, так как сам делаю обратное. Поискал аналоги ради интереса, зарегистрировался на Платформе. На Платформе же посмотрел видеоролики с критикой блогеров Платформы, что сыро тут и тут и контекстная выдача плохо работает. Хотя я заметил что в ленте Платформы пошли ролики с критикой Платформы, что признак нормальной работы. И просмотры не единичные, я на Ютубе специфические ролики по микроконтроллерам смотрю, там бывает 50 просмотров, тут более 4958 и в комментах активность.
Мне кажется основная причина роста это куча пиратского контента.
Я когда в отпуске был с поиска яндекс часто вел туда чтоб фильмы смотреть.
я помню так год .. ДО 2008.. я тогда даже сериал смотрел в ВК. а сейчас ума не приложу.. не, можете не объяснять про то что большинство не знает и не умеет, я знаю, но когда речь заходит про пиратский контент, то почему не торренты? я тоже иногда смотрел фильмы онлайн, но вообще отложился исключительно отрицательный опыт. садишься, начинаешь смотреть, кайф.. и тут видео зависает, тормозит. другое дело, скачал в хорошем качестве с торрента, и никаких тормозов при просмотре.
Как вариант - вы планируете заранее, что посмотреть.
Альтернатива - начать смотреть что-то. Не понравилось - переключиться на другое. Ну как перед телевизором каналы щелкали.
(хотя при практически безлимитном трафике вполне можно с запасом накачать, а что не зашло - просто стереть).
У меня обратный опыт.
Я скачиваю обычно то что планируется много раз смотреть, или для оффлайн просмотра. Остальное и онлайн хорошо.(Москва если что)
например яндекс музыкой я перестал пользоваться в 2022 году. до этого даже подписку имел на этот сервис несколько лет. где-то тогда же и кинопоиском перестал пользоваться. в этом году истекает оплата на яндекс диск. само собой продолжать платить им не буду. на рутуб не пойду, даже если реально к ютубу будет не пробиться. вк держу ради 2-4 сообществ, которые увы не имеют аналогов вне ВК. причин отказа от указанных сервисов несколько, в том числе и претензии к их функциональности. но есть и пару причин принципиальных.
читал тут комменты в инсте по поводу ютуба. меня поражает с какой лëгкостью все обсуждают что можно пользоваться (например) кинопоиском вместо ютубу. я вот считаю что платить тем кто строит мне клетку это не уважать себя (жаль от еды так не откажешься, как от яндекс музыки или диска, хотя производителя продуктов и вещей выбираю, когда есть возможность). ещë и денежку им несут. а на эти денюжки (налоги) потом сами знаете что.. эти же блокировки и делают.
Там я нашёл, как именно замедляется ютуб и контрпример, подтверждающий на 100%, что это проделки большого брата.
У меня Йутуб только в Firefox тормозит. В Opera все отлично. Не знаю кто ваш брат, но Firefox ему определенно не нравится.
Проблема в лисе (или в ютубе, может быть, они так хромиум продвигают). Он не всегда использует QUIC. Я бы даже сказал по-настроению. В хроме все стабильнее.
У меня наоборот, в firefox ютуб сначала тормозит, но потом работает в 1080, в хроме вообще ничего не грузит
А у меня есть два компа, на обоих FF, на обоих установлен GoodByDpi от Valdik. Причем на первом я сделал network.http.http3.enabled true, и работает какое-то время, а потом ютуб выводит "Интернет не подключен". Причем если запустить FF Portable с чистым профилем, то результат похожий. В Опере такого не ожидается.
На втором компе тоже FF, и все работает. При этом в самом браузере ничего не настраивал вообще.
И если запустить это запрос, то мы получим
Я правильно понимаю, что на адресе speedtest.selectel.ru:443 находится прокси, через который доступны другие сайты в интернете?
Иначе почему мы вообще что-то получим?
По-моему, название говорит само за себя. inline сервис для проверки скорости. Можно подключиться `curl speedtest.selectel.ru/100MB -o /dev/null` и мы получим скачивание 100MB файла на максимально возможной скорости интернета. Методом, который указан в curl запросе я подменяю Host и TLS SNI на те, которые нужны. speedtest.selectel.ru никак это не обрабатывает, зато ТСПУ видит googlevideo SNI и начинает шейпить данные.
Причём если ввести не *.googlevideo.com, а google.com, скорость восстанавливается.
speedtest.selectel.ru никак это не обрабатывает
Выглядит как дыра в безопасности.
Selectel вы же в курсе, да? Это норм?
А, понял, имеется в виду "Домен в url игнорируется", а не "Домен используется из url".
Тогда вроде не дыра...
Так они специально это сделали. Чтобы люди тестировали свою скорость. Там собственно и "дырить" нечего) Какой им смысл запрещать другие SNI или Host.
К слову, такое можно и с гуглвидео провернуть, в другую сторону. Я копировал огромный запрос из yt-dlp логов, подменял SNI на yandex.ru, Host header ставил обратно в googlevideo, и connect-to в ::.googlevideo.com. Всё работало. Я писал об этом где-то в yt-dlp issue. https://github.com/yt-dlp/yt-dlp/issues/10443#issuecomment-2237395791
Адрес speedtest.selectel.ru:443 выбран просто как доступный в сети адрес, идея того curl запроса в том, что запросу принудительно присваивается ютубовский SNI, и, как следствие, ТСПУ по признаку этого SNI замедляет передачу данных. Также сайт спидтеста селектела удобен тем, что можно указывать размер файла и наглядно увидеть падение скорости(это можно заметить в SNI, в конце написано 100MB).
Там находится сервер которые просто отвечает на запросы как должно (отдачей конкретных тестовых файлов) При этом на то, что было передано в заголовке host и TLS SNI - ему плевать.
Можно самостоятельно поднять свой тестовый сервер. Или найти другой такой же.
Есть ли решение для телевизоров, в частности на WebOS?
Да, можно поставить OpenWRT на роутер и собрать для него один из пакетов из заключения (я свой тестировал, есть инструкция по кросс-компиляции)
а вот с этим по подробнее, можно ссылочку на инструкцию?
https://github.com/Waujito/youtubeUnblock?tab=readme-ov-file#openwrt-case
Для моего работает. Главное - чтобы тулкит было подходящим.
"Любимый" WebOS не имеет функции прокси, поэтому пришлось поднимать zapret на openwrt как прозрачный прокси и через DHCP выдавать адрес этого роутера как шлюз. Ютуб летает, как бонус стали грузить Аватарки.
GGC. Официальное заявление было, что кэш сервера устарели и долго не обновлялись
Нарушен новостно-временной континуум. Сначала есть проблема, а потом, после анализа, об этом становится известно на политическом уровне. А не наоборот или одновременно с появлением проблемы.
Подскажите, пожалуйста, для мака решение.
В zapret заявлена частичная поддержка MacOS.
Одни айтишники страны пилят ТСПУ, другие способы обхода.
Все при деле, получают за работу деньги, уровень безработицы падает
Уверены, что другие?
Самое мерзкое в том, что это не в администрации презедента придумали и даже не начальники в РКН и ростетелекомах. Придумали, дали совет и продвинуди эту тему люди пониже, люди квалифицированные, прошаренные в ИТ, но тем не менее желающие лизнуть.
Я бы поправил. Прошаренные и патриотичные. Без шуток.
Представьте картину: молодой человек, у которого папа - офицер ФСБ, неустанно борющийся с террористами-навальнистами, желающими развалить нашу великую Родину, разбирается в ИТ, заканчивает профильный университет и поступает на работу в какой-нибудь отдел "К". Далее, получив профдеформацию безопасника (эти люди реально на своей волне), проработав лет 10 в этой системе, мутирует в того, кто реально думает, что защищает Родину (а не представляет интересы правящего класса), при этом обладая компетенциями в ИТ и ИБ.
Нет злодеев, которые осознают себя злодеями. Мы все делаем то, что считаем правильным. Если мировоззрение этого "защитника Родины" поменяется, то поменяются и его действия. А сейчас - так.
А так ли сильно отличается защита Родины от защиты интересов правящего класса? Ну то есть крах государства приводит к краху страны и населения, поэтому государство надо защищать, а с ним и правящий класс.
Если правящий класс не представляет интересы людей, то да, сильно отличается. Крах режима не обязательно приводит к краху страны. Просто власть меняется на другую.
Это правящий класс меняется "просто"? А на что он меняется?
Ы, ахахах, вы так говорите что поменять правящий класс всё равно что носки, последний раз когда в России меняли правящий класс, именно меняли, а не правящий класс менял вывеску, то было 2 революции, Война, Война Гражданская, Голод, Разруха, Белый Террор, Красный Террор, Эпидемии, Иностранная интервенция, это ещё очень повезло что на этой территории тогда сохранилось хоть какое-то организованное гос-во, а то есть места в мире где хаос продолжается десятилетиями.
Даже если вы сами лично готовы подписаться на такое, то много ли вы людей найдёте, которые пока живут относительно сытой и спокойной жизнью
Все вышеперечисленное происходило как раз из-за того, что со сменой правящего класса слишком сильно затягивали, и делали это когда класс слишком сильно укоренялся, что сменить его без большого шухера уже было невозможно. Тут важный момент как раз ещё в том, что чем дольше оно откладывается и затягивается, тем менее все становится "сытым и спокойным". То есть если есть желание остаться в сытости и спокойствии, то делать это надо все надо пока ещё не слишком поздно. Вот такой вот парадокс.
У нас "патриоты" видимо забыли что помимо врагов внешних куда более опасные — внутренние, которые пробились во власть и там отстаивают свои интересы, а на интересы народа, государства, будущее им глубоко плевать. Но ведь проще сказать: "Вот они там все враги, они плохие, а мы все хорошие", и вроде как бы не такой уж правящий класс плохой, ведь вон там враг, надо объединиться, все вместе к светлому будущему. Ничего не напоминает? Думаю, напоминать к чему это привело не надо?
У нас "патриоты" видимо забыли что помимо врагов внешних куда более опасные — внутренние,
Они ничего не забывали, этим людям хоть плюй в глаза - всё божья роса. Для них и репрессии 37-38 норм, ведь с врагами боролись, и ЧК с НКВД это бравые ребята которые родину спасали, и шарашки были гениальным и очень полезным изобретением, а экономика СССР самой мощной в мире.
В царской России с врагами безжалостно боролись, чем кончилось - известно, в советской России с врагами боролись ещё более безжалостно, итог - известен, теперь в ныненшней России опять все силы бросили на точно такую же борьбу с врагами, но эти люди свято убеждены что просто раньше боролись недостаточно, а в этот раз результат-то будет другой!
Я уже говорил тебе, что такое безумие? (с) великий философ Ваас
В царской России с врагами боролись не особо безжалостно: страшных террористов то в ссылку отправят, то под честное слово выпустят. А закончилось всё отречением царя-батюшки, который к врагам, вроде как, отношения не имеет.
В советской России с врагами безжалостно боролись при Сталине, и при нём ничего не закончилось. Закончилось в момент, когда с врагами перестали бороться.
Сейчас и борьба не точно такая же, и враги другие, так что чем закончится – вопрос. Хочется, конечно, всё лихо под одну гребёнку, но жизнь несколько сложнее.
В царской России с врагами боролись не особо безжалостно
Вам отрывки из "Записок из мёртвого дома" почитать? Займитесь своим образованием вместо потуг над тривиализацией истории
Займитесь лучше своим образованием, чтобы отрывки из художественного произведения за аргументы в вопросе исторического процесса не выдавать. А потом либо за словарь возьмитесь - чтобы слово "тривиализация" по делу применять, - либо внимательнее читать учитесь.
хех, два выстрела и все мимо :)
и "тривиализацию" я использовал правильно, и использование художественных произведений в исследовании исторического процесс – это тоже валидный инструмент
и "тривиализацию" я использовал правильно
Значит с чтением проблемы. Если что, "тривиализация" - это упрощение, а я в своём комментарии занимался обратным: откатывал попытки свести историю страны к "с врагами жестоко борются, а потом плохо".
и использование художественных произведений в исследовании исторического процесс – это тоже валидный инструмент
Ага, если его правильно использовать. Когда других источников нет, например. Но никак не первым аргументам, когда других источников навалом. Это как начинать изучение истории репрессий с "архипелаг гулаг".
хех, два выстрела и все мимо :)
Ну, хотя бы считать умеете. До двух, по крайней мере.
Я вам сейчас немного информации для размышления подкину, касаемо той интересной детали, что в России в революционном движении конца XIX - начала XX века почему-то было подозрительно много еврейских фамилий и имён.
Это был естественный ответ значительной и социально активной части населения Российской империи (в которой согласно пропаганде была тишь, гладь да Божья благодать) на политику этой самой империи. Евреев там как бы это сказать... не любили. Понятие "черта оседлости" именно оттуда пошло - евреям запрещено было жить в крупных городах, жить можно было за определенной чертой - вот этой самой, проведённой на карте. Вот молодые подданные империи с курчавыми волосами росли и не понимали, почему они - люди второго сорта и хотели эту реальность поменять. И поменяли, во всяком случае без их помощи не обошлось. Сейчас люди второго сорта - все, кто не у кормушки. Только эти самые второсортные пока этого не осознали, но для этого пропаганда и работает, чтобы как можно дольше продолжать сон разума.
Не думаю, что это так. Как правило, для того, чтобы выйти на какой-никакой уровень экспертизы в нашей сфере нужно обладать критическим мышлением и способностью находить и анализировать информацию. Вы слишком романтизируете ситуацию. Как мне кажется, люди, которые активно заняты реализацией репрессивных инициатив просто понимают, что в обычном энтерпрайзе им не получить таких денег, которые можно получить у этой кормушки. А после того, как кормушка иссякнет можно будет спокойно свалить из страны, благо финансы на это будут на руках
не в администрации презедента придумали
Ну т.е. цензуру вводят не они?! Что-то сразу НТВ вспоминается...
Я может что-то не понимаю, но разве DoH и ему подобные не должен помочь? Зачем огород городить, тем более это уже во многих браузерах и роутерах встроено.
Спасибо за статью, но есть претензии то ли к формулировке, то ли к логической цепочке в одном абзаце:
"Как только я начал разбираться с этой проблемой и открыл Wireshark, меня ждали логи, состоящие наполовину из красных полос... тут тонны потерянных пакетов." - Если вы не меняли цветовую схему Ваершарка (а что-то мне подсказывает, что не меняли), то красные полосы - это флаг TCP RST, который к потерям имеет только очень опосредованное отношение.
если бы это были GGC, они бы либо не работали вообще, либо просто скорость была маленькая, а тут тонны потерянных пакетов. " - Скорость не бывает "просто маленькая". С т.з. анализа трафика самая распространенная (разумеется, не единственная) причина низкой скорости - это именно потеря пакетов, которая может происходить по разным причинам.
Т.е. весь этот абзац, откуда я это скопировал, можно прочесть как "Я увидел кучу RST флагов, а это значит, что много потерь, а это значит, что занижение искусственное.". Нет, не значит, и нет, не значит.
RST это прям ярко красные. Я про всякие Out-of-order, Retransmission и им подобные.
"Скорость не бывает просто маленькая" - вообще, бывает. Сразу пришли на ум сервера эклипса. Месяца два назад скачивал jdtls на скорости 20 килобайт/с. Сейчас они их пофиксили чуть-чуть, я получил 1 мегабайт, но всё равно в вайршарке с точки зрения TCP никаких ошибок нет.
Не за горами и полное отключение. Кто-то там в сентябре уже обещал
Попробовал упомянутый youtubeUnblock.
У меня роутер на debian. Скомпилировал, установил, а дальше в файле службы youtubeUnblock.service вписан лишь вариант как на самом этом роутере траффик пропускать через youtubeUnblock. Добавил в него iptables строчки для forward:
ExecStartPre=iptables -t mangle -A FORWARD -p tcp -m tcp --dport 443 -j NFQUEUE --queue-num 537
ExecStop=iptables -t mangle -D FORWARD -p tcp -m tcp --dport 443 -j NFQUEUE --queue-num 537
И убрал --queue-bypass везде т.к. со включенным невозможно понять работает/нет вообще. Пока не до конца понял чем это грозит...
Следующим шагом было проверить работает ли в принципе что-то. Поменял:
ExecStart=/usr/local/bin/youtubeUnblock 538
Т.е. теперь iptables заворачивает не туда. И дальше проверил с работающим только OUTPUT блоком - вообще ничего не скачать на самом роутере, а на клиентах работает как и раньше.
С работающим только FORWARD блоком - наоборот, на клиентах все потухло, а на роутере как обычно.
Т.е. вроде был порядок. Возвращаю обратно на 537, запускаю OUTPUT и FORWARD - ну как минимум все сайты работают, ютуб открывается. И вроде как даже ролики играют. Но стало ли прям заметно лучше пока однозначно не скажу.
Буду еще пробовать на всех клиентах - тв, телефоны и т.д.
Работает/не работает можно посмотреть если делать make dev (или просто передать -DDEBUG флагом). Тогда когда программа видит SNI гуглвидео, она будет выводить сообщение об этом + пропроцию в которой разбивается пакет. Отключение байпасса ничем особо не грозит, разве что если программа отвалится (мало ли), можно остаться без интернета. Узнать точно, что помогает можно по логам Wireshark. Тогда на контрасте можно будет посмотреть разницу (правда, это видно только если подключение без QUIC).
OUTPUT на роутере не надо делать.
Если немного разбираться как устроены сети провайдеров и уметь строить причинно-следственные связи, то окажется все намного банальный.
Давно известно что потребление интернет трафика растет каждый год.
Один из самых тяжеловесных контентом это видео, в т.ч. Ютуб
Для снижения нагрузки на сети операторов гугл в свое время ставил кеширующие сервера по всей сети.
2 года назад все крупные производители телеком оборудования ушли из РФ.И гугл прекратил свою деятельность.
Теперь внимание вопрос что происходил последнее 2 года на сетях операторов. Правильно, росла нагрузка на сеть. Плюс развлекух стало меньше, народ стал больше сидеть в интернете. Кеширующие сервера помаленьку выходили из строя. Больше трафика стало идти через международные пиринговые точки, где оборудование также имело очень ограниченный ресурс расширения (по сути только за счет старых запасов и переноса с других участков сети). Эти ресурсы закончились. Каковы действия операторов в этих условиях, когда трафик растет а оборудование не поставляется, - ограничить какой либо трафик. Выбор в сторону тяжелого очевиден.
Наверняка ещё и можно прижать гугловские сервера под свои нужды. Под хранения того же трафика абонентов для "компетентных' органов
Ах да, про импртозамещение, IP-оборудования операторского класса для больших объемов трафика никогда не производилось российскими производителями. Его не существует в природе.
Все это один из явных признаков технологической деградации страны.
Это все правильно и верно, кроме того факта, что скорост ограничивает Роскомнадзор на ТСПУ, а не сами операторы.
Ну и плюс очень подозрительно, что две недели назад оборудование отлично справлялось (никаких затыков, железо и каналы явно загружены не в полку), а в одну ночь резко перестало, причем сразу одновременно у совершено разных операторов в разных локациях.
Если бы была деградация кэша, то тест с подменой SNI бы не работал.
Я тоже сначала думал, что замедлять YouTube могут с целью снизить нагрузку на магистральные сети. Но, исходя из заявления Дом.ру, дело не в этом:
«Дом.ру обеспечивает своим клиентам качественный доступ в интернет в соответствии с заявленными обязательствами. Замедление работы сервисов Google и YouTube связано с вопросами регулирования иностранных онлайн-сервисов и их взаимодействии с Роскомнадзором».
И вообще, как уже сказали, провайдеры сами разберутся с балансировкой трафика. Зачем Роскомнадзору со своими ТСПУ в этом участвовать?
Вы вещаете не на ту аудиторию.
Да я уже понял) столько дизлайков видимо за призыв включить мозг и подумать)) поэтому не вижу смысла далее тратить свое время на придурков
Так наоборот, люди включили мозг и подумали, и поняли, что то, что вы пишете совершенно не бьётся с другими установленными фактами (коих уже найдено очень много и убедиться в них может каждый), и вообще как-то подозрительно похоже на нарративы госпропаганды, мол, это просто оборудование устарело, а не РКН намеренно тормозит и блокирует. За это вас и минусуют.
Ой, пожалуйста, не тратьте на нас свое время, рассказывая, как GGC серваки в одночасье резко деградировали, да еще и начали замедлять совершенно к ним не относящийся и через них не проходящий трафик просто с "googlevideo" внутри пакета.
Только успел прочитать статью и тут же подъехала новость: "РКН планирует признать научно–техническую и статистическую информацию о VPN для обхода блокировок запрещённой в РФ". Надо на Хабре при логине вместо капчи "Я не робот" тест на работников из РКН.
Как пользователь интернета из стран СНГ (Узбекистан) могу сказать что блокировки интернета очень затронуло и нас. Местные провайдеры ничего не могут сделать.
Т.е. у вас каналы только через РФ и больше нет?
А каким образом это может касаться вас, если блокировки происходят на оборудовании ТСПУ перед провайдерами?
В нашем стране нет кеш серверов гугла. все ускорения мы получали из серверов гугла ( Саратов-Самара-Оренбург-Уфа. Вот и получили. Местные новости
Мобильный траффик от лана отличается провайдером?
Интересно, возможно ли средствами файрволла MikroTik фрагментировать пакеты, чтобы не городить дополнительные сервисы, VPN и прокси?
Может у меня ошибка выжившего, но все таки... На десктопе YouTube начал тормозить во всех установленных браузерах (Vivaldi, Chrome, Opera, Firefox, Brave, Яндекс.Браузер). Кроме MS Edge... ¯\(°_o)/¯ QUIC уже был во всех включен.
Помню читал про eSNI - оно до сих пор не родилось по итогу?
eSNI убили, его не будет. Вместо него заявлен ECH, которой тоже не торопятся вводить, и скорее всего никогда не введут.
Последний актуальный ФФ
К примеру, один из самых популярных CDN, CloudFlare, поддерживает ECH:
sni=encrypted
Поддержка ECH реализована в Firefox. С проигрыванием видео с YouTube он сейчас вполне справляется
Поддержка ECH реализована и в Chrome. Это не решает той проблемы, что кроме Cloudflare, никто не пытается делать поддержку этого самого ECH на сервере (без которого ECH на клиенте не работает). Google в целом и YouTube в частности, насколько я помню, ECH не умеют.
Я решил проблему немного по-другому. Начитавшись мануалов по микротику и имея белый статический IP (бесплатный от провайдера), некоторое время назад чисто из спортивного интереса я поднял туннель 6to4 через зарубежного IPv6 брокера. Затем прокинул пул адресов /64 в локальную сеть, настроил файрвол.
Проблем с ютубом не заметил. Даже появился доступ к некоторым другим сервисам (но не об этом сейчас :-) )
На следующий день попросил сеть /48. После чего раскидал IPv6 адреса: в гостевую сеть, на дачу через EoIP-tunnel over Wireguard. Этого было мало, и я пошёл дальше. Раздал сеть на свой смартфон, рабочий компьютер через WireGuard (на телефоне уже давно заворачиваю IPv4 трафик).
Надеюсь, провайдер не задушит мой туннель.
а сможешь чуть подробнее описать процесс настройки? я припилил пока вылавливание субдоменов гуглвидео, которые добавляются в адрес лист и перенаправляются через интерфейс с впном, в целом работает, но на некоторых субдоменах запинается.
припилил пока вылавливание субдоменов гуглвидео
В том то и дело, что Google, Youtube, Facebook (да даже наш Яндекс) и прочие давно поддерживают IPv6, поэтому по умолчанию идут через IPv6 (он идёт только через IPv6 туннель).
Могу показать ссылку, которая поможет настроить основу: https://help.mikrotik.com/docs/display/ROS/6to4
Было тяжело с ходу найти подходящий ящик. Мне подошёл ящик из etlgr.me домена.
Тоже был бы очень признателен, если бы описали подробнее. Да и многие другие тоже, я полагаю)
Уже попахивает на мою первую статью. Вот задумываюсь над этим.
Пока в кратце, читал мануал. В целом, зарегистрировался на сайте, поднял туннель. завёл IPv6 подсеть в локальную сеть.
Надеюсь, будет полезна следующая статья, размещённая на хабре.
В песочницу положил статью. Вдруг будет полезна и поможет настроить IPv6 на Mikrotik.
Пока ждете приглашения от имеющего достаточно кармы, может еще добавите для тех, у кого адрес белый (принимает входящие), но не статический (меняется при перезгрузке роутера и т.п.)?
Мне в свое время пришлось скриптик писать, который периодически проверял, что публичный адрес изменился и через API обновлял его на HE (ибо там требовался именно IP, DynDNS никакой не помогал)
С не статическим адресом достаточно просто. Достаточно сравнивать текущий адрес с предыдущим, затем просто перейти по ссылке, там не надо передавать IP. Только логин и ключ, которые сразу же передаются прямой ссылкой. В ответе будет good "новый IP без кавычек". Типа, good 1.1.1.1
Чтобы дёрнуть белый IP, можно использовать скрипт, как предложено здесь. За одним исключением. Вместо ссылки https://wtfismyip.com/text прописывать ссылку https://ipv4.wtfismyip.com/text
Но я ещё подумаю, поищу, как выхватывать ссылку напрямую, без файла. Что-то мне кажется, можно и так сделать. Поищу в документации. Спасибо за идею обновлять IP.
не уверен, что оно надо, но иметь в запасе ещë один вариант обхода блокировки не плохо. поэтому заинтересовался вашим вариантом. смущает в предложенной схеме в частности то что как понимаю все устройства получают внешнии IP. А оно нафиг не нужно. Наверняка можно оставить устройства в локальной сети за роутером, не давая каждому ipv6. Раз ваша статья не опубликовано, предлагаю вам рассмотреть такой вариант, дополнить статью. Мне лично интересно.
Прошу прощения за ламерский вопрос, но искренне интересно: вот если я настрою себе PiHole, на него получится ли накатить Ваше решение под Линукс и станет ли оно тогда разблочивать Ютуб по всей моей домашней сети?
Занижение скорости уже давно начали, причем это на весь заграничный интернет. Возможно хотят снизить покупку заграничного трафика, или вообще чисто перейти на федеральную локалку, типа постепенно зарубить заграничный интернет. Типа создать закрытое государство, как было ранее при СССР. Какой в этом смысл? В Китае такое уже давно, Китайский интернет ограничен Китайским интернетом. А может готовят людей к новым санкциям, если вдруг США блокирует интернет, то будет только локальная федеральная сеть?
С одной стороны хорошо, огородиться от западной грязи, создать порядок в сети интернет. Но с другой не будет доступно образование, технологии, фильтровать такое не реально.
Вы усложняете, просто Гугл не удаляет видео, которые РКН считает противозаконными, и теперь пришло время блокироваться.
При всем при том, что Гугл довольно часто шел навстречу властям РФ и удалял некоторые видео по их запросам. Но еще больше видео не удалялось.
Китайский интернет может себе позволить самоблокировку по той причине, что их там почти полтора миллиарда. У них есть реально работающие аналоги соцсетей, видеохостингов, мессенджеров... А рутруб тормозил даже до торможения тытруба.
При этом можете почитать в телеге БэдКоммедиана о том, как "легко" выложить видео авторам контента. По крайней мере, если этот контент чуть сложнее, чем у Инстасамки.
Поиграют, как это было с телегой, и перестанут.
Спасибо, все работает )
Собрал под OpenWrt 23.05.3, не хочет слать пакеты =(
root@OpenWrt:/tmp$ ./youtubeUnblock 537
Using TCP segmentation!
GSO is enabled!
raw frags send: Operation not permitted
raw frags send: Operation not permitted
raw frags send: Operation not permitted
raw frags send: Operation not permitted
raw frags send: Operation not permitted
raw frags send: Operation not permitted
И такие наминусили в рейтинг, мне важны ваши ответы и что думаете =) Мне всегда интересно обсуждение подобного, ваша критика, иначе на чем строить подтверждение. Что вы думаете интересно, а не то, что вам не нравится =)
Однозначно скажу, что оборудование не может замедлить скорость, это глупо. Оборудование может выйти из строя, отключиться, то есть полный сбой, нет связи с сервером. Но не замедлить скорость. То есть может не быть доступа к серверу из за поломки, но никак не уменьшение скорости. =)
Это не какая то засорившаяся кофемолка, это сервер. Сервер это точные настройки! Тут либо он работает, либо нет.
c 14 июля вышло предупреждение - Скорость загрузки и качество воспроизведения видео на YouTube будет ухудшаться с сегодняшнего дня.
Этим все сказано, скорость будет занижена. То есть нет IT специалистов предсказателей, это сделано намеренно. =)
Для тех, кто в танке, объясняю, резко ухудшиться скорость загрузки, само по себе не может. Даже из за нагрузки посещений на сервер Youtube, соединение либо будет нормальное, либо будет ограничен доступ совсем!
Вы немного в сторону уводите дискуссию, статья сабж однозначно и недвусмысленно доказывает причины падения скорости загрузки с/на Ютуб.
А то, что вы не можете представить что скорость может просто замедлиться -
во-первых современные сервисы масштаба Ютуб - очень распределённые, в случае выхода из строя одного узла, другой может подхватить обработку, но вы заметите падение скорости,
во-вторых, некоторын аппаратные ошибки, например, "сыпящиеся" диски, могут привести как раз к падению скорости обслуживания.
@Waujito напишите пожалуйста хорошую подробную инструкцию как использовать вашу разработку.
как собрать (с командамм, результатами возможнными ошибками)
как использовать:
отдельный прокси
в составе какого то решения
как запустить как сервис systemctl или как то там
с командами
я понимаю что мы тут все технари, но не все каждый день собирают под линукс из исходником, настраивают iptables и т.п.
Запустить терминал (Ctrl+Alt+T)
Ввести в нем команды, соглашаться если есть запрос, вводить пароль когад просит:
sudo apt update && sudo apt install git
git clone https://github.com/Waujito/youtubeUnblock.git
sudo apt install gcc
sudo apt install make
sudo apt install autoconf
sudo apt install automake
sudo apt install pkg-config
sudo apt install libtool
sudo apt install linux-headers-$(uname -r)
sudo iptables -A OUTPUT -p tcp --dport 443 -j NFQUEUE --queue-num 537 --queue-bypass
cd youtubeUnblock/
make
sudo make install
sudo youtubeUnblock 537
На любом этапе могут быть проблемы, к сожалению без хотя бы начальных знаний linux'а и С их не решить
отлично. спасибо. на Ubuntu 18.04.6 LTS все сработало. Проверить эффективность не могу, т.к. пока не блокирует местный РТ
дополню. надо создать в /etc/systemd/system файл youtubeunblock.service с параметрами
[Unit]
Description=Start youtubeUnBlock
After=network.target
[Service]
User=user_name
ExecStart=/usr/local/bin/youtubeUnblock 537
Restart=always
[Install]
WantedBy=multi-user.target
для файла уставить разрешения
sudo setcap cap_net_raw,cap_net_admin=eip /usr/local/bin/youtubeUnblock
ну а дальше sudo systemctl daemon-reload
sudo systemctl enable youtubeunblock.service
Спасибо!
Это всё я сделал. Перезагрузился. Запустил sudo youtubeUnblock 537. А вот дальше-то что? :) Браузер сам куда надо перенаправит свои запросы или как? У меня запущенная программа пишет:
Using TCP segmentation!
GSO is enabled!
И всё. Открываю в FireFox ютуб - нифига, всё так же не работает.
За FireFox не подскажу, а в хроме по ссылке chrome://flags/#dns-over-https нужно выключить TLS 1.3 hybridized Kyber support, и перезапустить браузер
Правило iptables добавили?
Добавил. Программа пишет в консоли
Packet split in portion 193 592
Google video!
Packet split in portion 197 595
Google video!
Packet split in portion 197 595
Google video!
Packet split in portion 197 595
Google video!
Packet split in portion 197 595
Google video!
Packet split in portion 197 595
Google video!
Packet split in portion 197 595
Google video!
Packet split in portion 197 595
Google video!
Packet split in portion 193 592
Google video!
Packet split in portion 197 595
Только вот видео всё равно не грузится. Максимум, начальный экран youtube.
Как же я благодарен умным людям, что находят причины и возможности решения проблем. Спасибо большое!
А кто-нибудь смог настроить byeDPI для андроида? Пробовал разные настройки применять и менять домены, но все равно секунд через 30 ютуб снова начинает уходить в буферизацию.
Я смог, могу в личку направить
У меня с этим ByeDPI для Андроида случился следующий анедот. Поставил его себе на планшет, запустил, нажал Connect, он сразу же завис. Остановил его, сбросил кэш и данные приложения, запустил заново, ткнул в Connect, и, о чудо, всё заработало само по себе.
Заработал инстаграм, твиттер, который Х, и ещё всякое по мелочи. Но радость была недолгой. Часа через три очнулся дежурный прапорщик по ТСПУ, увидел бардак в виде несметной толпы подключений якобы к www.iana.org, но к совершенно не относящимся к этой организации IP-адресам, растолкал товарища лейтенанта, тот, проморгавшись, поднял по тревоге товарища майора, и совместными усилиями они завернули ByeDPI лыжи взад: всё опять перестало работать.
Жаль, что DPI бубны от ValdikSS отвалились ночью и не работают ни в каких конфигах, а ещё раньше перестал помогать флажок QUIC и другие недогайды, буквально всё отваливалось по часам вчера вечером, и сегодня ночью перестало работать полностью. Работают только мобильные сети и те, кто выходит в инет без ТПСУ грёбаных, но вроде как МТС работает меньше всего (это неточно). Мегафон и Билайн работают для ютуба 100%.
А поможет ли простое использование VPN в борьбе с замедлением YouTube?
Возможно ли то, что ТСПУ будут фильтровать пакеты с ответом? Или в нем нет незашифрованных данных по которым можно определить что он идет от googlevideo?
вот тут можно посмотреть подробнее: https://ntc.party/t/замедление-youtube-в-россии/8055/ and https://ntc.party/t/обсуждение-замедление-youtube-в-россии/8074/
я один не могу попасть на сайты по ссылкам?
Спасибо за статью. Я замедления не заметил, но смотрю через хром с расширением "Обход блокировок Рунета".
Подскажите, а есть ли решение прям для всей сети? А то все эти утилиты конечно хорошо, но со smart TV посмотреть не получится...
Попробовал youtubeUnblock на Ubuntu 22.04, без него youtube тормозит, без него проигрываться вообще перестает. Собрал через "make dev", во время попытки проигрывания исправно пишет "Google video! Packet split in portion 198 599", но ничего не проигрывается. Если остановить нажатием ^C, начинает опять проигрывать (с тормозами)...
...speedtest.selectel.ru
А для провайдера МГТС ссылку можно модифицировать?
Хочу посмотреть есть ли замедление внутри сети МГТС, чтобы выкатить претензию, если оно есть.
Да делайте что хотите) Если знаете сервер, который в +- такой же манере работает - почему нет. Другой интересный кейс - дотянет ли оно до ТСПУ. Кстати, у меня на мегафоне сработало:
```curl --connect-to ::msc.bigspeedtest.netbynet.ru.prod.hosts.ooklaserver.net 'https://manifest.googlevideo.com:8080/download?nocache=ffb8h452-219c-46a2-ac07-ae26f8064445&size=25000000&guid=fb78549a8-f40a-40d9-b760-1f8fcaa03c8e' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0' -H 'Accept: /' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate, br, zstd' -H 'Origin: https://www.speedtest.net' -H 'Connection: keep-alive' -H 'Referer: https://www.speedtest.net/' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: cross-site' -H 'Sec-GPC: 1' -o NUL -k```
Я просто скопировал это как cURL из окна для разработчиков в Firefox во время speedtest
Домашний провайдер, с компьютера видео не показывает, запросы к googlevideo в инструментах разработчика статус canceled. Со смартфона через вифи в той же сети видео в качестве 480 показывает без лагов, некоторые видео в 720 с небольшими лагами. при начальной загрузке видео может быть задержка, затем при воспроизведении задержки нет, что может указывать на работающий кэш гугла, либо перебор доменов googlevideo которые проходят через фильтр.
https://subdomainfinder.c99.nl/scans/2020-01-14/googlevideo.com выложены домены googlevideo и их ip.
Ох, спасибо тебе, добрый Человек! Поставил youtubeUnblock на ubuntu, рад как слон)
Предлагаю в треде подумать и предложить варианты, которые нагрузят "средства" ограничения, но минимально на грузят другие сервисы.
Например, что если создавать и рвать кучу соединений? Какой трафик нужно сгенерить до отказа "средства"? Может кто-то даже сделает тест и в масштабе будет видна разница в времени установки соединения. А там в докере и отдать народу.
Идея хорошая, но за такое 273 статью могут притянуть.
273 приятнуто за уши, ни по одному из пунктов не притянуть
IMHO вполне можно притянуть "использование компьютерных программ .... заведомо предназначенных для ... нейтрализации средств защиты компьютерной информации".
ТСПУ - средство для защиты? Нейтрализуешь защиту? Чем не состав :(
Я даже не удивлюсь, если за использование VPN по ней начнут привлекать. Тоже ведь обход фунцкций ТСПУ (нейтрализация)...
как минимум по двум пунктам притянуть легко:
предназначенных для несанкционированного ... блокирования ... компьютерной информации
Вы задудосили ТСПУ, он перестал пропускать трафик = заблокировали передачу информации
нейтрализации средств защиты компьютерной информации
Вы задудосили ТСПУ, провайдер по регламенту был вынужден пустить трафик вместо него через байпасс = вы нейтрализовали ТСПУ, которое официально называется "средством противодействия угрозам", то есть средством защиты.
Автор, ты красава, давай допилим твою тулу, чтобы макросы превратились в ключи командлайна, а фильтр задавался в файле списком (списком регексов как вариант). Получится простой и понятный инструмент для обхода фильтров по SNI.
Пойду попробую пулреквест запилить.
У пчелайна какая-то хрень творится: ФФ с выключенным http3 нормально, с включенным - висит
http3 false
http3 true
Один и тот же ролик 1080p
Как это, каждая семья несчастлива по своему? Вот у меня вчера (Yota, Лен.область) youtube напрочь не работал на Chrome, пока kyber не отключил. На Firefox'е никаких проблем.
Так они блокируют 70% пакетов. Но, не на пользователя, а на всех. Т.е. статистически есть вероятность попасть в поток, где 100% твоих пакетов пройдёт, как есть вероятность, что не пройдёт ни один.
Ну, я долго не мог вспомнить про эту настройку. Пардон, kyber, конечно.
По закону больших чисел, если пакетов много (а их при просмотре видео будет много), то существенно отклониться от этих 70% практически невозможно. Если, конечно, замедление реализовано равномерным и честным рандомом, а не целенаправленно отдаёт предпочтение определённым пользователям.
Мне кажется, как раз наоборот, благодаря закону больших чисел, есть довольно большой шанс попасть в поток, где твои пакеты почти не блокируются.
https://ru.wikipedia.org/wiki/Закон_больших_чисел
Согласно закону, среднее значение конечной выборки из фиксированного распределения близко к математическому ожиданию этого распределения.
Другими словами, чем больше объём выборки, чем чаще проводятся измерения какого-либо параметра, тем выше вероятность того, что результаты окажутся близкими к ожидаемым.
Вы утверждаете ровно обратное.
P.S. Поясню: мат. ожидание распределения - 70% отброшенных пакетов, конечная выборка - пакеты, отправленные во время одного просмотра ролика.
Вы, видимо, берёте не те вероятности.
Смотрите, допустим провайдер блокирует каждые 7 пакетов из 10. В какой то момент, видео одновременно смотрят 10 000 пользователей ровно. При условии, что трафик идёт достаточно равномерно, у 7 000 пользователей не пройдёт ни один пакет, при этом 3 000 пользователей не заметят блокировки вообще. Это в теории.
На практике, нужно предусмотреть большое количество факторов, однако, благодаря большому количеству пользователей и огромному количеству трафика, вероятность возникновения таких коридоров довольно велика.
Кроме того, видео буферизируется из-за чего потери пакетов незаметны. Т.е. пользователю достаточно загрузить первые 3-5 секунд, что бы почти не заметить потерь.
Это в теории.
Как раз в теории влияние большого количества факторов и смешивание трафика большого количества пользователей позволяет считать, что прохождение каждого пакета это независимое событие с вероятностью 30%, и дальше к этому применять аппарат теорвера. И получить, что вероятность попасть в такой коридор ничтожно мала.
А вот на практике может оказаться, что там не каждые 7 из 10 пакетов блокируются, а то ничего не работает и поэтому все пакеты пропадают, то ничего не работает и поэтому все пакеты проходят, то блокируется как надо, но не для всех пользователей, то ещё какие проблемы.
Кроме того, видео буферизируется из-за чего потери пакетов незаметны.
Буферизация только сглаживает проблемы во времени, не более того. Если из-за потерь средняя скорость падает ниже битрейта видео, то она ничем не поможет.
Вероятно Andy_U имел ввиду, что при достаточном количестве попыток даже самое маловероятное событие будет происходить относительно регулярно. Что, впрочем, совершенно никак не влияет на вероятность этого события
Из интересных наблюдений - ютуб не тормозит на тарифах для ЮЛ. Провайдер - РТ.
Автор... Дай тебе Бог здоровья. А то без ютуба я не знаю как. И о чём граждане "замедлительные" думают... Предлагают рутубом пользоваться. Ну допустим. Только тогда перенесите туда все туториалы и курсы по фреймворкам и языкам программирования, всё, что мне интересно смотреть тоже туда перенесите и регулярно зеркальте туда с ютуба всё это. А иначе что вы мне предлагаете смотреть ? КВН и камеди клаб с сериалами ? Ну вот спасибо, не надо
Они даже не готовы дать официально разрешение зеркалить на альтернативные платформы контент с Youtube. Не то чтобы это кого то останавливало...
Если начнут переносит туториолы, то скорее всего приложение рутуба сразу повыкидывают из всех маркетов за нарушение авторских прав, как недавно произошло в app store
Да пусть выкидывают из апстор и из плеймаркет, - уже есть рустор. И, кстати, сейчас это уже больше похоже на сговор операторов связи. Потому, что через домашний интернет не работает ютуб, а через мобильный интернет работает прекрасно. Операторы связи пролоббировали блокировку ютуба, чтобы люди активно тратили мобильный интернет и покупали больше и больше дорогих мобильных гигабайт.
А на провайдерском уровне такое можно применить?
Вот все обвиняют Хинштейна, а тем временем в пабликах появилась проплаченная реклама ВК видео, которым нужно пользоваться всвязи с замедлением ютуба. Вопросы нужно адресовать не Хинштейну, а владельцу VK. Это товарищ Усманов (который нам не товарищ) и Газпром, то есть фактически, государство.
А какое решение для macOS?
Предлагаю причастных "блокировщиков" запомнить "в лица", а при собеседовании на вакансию "учитывать" их опыт работы в РНК
Например - задавать вопросы с пристрастием
А вот мобильные приложения как-то по-другому работают? Почему их это пока не затрагивает?
На самом деле заметил очень странную вещь.
Если использовать команду с подменой, которая проверяет скорость, то можно сильно удивиться.
В моем случае у меня cкорость пару мегабит(от 1 до 5), но на сервере в МСК/СПБ (timeweb хостер) - скорость идеальная.
Чет я начинаю думать, что это не из-за РКН...
Пруфы:
Windows 11C:\Users\***>curl --connect-to ::speedtest.selectel.ru https://manifest.googlevideo.com/100MB -k -o file.txtДа, здесь я получил 30 мегабит скорости, но такое редко бывает
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 100M 0 174k 0 0 32969 0 0:53:00 0:00:05 0:52:55 32982
Ubuntu 22.04, MSK расположениеcurl https://api.myip.com/ && curl --connect-to ::speedtest.selectel.ru https://manifest.googlevideo.com/100MB -k -o file.txtИнтересно откуда такое получается, может все не туда думают?
{"ip":"91.198.220.65","country":"Russian Federation","cc":"RU"} % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 100M 100 100M 0 0 73.4M 0 0:00:01 0:00:01 --:--:-- 73.4M
В соседнем посте уже ответили вам. Вы тестирует не с residential-подключения, а с VPS. У многих VPS-хостеров нет на аплинках оборудования ТСПУ, которое и обеспечивает замедление Ютуба (но при этом могут быть тупые блокировки старого типа по IP-адресам, то есть условная Флибуста открываться оттуда не будет, но Ютуб будет летать)
Но замеделение YT касается только свежих версий брацзера на базе Хромиум
Пруф - машина с W8.1 и Хромом 109 версии, провайдер МТС, а рядом обычный ПК с W10 и EDGE (на базе Хромиум) 126 версия , провайдер тот же один и тот же ролик себя ведет по разному, при чем на второй машине замеделние проявилось после применения обновления браузера.
Так же проводил экспиремент: На машину с W10 "поставил" Хром 109 версии и слчилось Чудо Ютуб начал летать - это "магия" которая пришла с новоой версией движка браузера, что принесло использование протокола или чего-то еще, что "не нарвится" РКН и его железкам у провайдеров
С QUIC и правда не все в порядке. Я полез и настроил ваше решение на роутере и проверочная ссылка заработала. Но поскольку я ютуб смотрю на телике в приложении YouTube мне это не помогло.
Видео 1080p уже смотреть невозможно, такими темпами через неделю отвалится и 720p
есть ли что-то подобное для mikrotik? извните, если пропустил в комментах
спасибо авторам трех решений (GoodbyeDPI, youtubeUnblock и byedpi ) за усилия, а Вадиму за подробный разбор ситуации, но решения бесполезны. столько человекочасов потратил на эти решения: перебор параметров, для byedpi даже отдельную машину и докер образ собрал , - но они не работают (РТ).
а эти замечания "у меня работает" просто означают, что скоро перестанут. Значит у моего провайдера нашли обходы обходов и распространят скоро по всем устройствам обновленные правила.
А вы выключали/включали QUIC и kyber? Их судя по всему тоже начали блокировать, спустя какое то время, после начала замедления. У меня на РТ так. Если они включены, то ютуб вообще мёртвый стал, хотя до этого еле еле но грузился. Если выключить, то еле еле сейчас грузится. Если включить GoodbyeDPI, то всё работает как до начала замедления.
первое что сделал - выключил это волшебный куик и более волшебный kyber.
у нас всклочили замедление сегодня в 1:00. По совпадению я как раз занимался развертыванием прокси на базе byedpi для всей сети и смотрел на фоне, что твориться "с ответом на ликвидацию".
короче только впн.
А наоборот включить(не по умолчанию) или версию обновить до 0.2.3rc1. Я сейчас проверил, по крайней мере у меня на РТ, работает независимо от состояния флагов. А до этого на версии 0.2.2, только с выключенными обоими флагами.
У вас он вообще не работает или тормозит? А то может провайдер в полный блок кинул сервера гугла.
Попробуйте это https://github.com/Waujito/youtubeUnblock/issues/32#issuecomment-2269789997
интересно, а почему просто не заблокировать7 зачем этот сложный путь с замедлением?
Замедляли чтобы заблокировать? странная логика и реализация
Сначала сотовые операторы избавились от безлимита, так как оборудования нет столько, купить его негде, потом снизили скорость до 5 мбит,, теперь РКН занизило траффик на Ютьюб, видимо оборудования не будет
как объяснить что, если войти в ютуб, то видео моего канала воспроизводятся как раньше без задержек; если выхожу, то все видео (и моего канала в том числе) не воспроизводятся ?
Подскажите, в Спб sknt. Работает, запрет, byedpi андройд и линукс, но исключительно для приложения в андройде или на винде браузера. Телевизор какое-то время через раз загружал и работал отлично справляясь с 4к. Но сейчас даже не грузится главная, серый экран. Примерно 8 рабочих комбинаций, которые применимы мною для пк, не дают результата на ТВ. Я один такой?
Хочу сделать быстрым Ютуб. ЧИтая статью на хабре как это сделать через роутер (если плагин для хрома, то реклама вылазит постоянно на роликах).Делаю по хабру и таки ошибки:Помогите:1. Пишет ошибку в логе "Opkg::Manager: invalid initrc "/opt/etc/initrc": no such file or directory, trying /opt/etc/init.d/."(при попытке установки с флешки EN_mipsel-installer.tar.gz)2. Не соединяется по ssh по 222 порту. Только по 22 порту.3. Набирая команду в Putty: opkg update пишет ошибку: no souch command update (подлючиться смог только по порту 22)4. Написано на сайте КИнетика: "Важно! 222-й порт используется, если в роутере установлен компонент "Сервер SSH". Если он не установлен, используйте 22-й порт для подключения к Entware". Верно ли я понял, что это значит что у меня нет ssh на роутере?5. решил сменить прошивку думая что в новой прошивке будет поддержка уже сразу ssh на роутере. Или я не прав?пишет в Putty:(config)> mtd_write write /tmp/fw.trx Firmware_StubCommand::Base error[7405600]: no such command: mtd_write.(config)>
На AX-56U завелось на мерлиновском Entware. Единственный нюанс - в роутере работу скрипта не проверить, он сам по себе старый маршрут по-видимому использует, а вот устройства в локальной сети летают, в смысле показывают и скорость curl измеряет максимальную на всю ширину канала провайдера)
А вы не подскажете, как адаптировать вашу программу для любого сайта? Я не знаю, в чём дело, но уже три дня у меня хабр открывается не лучше ютуба. Причём, через VPN загрузка идёт гораздо бодрее, чем без него, что очень странно. Причём, пинги до требуемых адресов работают хорошо. Значит, почему-то провайдер режет. Он уверждал пару дней назад, что на него была DDos-атака (и инет почти лежал). Видимо, они там что-то заблокировали так, что хабр отвалился.
В вашей программе есть
#define DEFAULT_SNISTR "googlevideo.com,ggpht.com,ytimg.com,youtube.com,play.google.com,youtu.be,googleapis.com,googleusercontent.com,gstatic.com,l.google.com"
static const char defaul_snistr[] = DEFAULT_SNISTR;Тут понятно, что перечислены адреса, которые блокируются.
Есть
static const char fake_sni[] =В котором есть строка www.google.com. Причём, весь этот fake_sni как минимум завязан на размерность этой строки (если посмотреть протокол).
Я пробовал менять всё эти параметры - не работает. Чего-то не хватает. :)
О, как! Стоит эту страницу открыть не через vpn и...
Так что, похоже, блокируют и habr у меня.
Всё настраивается параметрами через аргументы к анблоку. Смотрите в ридми.
Замедление YouTube с технической стороны: ограничение и обход