Что нового в мире обхода блокировок в середине 2024
Представляю вашему вниманию короткий обзор что же произошло в России и в мире в области цензуры интернета и того, как этому противостоят энтузиасты. На всякий случай напоминаю, что статья «Надежный обход блокировок в 2024: протоколы, клиенты и настройка сервера от простого к сложному» заблокирована на Хабре для пользователей из РФ, но по-прежнему без проблем открывается через прокси/VPN с иностранных адресов. Ну, а мы сейчас разберем, что же изменилось с тех пор.
Сегодня в программе: Замедление YouTube — проблемы с Google Cache или намеренное вредительство? Можно ли заблокировать Shadowsocks и как РКН смог это сделать? Новые транспорты в XRay: HTTPUpgrade и SplitTunnel. Новости из мира Tor, и многое другое.
В очередной раз про Youtube
Начнем с того, что случилось буквально вот вчера: ограничение скорости к Youtube. Официальная позиция некоторых операторов связи звучит как «Раньше было много серверов Google Global Cache, они устаревают, поэтому все начинает тормозить». С одной стороны, звучит довольно правдоподобно, а с другой стороны — как-то довольно странно, что сразу у многих операторов в пятницу за одну ночь резко взяли устарели сервера GGC, которые еще за день до этого работали нормально.
Слышали про запланированное устаревание? Вот кое-кто его кажется и запланировал. На одном известном в узких кругах форуме люди проверяют разные гипотезы, и знаете что? В большинстве случаев «замедление» Youtube пропадает при использовании средств обхода ТСПУ типа GoodbyDPI и Zapret, осуществляющих фрагментирование поля SNI из хендшейка (которое содержит домен сервера назначения). То есть когда оборудование ТСПУ Роскомнадзора не может определить, что пользователь подключается к домену *.googlevideo.com, то все работает нормально, а когда может, то начинают потери пакетов, что вызывает резкое понижение скорости доступа, при том что и в том и в том случае подключение выполняется к одним и тем же IP-адресам.
Блокировка Shadowsocks, VMess, Outline
В конце апреля — начале мая, Роскомнадзор начал развлекаться с блокировками полностью шифрованных протоколов — таких как VMess и Shadowsocks (и следовательно использующего его Outline). Они попадали под блокировку и раньше, когда РКН, пытаясь заблокировать Телеграм-прокси во время некоторых событий, резал все «неопознанные» протоколы, но, понятное дело, такой подход имел огромный побочный ущерб (грубо говоря, переставало работать все, что не мог опознать ТСПУ, например, у людей отвалились клиенты Radmin). Теперь же все стало гораздо тоньше.
Суть блокировки можно проиллюстрировать вот такой картинкой:
На картинке мы не видим, что находится внутри удава, но по его внешней форме мы можем догадаться, что это.
Примерно так же реализовал блокировки РКН. В протоколах VMess и Shadowsocks отсутствуют какие-либо характерные признаки, а передаваемые данные полностью зашированы. Но при этом внутри них бегает самый обычный HTTPS с TLS, поэтому размеры передаваемых пакетов и их последовательности при TLS-хендшейке напрямую влияют на размеры передаваемых пакетов и их последовательности для транспортного проктокола типа Shadowsocks. Например, как минимум один шаблон блокировки на цензурирующем оборудовании для всех неопознанных протоколов выглядит так:
Клиент отсылает три пакета, каждый из которых содержит 411+ случайных байт
Сервер отсылает произвольное количество любых байт чаще, чем клиент отправляет свои пакеты
При выполнении этих условий подключение блокируется. Либо возможно блокируют по размеру пакетов, возможно, не по абсолютным цифрам, а по соотношению размера отправляемого к принимаемому.
Таблицу тестов на разных операторах можно найти здесь: 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 после такого и стоит ли им доверять — каждый решает сам для себя.
HTTUpgrade
Теперь о том, что же нового появилось в XRay и компании. Первая штука это транспорт «HTTUpgrade». По сути дела, те же вебсокеты, но с небольшим упрощением. Websockets — это расширение протокола HTTP, когда клиент и веб-сервер с помощью специального заголовка «Upgrade» договариваются «давай мы теперь будем слать данные не как запрос-ответ, а просто как захочется», и подключение переключается в режим «трубы для данных». Кроме этого, при обмене данных через вебсокеты каждый посланный пакет данных заворачивается в так называемый «вебсокет-фрейм». Сделано это потому, что протокол TCP (поверх которого и работают HTTP/HTTPS) — потоковый, то есть, грубо говоря, он не разделяет границы передаваемых данных. Например, вы шлете в TCP-поток сообщение длиной 50 байт, а спустя некоторое время еще одно сообщение длиной 50 байт. Нет никаких гарантий, что на другом конце данные будут получены точно так же в виде двух сообщений по 50 байт. Возможно сразу придет 100 байт одним куском, а может вообще прийти сначала 20 байт, потом 60 байт, и потом еще оставшиеся 20 байт. Поэтому в вебсокетах и добавляются специальные заголовки фреймов, чтобы контролировать эти границы и разработчики софта могли не ломать голову обо всем этом, а просто посылать сообщения и получать их на другой стороне ровно так же, как их и отправили.
Разработчики 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 родили неплохую идею. Они разделили подключение к прокси на две части — одну для отправки данных, другую для приема данных, а внутри соединения использовали механизм по типу 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 с исправлениями и улучшениями. В клиентах пока еще новый транспорт не появился, как обычно нужно подождать месяц-два.
WebTunnel
Tor тоже не стоит на месте. Если вы следите за тем, что происходит, то наверное знаете, что большинство публичных нод Tor в России и подобных странах заблокированы, поскольку их адреса доступны в открытых списках. Для решения этой проблемы еще долгое время назад был придуман механизм «бриджей» (мостов), адреса которых выдаются точечно пользователям их запросившим. Долгое время стандартным транспортом для таких бриджей был obfs4, по принципу похожий на упомянутый выше Shadowsocks и VMess со всеми соответствующими недостатками (см. How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic | USENIX). Разрабочтики Tor, в соответствии с веяниями времени, ищут новые вариантов транспортов, и недавно в экспериментальном режиме запилили новый транспорт для бриджей под названием WebTunnel. Да, это те же самые веб-сокеты :)
Пока что запросить адрес бриджа типа 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) чтобы запросы на «секретный URL» передавались на Tor.
Ресурсов оно потребляет не много, вполне себе без проблем работает VPS с 512 мегабайтами ОЗУ, а на машинку с гигабайтом памяти можно водрузить даже сразу два Tor-бриджа (вы можете поднимать до двух бриджей на одном IP-адресе). Трафика оно генерирует не много, в зависимости от того, скольким пользователям достался ваш бридж, обычно не более десятка мегабит в секунду.
Что делать, если вы хотите помочь, у вас нет сайта и домена, но есть сервер? Поднимите Snowflake-бридж! Snowflake — еще один вариант pluggable transports для Tor, используются WebRTC (примерно как видеозвонки в месседжерах). Установка его очень простая, буквально в два шага: можно использовать Docker, а можно скачать и собрать бинарник самому. Каждый час проксик пишет в логи статистику, сколько пользователей к вам было подключено за это время и сколько данных было передано. Snowflake-proxy написан на Go, не требует никаких зависимостей. Важно, чтобы на фаерволе были открыты UDP порты 30000–60000.
Что делать, если вы хотите помочь, но у вас нет ни сайта, ни домена, ни сервера, вы вообще далеки от всего этого, но живете в стране, где 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 и т.д. Ради интереса я даже потратил немного денег и время, чтобы изучить, то это такое и как оно работает… И мама миа!
Бизнес-идея, посетившая явно не одного человека (подозреваю, что чаще всего это школьники старших класов или студенты) очень проста:
Покупаем парочку самых дешевых VPS за 200–300 рублей в месяц
Ставим туда XRay (нередко даже сразу панелью X-UI или Marzban)
Прикручиваем к этом Telegram-бота для приема платежей и продажи «подписок»
Продаем эти «подписки» за 200–300–500 рублей десяткам или даже сотням пользователей
???
PROFIT!
О качестве подобных «сервисов», вы уже, наверное, догадались. Из того, что обнаружил я практически у всех из них:
1. Скорость и стабильность так себе, нередко ощутимо лагает;
2. Выходные IP-адреса часто отравленные (гугл требует капчу на каждый чих, Instagram просто периодически перестает пускать);
3. Никаких гарантий, сервис может сломаться и перестать работать в любой момент. Заплатили деньги за месяц вперед или даже больше? Кому должен — всем прощаю!
4. Настроено нередко все довольно криво и с детскими ошибками. MiraclePtr, автор легендарных статей про правильную настройку XRay, наверное до сих бы совершил сепукку, если бы узнал, как люди следуют его инструкциям и внемлют его предупреждениям;
5. Самое интересно, что сервисы за 400–500 рублей работают ничуть не лучше сервисов за 100–200. Более того, чем громче владельцы подобных сервисов кричат в чатах о том, что «уж у них-то все нормально, поэтому и стоит дороже», тем больше риск обнаружить, что у них все сделано еще более через задницу и работает соответствующе.
Впрочем, встретилась мне пара товарисчей, у которых все сделано более-менее по уму и работает неплохо, но учитывая, так сказать, их взгляды и риторику в чатах, я не удивлюсь, если рано или поздно окажется, что все логи доступа всех своих пользователей они сливают куда-нибудь в органы, так сказать, проявляют гражданскую бдительность.
Мораль какая? Не пользуйтесь услугами мутных сервисов от всяких анонимусов, если не хотите потерять деньги и получить фигню. Самый лучший прокси-сервер — который вы подняли сами, благо что сделать это можно очень просто (см. инструкцию от MiraclePtr, она недоступна из России, но можно открыть ее через прокси/vpn). Если для вас это все равно сложно — то используйте AmneziaVPN, которых я уже упоминал выше.
Если и это слишком сложно — есть AmneziaFree и VPN Generator (см. также их тг-канал). Оба проекта бесплатные (некоммерческие, так что не реклама) и устойчивые к блокировкам.
А если уж вам так хочется отдать кому-нибудь деньги — то лучше предпочтите известные проекты, за которыми стоят известные сетевые активисты. Благо, многие из них тоже серьезно озаботились обходом блокировок и предлагают в том числе протоколы семейства VLESS и XTLS.
