Была пару лет назад на Хабре одна очень интересная статья о работе виртуальных частных сетей в условиях плохой работы интернета и деградации серверов. Но потом эта статья попала под 451 код http. Так что опубликую эту статью с небольшими изменениями здесь, чтобы у желающих была возможность с ней ознакомиться.
1. Интернет-цензура и обход блокировок
Disclaimer: практически всё, описанное в статье, не является чем-то принципиально новым или инновационным - оно давно известно и придумано, используется в разных странах мира, реализовано в коде и описано в научных и технических публикациях, поэтому никакого ящика Пандоры я не открываю.
Нередко на Хабре в темах, посвященных блокировкам ресурсов, встречаются забавные заявления вида "Я настроил TLS-VPN, теперь будут смотреть что хочу и цензоры мой VPN не заблокируют", "Я использую SSH-туннель, значит все ок, не забанят же они весь SSH целиком", и подобное. Что ж, давайте проанализируем опыт других стран и подумаем, как же оно может быть на самом деле.
0
Итак, допустим мы купили у какого-то сервиса, или, как подкованные пользователи, установили в личном облаке/VPS и настроили VPN-сервер для себя. Допустим, это популярные WireGuard или OpenVPN. Знаете что? WireGuard - это такой прекрасный протокол, который всеми своими пакетами просто кричит "Смотрите все, смотрите, я - VPN". И это, в принципе, не удивительно, потому что авторы на сайте проекта прямым текстом пишут, что обфускация не входила и не будет входить в их цели и планы.
Соответственно, на оборудовании DPI (оно же ТСПУ) при небольшом желании протокол WireGuard выявляется и блокируется на раз-два. IPSec/L2TP - аналогично. С OpenVPN то же самое - это, наверное, вообще самый первый протокол, который китайцы научились выявлять и банить на своем "великом китайском фаерволе" (GFW). We are fucked.
1
Окей, допустим мы сделали выводы, и вместо совсем уж палевных протоколов решили использовать TLS-VPN, такие как SSTP, AnyConnect/OpenConnect или SoftEther - трафик в них ходит внутри TLS, начальная установка соединения производится по HTTP - что должно быть совсем никак неотличимо от обычного подключения к любому обычному сайту. Ну, как сказать...
В случае с MS SSTP цензоры, желая выяснить, а чем же вы таким занимаетесь, просто сделают запрос на ваш сервер с URL /sra{BA195980-CD49-458b-9E23-C84EE0ADCD75}/_ c HTTP-методом SSTP_DUPLEX_POST, как это описано в стандарте протокола, и сервер радостно подтвердит в ответ, что он - да, действительно MS SSTP VPN.
SoftetherVPN в ответ на GET-запрос с путем /vpnsvc/connect.cgi, типом application/octet-stream и пэйлоадом 'VPNCONNECT' выдаст в ответ 200 код и предсказуемый бинарный блоб с рассказом о том, кто он такой.
AnyConnect/OpenConnect при обращении по / или по /auth ответят очень характерной XML'кой. И от всего этого вы не избавитесь никак - это определено в протоколах, и именно через эту логику работают VPN-клиенты. We are fucked.
2
Ясно, мы будем умнее, и поскольку у нас все-таки TLS, давайте поставим перед VPN-сервером reverse-прокси (например, haproxy) и будем разруливать всё по SNI (server name identification): подключения с определенным доменом в запросе будем отправлять на VPN-сервер, а все остальные - на безобидный сайт с котиками. Можно даже попробовать спрятаться за какой-нибудь CDN - не забанят же они весь CDN, правда, и наш трафик из общего трафика ко всей CDN выцепить не смогут, да?
Правда, есть одно "но". В нынешних версиях TLS поле SNI не шифруется, соответственно цензоры легко его подсмотрят и сделают запрос именно с тем именем домена, что надо. На расширение Encrypted Client Hello (ECH), ранее известное как eSNI, можно не рассчитывать: во-первых, оно находится еще в состоянии Draft и неизвестно когда будет принято и повсеместно использоваться, а во-вторых, цензоры могут взять и просто-напросто заблокировать все соединения TLSv1.3 с ECH, как это сделали в Китае. Проблемы индейцев шерифа не волнуют. We are fucked.
3
Шутки в стороны, мы настроены решительно. Например, мы пропатчили OpenConnect-сервер, чтобы он принимал подключения только со специальным словом в URL'е (благо, AnyConnect/OpenConnect-клиенты такое позволяют), а всем остальным отдавал правдоподобную заглушку. Или настроили обязательную аутентификацию по клиентским сертификатам.
Или же мы подключаем тяжелую артиллерию от товарищей-китайцев, которые на обходе блокировок собаку съели. Shadowsocks (Outline) отпадает, ибо его версии до 2022 года уязвимы к replay-атакам и даже active probing'у, но вот V2Ray/XRay с плагином VMess и VLess поверх Websockets или gRPC, либо Trojan-GFW - это то что надо. Они работают поверх TLS, могут делить один и тот же порт с HTTPS-вебсервером, и не зная заветной секретной строчки, которую подслушать снаружи не получится, выявить наличие туннеля и подключиться к нему, казалось бы нельзя, значит все хорошо?
Давайте подумаем. Каждый TLS-клиент при подключении передает серверу определенный набор параметров: поддерживаемые версии TLS, поддерживаемые наборы шифров, поддерживаемые расширения, эллиптические кривые и их форматы. У каждой библиотеки этот набор свой, и его варианты можно анализировать. Это называется ClientHello fingerprinting. Отпечаток (fingerprint) библиотеки OpenSSL отличается от отпечатка библиотеки GnuTLS. Отпечаток TLS-библиотеки языка Go отличается от fingerprint'а браузера Firefox.
И когда с вашего адреса будут зафиксированы частые и долгие подключения к некому сайту клиентом с библиотекой GnuTLS (которая не используется ни в одном популярном браузере, но используется в VPN-клиенте OpenConnect), или с мобильного телефона через мобильного оператора подключается какой-то клиент на Go (на котором написан V2Ray), we are fucked. Такое детектирование, например, производится в Китае и в Туркменистане.
4
Ладно. Допустим, мы пересобрали наш V2Ray-клиент не со стандартной TLS-либой, а с uTLS, которая может маскироваться под популярные браузеры. Или вообще взяли исходники самого популярного браузера, выдрали оттуда весь код сетевого стека и написали свой прокси-клиент на его базе, чтобы быть совсем уже неотличимыми от обычного браузерного TLS. Или решили пойти в сторону маскировки под другие протоколы типа SSH, или взяли OpenVPN с XOR-патчем. Или какой-нибудь KCP/Hysteria с маскировкой под DTLS.
Короче говоря, допустим у нас что-то более редкое и незаметное. Казалось бы, все хорошо? Ну как сказать. Помните "пакет Яровой"? Тот самый, который требует, чтобы интернет-сервисы сохраняли все метаданные сессий, а интернет-провайдеры так вообще записывали дампы трафика своих абонентов? Многие, еще тогда смеялись - мол, ну тупые, что им дадут гигабайты зашифрованных данных, которые они все равно не расшифруют? А вот что.
Пользуетесь вы, допустим, своим туннельчиком, смотрите всякие там запрещенные сайты. А потом - клик! - и случайно заходите через свой туннель на какой-нибудь отечественный сайт или сервис, замеченный в сотрудничестве с государством - условные там VK/Mail.ru/Яндекс или еще что-нибудь. Или на каком-нибудь безобидном сайте попадается виджет, баннер или счетчик от них же. Или кто-нибудь в комментарии вбросит ссылку на какой-нибудь сайт-honeypot, косящий под новостной ресурс, и вы на нее нажмете.
И вот тут произойдет самое интересное. Что внутри TLS, что внутри SSH, что внутри OpenVPN+xor, данные передаются в зашифрованном виде, и их не расшифровать. Но вот "внешняя форма" (размеры пакетов и тайминги между ними) у зашифрованных данных точно такая же, как и у нешифрованных. Цензоры видят, что от абонента к какому-то неизвестному серверу и обратно ходит трафик, а поток со стороны какого-нибудь подконтрольного сервиса видит, что с того же IP-адреса, что у "неизвестного сервера", туда прилетают какие-то запросы и улетают ответы, и - вот интересно - размеры пакетов и временные моменты практически полностью совпадают. Что весьма характерно говорит о том, что у нас тут прокси, возможно VPN, Андрюха, по коням!
И да, если вы поступите мудрее и у вашего сервера будет два IP-адреса, один на вход, а другой на выход, то сопоставить ваш "вход" и "выход" по адресам не получится, но по "форме" переданных данных, хоть и ощутимо сложнее, но при желании по прежнему можно. We are fucked again.
5
Не так уж плохо дело. Мы настроили для своего туннеля rule-based access. А именно, будем ходить по нему только туда, куда надо, и тогда, когда надо - а во всех остальных случаях пусть пакетики бегают сразу по обычному интернет-подключению. Правда, добавлять каждый раз новый ресурс в список - тот еще геморрой, особенно когда вы держите прокси/VPN не только для себя, но и, например, для далеко живущих немолодых родителей, которые, например, хотят читать всяких там иноагентов - но это, на самом деле, мелочи, мы справимся.
Допустим, мы по-прежнему используем SSH-туннель. Правда, проработает он, скорее всего, недолго. Почему? Потому что дело во всех тех же паттернах трафика. И нет, записывать и мучительно сравнивать ничего никуда уже не надо. Паттерны трафика у ssh-as-console, ssh-as-ftp и ssh-as-proxy очень разные и элементарно выявляются довольно просто должным образом натренированной нейросетью. Поэтому китайцы и иранцы уже давно всё подобное "неправильное" использование SSH выявляют и режут скорость подключения до черепашьей, что в терминале работать вы еще сможете, а вот серфить - практически нет.
Ну или, допустим, вы все-таки используете whatever-over-TLS-туннель с учетом всего приведенного в этой статье. Но проблема в том, что все сказанное в предыдущем абзаце, применимо и к нему - а именно, TLS-inside-TLS выявляется сторонним наблюдателем с помощью эвристик и машинного обучения, которое еще можно дополнительно натренировать на наиболее популярных сайтах. We are still fucked.
6
Ладно. Мы добавили в наш тайный туннель random padding - "дописывание" в конец пакета какого-нибудь мусора случайно длины, чтобы сбить с толку наблюдателей. Или специально бьём пакеты на маленькие кусочки (и получаем проблемы с MTU, ой, придется потом старательно пересобирать). Или, наоборот, когда у нас внутри туннеля устанавливается TLS-соединение с каким-нибудь сервером, мы начинаем слать эти пакеты as-is без дополнительного слоя шифрования, таким образом выглядя со стороны на сто процентов как обычный TLS без двойного дна (правда, придется еще потратить несколько итераций на доведение протокола до ума и затыкание очень тонких и очень неочевидных уязвимостей реализации). Казалось бы, happy end, we are not fucked anymore?
А тут начинается все самое интересное. А именно, рано или поздно в вопросах выявления туннелей и блокировок, особенно с развитием технологий их обхода (в конце концов, мы ещё не затронули стеганографию и много других интересных вещей), начинает расти то, что называется collateral damage - ущерб, возникший случайно в ходе атаки намеренной цели. Например, как говорят инсайдеры и подтверждают сводки с полей, то самое упомянутое выше выявление tls-inside-tls даже с random padding'ом китайцы научились выявлять примерно с точностью 40%. Понятно дело, что при такой точности возможны также ложные срабатывания, но когда проблемы индейцев волновали шерифа?
Протоколы, которые снаружи не похожи ни на что (например, shadowsocks obfs4, и т.д.) тоже при большом желании можно выявить по... статистике нулей и единичек в байтах, потому что у зашифрованного трафика это соотношение очень близко к 1:1 - хотя, понятное дело, при этом могут пострадать невиновные. Можно банить адреса, когда висят слишком много или слишком долго подключения к не-являющимися-очень-популярными-сайтам. Подобных вариантов довольно много, и если вы думаете, что цензоров остановят ложноположительные срабатывания и ущерб от блокировок добропорядочных сайтов - то вы заблуждаетесь.
Когда Роскомнадзор пытался заблокировать Telegram, они вносили в бан-лист целые подсети и хостинги, таким образом побанив кучу ни в чем невиновных сайтов и сервисов - и им за это ничего не было. В Иране, в связи с популярностью упомянутого выше похожего-на-браузер-прокси-клиента, цензоры вообще тупо запретили подключения с Chrome TLS fingerprint к популярным облачным сервисам. В Китае массово попадают под раздачу CDN, услугами которых пользуются безобидные и невиновные сайты и сервисы. В Туркменистане так вообще заблокирована почти треть (!) всех существующих в мире IP-адресов и подсетей, потому что стоит цензорам только выявить хотя бы один VPN или прокси, как в бан отправляется целый диапазон адресов около него или даже вся AS.
Вы, наверное, можете спросить, а что же делать юрлицам, которые тоже пользуются VPN для работы, или чьи сервисы могут случайно попасть под раздачу? Этот вопрос легко решается белыми списками: если юрлицу нужен VPN-сервер, или нужно обезопасить от случайной блокировки какие-либо свои сервисы, то стоит обязать их заранее сообщать о нужных адресах и протоколах в соответствующие ведомства, чтобы те добавили их в какой надо список - именно такие запросы Роскомнадзор через ЦБ рассылал в банки, задумывая что-то нехорошее, и механизм таких списков уже существует.
Ну и, естественно, вполне вытекающим продолжением из этого будет "все что не разрешено - то запрещено". Закон о запрете VPN и анонимайзеров в целях обхода блокировок в РФ уже есть. Запрет использования несертифицированных средств шифрования - тоже. Подкрутить и расширить их зоны применения и многократно ужесточить наказания за такие "нарушения" - дело несложное. В Китае вежливые ребята пришли в гости к разработчикам небезизвестных ShadowSocks и GoAgent и сделали им предложения, от которых те никак не смогли отказаться. В Иране есть случаи возбуждения дел в связи с использованием VPN для доступа к запрещенным сайтам. Механизм стукачества в органы на неблагонадежных соседей был отлично отработан еще в прошлом веке в СССР. У государств есть монополия на насилие, не забывайте. We are fucked again?
4294967295
К чему это всё?
Как я уже сказал, большая часть того, что описано в статье, не является выдумками или голой теорией - оно давно известно, используется в некоторых странах мира, реализовано в коде и даже описано в научных публикациях.
Обход блокировок - это постоянная борьба щита и меча, и одновременно игра в кошки-мышки_:_ иногда ты ешь медведя, иногда медведь ест тебя иногда ты догоняющий, иногда догоняемый.
Если у вас сейчас есть прокси или VPN, и он работает - не расслабляйтесь: вы всего-лишь на полшага впереди недоброжелателей. Можно, конечно, спокойно сидеть и думать "Да они там все дураки и криворукие обезьяны и ниасилят ничего сложного и реально работающего", но, как говорится, надейся на лучшее, а готовься к худшему. Всегда есть смысл изучить опыт тех же китайских коллег и присмотреться к более сложновыявляемым и более цензуроустойчивым разработкам. На чем больше шагов вы будете впереди цензоров, тем больше времени у вас будет в запасе чтобы адаптироваться к изменившейся ситуации. Если вы разработчик и разбираетесь в сетевых протоколах и технологиях - можно присоединиться к одному из существующих проектов, помочь с разработкой и подумать над новыми идеями. Люди всего мира скажут вам спасибо.
Интересными и полезными в этом плане будут Net4People, No Thought is a Crime, дискуссии в проекте XTLS (там большая часть на китайском, но автопереводчик на английский справляется неплохо), GFW report. Если кто-то знает ещё хорошие ресурсы и сообщества по этой теме - напишите в комментарии
Ну и не стоит забывать, что рано или поздно, не имея возможности противостоять подобному свободолюбию технически, государство может начать противостоять административно (та самая монополия на насилие), причем так, что с вашей стороны, в свою очередь, технически противостоять может уже не получиться. Но это уже совсем другая история, требующая отдельной статьи, и, скорее всего, на другом ресурсе.
Когда я писал эту публикацию, я хотел вставить в нее картинки из какого-нибудь мрачного киберпанк-фильма, где в результате развития технологиий слежения и цензуры и невозможности противостоять этому, люди целиком и полностью стали подконтрольны государствам и потеряли все права на свободу мысли и приватность личной жизни. Но я надеюсь, до этого не дойдет. Все в наших руках.
2. Современные технологии обхода блокировок
Мировым лидером в области интернет-цензуры является Китай, поэтому имеет смысл обратить наш взор на технологии, которые разработали энтузиасты из Китая и других стран для борьбы с GFW (“великим китайским файрволом”). Правда, для неподготовленного пользователя это может оказаться нетривиальной задачей: существует огромное количество программ и протоколов с похожими названиями и с разными не всегда совместимыми между собой версиями, огромное количество опций, плагинов, серверов и клиентов для них, хоть какая-то нормальная документация существует нередко только на китайском языке, на английском - куцая и устаревшая, а на русском ее нет вообще.
Поэтому сейчас мы попробуем разобраться, что же это все такое, как это использовать, и при этом не сойти с ума.
В этой статье я проведу обзор самых передовых протоколов и технологий, которые:
-
позволяют делать передаваемый трафик не похожим вообще ни на один существующий стандартный протокол, делая его полностью неразличимым для цензоров;
-
либо наоборот, позволяют максимально достоверно маскироваться под безобидный HTTPS-трафик, включая защиту сервера от детектирования методом active probing с помощью фейкового веб-сайта, маскировку TLS fingerprint клиента под обычный браузер, и защиту от выявления туннеля нейросетями (детектирования TLS-inside-TLS);
-
позволяют работать в условиях жесткого шейпинга канала и потерь пакетов;
-
позволяют создавать цепочки из серверов и настраивать маршруты (например, фильтровать трафик до российских адресов).
Итак, поехали.
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 вполне можно рассматривать как запасной вариант, активировав его на одном сервере с другими протоколами.
V2Ray, V2Fly, XRay (VMess, VLESS, XTLS)
Все началось с проекта под названием V2Ray, автором которого была Victoria Raymond (отсюда, видимо, и появилось название). Достоверно неизвестно, существовал ли в реальности человек с такими именем, или это чья-то виртуальная личность, но в итоге случилось следущее: в один момент Victoria Raymond перестала выходить на связь что на Github, что в Twitter, что где-либо еще (ничего не напоминает, правда?).
В результате остальные контрибьюторы проекта, не имея административного доступа к Git-репозиториям и веб-сайту, были вынуждены форкнуть его под названием V2Fly для того чтобы продолжить разработку. Грубо говоря, если вы видите github-юзера или веб-сайт с названием V2Ray - весьма вероятно, что там содержится старый код и устаревшая информация, а вот с названием V2Fly - это уже нечто гораздо более актуальное. Между тем, многие люди (и даже сами разработчики!) по-прежнему продолжают называть V2Fly как V2Ray, бинарники и пакеты по-прежнему называются v2ray-core, что добавляет немного путаницы.
XRay - это форк V2Fly, когда некоторые разработчики из-за ряда разногласий с остальным сообществом (где-то я встречал упоминания что разногласия были по технической части, где-то же написано что из-за лицензий) ушли из проекта V2Fly и продолжили развивать код параллельно под названием XRay, придумав ему слоган “Penetrates everything”, что очень недалеко от правды. Формат конфигурационных файлов остался прежним, но при этом новая реализация считается более эффективной в плане производительности, а самое главное - разработчики добавили туда несколько очень крутых фич, направленных в том числе на снижение детектируемости подключений на DPI (например, с помощью выявления TLS-in-TLS), таких как XTLS, речь о которых пойдет ниже.
V2Ray/XRay - это не протокол, а, можно сказать, фреймворк - разные протоколы с разными транспортами и расширениями под одной крышей в одном приложении. Идея простая: что клиент, что сервер - это один бинарник. В конфигурации задаются inbounds (обработчики входящих подключений) и outbound (обработчики исходящих подключений).
На клиенте inbound обычно будет работать как HTTP- или SOCKS-прокси сервер, принимая подключения от браузеров и других программ, а outbound будет настроен как клиент какого-нибудь прокси-протокола для подключения к удаленному серверу.
На сервере все наоборот, inbound - это сервер какого-нибудь протокола (их может быть несколько одновременно с разными вариантами), а outbound - это, например “freedom” (выход в чистый интернет), “blackhole” (блокировка исходящих подключений, если вам, например, нужно ограничить доступ в зависимости от каких-то правил), или следущий прокси в цепочке, и т.д.
Для каждого из используемых протоколов можно задать также тип транспорта, например, просто TCP, либо TLS, либо Websockets, либо еще что, и таким образом создавать самые разнообразные комбинации и варианты.
Для связи inbounds и outbouds можно задавать всевозможные правила маршрутизации. Например, уже на клиенте можно автоматически отправлять все запросы к доменам “.ru” и российским IP-адресам согласно базе GeoIP на outbound “freedom” (прямой доступ к интернет без прокси), а все остальное проксировать на удаленный сервер. Или наоборот, по умолчанию отправять все на freedom, а проксировать только адреса и домены из списка (в том числе с масками и регулярными выражениями). Можно использовать разные прокси и протоколы в зависимости от типа подключения (TCP или UDP), в зависимости от порта назначения (например, перехватывать DNS-запросы на 53-ий порт, и т.д.). Можно строить цепочки из серверов - приняли подключение на одном прокси-сервере, передали его дальше на следущий, и т.д. Короче говоря, штука получилась очень гибкая и фунциональная.
Непосредственно классических протоколов в V2Ray и XRay всего два с половиной: VMess, VLESS и VLite (это та самая половина).
VMess - самый первый и самый старый. Поддерживат определение свой/чужой по ID пользователя и опционально шифрование данных.
В качестве ID-пользователя выступает UUID и (в оригинальной реализации VMess) специальное число под названием alterId. Если эти данные совпадают на клиенте и на сервере - подключение устанавливается, если нет - извините :) В конфигурации сервера может быть определено сразу много пользователей. Не буду детально углублятся в то, что такое alterId, скажу просто - это значение могло быть в принципе любым (обычно от 1 до 64), главное что оно должно было совпадать на клиенте и сервере, и изначально было нужно для механизма повышения надежности протокола. Со временем выяснилось, что механизм аутентификации оригинального VMess уязвим к ряду атак, в итоге разработчики выпустили новый вариант протокола с переделанным алгоритмом проверки пользователя, который активировался при выставлении значения alterId в 0. То есть в наше время alterId по сути дела не используется, благо практически все серверы и клиенты умеют в новый вариант протокола.
В настоящее время VMess считается устаревшим, а при работе через просто TCP - небезопасным, однако вариант VMess-over-Websockets-over-TLS по-прежнему вполне себе жизнеспособен и может использоваться при отсуствии поддерживаемых в каком-либо клиенте альтернатив.
VLESS (как отметили в комментах, именно так, большими буквами) - это более новый протокол. В отличие от VMess он не предусматривает механизма шифрования (подразумевается, что шифрование должно производиться нижележащим транспортным протоколом, например TLS), а только проверку “свой/чужой” и паддинг данных (изменение размеров пакетов для затруднения детектирования паттернов траффика). В протоколе исправлен ряд уязвимостей старого VMess, и он активно развивается - например, автор планирует добавить поддержку компрессии алгоритмом Zstd - не сколько для производительности, сколько для затруднения анализа “снаружи”. При этом, при установлении соединения (хендшейке) клиент и сервер обмениваются версией протокола и списком поддерживаемых фич, то есть при дальнейшем развитии должна сохраняться обратная совместимость. В общем и целом, на сегодняшний день это самый свежий и прогрессивный протокол.
VLite есть только в V2Ray (в XRay его нет), поддерживает только передачу UDP-пакетов, и максимально оптимизирован именно для этого, что может быть полезно, например, для онлайн игр, но параллельно придется настроить еще VMess/VLESS для TCP - поэтому я считаю его только “половиной” :)
Кроме VMess и VLESS сервера и клиенты V2Ray и XRay также поддерживают протокол Shadowsocks (в том числе версий AEAD и 2022) о котором я говорил выше, а также Trojan, о котором речь пойдет в следущей главе.
С протоколами закончили, перейдем к транспортам. VLESS, VMess и другие могут работать, скажем так, разным образом. Самый простой вариант - обычный TCP-транспорт. VMess+TCP в данном случае очень похож на Shadowsocks, а VLESS+TCP не имеет смысла (из-за отсутствия шифрования). Более интересный вариант - TLS-транспорт, когда устанавливается обычное TLS-подключение (как и в случае с любыми HTTPS-сайтами), а уже внутри этого зашифрованного соединения работает протокол. V2Ray и XRay умеют также работать поверх mKCP (о нем будет в следущих главах), QUIC (aka HTTP/3, правда в России его массово блокируют и смысла в нем мало), gRPC, и самое интересное - через Websockets.
Вариант с Websockets очень ценен тем, что:
- Позволяет легко поставить V2Ray/XRay не перед, а за Nginx/Caddy/любымдругимвебсервером;
- Позволяет пролезать через строгие корпоративные фаерволы;
- Добавляет дополнительный уровень защиты (не зная URI невозможно достучаться до прокси-сервера);
- И самое интересное - позволяет работать через CDN (upd.: gRPC тоже позволяет).
На последнем пункте остановимся чуть подробнее. Некоторые CDN, в том числе и имеющие бесплатные тарифы, такие как Cloudflare и GCore, разрешают проксирование веб-сокетов даже на бесплатных тарифах. Таким образом, это может быть хорошим подспорьем - если по какой-то причине IP-адрес вашего сервера попал в бан, вы все равно можете подключиться к нему через CDN, а полный бан всей CDN гораздо менее вероятен, чем какого-то одного VPS. А еще Cloudflare (возможно и GCore тоже, не уточнял) умеет проксировать IPv4 запросы на IPv6 адрес, то есть свой прокси-сервер вы можете поднять даже на копеечном (можно найти варианты за 60 центов в месяц!) IPv6-only или NAT VPS без IPv4 адреса, и наплодить таких серверов чуть ли не десяток в разных локациях :)
Недостатком транспорта через веб-сокеты является более долгий хендшейк (установление каждого соединения) чем напрямую через TLS. Но и здесь есть решение.
Сервера XRay и Sing-Box (возможно и V2Ray тоже, не проверял) позволяют задавать также механизм fallaback’ов для разных протоколов. Например, при подключении пользователя первым делом сервер пытается обработать входящее подключение как VLESS-over-TCP. Если хендшейк оказался успешным, пользователь опознан - работаем, если нет - передаем следущему обработчику. Следущий обработчик, может, например, попытаться воспринять это новое подключение как VMess-over-Websocket. Если сработало - отлично, если нет - то передаем подключение следущему inbound’у. А тот, в свою очередь, не разбираясь, перенаправляет подключение на локальный веб-сервер с котиками. Таким образом у нас есть возможность одновременно принимать подключения и через VLESS-TCP, и через VLESS-Websockets или VMess-Websockets на одном порту, а если не сработал ни один из вариантов, прикидываться безобидным веб-сайтом.
Еще одна фича V2Ray и XRay - мультиплексирование соединений (mux или mux.cool). В этом случае на каждое новое подключение к какому-либо сайту не будет устанавливаться новое подключение к прокси, а будут переиспользованы существующие. Что в теории может ускорить хендшейк и привлекать меньше внимания со стороны цензоров (меньше параллельных подключений к одному хосту), с другой стороны снижает скорость передачи данных из-за оверхеда на дополнительные заголовки пакетов.
XUDP и Packet - расширения VLESS для более эффективной передчи UDP-пакетов и реализации Full Cone NAT. Packet - версия подревнее, XUDP по-новее. Без их использования многие NAT-тесты будут жаловаться на кривой NAT ("endpoint address not changed), а с XUDP вы получаете нормальный честный Full Cone. Это может быть полезно для онлайн-игр, месседжеров и разного софта с передачей аудио и видео. XUDP и Packet нельзя использовать одновременно с MUX из прошлого параграфа из-за особенностей реализации (авторы старались впихать все в рамки существующего протокола и сохранить обратную совместимость, поэтому были вынуждены переиспользовать некоторые механизмы).
А теперь про самое интересные фичи.
uTLS предназначена для обмана механизма детектирования на основе TLS fingerprint, о котором я рассказывал в прошлой статье. Почитать про TLS fingerprint можно на посвященном ему сайте. В Китае и Иране цензоры активно используют этот механизм для детектирования прокси-клиентов - если мы обращаемся к какому-нибудь прокси, замаскированному под HTTPS-сайт, но при этом TLS fingerprint клиента отличается от популярных браузеров (особенно если клиент написан на Go, у которого очень специфичный фингерпринт), то соединение блокируется. uTLS - это специально пропатченный вариант стандартной TLS-библиотеки Go, позволяющий маскироваться под другие приложения. Некоторые клиенты дают выбор из нескольких вариантов (например chrome, firefox, safari), некоторые позволяют выбирать желаемый fingerprint вплоть до версии конкретного браузера.
В нынешних реалиях uTLS является очень крутой и почти что жизненно необходимой штукой (РКН пока что по фингепринтам не блочит, но как показывает опыт других стран, может начать в любой момент), поэтому рекомендуется его использовать во всех случаях, если он поддерживается клиентом (а если не поддерживается - лучше выбрать клиент, который поддерживает).
И наконец, XTLS, фирменная фишка XRay.
Сегодня почти что все веб-сайты работают не через голый HTTP, а через HTTPS (TLS). Используя прокси с TLS мы, по сути дела, еще раз шифруем уже зашифрованные данные. Во-первых это неэффективно, а во-вторых, что гораздо хуже - китайские цензоры научились определять TLS-inside-TLS (возможно с помощью нейросетей). Авторы XRay посмотрели на это, и решили: зачем шифровать то, что уже зашифровано? И придумали XTLS.
Суть проста: прокси-сервер подслушивает передаваемый трафик, и если видит, что если между клиентом (например, браузером) и удаленным хостом (например веб-сервером) устанавливается TLS-соединение, то дожидается окончания хендшейка, и после чего перестает шифровать трафик, начиная передавать пакеты данных “как есть”. В итоге существенно снижается нагрузка на прокси-сервер и клиент, и что важнее - со стороны трафик выглядит гораздо менее подозрительно (у нас подключение по TLS, поэтому до сервера бегают простые TLS-пакеты без аномалий, никакого двойного шифрования).
XTLS имеет несколько разных версий, которые отличаются алгоритмами работы, xtls-rprx-origin и xtls-rprx-direct - самые первые из них, в xtls-rprx-splice задействован механизм ядра Linux splice для более эффективного копирования данных между сокетами. Все они уже не актуальны, в настоящее время рекомендуется использовать последнюю версию XTLS-Vision (xtls-rprx-vision), подробное описание работы которой можно прочитать здесь. По ряду сообщений, на сегодняшний день связка VLESS+XTLS-Vision является единственной, которую пока еще не умеет эффективно блокировать китайский GFW (при условии соблюдения рядя важных моментов, например, запрета доступа к китайским сайтам через прокси). Единственный минус - xtls-rprx-vision пока что поддерживается не всеми клиентами, и XTLS по понятным причинам не работает через CDN.
Хозяйке на заметку: в отличие от предыдущих версий, при настройке клиентов для xtls-rprx-vision нужно выбирать тип транспорта не “XTLS”, а просто “TLS”. Нелогично, видимо связано с особенностями реализации, но такова жизнь.
И наконец, заглянем в завтрашний день: XTLS-Reality. Это самое новое изобретение от авторов XRay. Он уже поддерживается в master-ветке xray и даже в некоторых клиентах, но про него все еще мало что известно. В отличие от всех остальных вариантов, определение “свой/чужой” здесь происходит еще на этапе TLS-хендшейка в момент чтения ClientHello. Если клиент опознан как “свой”, сервер работает как прокси, а если нет - вжух! - и TLS подключение передается на какой-нибудь другой абсолютно реальный хост с TLS (например, google.com или gosuslugi.ru), и таким образом клиент (или цензор, желающий методом active probing проверить, а что же прячется на том конце) получит настоящий TLS-сертификат от google.com или gosuslugi.ru и настоящие данные с этого сервера. Полное соответствие. Основная загадка - как именно происходит определение “свой/чужой”, потому что на этапе хендшейка данные еще передаются в открытом виде (ECH, как мы знаем, пока что не в ходу), и поэтому механизм должен позволить достоверно определить подлинность клиента, но вместе с тем не вызывать подозрения у цензоров и быть устойчивым к replay-атакам. Делается ли это с помощью клиентских сертификатов, или TLS-токенов, или еще каким образом - не ясно, какого-либо понятного описания протокола в интернете пока что опубликовано не было (по крайней мере мне не нашлось, даже на китайском), залезать в исходники пока что нет времени, но ясно одно - вероятно за этим будущее :) Ну и да, если кто уже разобрался, как оно работает - отпишитесь в комментах, всем интересно.
Upd:
«Bleeding-edge обход блокировок: настраиваем сервер и клиент XRay с XTLS-Reality быстро и просто»
Trojan-GFW и Trojan-Go
Наряду с Shadowsocks и V2Ray протокол Trojan является одним из первых и популярных способов обхода блокировок в Китае, и по принципу работы в принципе соответствует своему названию :) Для стороннего наблюдателя работа через него выглядит как подключение к обычному веб-серверу, но на самом деле это веб-сервер с подвохом секретом (аки троянский конь).
Trojan работает поверх TLS (точно так же как HTTPS). После установления TLS-сессии сервер ожидает хендшейк в специальном формате, одним из полей которого является хеш секретного ключа. Если сообщение и ключ корректны - дальше сервер работает как прокси, если нет - запрос передается на стоящий рядом веб-сервер, и таким образом имитируется работа безобидного сайта через HTTPS.
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. Не знаю, основан ли он на нем же, или авторы просто вдохновлялись его идеями - напрямую об этом нигде не сказано, но сходство весьма существенное. Кто авторы - тоже неизвестно, они сохраняют анонимость, документация на официальном сайте только на английском и китайском языке, но в примерах конфигурации среди секретных ключей встречается строка “Мать-Россия”, прямо так, кириллицей, что наталкивает на размышления.
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-пингов. Звучит многообещающе.
Что использовать?
Зависит от того, насколько вы себя уверенно чувствуете в системном администрировании и готовы во всем этом разбираться методом проб и ошибок.
Если не уверены, либо не готовы и хочется максимально простое и универсальное решение, то я могу посоветовать настроить XRay в варианте VLESS-over-Websockets с fallback’ом на какой-нибудь безобидный веб-сайт. Со стороны клиентов обязательно выбрать опцию uTLS, и желательно добавить настройку чтобы ресурсы в зоне .ru и с российскими IP открывались без прокси.
Такая связка поддерживается практически всеми клиентами, еще долгое время будет устойчива к детектированию (учитывая отсталость и тормознутость нашего родного РКН), при наличии зарегистрированного домена можно работать через CDN, а устанавливается и настраивается все это элементарно парой команд в консоли (об этом будет в одной из следущих статей).
Если вы готовы к подвигам и экспериментам, то можно задуматься о настройке XRay с VLESS+XTLS-Vision, добавить fallback на VLESS+Websockets для старых клиентов и CDN разных видов, и на том же сервере поднять еще mKCP/Hysteria, Shadowsocks-2022 и классический SSH-туннель. И на будущее присмотреться к XTLS-Reality. В случае чего, хоть один из вариантов, но сработает.
А еще в одной из следущих статей я расскажу про клиенты. Потому что с клиентами дело обстоит примерно так же, как с серверами и протоколами: их много, они разные, некоторые из них являются форками друг друга, но с существенными отличиями, некоторые поддерживают одно, некоторые другое, а некоторые, казалось бы, поддерживают только это и это, но при правильном подходе их можно заставить поддерживать то, что они, казалось бы, не поддерживают :) Короче говоря, будет интересно, не переключайтесь.
3. Программы-клиенты для протоколов недетектируемого обхода блокировок сайтов
Для начала хочу обратить внимание на ряд нюансов и терминов, которые можно встретить в описании и интерфейсах разных клиентов.
uTLS, XTLS, Vision, Reality - см. [[2. Современные технологии обхода блокировок]]
Routing или Policies - обычно определяют правила, по которым трафик пользователя будет отправляться на прокси или уходить в интернет напрямую. Например, клиент может автоматически отправлять все запросы к доменам “.ru” и российским IP-адресам согласно базе GeoIP в интернет напрямую, а все остальное выпускать наружу через прокси-сервер. Или наоборот, по умолчанию отправять все напрямую, а проксировать только адреса и домены из списка (в том числе с масками и регулярными выражениями). База GeoIP (принадлежности IP-адресов той или иной стране) нередко поставляется вместе с самим клиентом и ее желательно периодически обновлять.
Share link, share QR - многие мультипротокольные клиенты позволяют делиться настройками с помощью “ссылок” или QR-кодов. “Ссылка” обычно представляет собой URL начинающийся с ss:// (для Shadowsocks), vmess:// (для VMess), vless:// (для VLESS) и т.д., где дальше следует закодированная в base64 JSON-структура с данными для подключения. Соответственно, можно сгенерировать такую ссылку из настроек какого-нибудь клиента, переслать ее на другое устройство или другому человеку, вставить ее в другой клиент и получить там настройки для подключения к этому серверу. QR - примерно то же самое, но не в виде ссылки с base64, а в виде QR кода, который можно сканировать камерой с экрана. Это в теории. Проблема в том, что во-первых существует несколько разных форматов ссылок (формат SIP002, формат Clash, формат Sing-box), и даже при кодировании одним и тем же форматом среди данных могут оказаться поля, которые знает один клиент и не знает другой. Поэтому иногда может случиться так, что скопипастив ссылку или отсканировав QR в клиенте вы получите данные конфигурации нового сервера, но некоторые поля будут пустые. Например, часто теряется поле uTLS fingerprint, поэтому будьте внимательны.
Subscriptions - многие клиенты умеют автоматически подгружать список серверов откуда-нибудь. Например, вы настроили сервер для своих друзей и родственников. Через какое-то время вы можете поднять на нем новый более защищенный протокол, или перехостить сервер его на другом домене, или еще что. Чтобы не рассылать ссылки/QR-коды вручную вместе с инструкциями о том, как их правильно импортировать, можно просто всем желающим в клиенте вбить URL по которому лежит файл с описанием подключений, и клиент сможет автоматически либо по запросу подтягивать обновления и новые настройки. Правда, тут проблема та же, что и в прошлом пункте - существует несколько разных форматов подписок, например SIP008, формат Clash, формат V2RayN (по сути дела список URL’ов из предыдущего пункта, по одному на строку, и весь файл еще раз закодирован в base64), OpenOnlineConfig, и т.д. Существуют всякие онлайн-конвертеры для преобразования из одного в другой, но работают они так себе, а иногда вообще не работают.
TUN / VPN. Клиенты обычно могут работать в двух режимах: первый режим - “системный прокси”, клиент просто слушает на каком-нибудь локальном порту (например 10080 или 2080), а в системе или в браузере настраивается адрес прокси-сервера 127.0.0.1:10080 и все довольны. Это самая простая и надежная схема, однако есть два недостатка. Первый состоит в том, что некоторые приложения резолвят доменные имена (DNS) сами, еще до отправки запроса на прокси, что может привезти к тому, что называется “DNS-утечка” (ваш провайдер узнает, на какие сайты вы ходили, и может даже прислать фейковый ответ ради блокировки неугодного ресурса). Второй недостаток похож на первый, но еще более критичный: некоторые приложения тупо игнорируют настройки системного прокси, либо не умеют работать через прокси вообще.
Поэтому разработчики придумали второй режим, обычно называемый TUN. В системе создается виртуальный сетевой интерфейс с каким-нибудь фейковым IP-адресом и маршрут по умолчанию для всей системы настраивается именно через него. Таким образом все TCP и UDP подключения от всех приложений в системе попадают на этот сетевой интерфейс, а далее специальный драйвер перенаправляет их на локальный SOCKS-прокси.Такой режим еще иногда называют “VPN”, хотя по факту он не имеет к VPN никакого отношения :)
IPv6. Многие клиенты поддерживают IPv6. Многие серверы тоже (единственный нюанс - если вы запускаете его из Docker, то там не все так просто и для работы IPv6 может понадобиться настроить контейнер на использование host network). Но если вы используете упомянутый в предыдущем абзаце TUN-режим, то нужно быть внимательными. Если клиент не поддерживает IPv6 или IPv6 отключен в его настройках (а нередко он по умолчанию отключен), а ваш провайдер предоставляет вам IPv6-связность, то есть неиллюзорный шанс, что IPv6 трафик пойдет в интернет в обход прокси. Вариантов решения несколько: или отключить IPv6 на сетевых интерфейсах (Ethernet/WiFi) вообще, или включить IPv6 в клиенте. Тогда если сервер может в IPv6, то все будет вообще прекрасно, а если сервер в IPv6 не может, то запросы будут уходить “в никуда” и все приличные браузеры в этом случае автоматически fallback’нутся на IPv4, никаких проблем.
С терминами и нюансами разобрались, переходим к самим клиентам.
Консольные (cores)
Начнем с консольных клиентов, или, как их часто называют, cores (ядра). Называют их так потому что обычно эти самые cores используются в красивых графических и мобильных клиентах, запускаясь там в фоновом режиме и делая всю работу, либо клиенты линкуются с ними как с библиотеками. Соответственно, именно эти cores ответственны за непосредственную реализацию протоколов и другие фичи. И, само собой, никто не запрещает просто запускать их как консольные приложения в системе и пользоваться ими, например, используя какое-нибудь расширение для браузера (например SwitchyOmega) которое позволяет включать/выключать локальные настройки прокси или делает это автоматически в зависимости от открываемого сайта.
V2Ray/XRay
https://github.com/v2ray/v2ray-core
https://github.com/XTLS/Xray-core
Родные братья: V2Ray - самая классика, а XRay - пожалуй, самый прогрессивный на сегодняшний день в плане новых методов маскировки. Их историю и различия я рассказывал в предыдущей статье, здесь же будет пара слов о том, что нужно знать о них при использовании в качестве клиентов.
V2Ray умеет Shadowsocks, VMess, Trojan, все это с транспортами TLS с uTLS, Websockets, gRPC и mKCP.
XRay умеет все вышеперечисленное, и что самое главное - он поддерживает еще VLESS и XTLS (включая Vision и Reality) - собственно, именно авторы XRay и придумали эти новые фичи и протоколы.
Примеры конфигураций клиента для разных протоколов и транспортов можно найти здесь: https://github.com/XTLS/Xray-examples
Clash, ClashMeta
https://github.com/Dreamacro/clash
https://github.com/MetaCubeX/Clash.Meta
Другой клиент (совершенно не зависим от V2Ray/XRay).
Формат конфигурации - YAML (в отличие от V2Ray и XRay, которые используют JSON), поэтому если есть какие-то примеры конфигов от тех двух, то их придется переписывать.
Есть богатые возможности настройки правил и маршрутизации.
Оригинальный Clash поддерживает Shadowsocks, VMess, Trojan поверх TLS (с uTLS).
Существует также версия Clash.Premium от того же автора, ее исходники закрыты, но бинарник можно скачать бесплатно. В ней также реализована поддержка TUN-интерфейса прямо в клиенте (не нужно ничего дополнительно устанавливать и настраивать), возможность написания скриптов для правил и маршрутов и загрузки новых правил маршрутов из Сети.
И вы наверное заметили, что в списке протоколов Clash и Clash.Premium нет VLESS. Автора уже с десяток раз просили добавить его поддержку в клиент, но сначала он отвечал “VLESS еще сырой”, а когда протокол стали поддерживать и использовать вообще все вокруг, то ответы свелись к чему-то типа “Он мне не нравится и все, идите нахрен, мой клиент - что хочу, то и запиливаю”.
Поэтому не удивительно, что в итоге появился форк Clash под названием Clash.Meta. В нем не хватает некоторых возможностей Clash.Premium, но зато есть много других отстутствующих в оригинальном клиенте, в том числе поддержка VLESS и XTLS (Vision и Reality), и в целом его разработка идет очень активно.
Sing-Box
Github: https://github.com/SagerNet/sing-box/
Сайт: https://sing-box.sagernet.org/
Примеры конфигураций: https://github.com/SagerNet/sing-box/tree/dev-next/docs/configuration
Самая свежая и навороченная разработка от автора клиента SagerNet, который долгое время был наиболее прогрессивным Andorid-клиентом с самым большим количеством поддерживаемых протоколов и транспортов. Как и V2Ray/XRay может работать и как клиент, и как сервер, поддерживает Shadowsocks, VMess, VLess, Hysteria, Trojan, и даже Tor, Wireguard и SSH. Само собой, способен работать с XTLS Vision и Reality и TLS (с uTLS), WS, еще умеет создавать TUN-интерфейс, и вообще всё остальное что полагается приличному клиенту - и кроме этого умеет еще очень много чего, на странице проекта есть вот такая табличка сравнения, и да - всё что написано в левой колонке Sing-Box умеет. И делает это хорошо.
Десктопные GUI-клиенты
v2rayN
https://github.com/2dust/v2rayN
Наверное, самый олдовый и известный графический клиент под Windows. Написан на .NET 6 и WPF. На Гитхабе на странице релизов можно скачать архивы только с самим GUI, либо же GUI+ядра (“-With-Core”).
В качестве ядра по умолчанию используется последняя версия XRay, то есть поддерживаются Shadowsocks (включая 2022), VMess, VLESS, Trojan, и все фичи XTLS и uTLS. v2rayN может еще работать с V2Ray, Clash, ClashMeta, hysteria, naiveproxy в качестве ядра клиента - правда, для ядер отличных от V2Ray/XRay редактировать конфиги в GUI-окошках не получится, можно только подсунуть готовый текстовый конфиг.
Изначально клиент запускается на китайском языке, и нужно изловчиться переключить его на английский или русский.
Активация или деактивация прокси осуществляется выбором режима в нижней части окна или при щелчке правой кнопкой мыши на иконке в трее: Set system proxy - активирует доступ через прокси, Clear system proxy - деактивирует.
В TUN клиент, судя по всему, не умеет (если только вы не подсунете ему специально сгенерированный конфиг для Clash/ClashMeta/Sing-box). Upd: Комментарий от читателя: "Умеет TUN — для этого надо запускать его от имени Администратора и внизу окна программы появится переключатель Enable TUN"
Существует также вариант под названием ClashN - по сути дела, тот же v2rayN, но заточенный на работу с ядром Clash/ClashMeta.
Invisible Man XRayhttps://github.com/InvisibleManVPN/InvisibleMan-XRayClient
Клиент под Windows на базе XRay ориентированный на простоту: минимум настроек, но можно подсунуть любой конфиг XRay, просто положив его в папочку с конфигами, и он появится в списке - после этого достаточно нажать кнопочку "Сделать зашибись" "Подключиться" и все работает. Активно развивается.
v2rayU
https://github.com/yanue/V2rayU/tree/master
Старый клиент под Mac.
Основное взаимодействие с ним осуществляется через менюшку иконки в трее.
Поддерживает Shadowsocks (но не 2022!), VMess, VLESS, XTLS (но только старых версий, vision и reality в пролете), судя по всему не умеет менять TLS identity, TUN-режима тоже нет.
По какой-то причине автор удалил все исходники из дефолтной ветки на своем Github, поэтому будущее развитие проекта под вопросом.
Существует также форк проекта под названием v2rayXS, но он, кажется, тоже не очень живой.
Qv2ray
https://github.com/Shadowsocks-NET/Qv2ray
Классический клиент на базе V2Ray и Qt. Имеет гордый слоган “For developers. By developers”. Кроссплатформенный: Windows, MacOS, Linux.
В одной Github-репе (https://github.com/Qv2ray/Qv2ray) лежит версия 2.7.0, в другой Github-репележит версия 2.7.0 и release candidate версии 3.0.0, и автор жалуется, что какие-то злые люди украли у него доступ от старой репы.
Клиент выглядит неплохо, если бы не одно НО - во-первых он поддерживает только то, что поддерживает классический V2Ray, а про XRay автор пишет “...No Such Word In My Dictionary”. А во-вторых, у меня он так и не заработал.
Для версии 2.7.0 нужно подсунуть по определенному пути бинарник v2ray, для версии 3.0.0 уже не надо (там есть встроенный V2Ray-плагин), но результат одинаковый - при настройке подключения (что ShadowSocks, что VLess) и попытке запустить прокси, клиент выплевывает ошибку, мол, извини, не получилось - причем вообще без каких-либо подробностей. Каких-дибо информации об ошибке не выводится, логов в окне не отображается, логов в файлах в папке с программой нет, включить логгирование в настройках каким-то образом нельзя. Тупик. Короче, не рекомендую.
Clash for Windows и Clash Verge
https://github.com/Fndroid/clash_for_windows_pkg
https://github.com/zzzgydi/clash-verge
Clash for Windows - как следует из названия, работает на базе Clash, но как не следует из названия, работает не только под Windows, но и под macOS и Linux.
Конфиги принимает только в формате Clash, настроить сервер ручками через интерфейс нельзя, только вручную писать YAML-код.
Clash for Windows написан на Electron, поэтому один только его дистрибутив в распакованном виде на диске занимает 277 мегабайт, и памяти жрет соответствующе.
Исходники закрыты, на Github лежат только бинари.
Но! Но… Есть также клон проекта под названием Clash Verge.
И он гораздо лучше. Написан на tauri (аналог Eleсtron, но с Rust и WebView2), благодаря чему он в пять раз менее жирный. Интерфейс сделан гораздо более аккуратно. В качестве ядра можно использовать не только Clash, но и Clash.Meta (что добавляет поддержку VLess и XTLS, включая Reality).
Если вам по каким-то причинам нравится или нужен Clash-based-клиент - то Clash-Verge не самый плохой вариант.
Nekoray / Nekobox
https://github.com/MatsuriDayo/nekoray
https://github.com/MatsuriDayo/nekoray/releases
https://github.com/aaaamirabbas/nekoray-macos/releases ( билды для MacOS)
И самое вкусное на конец.
NekoRay, он же NekoBox. В качестве ядра может использовать сразу и v2ray и sing-box - нужную опцию можно выбрать в настройках, после этого клиент перезапускается, меняет свое имя в заголовке окна и немного изменяется интерфейс настроек в зависимости от выбранного ядра.
Написан на Qt, поэтому компактен, быстр и приятно выглядит, кроссплатформенный (Windows, MacOS, Linux).
Интерфейс действительно удобный: сервера можно группировать по вкладкам, сверху окна есть две простые галочки для активации режима системого прокси или TUN (тут оно называется VPN)
Выбранный сервер можно пошарить стандартной ссылкой или QR-кодом, а можно в формате Sing-box, что может быть удобно при обмене с клиентом Nekobox под Android (да, он там тоже есть!) и Sing-box для iOS.
Поддерживает все то что поддерживают V2Ray и Sing-box (Shadowsocks-2022, VMess, VLESS, Trojan, XTLS, uTLS, Hysteria и даже Wireguard и SSH). Даже если каких-то опций нет в интерфейсе, можно докидывать конфигурационные параметры ручками, например, чтобы активировать XTLS Vision, можно в настройках сервера нажать на “Custom JSON Settings” и добавить там соответствующую строчку "flow": "xtls-rprx-vision" (Upd: в новой версии поддержку опции запилили в интерфейсе, хак больше не нужен)
Благодаря этому можно использовать даже протоколы и фичи, которые не перечислены в UI Nekobox, но поддерживаются ядром Sing-box, например, можно настроить подключение по SSH и оно будет отображаться и работать точно так же как и другие сервера. Ещё можно подключать дополнительные cores, например, Naiveproxy.
На сегодняшний день, как по мне, самый функциональный, удобный и продуманный клиент для Windows/MacOS/Linux с графическим интерфейсом.
Лайфхак: в меню выбрать "Activate last server automatically", тогда нужный сервер будет автоматически выбираться при старте.
Что использовать на десктопе?
Буду краток - если вам нужен хороший и удобный кросс-платформенный клиент с поддержкой всего что нужно - используйте Nekobox (с ядром sing-box).
Если вы Windows-only-guy, интерфейс v2rayN вас не бесит, и не требуется каких-либо специальных фич типа TUN - можно использовать так же и v2rayN, почему бы и нет.
Если вы пользователь MacOS, и вам хочется более аутентичного интерфейса, чем в Nekobox, присмотритесь к Wings X / FoXray (он не будет ниже в разделе про мобильные клиенты).
Если вам нравится Clash или нужны какие-то его специфичные фичи, то можно попробовать Clash-Verge с ядром Clash.Meta.
Android
V2RayNG
https://play.google.com/store/apps/details?id=com.v2ray.ang&hl=en_US
https://github.com/2dust/v2rayNG
Один из самых популярных Android-клиентов. XRay в качестве ядра. Соответственно, может быть клиентом Shadowsocks, VMess, VLESS, Trojan и все остальное что умеет XRay, в том числе uTLS и XTLS. Версии в Google Play немного отстают, на Github лежат самые свежие APK - например, версия из Google Play пока еще не поддерживает XTLS-Reality, а APK-шка с гитхаба - уже да.
Единственная проблема: у меня v2rayNG почему-то не смог соединиться с сервером через VLESS + XTLS-Vision (и версия из стора, и самая новая с гитхаба). Без Vision все окей, с Vision - не работает. Причем наврядли проблема в настройках или в сервере, потому что другие клиенты с использоваием той же самой ссылки и того же QR-кода подключились к тому же серверу вполне нормально. Upd: Я еще немного покопал, и кажется понял. При установке uTLS как "android" подключение фейлится, при установке uTLS как "chrome" - все работает. Не совсем понятно, это баг на стороне v2RayNG или на стороне XRay, но баг интересный.
Clash Meta
https://github.com/MetaCubeX/ClashMetaForAndroid
https://f-droid.org/packages/com.github.metacubex.clash.meta/
Android-клиент на базе Clash.Meta. В Google Play нет, есть APK на Github и в F-Droid.
Конфигурировать сервера в интерыфейсе нельзя, добавить через QR-код или ссылку тоже нельзя, можно только загрузить YAML-файл из файловой системы или с какого-нибудь сервера, естественно только в формате Clash.
Поэтому я работоспособность не тестировал, терпения не хватило возиться.
Sagernet / Matsuri
https://sagernet.org/
https://github.com/SagerNet/SagerNet
https://play.google.com/store/apps/details?id=moe.matsuri.lite
https://github.com/MatsuriDayo/Matsuri
SagerNet - клиент под Andorid написанный на Kotlin. Долгое время считался клиентом с самым большим количеством поддерживаемых протоколов и фич. На гитхабе проекта висит объявление о том, что проекту нужен новый ментейнер, последняя версия вышла почти пол года назад, и, например, до сих пор не поддерживает XTLS-Vision.
Matsuri - форк SagerNet (в чем именно различия не разбирался), но на странице проекта написано что проект “no longer active” и предлагается перейти на Nekobox, о котором будет в следущем параграфе.
Nekobox Android
https://play.google.com/store/apps/details?id=moe.nb4a
https://github.com/MatsuriDayo/NekoBoxForAndroid/releases
Тот самый Nekobox, про который уже писали выше в главе про десктопные клиенты, только под Android. Sing-box в качестве ядра, поддерживает все что нужно на сегодняшний день, в том числе XTLS-Vision (работает без проблем) и XTLS-Reality.
Интерфейс очень похож на SagerNet (автор до этого разрабатывал его форк Matsuri), все что надо под рукой и все работает.
Что использовать на Android?
Тут ответ такой же, как и про декстопы - мне больше всего нравится Nekobox, он поддерживает всё что актуально на сегодняшний день и работает хорошо.
Если по какой-то причине не нравится, то всегда есть v2rayNG, который тоже популярный и умеет все что надо.
iOS
i2rayhttps://apps.apple.com/us/app/i2ray/id1445270056
Упоминаю этот клиент только потому что на него много где есть ссылки, в том числе на странице “Awesome V2Ray”. По факту клиент безнадежно устаревший: основан на старой версии V2Ray, умеет только в Shadowsocks и VMess, а во что-то более свежее типа VLESS, не говоря уж об XTLS - нет. Короче говоря, не стоит тратить время и деньги.
Shadowrocket
https://apps.apple.com/us/app/shadowrocket/id932747118
Один из старейших клиентов до сих пор на коне.
На каком ядре основан - не понятно, но поддерживает Shadowsocks (включая 2022), VMess, VLESS, Trojan, TUIC, Hysteria, WireGuard, XTLS-Vision (Reality пока еще нет, но будем надеяться что скоро). В отличие от многих других клиентов, настройки TLS fingerprint в окне параметров сервера нет, и можно подумать, что он клиент не поддерживает uTLS - но нет, все в порядке, просто оно настраивается там не индивидуально для каждого сервера, а в общих настройках приложения (и это даже логично). Позволяет довольно гибко настраивать правила маршрутизации (пример).
Работает даже на старых устройствах (с iOS <16). Работает без проблем. Своих денег (2.99$) однозначно стоит, но если хочется бесплатно - читайте дальше.
Stash
https://apps.apple.com/us/app/stash-rule-based-proxy/id1596063349
Тоже платный (3.99$). На базе Clash, поэтому особенности все те же, что и у Clash-клиентов: конфиг только из файла или из сети и только в формате Clash. Не совсем понятно, на базе Clash или Clash.Meta, поэтому есть вероятность что не поддерживает VLESS и XTLS. Я не тестировал.
Pharos Pro
https://apps.apple.com/us/app/pharos-pro/id1456610173
Еще один платный клиент, но уже на базе Clash.Meta - то есть должен уметь в VLess и XTLS, заявляется даже поддержка XTLS-Reality. На сайте Hysteria утверждается, что подсунув ему правильный конфиг можно заставить его работать также и с Hysteria. Кроме чтения конфигов из файла и из сети позволяет еще отсканировать QR, но в моем случае почему-то, как и v2rayNG, не заработал с VLESS+XTLS-Vision. Поэтому я рекомендую переходить к следущему пункту :)
V2Box
https://apps.apple.com/us/app/v2box-v2ray-client/id6446814690
Не смотря на название, основан на XRay, и поддерживает все то что тот умеет.
Проект еще сыроват, но активно развивается - в ранних версиях была проблема со скоростью (тормозило-с), потом проблему со скоростью исправили, но появилась проблема с хаотичными отсоединениями, в свежей версии все эти проблемы исправили и клиент в принципе работает как надо, по добавилась реклама при подключении :)
В теории должен работать и на десктопной macOS, я не проверял.
Wings X / FoXray
А вот это отличный клиент под iOS (версии не ниже 16) на базе XRay-core.
Умеет всё то, что поддерживает свежий XRay-core: VLESS, Socks, VMess, Shadowsocks, Trojan поверх TCP, TLS, WebSocket, mKCP, gRPC, HTTP/2, QUIC. И да, свежая версия поддерживает XTLS, в том числе Reality.
Заявлена поддержка форматов подписок v2rayN и Clash, поддержка формата QR-кодов v2rayNG, а также своего варианта для шэринга серверов со всеми настройками (включая правила и маршруты).
Приятный интерфейс. Работает без проблем. И бесплатный. Одно но - требует свежей iOS (16 и выше).
На сегодняшний день, пожалуй, самый лучший клиент для iOS. Кстати, Wings X есть и под десктопную macOS - я не тестировал, но надеюсь там тоже все замечательно.
Upd: В мае 2023 Wings X исчез из сторов, но зато появился его форк под названием FoXray (судя по описанию, даже от того же разработчика).
Что использовать на iOS?
Я думаю, вы уже поняли. Мой выбор - Wings X / FoXray либо Shadowrocket, что больше понравится. Можно начать с первого, он бесплатный, а если по какой-то причине не подойдет или перестанет обновляться, то перейти на второй.
OpenWRT
Сразу скажу - этот вопрос я глубоко не копал, ибо подходящего роутера под рукой нет, поэтому просто докину пару ссылок:
Luci-App-XRay - клиент под OpenWrt на базе XRay, поддерживает все протоколы что поддерживает XRay (включая XTLS Vision и Reality), в качестве inbounds поддерживает HTTP/HTTPS/Socks прокси и прозрачный (TProxy). Ну и человекопонятный интерфейс для настройки.
OpenWRT-Passwall - популярный и много где упоминаемый набор инструментов, там есть и v2ray, и xray, и sing-box, и hysteria, и naiveproxy, и чего только еще нет.
Merlin-Clash - для роутеров ASUS и им подобным на базе Clash (на китайском, блин).
4. Обход блокировок настройка сервера XRay
С протоколами разобрались, с клиентами разобрались, теперь наконец‑то настало время рассказать о том, как же настроить свой личный прокси‑сервер с современными протоколами для обхода блокировок. Мы будем настраивать сервер на базе XRay (который является форком известного V2Ray, и еще я немного упомяну Sing‑Box) с протоколами Shadowsocks-2022 и VLESS с транспортом XTLS‑Vision и фейковым веб‑сайтом для защиты от выявления. И в качестве запасного варианта на том же сервере мы настроим fallback на VLESS+Websockets, чтобы была возможность работать через CDN типа Cloudflare, если вдруг IP-адрес вашего сервера попадет под блокировку. В конце я приведу настройки десктопных и мобильных клиентов для подключения ко всему этому.
Поехали.
Настройку буду описывать под Debian или Ubuntu Linux. Если у вас на VPS стоит другой дистрибутив, то там будет примерно все то же самое, хотя некоторые команды и названия пакетов могут отличаться.
Итак, допустим у нас уже есть VPS-сервер с Debian или Ubuntu в какой-нибудь заморской юрисдикции, у него есть IP-адрес, на нем настроен SSH и вообще все пока что неплохо. И еще у вас должен быть какой-нибудь домен, не обязательно платный (хотя сейчас по акциям можно зарегистрировать домен в какой-нибудь не очень популярной зоне всего за доллар-два в год), подойдет даже DynDNS. Если чего-то из вышеописанного у вас нет, советую ознакомиться этой и этой статьей, там в начале описывается базовая установка и настройка VPS-сервера с Linux и регистрация бесплатного домена через DynDNS. Ну а мы идем дальше.
Первый вариант настройки я приведу для "пустого сервера" - это если на вашем сервере нет никаких других сервисов (но потом можно будет добавить еще и веб-сайт, да). Во второй половине статьи я расскажу, как настроить XRay когда у вас на машине уже крутится веб-сервер и вы не хотите лишний раз трогать его конфигурацию. Третий вариант будет с Docker для самых маленьких.
Вариант первый, полный, подробный
Разработчики XRay подготовили скрипт, который автоматически скачивает XRay под используемую систему и создает systemd-юнит (спасибо @alegz81 что напомнил): https://github.com/XTLS/Xray-install
Устанавливается одной длинной командой
$ bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install
Единственное различие от описанного в статье при конфигурации будет в том, что конфиги XRay будут лежать не в /opt/xray, а в /usr/local/etc/xray/.
Либо же можем установить все ручками.
Идем вот сюда: https://github.com/XTLS/Xray-core/releases и скачиваем самый свежий билд XRay-core:
$ wget https://github.com/XTLS/Xray-core/releases/download/v1.8.0/Xray-linux-64.zip
Cоздаем директорию, распаковываем и делаем файл исполняемым (он поставляется в .zip-архиве, поэтому разрешения при упаковке-распаковке теряются):
$ mkdir /opt/xray
$ unzip ./Xray-linux-64.zip -d /opt/xray
$ chmod +x /opt/xray/xray
Далее создадим systemd-юнит и вставим туда следущий текст (я использую nano, вы, понятное дело, можете использовать vi и вообще все что угодно):
$ nano /usr/lib/systemd/system/xray.service
[Unit]
Description=XRay
[Service]
Type=simple
Restart=on-failure
RestartSec=30
WorkingDirectory=/opt/xray
ExecStart=/opt/xray/xray run -c /opt/xray/config.json
[Install]
WantedBy=multi-user.target
$ systemctl daemon-reload
$ systemctl enable xray
Обратите внимание - в данном случае xray запустится от пользователя root. Это не очень хорошо в плане безопасности, я сделал это так в примере для упрощения мануала, но по-хорошему нужно создать для xray отдельного пользователя, запускать его от него, не забыть выставить ему права для чтения на директории и файлы от certbot/letsencrypt (об этом чуть дальше), и чтобы была возможность повесить сервер на порт 443 или другие <1000, выставить специальную опцию на бинарник/процесс.
На этом установка XRay закончена, дальнейшие действия будут одинаковы и при ручной настройке, и при использовании скрипта.
Нам будут нужны TLS-сертификаты.
Устанавливаем certbot и запрашиваем сертификат для нашего домена (например, example.com):
$ apt install certbot
$ certbot certonly --standalone --preferred-challenges http -d example.com
Если вам нужно иметь два домена или домен и поддомен (например, один будет доступен напрямую, другой через CDN), то можно указать ещё один аргумент -d в этой команде и у вас будет сертификат сразу для двух доменов. А ещё оно поддерживает wildcards.
Certbot спросит ваш емайл на всякий случай, спросит согласны ли вы с правилами, запросит сертификат от LetsEncrypt, положит его в папочку /etc/letsencrypt и создаст правило, чтобы он обновлялся каждые 3 месяца. При каждом обновлении сертификата нужно перезапускать XRay-сервер, давайте попросим certbot делать это автоматически:
$ nano /etc/letsencrypt/renewal/example.com.conf
и там в конец добавим строку
renew_hook = systemctl reload xray
Теперь переходим к самому интересному. Создаем и редактируем конфиг:
$ nano /opt/xray/config.json # или в /usr/local/etc/xray/ в случае использования скрипта
{
"log": {
"loglevel": "info"
},
"routing": {
"rules": [],
"domainStrategy": "AsIs"
},
"inbounds": [
{
"port": 23,
"tag": "ss",
"protocol": "shadowsocks",
"settings": {
"method": "2022-blake3-aes-128-gcm",
"password": "aaaaaaaaaaaaaaaabbbbbbbbbbbbbbbb",
"network": "tcp,udp"
}
},
{
"port": 443,
"protocol": "vless",
"tag": "vless_tls",
"settings": {
"clients": [
{
"id": "7957c33c-d9ca-11ed-afa1-0242ac120002",
"email": "user1@myserver",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none",
"fallbacks": [
{
"path": "/myverysecretpath",
"dest": "@vless-ws"
},
{
"dest": "8080"
}
]
},
"streamSettings": {
"network": "tcp",
"security": "tls",
"tlsSettings": {
"alpn": [
"http/1.1",
"h2"
],
"certificates": [
{
"certificateFile": "/etc/letsencrypt/live/example.com/fullchain.pem",
"keyFile": "/etc/letsencrypt/live/example.com/privkey.pem"
}
]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
]
}
},
{
"listen": "@vless-ws",
"protocol": "vless",
"tag": "vless_ws",
"settings": {
"clients": [
{
"id": "7957c33c-d9ca-11ed-afa1-0242ac120002",
"email": "user2@myserver"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "ws",
"security": "none",
"wsSettings": {
"path": "/myverysecretpath"
}
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}
На что обратить внимание. В inbounds мы задаем правила обработки входящих подключений - первым идет Shadowsocks-2022 на 23 порту (можете использовать любой другой порт, само собой). О том, что эта версия протокола именно 2022 говорит method "2022-blake3-aes-128-gcm". Ключ - любой в шестнадцатеричной форме, его длина зависит от типа шифра, в примере 128-битный шифр, если используете 256-битный, то ключ, соответственно, должен быть в два раза длиннее.
Дальше идет VLESS через TLS, стандартный порт 443. В секции "clients" задаются пользователи-клиенты, в примере он только один. ID клиента можно сгенерировать любым онлайновым UUID-генератором. Также для юзера задается опция "flow" со значением "xtls-rprx-vision", означающая что этот пользователь будет подключаться с использованием XTLS-Vision. В настройках "streamSettings" вы можете увидеть пути к сертификатам, которые мы запросили у LetsEncrypt, в пути должен быть файл соответствующий вашему домену. В "fallbacks" задаются правила о том, что делать, если юзер был не опознан, либо подключение производится не через чистый VLESS-протокол: если мы видим HTTP-запрос с URI /myverysecretpath, то передаем подключение на обработчик vless-ws, для всего остального - на порт 8080, где у нас будет висеть веб-сервер с фейковым (или даже настоящим) веб-сайтом.
И наконец, третим идет вариант VLESS через Websocket, на том же 443 порту. Таким образом, например, можно подключаться к серверу не напрямую, а через CDN, что поможет если ваш сервер вдруг заблокировали цензоры или если вы подключаетесь через строгий корпоративный прокси. Настройка его почти аналогична предыдущему пункту, UUID пользователя там указан тот же самый, единственные различие - нет опции "xtls-rprx-vision", потому что через CDN она работать не будет, и есть секция "wsSettings", где указан тот же секретный путь на сервере /myverysecretpath что и в fallbacks.
В комментариях к предыдущей статье упоминали, что websocket-транспорт не всегда работает надежно и эффективно, а еще при очень больших объемах передаваемого трафика Cloudflare может обидиться и начать просить перейти на платный тариф. Поэтому вместо websocket некоторые советуют использовать gRPC-транспорт. Я пробовал, и у меня не получилось нормально настроить fallback на gRPC. В комментарии к статье хабраюзер @s7eepz приложил пример настройки fallback'а на gRPC через Nginx - но важный момент, Nginx должен быть собран с gRPC-модулем. В Debian/Ubuntu и в официальных репозиториях от разработчиков он собран без него.
И как вы могли заметить, в конфиге упомянут порт 8080 для fallback. На нем у нас должен слушать веб-сервер с сайтом для маскировки. Самый просто вариант это сделать - поставить позади него nginx:
$ apt install nginx
$ nano /etc/nginx/sites-enabled/default
$ systemctl restart nginx
Где /etc/nginx/sites-enabled/default в самом простом случае будет представлять собой что-то типа такого:
server {
listen 127.0.0.1:8080 default_server;
listen [::1]:8080 default_server;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
try_files $uri $uri/ =404;
}
}
(главное изменение по сравнению с дефолтной конфигурацией - сервер слушает не на всех адресах, а только на localhost, и не на 80, а на 8080 порту).
После этого при попытке подключиться к вашему IP-адресу обычным браузером (то, что могут автоматически делать цензоры, пытаясь выявить прокси-сервера), отвечать будет Nginx, отдавая страницы лежащие в /var/www/html. По умолчанию там лежит заглушка, можно закинуть туда какие-нибудь странички и видео с котятками.
Если лень заморачиваться с поднятием фейкового сайта, есть второй вариант - пусть веб-сервер спрашивает у подключающихся логин и пароль, и отклоняет все введенные варианты:
location / {
auth_basic "Administrator’s Area";
auth_basic_user_file /etc/htpasswd;
}
Сам файл /etc/htpasswd может вообще даже не существовать - нам не нужно проверять правильность пароля, мы будем отклонять все подряд, делая вид что пароль не подошел. Nginx все равно запустится даже без этого файла.
В браузере это будет выглядеть вот так
Третий вариант - переадресовывать подключения на какой-нибудь другой сайт. XRay не умеет перекидывать подключения на внешние сервера, только на локальные, поэтому тут нам опять поможет Nginx:
server {
listen 127.0.0.1:8080 default_server;
listen [::1]:8080 default_server;
server_name _;
location / {
proxy_pass http://lib.ru;
}
}
В результате при попытке открытия адреса прокси браузером загрузится зеркало lib.ru - замените его на какой-нибудь другой сайт. Использовать для этого какие-либо популярные или навороченный сайты явно не стоит, а вот какую-нибудь богом забытую хомпагу эпохи Web 1.0 или безымянную webftp-файлосвалку - уже можно. А чтобы некоторые тупые боты или пауки поисковых систем не нагнали вам трафика, можно добавить опции ratelimit-модуля в Nginx и ограничить скорость передачи данных с "переадресованного" сайта, например, до 1 мегабита.
Перезапускаем еще раз xray:
$ systemctl restart xray
Проверяем что все нормально запустилось:
$ journalctl -u xray
Например, XRay может ругнуться что не удается распарсить JSON-файл, обычно это связано с лишними запятыми в конце {} блока, в этом случае он укажет, на какой строке ошибка. Исправляем ошибки, перезапускаем еще раз, и переходим к настройке клиентов.
Чтобы настроить в других клиентах или на других устройствах (например, на смартфоне, или поделиться сервером с друзьями), кликаем на сервер правой кнопкой мыши, выбираем Share -> QR code and Link, и получаем ссылку, которую можно отправить кому-нибудь например через Telegram и QR-код, который можно отсканировать камерой во многих клиентах.
Соответственно, потом на мобильном устройстве в Nekobox, или в v2rayNG, или в Wings X, или в любом другом клиенте, нажимаем что-то типа "Add server" -> "Scan QR" - и все, новый сервер у вас в списке, можно подключаться.
Важно: некоторые клиенты при добавлении сервера по ссылке или QR теряют настройку uTLS, поэтому перепроверяйте все ли на месте после добавления нового сервера.
Лайфхак #1: а еще можно упороться и добавить в Nekobox еще и SSH в качестве подключения, пример конфигурации есть вот здесь (сначала надо будет подключиться родным системным ssh-клиентом, сгенерить клиентский ssh-ключи и сделать ssh-copy-id, в Windows это тоже работает).
Лайфхак #2: Чтобы не забывать ставить uTLS fingerprint для каждого подключения отдельно, его можно задать дефолтное значение в общих настройках Nekobox.
Вариант второй, полуготовый
А теперь представим, что у вас на VPS уже установлен веб-сервер с каким-нибудь сайтом, уже настроены TLS-сертификаты, и все остальное, и нужно просто аккуратно добавить прокси, желательно не ломая конфиг сервера.
Вариант раз: заиметь еще один поддомен, и разруливать TLS-подключения еще на этапе хэндшейка по SNI с помощью, например, HAProxy или ssl_preread модуля в Nginx. Тогда настройка XRay будет полностью аналогична описанному в предыдущем пункте, разве что только надо будет перевесить его с 443 на другой порт.
Вариант два: TLS-сессия будет терминироваться веб-сервером, и в случае обращения к определенному URL он будет передавать подключение на прокси. Этот вариант проще, единственное ограничение - никакого XTLS (ни Vision, ни Reality) уже не получится, и производительность будет немного ниже.
Итак, допустим, у вас настроен Nginx (или любой другой веб-сервер с каким-нибудь сайтом). Нужно средствами веб-сервера настроить переадресацию обращений к определенному урлу на прокси. Варианта два - использовать websockets (и надо не забыть передать специфичные для них хедеры), или использовать gRPC (если ваш сервер умеет его проксировать). В Nginx это будет выглядеть примерно так, для веб-сокетов:
location /myverysecretpath {
proxy_pass http://127.0.0.1:8888;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
}
А конфиг XRay будет таким:
{
"log": {
"loglevel": "info"
},
"routing": {
"rules": [],
"domainStrategy": "AsIs"
},
"inbounds": [
{
"port": 23,
"tag": "ss",
"protocol": "shadowsocks",
"settings": {
"method": "2022-blake3-aes-128-gcm",
"password": "aaaaaaaaaaaaaaaabbbbbbbbbbbbbbbb",
"network": "tcp,udp"
}
},
{
"listen": "localhost",
"port": 8888,
"protocol": "vless",
"tag": "vless_ws",
"settings": {
"clients": [
{
"id": "7957c33c-d9ca-11ed-afa1-0242ac120002",
"email": "user1@myserver"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "ws",
"security": "none",
"wsSettings": {
"path": "/myverysecretpath"
}
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}
Как видно, почти то же самое, что и в предыдущем варианте, только нет inbound для "прямого" TLS-подключения, и вообще нет ничего про TLS - сервер слушает 8888 порт и сразу обрабатывает его как веб-сокет. /myverysecretpath, понятное дело, должен совпадать в конфиге веб-сервера и в конфиге прокси.
Настройки клиентов для этого варианта будут полностью аналогичны настройкам клиентов для Shadowsocks и VLESS+Websocket из прошлого пункта.
Вариант с gRPC по примеру из официальной репы с примерами у меня так и не заработал (чует мое сердце, там есть какой-то подвох с TLS и с переадресацией на него) - так что если у кого-то есть рабочие конфиги для XRay и Nginx с gRPC, делитесь в комментариях.
Вариант третий для самых ленивых (Websockets-only)
$ apt install docker.io docker-compose
$ mkdir /etc/xray/
$ nano /etc/xray/config.json
$ nano /etc/xray/Caddyfile
$ nano docker-compose.yml
/etc/xray/config.json:
{
"log": {
"loglevel": "info"
},
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "block"
}
]
},
"inbounds": [
{
"listen": "0.0.0.0",
"port": 5000,
"tag": "vless_ws",
"protocol": "vless",
"settings": {
"clients": [
{
"id": "7957c33c-d9ca-11ed-afa1-0242ac120002",
"email": "test@test.com"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "ws",
"security": "none"
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}
/etc/xray/Caddyfile
example.com {
handle_path /myverysecretpath {
reverse_proxy http://xray:5000
}
reverse_proxy lib.ru:80 {
}
}
или, если не нужна переадресация, а хватит просто 401 Unauthrized:
example.com {
handle_path /myverysecretpath {
reverse_proxy http://xray:5000
}
basicauth / {
bob JDJhJDE0JElab2ZPM25zdU40bE5SSURlTHd3OHVBeVJvYTlMN3dMOEFMdFVCRzNYS1l5ODl6TlVyQllH
}
}
docker-compose.yml
version: '2'
volumes:
caddy_data:
caddy_config:
services:
xray:
image: teddysun/xray
volumes:
- /etc/xray:/etc/xray
ports:
- 23:23
caddy:
image: caddy
volumes:
- caddy_data:/data
- caddy_config:/config
- /etc/xray/Caddyfile:/etc/caddy/Caddyfile
depends_on:
- xray
links:
- xray:xray
ports:
- 443:443
- 80:80
$ docker-compose up -d
Тут в качестве веб-сервера используется Caddy, он же сам запрашивает и обновляет TLS-сертификаты (certbot не нужен). IPv6 не будет, но все остальное в принципе работает - опять же, только WS, и никакого XTLS. Lazydocker вам в помощь.
Нюансы и мудрости
На сегодняшний день связка VLESS+XTLS-Vision является самой проверенной и устойчивой к блокировкам. Однако нужно иметь в виду еще пару вещей:
- Обязательно используйте uTLS на клиентах, выставляя правильный TLS fingerprint. Клиенты, которые не умеют в uTLS лучше не использовать;
- Обязательно поднимите фейковый веб-сайт или настройте fallback-переадресацию на какой-нибудь левый адрес;
- С uTLS связан интересный баг: если при использовании XTLS-Vision вы почему-то не можете подключиться, в логах сервера видна ошибка типа "failed to use xtls-rprx-vision, found outer tls version 771", попробуйте сменить версию uTLS. У меня, например, при выборе "android" клиент не подключается, а при выборе "chrome" все окей;
- С XTLS лучше, чем без него;
- Во время отладки конфигурации в случае проблем с TLS может помочь опция "allowInsecure" на клиенте;
- Очень рекомендуется настраивать на клиентах правила маршрутизации, чтобы трафик до .ru-доменов и хостов с российскими IP шел напрямую, а не через прокси (в клиентах для такого поставляется GeoIP база данных). GeoIP из Nekobox (да и других клиентов) знает российские диапазоны, а вот GeoSite - уже нет, увы.
В итоге у меня работает вот такая настройка, GeoIP активируется стандартным образом в Nekobox.
правила по суффиксам Nekobox не умеет, но их умеет sing-box в его основе, поэтому жмем "Custom" и прописываем вот такое
{
"rules": [
{
"domain_suffix": [
".ru"
],
"outbound": "direct"
}
]
}
После этого весь трафик до .ru-доменов и российских IP-адресов будет идти напрямую.
Если нужно заблокировать полностью - то в первом окне вместо Direct вставить в Block, а в JSON-коде исправить direct на block.
Ещё можно иметь два сервера (low-end сервер в РФ можно арендовать рублей так за 60), и приняв подключение передавать его на следущий сервер, указав в outboundTag не freedom и не block, а тег соответствующего outbound'а (XRay может работать сразу и как сервер, и как клиент, не забываем).
7. При проксировании на Nginx или любой другой сервер, так же хорошей практикой считается проксировать HTTP/1.1 и HTTP/2 отдельно.
В конфиге Nginx для этого нужно что-то типа такого:
listen 127.0.0.1:8888;
listen 127.0.0.1:8889 http2;
А в конфиге XRay:
"fallbacks": [
{
"dest": "8888"
},
{
"alpn": "h2",
"dest": "8889"
}
]
А что там с CDN?
Пока что известно две CDN, которые позволяют на бесплатных аккаунтах работать с подобным: Cloudflare позволяет проксировать Websocket и gRPC, GCore позволяет проксировать Websocket (насчет gRPC не знаю, не проверял). Про Cloudflare говорят, что при проксировании очень больших объемов через вебсокеты они могут попросить перейти на платный тариф, про gRPC такого не написано.
Для работы через CDN нужен будет уже полноценный домен (не DynDNS), который можно делегировать на NS CDN-сети и управлять им там. Дальше нужно включить проксирование для конкретного домена.
Лайфхак: если у вас дешевый IPv6-only сервер, вы можете указать для него только AAAA-запись (IPv6), и Cloudflare все равно позволит вам подключаться к нему по IPv4 через свою сеть. Смекалочка.
Ну и не забыть отдельно включить в настройках проксирование WS и gRPC.
А что с XTLS-Reality?
Технология многообещающая, уже даже во многих клиентах поддерживаемая, но с ней надо разбираться отдельно, и ее настройка - тоже разговор отдельный. Кто уже смог и осилил - пишите в комментарии, а лучше вообще еще одну статью. Источник вдохновения и примеры конфигов с XTLS-Reality можно найти здесь.
А что с Sing-box?
Sing-box - активно развивающийся и тоже многообещающий клиент и сервер, и он может использоваться вместо XRay, поскольку тоже поддерживает Shadowsocks-2022, VLESS, Trojan, XTLS-Vision и XTLS-Reality, а еще умеет работать с Hysteria, Naiveproxy, и всякое другое.
Официальный сайт
Github
Документация по настройке
Разработчики реорганизуют репу, поэтому переход по ссылкам в документации может выдавать 404 ошибку — без паники, смотрим название файла, и находим правильный путь в гите по названию, дальше никаких проблем.
Как и XRay, Sing‑box умеет делать fallback'и, только здесь в секции «listen» оно называется «detour», и значением этого параметра должен быть «tag» другого inbound'а.
Сайт со скриптами автоустановки и примерами конфигураций
А можно проще, и чтобы все и сразу?
Для Xray и сотоварищей существует много разных user-friendly серверных морд с простой установкой.
Есть Marzban, например - его тоже можно ставить через Docker, он включает в себя XRay, обещает красивый интерфейс для настройки и управления пользователями и даже встроенный Telegram-бот.
Ещё есть Libertea, Hiddify (про него сказано что он умеет Reality), и разные форки X-UI, где обещают все то же самое.
Но тестировать и сравнивать их у меня пока времени и терпения нет.
5. Bleeding-edge обход блокировок с полной маскировкой
Но кое о чем мы не поговорили. Во второй части я вскользь упомянул самую передовую и недетектируемую технологию обхода блокировок под названием XTLS-Reality, и пришло время рассказать о ней поподробнее, а именно - как настроить клиент и сервер для нее.
Кроме того, что этот протокол еще более устойчив к выявлению, приятным фактом будет и то, что настройка сервера XRay для XTLS-Reality гораздо проще, чем описанные ранее варианты - после предыдущих статей я получил довольно много комментариев типа "А что так сложно, нужен домен, нужны сертификаты, и куча всего" - теперь все будет гораздо проще.
XTLS-Reality
Коротко про XTLS-Reality. Это самое новое изобретение от авторов XRay. Про XRay (и его прородителя V2Ray, он же V2Fly) [[4. Обход блокировок настройка сервера XRay | я рассказывал в предыдущей статье]]. XTLS-Reality поддерживается в последних релизах XRay, Sing-box и многих клиентах.
Он предназначен для защиты от выявления методом active probing. В отличие от старых протоколов (Shadowsocks, VMess, VLESS, и транспорта XTLS-Vision), определение “свой/чужой” здесь происходит еще на этапе TLS-хендшейка в момент чтения ClientHello. Если клиент опознан как “свой”, сервер работает как прокси, а если нет - вжух! - и TLS подключение передается на какой-нибудь другой абсолютно реальный хост с TLS (например, google.com или gosuslugi.ru), и таким образом клиент (или цензор, желающий методом active probing проверить, а что же прячется на том конце) получит настоящий TLS-сертификат от google.com или gosuslugi.ru и настоящие данные с этого сервера. Полное соответствие. Механизм определения "свой/чужой" во многом схож с механизмом работы Cloak, и позволяет достоверно определить подлинность клиента, но вместе с тем не вызывает подозрения у цензоров и устойчив к replay-атакам - со стороны систем анализа трафика это выглядит как подключение к настоящему популярному сайту, сервер отдает настоящий TLS-сертификат этого сайта, и вообще все (включая TLS fingerprint сервера) выглядит до предела аутентично и не вызывает подозрений. Еще XTLS-Reality может оказаться вариантом для обхода суровых корпоративных прокси с Man-in-the-Middle, которые перешифровывают весь трафик из сети своим сертификатом (нередко подобные прокси имеют список исключений для ресурсов с HSTS и certificate pinning, либо для экономии ресурсом, и подобрав правильный домен можно пролезть во внешнюю сеть без расшифровки трафика). Бонусом еще XTLS-Reality обычно используется в паре с XTLS-Vision, то есть мы имеем очень достоверно выглядящие паттерны трафика из-за отсуствия двойного шифрования TLS-in-TLS (и заодно еще очень высокую производительность, у меня между хостами в Москве и в центральной Европе XRay легко выдает >100 мегабит).
Единственный минус подобного решения - в отличие от более старых протоколов (VLESS без XTLS) нет возможности работать через websocket-транспорт, и, соответственно, через CDN типа Cloudflare. Upd: такая возможность есть если использовать многоуровневую схему с SNI-proxy (типа haproxy), при необходимости расскажу в комментариях.
Установка сервера XRay
А теперь настало время все это настроить. Дано: VPS на Linux (Debian или Ubuntu, на других дистрибутивах плюс-минус то же самое) с IPv4 или IPv6-адресом.
Установку XRay и уже описывал в предыдущей статье, поэтому здесь буду краток.
Можно установить XRay руками:
wget https://github.com/XTLS/Xray-core/releases/download/v1.8.1/Xray-linux-64.zip
mkdir /opt/xray
unzip ./Xray-linux-64.zip -d /opt/xray
chmod +x /opt/xray/xray
nano /usr/lib/systemd/system/xray.service
systemctl enable xray
xray.service
[Unit]
Description=Xray Service
Documentation=https://github.com/xtls
After=network.target nss-lookup.target
[Service]
User=nobody
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
NoNewPrivileges=true
ExecStart=/opt/xray/xray run -config /opt/xray/config.json
Restart=on-failure
RestartPreventExitStatus=23
LimitNPROC=10000
LimitNOFILE=1000000
[Install]
WantedBy=multi-user.target
А можно установить скриптом от разработчиков (почему-то по умолчанию он ставит старую версию 1.7.5, которая не поддерживает Reality, поэтому нужно явно указать более свежую):
bash -c "$(curl -L https://raw.githubusercontent.com/XTLS/Xray-install/046d9aa2432b3a6241d73c3684ef4e512974b594/install-release.sh)" @ install --version 1.8.1
Скрипт установит XRay и создаст для него systemd-юнит.
Настройка сервера XRay
Для настройки нам понадобится ряд параметров. Часть из них нам может сгенерировать сам XRay:
/usr/local/bin/xray uuid # /opt/xray/xray если устанавливали вручную
/usr/local/bin/xray x25519 # /opt/xray/xray если устанавливали вручную
На выходе вы получите UUID (идентификатор пользователя для протокола аутентификации VLESS), а также приватный и публичный ключи - запишите их, они вам понадобятся.
Еще один параметр, который нужен - short ID, он представляет собой просто шестнадцатиричное число (символы 0-9, a-g) длиной до 8 байт (16 символов) - можно набрать любую абракадабру типа "aabbccdd" или запустить openssl rand -hex 8
А вот дальше начинается самое интересное. Нам нужно найти сайт, под который мы будем маскироваться.
Требования довольно простые:
это должен быть иностранный сервер (вне РФ), не забаненный по домену Роскомнадзором, поддерживающий подключения по TLSv1.3 и HTTP/2, имеющий заглавную страницу, которая не переадресовывает на какой-нибудь другой домен. Если совсем упарываться, то неплохо было бы если бы IP-адрес был из диапазона того же облачного хостера, что и у вас, и чтобы сервер поддерживал Online Certificate Status Protocol (OCSP). Если вы не знаете, что вся эта фигня значит - не заморачивайтесь, выбирайте что-нибудь простое, например
- www.samsung.com:443
- www.googletagmanager.com:443
- www.asus.com:443
- www.amd.com:443
- www.cisco.com:443
- www.microsoft.com:443
- dl.google.com:443
- www.linksys.com:443
- www.nvidia.com:443 и т.д.
Сервер выбрали, настало время редактировать конфиг. Если вы ставили XRay вручную то он будет лежать в /opt/xray/config.json, если скриптом - то в /usr/local/etc/xray/config.json.
Приводим его к следующему виду:
{
"log": {
"loglevel": "info"
},
"routing": {
"rules": [],
"domainStrategy": "AsIs"
},
"inbounds": [
{
"port": 23,
"tag": "ss",
"protocol": "shadowsocks",
"settings": {
"method": "2022-blake3-aes-128-gcm",
"password": "aaaaaaaaaaaaaaaabbbbbbbbbbbbbbbb",
"network": "tcp,udp"
}
},
{
"port": 443,
"protocol": "vless",
"tag": "vless_tls",
"settings": {
"clients": [
{
"id": "4c3fe585-ac09-41df-b284-70d3fbe18884",
"email": "user1@myserver",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "www.microsoft.com:443",
"xver": 0,
"serverNames": [
"www.microsoft.com"
],
"privateKey": "GOTPj_klK7_j_IvjxiCtyBL80RYotYSOdBBBSfFOMH4",
"minClientVer": "",
"maxClientVer": "",
"maxTimeDiff": 0,
"shortIds": [
"aabbccdd"
]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
]
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}
На что обратить внимание: в "serverNames" указан домен, под сервер которого вы маскируетесь (в данном случае www.microsoft.com), "id" в секции "clients" - это тот самый UUID, что мы сгенерировали выше. "privateKey" и первый элемент в массиве "shortIds" - это приватный ключ и short ID, что мы тоже сгенерировали выше. Публичный ключ не теряйте, он будет нужен на клиенте.
В этом конфиге так же на 23 порту настроен Shadowsocks-2022, на всякий случай, вдруг пригодится. Если не надо, или хочется полной маскировки - можно удалить этот элемент из "inbounds".
Перезапускаем еще раз xray:
$ systemctl restart xray
Проверяем что все нормально запустилось:
$ journalctl -u xray
Например, XRay может ругнуться что не удается распарсить JSON-файл, обычно это связано с лишними запятыми в конце {} блока, в этом случае он укажет, на какой строке ошибка. Исправляем ошибки, перезапускаем еще раз, и переходим к настройке клиентов.
Настройка клиентов
Сначала Nekobox на десктопе (Windows, Linux, и есть неофициальные билды под MacOS).
Если вы раньше им не пользовались, нужно переключить его на использование движка sing-box, Preferences -> Basic Settings -> Core.
Address - IP-адрес вашего сервера, UUID - соответственно, UUID, SNI должен соответствовать домену, под который вы маскируетесь (один из списка "serverNames" из конфига сервера), uTLS - я выбираю Chrome (это маскировка клиента под обычный браузер), Reality Pbk - публичный ключ (не приватный, а второй, публичный), Reality Sid - shortId из конфига выше.
Сохраняем, кликаем правой кнопкой мыши на новый сервер в списке, жмем Start, и проверяем подключение выбрав там же Current Select -> URL test.
Если все нормально, то галочками "VPN Mode" или "System proxy" можно завернуть трафик всех приложений на прокси.
Настройка v2rayN под Windows аналогична, набор параметров тот же.
Автор Nekobox перестал собирать версии под macOS, поэтому я рекомендую использовать Wings X / FoXray. Настройки точно такие же.
Если вдруг вам нравятся Clash-based клиенты (например, Clash Verge под Windows, Linux, MacOS или для мобильных устройств), то нужно использовать ядро Clash.Meta и специальны конфиг для Clash. В случае с Clash Verge можно сделать так:
- Settings -> Clash Core -> Выбрать Meta
- Сохранить конфиг в какой-нибудь локальный файл: clash-reality.yml
mode: global
mixed-port: 7890
allow-lan: false
log-level: info
ipv6: true
secret: ''
external-controller: 127.0.0.1:9090
proxies:
- name: vless-reality-vision
type: vless
server: xxx.xx.xx.xx # ваш IP
port: 443
uuid: 4c3fe585-ac09-41df-b284-70d3fbe18884 # ваш UUID
network: tcp
tls: true
udp: true
flow: xtls-rprx-vision
servername: www.microsoft.com # ваш фейковый домен
reality-opts:
public-key: kbITklNKTdfvB6e3xy97pTV7gjl3Z3irv246oRZ5Gnk # public key
short-id: aabbccdd # short ID
client-fingerprint: chrome
- Profiles -> New - Type : Local -> выбрать ваш файл и кликнуть по нему в окне Clash
- Proxies -> выбрать ваш новый прокси на вкладке Global -> кликнуть по полю справа чтобы протестировать подключение, должно появиться значение пинга
- Settings -> System proxy: вкл - после этого трафик всей системы пойдет через прокси. Можно использовать и TUN, но для этого надо запускать Clash Verge от рута.
Далее, мобильные клиенты. Вариант раз: в Nekobox или в v2ray кликнуть правой кнопкой мыши на ваш сервер из списка, выбрать Share -> QR code или Link, и получить ссылку или QR-код, которые потом можно отсканировать/вставить в мобильные клиенты. Либо вбить все те же данные руками, вот как это выглядит в андроидовском v2rayNG (версия из Google Play еще не обновилась и не умеет работать с Reality, скачиваем APK с Гитхаба).
Под iOS я рекомендую использовать Shadowrocket (3$) или Wings X / FoXray (он бесплатный). Настройки подключения полностью аналогичны описанному выше.
Советы бывалых
- Очень рекомендуется настраивать на клиентах правила маршрутизации (пример в комментариях), чтобы трафик до .ru-доменов и хостов с российскими IP шел напрямую, а не через прокси (в клиентах для такого поставляется GeoIP база данных).
- Обязательно используйте uTLS на клиентах, выставляя правильный TLS fingerprint (например, Chrome).
Если при использовании XTLS вы почему-то не можете подключиться, в логах сервера видна ошибка типа "failed to use xtls-rprx-vision, found outer tls version 771", попробуйте сменить версию uTLS. У меня, например, при выборе "android" клиент не подключается, а при выборе "chrome" все окей. - Для увеличения производительности можно настроить на сервере Bottleneck Bandwidth и Round-trip propagation time (BBR) congestion control algorithm:
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p - Чтобы проверить, что маскировка работает как надо, добавьте IP-адрес вашего сервера и домен, под который вы маскируетесь, в hosts-файл (на Linux это /etc/hosts, на Windows это c:\windows\system32\drivers\etc\hosts), например, "38.25.63.10 www.microsoft.com", и после этого попробуйте зайти на этот адрес браузером - должна открыться настоящая страница этого домена с настоящим TLS-сертификатом.
Другой вариант: использовать CURL.
curl -v --resolve www.microsoft.com:443:151.101.65.69 https://www.microsoft.com (вместо 151.101.xx.xx должен быть IP вашего сервера)