#FREEWWW
Современные технологии организации VPN: V2Ray, XRay, XTLS, Hysteria, Cloak!
Данный опус является частью единого цикла заметок o CLI. Для его написания использовалось множество различных источников (скилы крутых специалистов, статьи с тематических сайтов, техническая документация, комментарии с форумов и социальных сетей и т. д и т. п.). К сожалению, указать все источники точно не представляется возможным! По этому, в конце заметки, будет указана ссылка только на основной источник. Материалы, использованные для написания заметки, изменялись автором под конкретную задачу! Вам, скорее всего, тоже придется поступить аналогичным образом для получения желаемого результата)
В оригинальной статье автор обсуждает несколько прокси протоколов и инструментов, которые помогают бороться с цензурой и брандмауэрами(основываясь перимущественно на опыте наших китайских коллег) , включая Shadows ocks , V 2Ray , XRay , Trojan , Naive proxy , Cloak , KCP и Hysteria . Эти протоколы и инструменты позволяют пользователям получать доступ к заблокированным веб -сайтам и службам , скрывая свои IP - адреса , шифруя трафик или используя альтернативные протоколы .
Некоторые из этих инструментов также предоставляют такие функции , как откат к HTTP / 2 или отпечатку пальцев Chrome / Firefox , предотвращение обнаружения активного зондирования и заполнение для запутывания .
KCP ( kc pt un) и mK CP — это транспортные протоколы с низкой задержкой , которые работают через U DP и могут обходить сетевые ограничения благодаря низкой задержке и высокой пропускной способности.
Hysteria — это прокси - инструмент , который использует протокол Q UIC (HTTP/3 ) для передачи данных с малой задержкой и поддерживает получение сертификата ACME для шифрования TLS . Он также обеспечивает ложный режим TCP , который имитирует TCP- пакеты , минуя брандмауэры, которые блокируют UDP- трафик.
FakeTCP поддерживается только в Linux . Автор отмечает , что некоторые из этих инструментов недостаточно известны и широко не используются , что потенциально снижает вероятность их блокировки цензорами или брандмауэрами.
Ссылка на первоисточник - origin.
Shadowsocks, ShadowsocksR, Shadowsocks-AEAD, Shadowsocks-2022
Начнем, по традиции, с “дедушки”, прародителя многих других современных средств обхода блокировок - протокола Shadowsocks.Идея Shadowsocks проста: авторы взяли классический SOCKS-протокол, который передает все данные в открытом виде и поэтому очень легко детектируется на DPI, прикрутили к нему шифрование разными алгоритмами, выкинули ненужный функционал (например, нет нужды в авторизации по логину и паролю, проверка свой/чужой определяется ключом шифрования), и добавили несколько других штук для усложнения детектирования. И это сработало - долгое время Shadowsocks был излюбленным инструментом тысяч людей, позволяющим пробиваться через великий китайский файервол.
Оригинальный Shadowsocks был разработан программистом с ником “clowwindy”. В 2015 году clowwindy написал в своем Github, что к нему нагрянула китайская полиция и сделала предложение, от которого не было возможности отказаться, и в результате чего он был вынужден прекратить работу над проектом и удалить все исходники из репозитория.
После этого другие энтузиасты создали форк под названием ShadowsocksR и продолжили дело. Через некоторое время разработка ShadowsocksR заглохла, но развитие протокола продолжилось в разных других репозиториях под оригинальным названием. В изначальном протоколе ShadowSocks исследователи обнаружили ряд уязвимостей, позволявших его индентификацию и блокировку (например, с помощью replay-атак), поэтому в 2017 году появился Shadowsocks-AEAD с измененным алгоритмом аутентификации, а в прошлом году была выпущена новая версия протокола под названием Shadowsocks-2022, в которой авторы продолжили работу по улучшению устойчивости протокола к блокировкам. Все эти версии между собой не совместимы.
Со стороны цензоров подключение через Shadowsocks, если вы не используете какие-либо дополнительные расширения для маскировки под TLS (Shadow-TLS) или Websockets, выглядит как непонятное нечто - просто не похожий ни на что поток данных. Старые версии Shadowsocks уже давно не считаются надежными и устойчивыми к выявлению, однако современные версии протокола до недавних пор вполне себе могли использоваться как средство обхода блокировок в случае если цензоры спокойно относятся к “неопределенным” протоколам. В конце 2022 года группа исследователей под названием GFW-report опубликовала отчет о том, что цензоры научились выявлять подобные “неопределенные” протоколы по… отношению количества 0 и 1 битов в потоке данных. Ими была выпущена специально пропатченная версия shadowsocks, однако во-первых пропатченные клиент и сервер не совместимы с “обычными версиями”, а во-вторых патч подходит только для старых версий протокола, но не для Shadowsocks-2022 (авторы сказали, что работают над этим). Из сторонних клиентов поддержка этого хака под названием ReducedIvHeadEntropy есть только в SagerNet и V2Ray и отсутствует практически во всех GUI-клиентах.
Оригинальный Shadowsocks был написан на C с использованием библиотеки libev. Данная версия более не развивается, основная актуальная на сегодняшний день реализация написана на Rust. Между тем, протоколы Shadowsocks разных версий поддерживаются в том числе и в других клиентах и серверах (таких как V2Ray, XRay, SagerNet, Sing-box, и т.д.), о которых речь пойдет позже, поэтому Shadowsocks вполне можно рассматривать как запасной вариант, активировав его на одном сервере с другими протоколами.
Наряду с Shadowsocks и V2Ray протокол Trojan является одним из первых и популярных способов обхода блокировок в Китае, и по принципу работы в принципе соответствует своему названию :) Для стороннего наблюдателя работа через него выглядит как подключение к обычному веб-серверу, но на самом деле это веб-сервер с подвохом секретом (аки троянский конь).
Trojan работает поверх TLS (точно так же как HTTPS). После установления TLS-сессии сервер ожидает хендшейк в специальном формате, одним из полей которого является хеш секретного ключа. Если сообщение и ключ корректны - дальше сервер работает как прокси, если нет - запрос передается на стоящий рядом веб-сервер, и таким образом имитируется работа безобидного сайта через HTTPS.
Trojan-GFW и Trojan-Go:
Trojan-GFW - оригинальная версия, написанная на C++. Trojan-Go - продолжение проекта, теперь уже на языке Go . Trojan поддерживается многими мультипротокольными клиентамии серверами типа Sing-box и V2Ray/XRay - в этом случае вместе с Trojan также можно использовать упомянутые выше фичи uTLS и XTLS, что повышает надежность протокола и уменьшает вероятность его детектирования. Если вы внимательно читали до этого, то Вам сразу же станет понятно, что Trojan в принципе аналогичен VLESS+TLS с настроенным fallback на веб-сайт. Каких-либо явных преимуществ перед VLESS+TLS у Trojan лично я не вижу, можно относиться к нему как к еще одной альтернативе.
Naiveproxy
Идея Naiveproxy, опять же, простая до невозможности. Если наша цель - замаскировать трафик от прокси-клиента так, чтобы он был вообще ничем неотличим от трафика от обычного браузера - почему бы не использовать для этого сам браузер?
Именно так и рассудил автор Naiveproxy и сделал следущее: взял исходники браузера Chromium, оторвал оттуда код сетевого стека, и использовал его в своем прокси-клиенте, причем в качестве прокси-протокола используется самый обычный метод CONNECT + HTTP/2.
В итоге одним выстрелом убивается сразу несколько зайцев:
- TLS finerprint и вообще поведение такого подключения полностью до мельчайших деталей соответствует настоящему браузеру Chromium - более того, автор периодически синхронизируется с кодовой базой Chromium, чтобы иметь самые новые версии его сетевого стека, и таким образом максимально соответствовать свежим версиям браузера;
- Определение паттернов трафика, характерных для определенных веб-сайтов, затрудняется благодаря HTTP/2 мультиплексированию;
- Определение свой/чужой, чтобы не демаскировать прокси при active probing осуществляется посредством стандартных HTTP-заголовков (“Proxy-Authorization”). Если там содержатся правильные данные - ларчик открывается, если нет, либо же заголовки отсутствуют - сервер делает вид, что не понимает, что от него хотят и выдает фейковый сайт.
В теории, на “той стороне” в качестве прокси-сервера может выступать вообще любой сервер, поддерживающий метод CONNECT (например, tinyproxy), а авторизацию “свой-чужой” можно сделать с помощью reverse-proxy такого как HAProxy. Однако гораздо лучше использовать реализации, знающие про особенности naiveproxy - в таком случае в пакеты данных также добавляется padding (грубо говоря, мусорные данные, не несущие смысловой нагрузки) для усложнения анализа паттернов трафика. Это может быть, например, сам naiveproxy на сервере, или же патченный плагин для известного веб-сервера Caddy.
Cloak
Посоветовали тут в комментариях. Штука интересная. Cloak - это не прокси-протокол, а только транспорт, то есть он делает подключение "точка-точка" (между вашим устройством и сервером), а внутри него уже можете гонять тот же Shadowsocks, или OpenVPN, или что угодно.
Работает поверх TLS 1.3, "свой/чужой" определяется по содержимому полей в ClientHello специальным образом (видимо очень схожим с XTLS-Reality), если "чужой" - то подключение передается на фейковый веб-сайт. Также используется TLS fingerprint от Chrome либо Firefox. Механизмы обфускации и подключения подробно описаны вот здесь: https://github.com/cbeuw/Cloak/wiki/Steganography-and-encryption. Есть также клиент под Android, и ещё транспорт Cloak поддерживается в некоторых мультпротокольные клиентах (например, Shadowrocket.
Если вы не хотите разбираться со всеми этими V2Ray, XRay, и подобным, у вас уже все настроено, и вы просто хотите обезопасить ваш существующий сервер (например, OpenVPN) от блокировки, то Cloak может быть отличным выбором
KCP (kcptun), mKCP
В сравнении со всем описанным выше, KCP - это протокол совершенно другого рода.
Авторы KCP переосмыслили алгоритмы передачи данных и разработали протокол, который работая поверх UDP обеспечивает надежную передачу, так же как TCP, но при этом в сравнении с TCP средняя задержка (пинг) при его использовании ниже на 30–40 %, а максимальная задержка меньше в три раза (правда, за счет потери полосы пропускания на 10–20%).
И все это как нельзя кстати оказалось для обхода блокировок, потому что в Китае и в некоторых арабских странах “неизвестные” протоколы нередко не блокировались полностью, а то ли намеренно, то ли из-за кривости механизмов фильтрации резались путем замедления и потерь пакетов. Также KCP может быть полезным при работе через отвратительные соединения (например, олдовый 3G в условиях плохого покрытия сети).
Для эффективной работы KCP требует указания в конфигурации измеренной реальной пропускной способности канала на прием и передачу.
Теперь разберемся с версиями и реализациями.
KCP - это оригинальный протокол.
Kcptun - реализация туннеля на основе KCP.
mKCP - это вариант протокола KCP от V2Ray - по сути дела тот же KCP, но с небольшими изменениями (KCP и mKCP между собой не совместимы, имейте в виду). В V2Ray/XRay mKCP не является самостоятельным прокси-протоколом, а только лишь транспортом - то есть поверх него все так же нужно использовать VMess или VLESS. V2Ray/XRay имеют также опцию “congestion” для автоматической перенастройки параметров канала в случае высоких потерь пакетов, как и в оргигинальном kcptun можно задать секретный ключ (тут он называется “seed”) для усложнения детектирования, а еще можно маскировать внешний вид UDP-пакетов под SRTP (используемый, например, в Apple FaceTime), uTP (Bittorrent), WeChat, и DTLS (используемый в WebRTC, например, многими месседжерами).
Hysteria
Hysteria во многом очень похож на KCP, а ещё на всем известный QUIC, и авторы то ли вдохновлялись их механизмами, то ли напрямую в какой-то мере переиспользовали их. Кто авторы - тоже неизвестно, они сохраняют анонимость, документация на официальном сайте только на английском и китайском языке, но в примерах конфигурации среди секретных ключей встречается строка “Мать-Россия”, прямо так, кириллицей, что наталкивает на размышления.
Hysteria - это прокси-инструмент, как и Kcptun предназаченный для работы через нестабильные сети с потерями пакетов, ну и обхода блокировок, само собой.
В отличие от KCP, Hysteria передает данные не просто поверх UDP, а с использованием протокола QUIC (HTTP/3). Поэтому для работы на сервере должен иметься TLS-сертификат, сервер Hysteria умеет автоматически запрашивать сертификаты методом ACME (например, от Let’s Encrypt). Поскольку QUIC часто полностью блокируется в ряде стран (в том числе и в России), есть также возможность установить ключ для обфускации данных, в результате чего UDP-пакеты становятся ни на что не похожи.
Также как и для KCP, на стороне клиента Hysteria необходимо задать доступную ширину канала (например, в мегабитах), а еще есть интересный режим port hopping - разработчики подметили, что в Китае при детектировании “неправильных протоколов” бан накладывается не на весь IP-адрес целиком, а на связку IP+порт, поэтому сервер может слушать сразу на большом количестве портов, а “клиент” может прыгать на разные рандомные порты при неудачных попытках соединения.
И еще одна интересная возможность Hysteria - FakeTCP. В этом режиме клиент и сервер будут обмениваться пакетами, которые выглядят как TCP-пакеты (согласно их заголовку), но в обход системного TCP-стека и его механизмов. В итоге для всех промежуточных роутеров и цензоров обмен данными выглядит как TCP-подключение, хотя на самом деле им не является. Это может помогать в случае использования корпоративных фаерволов или цензоров, полностью режущих UDP. FakeTCP поддерживается только в Linux.
Meiru, TUIC, Brook, Pingtunnel
Эти протоколы вы мало где встретите, разве что только в самых упоротых клиентах. Я не встречал на просторах интернета упоминания их массового использования, поэтому просто пройдусь очень кратко, для общего развития, так сказать:
Meiru - аналог Shadowsocks / VMess+TCP, просто зашифрованный поток данных с паддингом поверх TCP или UDP.
TUIC - прокси-протокол поверх QUIC нацеленный на минимальный оверхед (0-RTT)
Brook - официально называется даже не прокси, а “cross-platform network tool designed for developers”, видимо, чтобы не привлекать внимание цензоров, хотя в футере сайта есть гордое заявление “Undetectable Protocol”. Информации об идеях в основе протокола и его преимуществах практически нет даже на официальном сайте и Github’е, судя по обрывочным данным, может работать в режиме “random” (как и Shadowsocks, непонятный поток данных), HTTP/HTTPS, в том числе поверх Websockets, и т.д. Возможно разработчики действительно придумали какие-то оригинальные идеи, затрудняющие детектирование, но никому об этом открыто не рассказывают, чтобы не привлекать внимания, в надежде что лезть и изучать исходники у цензоров не хватит терпения и квалификации, либо рассчитывают на эффект "неуловимого Джо".
PingTunnel - как следует из названия, позволяет проксировать TCP и UDP с помощью обычных ICMP-пингов. Звучит многообещающе?
Cпасибо автору!
Источник: