VLESS и Reality простыми словами: как Xray выглядит как HTTPS

VLESS - лёгкий прокси-протокол из проекта Xray, который аутентифицирует клиента по UUID и переносит его трафик; собственного шифрования у него нет, и он полагается на нижележащий слой. Reality - и есть этот слой: модифицированный TLS 1.3, благодаря которому соединение для любого наблюдателя выглядит как посещение настоящего известного сайта, - а если кто-то без ключа подключится к серверу, чтобы проверить, его пропустят к этому настоящему сайту, и он увидит его подлинный сертификат. XTLS Vision, обычное значение настройки «flow», убирает статистические приметы TLS внутри TLS. Вместе они дают туннель, в котором сетям, блокирующим VPN по их форме, не за что зацепиться. В этой статье объясняется каждая часть, как Reality проводит аутентификацию без собственного сертификата, что значит каждое поле ссылки vless:// и где кончается маскировка - потому что необнаружимых протоколов не бывает, и заявлениям об обратном стоит не доверять.

Xray и откуда взялся VLESS#

Xray-core - прокси-платформа с открытым кодом, которую поддерживает Project X (организация XTLS на GitHub). Она появилась в 2020 году как форк V2Ray, платформы, стоящей за более старым протоколом VMess, и с тех пор стала основным местом новых разработок в этом семействе. Один процесс Xray может говорить на нескольких протоколах - VLESS, VMess, Trojan, Shadowsocks - поверх нескольких транспортов, а правила маршрутизации решают, что куда идёт.

Части соединения Xray складываются в слои, и большая часть путаницы возникает, когда их смешивают:

Значит, сервер «VLESS + Reality» - это протокол VLESS, обычно с flow Vision, поверх транспорта raw, защищённый Reality. Каждое из этого - отдельная настройка в конфигурации и отдельный параметр в ссылке для подключения.

VLESS: намеренно минимальный#

VMess, предшественник VLESS, сам шифровал свой трафик и использовал аутентификацию по времени, из-за чего был тяжелее и чувствителен к расхождению часов. VLESS от всего этого отказался. Заголовок запроса VLESS несёт версию, UUID клиента, необязательный блок дополнений (где указан flow), команду, а также адрес и порт назначения. Это всё.

UUID - это учётные данные: сервер хранит список ID клиентов и отбрасывает всё, что не совпадает. Поскольку сам VLESS не шифрует, конфигурация прямо об этом говорит - "decryption": "none" на сервере, encryption=none в ссылке, - а конфиденциальность целиком обеспечивает нижележащий слой безопасности. Если запустить VLESS с security: none через интернет, всё будет передаваться в читаемом виде; за пределами тестов так делать никто не должен.

Выгода минимализма - скорость и простота. Шифрование выполняется один раз, средствами TLS или Reality, двойной работы нет, а у самого протокола очень мало того, по чему можно снять отпечаток.

Проблема обнаружения: отпечатки и TLS внутри TLS#

Обернуть прокси в TLS - подход Trojan и VLESS поверх обычного TLS - значит сделать его похожим на HTTPS. Как выяснилось, этого недостаточно, по трём причинам.

У ClientHello есть отпечаток. Первое сообщение любого TLS-соединения перечисляет наборы шифров, расширения и их порядок. Браузеры выдают характерные, хорошо известные списки; стандартная TLS-библиотека Go, на которой написан Xray, выдаёт другой. Сеть, которая видит на порту 443 «это похоже на Go, а не на Chrome», получает зацепку. Поэтому клиенты Xray используют uTLS, чтобы в точности имитировать ClientHello браузера, выбранного настройкой fingerprint (обычно выбирают chrome).

Сертификат должен откуда-то взяться. Классическому TLS-проксированию нужны собственный домен и сертификат на него. Домен - фиксированный идентификатор, который можно внести в список, а сервер, предъявляющий сертификат малоизвестного домена с IP хостинг-провайдера, попадает в узнаваемый шаблон.

У TLS внутри TLS есть форма. Когда вы открываете HTTPS-сайт через прокси, обёрнутый в TLS, происходит два TLS-рукопожатия, одно внутри другого. Внутреннее рукопожатие порождает всплеск пакетов с характерными размерами и интервалами, которые видны сквозь внешнее шифрование как длины и паузы. Исследователи показали, что этот рисунок можно обнаружить статистически.

XTLS Vision, включаемый через flow: xtls-rprx-vision, решает третью проблему. Он дополняет пакеты внутреннего рукопожатия так, что их размеры перестают совпадать с известным рисунком, а когда внутреннее TLS-соединение установлено, перестаёт повторно шифровать уже зашифрованные данные и пропускает их напрямую. В итоге и распознавать почти нечего, и CPU тратится меньше. Vision работает только с транспортом raw.

Первые две проблемы решает Reality.

Как работает Reality#

Reality избавляет от необходимости иметь собственный домен и сертификат, заимствуя чужое рукопожатие. На сервере настраивается target - настоящий сайт, например главная страница крупной компании, - и список имён серверов (значений SNI), которые он будет принимать; все они должны быть именами, которые этот target действительно обслуживает.

Когда приходит соединение:

1. Клиент отправляет ClientHello TLS 1.3, который выглядит в точности как браузерный, с именем target в качестве SNI. В полях, которые в обычном TLS случайны, - session ID в сочетании с обменом ключами - спрятаны данные аутентификации, полученные из публичного ключа x25519 сервера и короткого ID.
2. Сервер, у которого есть соответствующий приватный ключ, пытается проверить эти данные. Если всё сходится, сервер сам завершает рукопожатие, предъявляя временный сертификат, который клиент может проверить с помощью общего секрета, и внутри запускается туннель VLESS.
3. Если не сходится - браузер, сканер, активный зонд цензора, - сервер вообще не отвечает от своего имени. Он пересылает соединение без изменений настоящему target. Посетитель проходит настоящее TLS-рукопожатие с настоящим сайтом и получает его подлинный сертификат и содержимое.

Именно третий шаг побеждает активное зондирование. Система, которая заподозрила сервер и подключилась для проверки, получает совершенно нормальную копию известного сайта. Нет ни поддельной страницы, ни самоподписанного сертификата, которые можно было бы заметить.

Пара ключей - x25519. Сервер хранит приватный ключ, клиент получает публичный. В текущей документации Xray поле на стороне клиента называется password, а не publicKey, а поле сервера - target, а не dest; старые имена по-прежнему работают как псевдонимы, поэтому в руководствах встречаются оба варианта.

Минимальная конфигурация сервера#

На сервере, которым вы управляете сами, настройка сводится к трём сгенерированным значениям и одному JSON-файлу. Их генерирует бинарник xray:

$ xray uuid                        # client ID$ xray x25519                      # server key pair; keep the private key secret$ xray x25519 -i "<private key>"   # prints the public key again from the private one$ openssl rand -hex 8              # a short ID: hex, even length, up to 16 chars

{  "inbounds": [{    "listen": "0.0.0.0",    "port": 443,    "protocol": "vless",    "settings": {      "clients": [{ "id": "<uuid>", "flow": "xtls-rprx-vision" }],      "decryption": "none"    },    "streamSettings": {      "network": "raw",      "security": "reality",      "realitySettings": {        "target": "www.example.com:443",        "serverNames": ["www.example.com"],        "privateKey": "<private key>",        "shortIds": ["<short id>"]      }    }  }],  "outbounds": [{ "protocol": "freedom" }]}

network: "raw" - текущее название того, что в старых версиях называлось tcp; в старом Xray используйте tcp. Outbound freedom отправляет развёрнутый трафик прямо по назначению. В рабочую конфигурацию обычно добавляют правила маршрутизации и outbound blackhole, чтобы отказывать в нежелательном трафике, - например, в соединениях с частными диапазонами адресов, чтобы через сервер нельзя было достучаться до его собственной внутренней сети.

Свой ID для каждого устройства

Массив clients может содержать сколько угодно записей, каждую со своим UUID, а в shortIds можно указать несколько значений. На сервере, которым вы управляете сами, стоит потратить немного усилий и дать каждому устройству или каждому человеку свой UUID. Когда телефон потерян или другу больше не нужен доступ, вы удаляете одну запись и перезапускаете Xray; все остальные устройства продолжают работать с уже имеющимися ссылками. С одним общим UUID отозвать доступ у кого-то одного можно только выдав новую ссылку всем. Добавьте к каждой записи клиента поле email - это лишь метка, а не адрес, на который что-то отправляется, - и логи и статистика Xray смогут показать, какому устройству принадлежит соединение. Короткие ID работают так же на уровне Reality, а пустая строка в списке разрешает клиентам, которые вообще не отправляют короткий ID; это удобно для проверки, но потом её лучше убрать.

Управляемый приватный VPN делает эту часть за вас. На RE:NODE сервер работает на Xray с VLESS и Reality, генерирует адрес и ключ для вашего сервера и выдаёт ссылку, которую вы вставляете в клиент, - приложение Renode VPN в Windows или любой VLESS-клиент на телефонах и Mac.

Устройство ссылки vless://#

Клиенты обмениваются конфигурациями в виде одного URI. Каждый параметр соответствует одной из описанных выше настроек:

vless://3f1c8a2e-...-9b7d@203.0.113.10:443  ?encryption=none  &flow=xtls-rprx-vision  &security=reality  &sni=www.example.com  &fp=chrome  &pbk=Zx9...publickey  &sid=6ba85179e30d4fc2  &type=tcp  #my-server

Ссылка несёт учётные данные и всё остальное, что нужно для подключения. Любой, у кого она есть, может пользоваться вашим сервером, поэтому делитесь ею как паролем, а не в групповом чате. Импорт в v2rayNG, Hiddify, Streisand и Shadowrocket описан в статье настройка VLESS-клиента.

Выбор target#

На собранном своими руками сервере target - единственное творческое решение, и значит оно больше, чем кажется. Рекомендации проекта REALITY и общая практика указывают на сайт, который:

• Поддерживает TLS 1.3 и HTTP/2, потому что ClientHello клиента должен выглядеть как современный браузер, заходящий на современный сайт.
• Не перенаправляет своё основное имя на другой домен, чтобы рукопожатие завершалось нормально.
• Правдоподобен для сети вашего сервера - крупный сайт, размещённый за пределами вашей страны, в идеале с серверами в том же регионе, что и ваш, чтобы соединения с ним из этого диапазона IP не выглядели странно.
• Не стоит за CDN, через который ваш сервер можно использовать как пересыльщик. Документация Xray предупреждает: поскольку неудачные аутентификации пересылаются на target, target за CDN может превратить ваш сервер в ретранслятор чужого трафика; настройки limitFallbackUpload и limitFallbackDownload это ограничивают.

xray tls ping www.example.com проверяет поддержку TLS у кандидата прямо с сервера.

Пределы маскировки#

Reality - самый убедительный из широко используемых подходов, но и он не невидим. Честные ограничения:

• SNI и IP не совпадают. Рукопожатие называет известный сайт, а IP принадлежит хостинг-провайдеру, а не этому сайту. Наблюдатель, который их сравнивает - разрешая имя или по спискам владельцев диапазонов, - может это заметить. Выбор target в том же регионе и у того же типа хостинга сужает разрыв; полностью его не закрывает ничто.
• Остаются рисунки трафика. Одно долгоживущее соединение, несущее часы смешанного трафика к «главной странице», - необычно. Vision уменьшает рисунок TLS внутри TLS; анализ объёмов и времени - более широкая проблема, которую ни один прокси полностью не решает.
• IP можно заблокировать, не распознав. Сеть может заблокировать адрес по любой причине, в том числе потому, что к нему идёт много неизвестных соединений.
• Это не анонимность. Сервер ваш и арендован на ваше имя. Reality скрывает, что представляет собой туннель, от промежуточной сети; он ничего не скрывает от посещаемых сайтов, которые видят адрес вашего сервера, или от аккаунтов, в которые вы входите.

Использование VPN законно в большинстве мест и ограничено в некоторых. Знайте закон там, где вы находитесь, и правила использования сетей, которые вам не принадлежат; трудно обнаружимый протокол не меняет того, что разрешено. Статьи что защищает VPN, а что нет и Xray, WireGuard и OpenVPN помещают это в контекст.

Когда не подключается#

Третья строка - это Reality, работающий как задумано: клиент, не прошедший аутентификацию, считается чужим и получает настоящий сайт. Если вы видите страницу target, заново импортируйте ссылку, а не правьте поля вручную. Что касается часов, на сервере можно задать maxTimeDiff, чтобы отклонять клиентов со слишком расходящимся временем; телефон с отключённой автоматической установкой времени может на этом споткнуться. Случай, когда соединение есть, но всё ползёт, разобран в статье почему мой VPN медленный.

FAQ#

Шифруется ли VLESS?

Сам VLESS шифрования не добавляет - так задумано. Шифрование даёт слой безопасности - TLS или Reality, - поэтому в ссылке VLESS написано encryption=none и security=reality. С Reality трафик защищён обменом ключами и шифрованием TLS 1.3.

Нужен ли домен для Reality?

Нет. Это одно из главных его преимуществ. Сервер заимствует TLS-рукопожатие сайта target, так что ни собственный домен, ни собственный сертификат не нужны. Клиенты подключаются к IP-адресу сервера с именем target в качестве SNI.

Чем Reality отличается от обычного TLS?

Обычный TLS предъявляет ваш собственный сертификат для вашего собственного домена. Reality предъявляет заимствованную личность, аутентифицирует клиентов через скрытый обмен ключами и пересылает всех остальных на настоящий сайт, так что зондирование сервера не выявляет ничего необычного.

Какие клиенты поддерживают VLESS с Reality?

Клиенты на основе Xray-core или sing-box с поддержкой Reality: v2rayNG на Android, Hiddify на нескольких платформах, Streisand и Shadowrocket на iPhone и Mac, а также другие. Обновляйте клиент: старые ядра появились раньше Reality.

Может ли сеть всё равно это заблокировать?

Да. Она может заблокировать IP-адрес сервера или отметить необычные рисунки трафика, не понимая протокола. Reality делает распознавание туннеля по форме очень трудным, но не делает блокировку невозможной.