Что нового в мире обхода блокировок Интернета в середине 2024

Представляю вашему вниманию короткий обзор что же произошло в России и в мире в области цензуры интернета и того, как этому противостоят энтузиасты. На всякий случай напоминаю, что статья "Надежный обход блокировок в 2024: протоколы, клиенты и настройка сервера от простого к сложному" заблокирована на Хабре для пользователей из РФ, но по-прежнему без проблем открывается через прокси/VPN с иностранных адресов. Ну а мы сейчас разберем, что же изменилось с тех пор.

Сегодня в программе: Замедление YouTube - проблемы с Google Cache или намеренное вредительство? Можно ли заблокировать Shadowsocks и как РКН смог это сделать? Новые транспорты в XRay: HTTPUpgrade и SplitTunnel. Новости из мира Tor, и многое другое.

В очередной раз про Youtube

Начнем с того, что случилось буквально вот вчера: ограничение скорости доступа к Youtube в России. Официальная позиция некоторых операторов связи звучит как "Раньше было много серверов Google Global Cache, они устаревают, поэтому все начинает тормозить". С одной стороны, звучит довольно правдоподобно, а с другой стороны - как-то довольно странно, что сразу у многих операторов в пятницу буквально за одну ночь резко взяли и устарели сервера GGC, которые еще за день до этого работали нормально.

Слышали про запланированное устаревание? Вот кое-кто его кажется и запланировал. На одном известном в узких кругах форуме люди проверяют разные гипотезы, и знаете что? В большинстве случаев "замедление" Youtube пропадает при использовании средств обхода ТСПУ типа GoodbyDPI и Zapret, осуществляющих фрагментирование поля SNI из хендшейка (которое содержит домен сервера назначения). То есть когда оборудование DPI Роскомнадзора не может определить, что пользователь подключается к домену *.googlevideo.com, то все работает нормально, а когда может, то начинаются дропы пакетов, что вызывает резкое понижение скорости передачи данных, при том что и в том и в том случае подключение выполняется к одним и тем же IP-адресам.

Вывод очевиден.

Блокировка Shadowsocks, VMess, Outline

В конце апреля - начале мая, Роскомнадзор начал развлекаться с блокировками полностью шифрованных протоколов - таких как VMess и Shadowsocks (и следовательно использующего его Outline). Они попадали под блокировку и раньше, когда РКН, пытаясь заблокировать Телеграм-прокси во время некоторых событий, резал все "неопознанные" протоколы, но, понятное дело, такой подход имел огромный побочный ущерб (грубо говоря, переставало работать все, что не могли опознать ТСПУ, например, у людей отвалились клиенты Radmin). Теперь же все стало гораздо тоньше.

Суть блокировки можно проиллюстрировать вот такой картинкой:

На картинке мы не видим, что находится внутри удава, но по его внешней форме мы можем догадаться, что это.

Примерно так же реализовал блокировки РКН. В протоколах VMess и Shadowsocks отсутствуют какие-либо характерные признаки, а передаваемые данные полностью зашированы. Но при этом внутри них бегает самый обычный HTTPS с TLS, поэтому размеры передаваемых пакетов и их последовательности при TLS-хендшейке напрямую влияют на размеры передаваемых пакетов и их последовательности для транспортного проктокола типа Shadowsocks. Например, как минимум один шаблон блокировки на цензурирующем оборудовании для всех неопознанных протоколов выглядит так:

1. Клиент отсылает три пакета, каждый из которых содержит 411+ случайных байт

2. Сервер отсылает произвольное количество любых байт чаще, чем клиент отправляет свои пакеты

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

Таблицу тестов на разных операторах можно найти здесь: Analysis of blocking in Russia. All entries in one table. (github.com)

Полностью восстановленный граф логики работы блокировок выглядит как-то так (версия в высоком разрешении):

Интересующихся отправляю в пост на том же форуме, где люди детально проанализировали поведение блокировок на разных провайдерах (Ростелеком, Эр-Телеком, Уфанет, МТС, Мегафон, Билайн), собрали дампы и выявили закономерности. Также существует тред на известной борде Net4People: Blocking of fully encrypted protocols (Shadowsocks, VMess) in Russia, targeting HTTPS traffic fingerprints · Issue #363 · net4people/bbs (github.com)

Удаление VPN-приложений из AppStore

В начале июля Apple по запросу от Роскомнадзора удалила из магазина AppStore несколько приложений сервисов VPN, которые используются для обхода блокировок. Известно о как минимум четырех - Proton VPN, Red Shield VPN, NordVPN и Le VPN. Как относится к Apple после такого и стоит ли им доверять - каждый решает сам для себя.

HTTPUpgrade

Теперь о том, что же нового появилось в XRay и компании. Первая штука это транспорт "HTTPUpgrade". По сути дела, те же вебсокеты, но с небольшим упрощением. Websockets - это расширение протокола HTTP, когда клиент и веб-сервер с помощью специального заголовка "Upgrade" договариваются "давай мы теперь будем слать данные не как запрос-ответ, а просто как захочется", и подключение переключается в режим "трубы для данных". Кроме этого, при обмене данных через вебсокеты каждый посланный пакет данных заворачивается в так называемый "вебсокет-фрейм". Сделано это потому, что протокол TCP (поверх которого и работают HTTP/HTTPS) - потоковый, то есть он не разделяет границы передаваемых данных. Например, вы шлете в TCP-поток сообщение длиной 50 байт, а спустя некоторое время еще одно сообщение длиной 50 байт. Нет никаких гарантий, что на другом конце данные будут получены точно так же в виде двух сообщений по 50 байт. Возможно сразу придет 100 байт одним куском, а может вообще прийти сначала 20 байт, потом 30 байт, потом ещё 40 байт и потом еще оставшиеся 10 байт. Поэтому в вебсокетах и добавляются специальные заголовки фреймов, чтобы контролировать эти границы и разработчики софта могли не ломать голову обо всем этом, а просто посылать сообщения и получать их на другой стороне ровно так же, как их и отправили.

Авторы XRay сообразили, что для целей проксирования это все не нужно. В случае с проксированием TCP все это делается на уровне самих протоколов и приложений, трафик которых вы проксируете, а в случае с UDP - на уровне прокси-протокола. Поэтому они создали транспорт под названием HTTPUpgrade, который устанавливает соединение точно так же, как и обычные веб-сокеты (заголовком "Upgrade"), но шлет информацию без дополнительного оборачивания в вебсокетные фреймы. В итоге передача данных получается более эффективной (меньше оверхеда на заголовки), такой трафик сложнее детектировать, и он по-прежнему позволяет пролезать через веб-серверы и популярные CDN (которых совершенно не волнует наличие или отсутствие заголовков вебсокет-фреймов, они просто передают данные как есть).

В XRay HTTPUpgrade появился еще несколько месяцев назад, и его поддержка уже появилась во многих популярных клиентах.

SplitTunnel

Дальше интереснее. Что если мы хотим проксировать трафик через CDN или корпоративные шлюзы, но они не пропускают веб-сокеты? Например, поддерживают веб-сокеты Cloudflare, Amazon Cloudfront и Gcore, а вот Fastly просит за них отдельных денег, а MS Azure и CDN77 вообще не умеют работать с веб-сокетами. И это очень обидно, потому что именно такие "не умеющие" CDN до сих пор разрешают domain fronting (статья о нем тут, запрещена в России, но доступна через прокси/VPN). Помните про XTLS-Reality, который позволяет маскироваться под настоящий чужой домен с настоящим TLS-сертификатом? Вот domain fronting позволяет делать примерно то же самое, но через CDN.

Проблема в том, что если мы не используем веб-сокеты, то мы ограничены только обычными HTTP-запросами. И взаимодействие в этом случае может быть только вида "запрос-ответ", то есть не получив ответ, мы не можем послать следующий запрос. Долгое время единственным вариантом работать в таком режиме и позволяющим пролезать через подобные CDN был транспорт Meek от разработчиков Tor. Работает он до неприличного просто: устанавливаем соединение, и в бесконечном цикле посылаем GET/POST запросы и ждем ответы. Если нам есть что отправить на прокси-сервер, оно будет послано в запросе, если есть какие-то данные, которые сервер хочет послать нам, мы их получим в ответе. Работало это все довольно медленно, и создавало существенную нагрузку и на удаленный сервер, и на CDN, даже в те моменты, когда никаких данных не передавалось.

И вот тут разработчики XRay родили неплохую идею под названием SplitTunnel. Они разделили подключение к прокси на две части - одну для отправки данных, другую для приема данных, а внутри соединения использовали механизм по типу long polling. В итоге получилось круто - уже нет нужды каждую секунды гонять туда-сюда запросы и ответы, можно ограничиться только несколькими подключениями, а заодно трафик "туда" и трафик "обратно" идут разными путями, что существенно затрудняет его анализ и блокировку.

Одно но необходимо чтобы CDN и веб-сервер не буферизовали данные в запросах и уважали заголовок `X-Accel-Buffering: no`. Я тестировал, Gcore CDN работает с таким транспортом без проблем, CF и Amazon еще не проверял, кто пробовал - расскажите, как оно там. Из веб-серверов точно работает Nginx и Apache, а вот через Caddy происходит затык, возможно нужно что-то докрутить в конфиге.

Как и HTTPUpgrade, SplitTunnel - это только лишь транспорт для других протоколов. А в качестве прокси-протокола внутри SplitTunnel можно использовать известные всем VLESS или Trojan.

Поддержка SplitTunnel появилась в версии XRay 1.16, а буквально вчера вышла версия 1.17 с исправлениями и улучшениями. В клиентах пока еще новый транспорт не появился, как обычно нужно подождать месяц-два.

Tor и WebTunnel

Tor тоже не стоит на месте. Если вы следите за тем, что происходит, то наверное знаете, что большинство публичных нод Tor в России и подобных странах заблокированы, поскольку их адреса доступны в открытых списках. Для решения этой проблемы уже давно был придуман механизм "бриджей" (мостов), адреса которых выдаются точечно пользователям их запросившим. Долгое время стандартным транспортом для таких бриджей был obfs4, по принципу похожий на упомянутые выше Shadowsocks и VMess со всеми вытекающими недостатками (см. How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic | USENIX). Разработчики Tor, в соответствии с веяниями времени, ищут новые вариантов транспортов, и недавно в экспериментальном режиме запилили новый транспорт для бриджей под названием WebTunnel. Да, это те же самые веб-сокеты, которые со стороны видны как обычный HTTPS :)

Пока что запросить адрес бриджа типа WebTunnel можно только через сайт: https://bridges.torproject.org/options. Бриджи этого типа поддерживаются уже во всех официальных клиентах. В мобильном Tor Browser отдельного пункта при выборе типа бриджа нету, но при вставке строки подключения с WebTunnel-бриджом он ее правильно подхватывает и подключается как надо.

Выглядит строка подключения примерно так:

webtunnel [2001:db8:f9e3:eb5a:eeee:3d:1da5:166e]:443 13EA8F4B49276D43ABCDED91C5B3976F599C url=https://someserver.com/ThJwaIl5uOzrpQnZPJBEKsA2 ver=0.0.1

Не пугайтесь, что в строке вы видите что-то похожее на IPv6-адрес, а у вас нет IPv6. Для WebTunnel точкой входа является доменное имя. А то что вы видите 2001:db8::/32 - это, скажем так, особенность архитектуры бриджей Tor, у которых всегда обязательно должен быть IP-адрес, а поскольку для webtunnel-бриджей IP-адрес явно предоставлять нет смысла, то они придумали такой костыль и генерируют виртуальные IP-адреса из "несуществующего" диапазона (этот диапазон зарезервирован в стандарте для документации и примеров).

Call for bridges!

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

Если у вас есть свой VPS с каким-нибудь сайтом и доменом - установите на сервер Tor с режиме бриджа с WebTunnel-транспортом!
Ручная установка не проста, но вот с использованием Docker это можно сделать очень легко. Потребуется только отредактировать .env-файл, задав там свой домен и придумав какой-нибудь "секретный URL", запустить Docker-контейнер, и прописать в конфиг вашего веб-сервера (точно работает с Nginx и Caddy) правило (location) чтобы запросы на "секретный URL" передавались в Tor.

Ресурсов оно потребляет немного, вполне себе без проблем работает VPS с 512 мегабайтами ОЗУ, а на машинку с гигабайтом памяти можно водрузить даже сразу два Tor-бриджа (вы можете поднимать до двух бриджей на одном IP-адресе). Трафика оно генерирует тоже немного, в зависимости от того, скольким пользователям достался ваш бридж, первое время совсем мало, а когда ваш бридж попадет в раздачу - обычно не более десятка мегабит в секунду.

Что делать, если вы хотите помочь, у вас нет сайта и домена, но есть сервер? Поднимите Snowflake-бридж! Snowflake - еще один вариант pluggable transports для Tor, в нем используется WebRTC (примерно как видеозвонки в месседжерах). Установка такого бриджа его очень простая, буквально в два шага: можно использовать Docker, а можно скачать и собрать бинарник самому. Каждый час он пишет в логи статистику, сколько пользователей к вам было подключено за это время и сколько данных было передано. Snowflake-proxy написан на Go, не требует никаких зависимостей. Важно, чтобы на фаерволе были открыты UDP порты 30000-60000. Трафик будет также в среднем от 5 до 10 мегабит в секунду.

Что делать, если вы хотите помочь, но у вас нет ни сайта, ни домена, ни сервера, вы вообще далеки от всего этого, но живете в стране, где Tor не забанен, и хотите сделать доброе дело? Установите расширение для браузера Snowflake. Оно работает в Firefox, Chrome, Edge. Когда вы его активируете в браузере, ваш компьютер начнет работать как Snowflake-прокси. Разработчики Tor прекрасно понимают, что важно не создавать неудобств пользователям-волонтерам, поэтому число одновременно подключенных к вам клиентов будет ограничено двумя. Вам может показаться, что это очень мало, но на самом деле именно такие "домашние" snowflake-бриджи и имеют максимальную ценность - потому что во многих странах с сильной интернет-цензурой фильтруются подключения к IP-диапазонам крупных хостинг-провайдеров, а вы с вашим Residential IP можете оказаться той самой палочкой-выручалочкой.

И да, тут нужно рассказать про один миф, связанный с Tor. Когда люди слышат "поднимите у себя Tor-бридж", то сразу же начинают думать, что в этом случае с их адреса кто-то сможет выходить в интернет и сделать от их имени какие-то нехорошие вещи. Нет, нет и еще раз нет. Не нужно путать бриджи (bridges), и выходные ноды (exit nodes), с которыми действительно такое может произойти. Если вы поднимаете у себя bridge, то ваш адрес будет использоваться только для соединения клиентов из стран с интернет-цензурой с другими нодами Tor. Tor-цепочки обычно состоят из трех хостов, и когда у вас работает bridge, вы можете быть только первым узлом этой цепочки, но уж никак не последним. Абсолютно никакого риска это не несет, зато вы делаете доброе дело и помогаете людям во всем мире с борьбой с государственной интернет-цензурой.

AmneziaVPN

AmneziaVPN тоже не стоит на месте. За последние месяцы у них много нового. Добавили killswitch, добавили split tunneling для Windows и Android, а ещё они уже давно экспериментируют с XRay и недавно добавили поддержку XRay для iOS и Android.

Changelog можно найти здесь: Releases · amnezia-vpn/amnezia-client (github.com), ну и заглядывайте в их блог Amnezia VPN

Meanwhile in Telegram...

И в конце лирическое отступление. Некоторое время назад я набрел на Telegram-группы и telegram-ботов, продающих "подписки" (или "ключи", это то же самое) для прокси-серверов с VLESS, XTLS-Reality и т.д. Ради интереса я даже потратил немного денег и время, чтобы изучить, то это такое и как оно работает... И мама миа!

Бизнес-идея, посетившая явно не одного человека (подозреваю, что чаще всего это школьники старших класов или студенты) очень проста:

1. Покупаем парочку самых дешевых VPS-виртуалок за 200-300 рублей в месяц

2. Ставим туда XRay-сервер (нередко даже сразу панелью X-UI или Marzban)

3. Прикручиваем к этом Telegram-бота для приема платежей и продажи "подписок"

4. Продаем эти "подписки" каждую за 200-300-500 рублей десяткам или даже сотням пользователей

5. ????

6. PROFIT!

О качестве подобных "сервисов", вы уже, наверное, догадались. Из того, что обнаружил я практически у всех из них что я проверял:

1. Скорость и стабильность так себе, лагает;
2. Выходные IP-адреса часто отравленные (гугл требует капчу на каждый чих, Instagram просто периодически перестает пускать);
3. Никаких гарантий, сервис может сломаться и перестать работать в любой момент. Заплатили деньги за месяц вперед или даже больше? Кому должен - всем прощаю! Техподдержки тоже либо вообще никакой, либо "попробуйте выключить и включить" с последующим игнором;
4. В плане устойчивости к блокировкам настроено нередко все довольно криво и с детскими ошибками. MiraclePtr, автор легендарных статей про правильную настройку XRay, наверное бы совершил сепукку, если бы узнал, как люди следуют его инструкциям и внемлют его предупреждениям;
5. Самое интересно, что сервисы за 400-500 рублей работают ничуть не лучше сервисов за 100-200. Более того, чем громче владельцы подобных сервисов кричат в чатах о том, что "уж у них-то все нормально, поэтому и стоит дороже", тем больше риск обнаружить, что у них все сделано еще более через задницу и работает соответствующе.
Впрочем, встретилась мне пара товарисчей, у которых все сделано более-менее по уму и работает неплохо, но учитывая, так сказать, их взгляды и риторику в чатах, я не удивлюсь, если рано или поздно окажется, что все логи доступа всех своих пользователей они сливают куда-нибудь в органы, так сказать, проявляют гражданскую бдительность.

Мораль какая? Не пользуйтесь услугами мутных сервисов от всяких анонимусов, если не хотите потерять деньги и получить фигню. Самый лучший прокси-сервер - который вы подняли сами, благо что сделать это можно очень просто (см. инструкцию от MiraclePtr, она недоступна из России, но можно открыть ее через прокси/vpn).

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

Если и это слишком сложно - есть публичные сервисы AmneziaFree и VPN Generator (см. также их тг-канал). Оба проекта бесплатные (некоммерческие, так что не реклама) и устойчивые к блокировкам.

А если уж вам так хочется отдать кому-нибудь деньги - то лучше предпочтите известные проекты, за которыми стоят известные сетевые активисты. Благо, многие из них тоже серьезно озаботились обходом блокировок и предлагают в том числе протоколы семейства VLESS и XTLS.