Архитектура и устройство протокола VLESS в Xray

Введение в VLESS: концепция stateless-протокола и фундаментальные отличия от VMess

Добро пожаловать в курс «Архитектура и устройство протокола VLESS в Xray». Мы начинаем наше погружение в мир современных технологий обхода блокировок с изучения одного из самых эффективных и популярных протоколов на сегодняшний день — VLESS.

Если вы когда-либо настраивали V2Ray или Xray, вы наверняка сталкивались с протоколом VMess. Долгое время он был «золотым стандартом». Однако технологии не стоят на месте, и на смену ему пришел VLESS. В этой статье мы разберем, что это такое, почему его называют «облегченным» (lightweight) и в чем заключается его революционная концепция stateless-архитектуры.

Что такое VLESS?

VLESS — это протокол передачи данных, разработанный для ядра Xray. Название можно расшифровать как «VMess Less», что намекает на его суть: это упрощенная версия VMess, лишенная некоторых встроенных функций, которые в современных реалиях стали избыточными.

Главная особенность VLESS заключается в том, что он не шифрует данные сам по себе. Это может звучать пугающе для инструмента, предназначенного для приватности, но в этом кроется его сила. VLESS спроектирован для работы внутри защищенных каналов, таких как TLS (Transport Layer Security) или XTLS. Он делегирует задачу шифрования транспортному уровню, избегая проблемы «двойного шифрования», которая была присуща связке VMess + TLS.

> VLESS — это протокол без состояния (stateless) и без собственного шифрования, предназначенный для аутентификации и передачи данных поверх надежных транспортных протоколов.

Концепция Stateless: почему это важно?

Чтобы понять архитектуру VLESS, нужно разобраться с понятием Stateless (без сохранения состояния). В контексте сетевых протоколов это означает, что серверу не нужно хранить сложную информацию о состоянии соединения после того, как аутентификация прошла успешно.

Как это работает в VMess (Stateful)

VMess — это протокол с состоянием. Он использует сложную схему защиты от повторных атак (Replay Attacks), основанную на времени и хешировании. Сервер должен помнить определенные параметры, чтобы валидировать каждый пакет данных. Это создает нагрузку на процессор и требует строгой синхронизации времени.

Как это работает в VLESS (Stateless)

VLESS отказывается от этого подхода. После того как клиент прошел проверку UUID (уникального идентификатора), протокол просто передает поток данных. Он не тратит ресурсы на постоянную перепроверку состояния шифрования или защиту от повторов на уровне приложения, полагаясь на то, что нижележащий уровень (например, TCP с TLS) уже обеспечивает целостность и порядок пакетов.

!Сравнение обработки пакетов в Stateful (VMess) и Stateless (VLESS) протоколах

Преимущества stateless-подхода:

Производительность: Меньше вычислений на каждый байт данных.

Масштабируемость: Серверу проще обрабатывать тысячи одновременных соединений.

Энергоэффективность: Критично для мобильных устройств, так как процессор телефона нагружается меньше.

Фундаментальные отличия VLESS от VMess

Давайте детально разберем, чем VLESS отличается от своего предшественника. Это поможет вам понять, почему сообщество Xray рекомендует переходить на VLESS.

1. Отсутствие собственного шифрования

Это самое заметное отличие.

* VMess: Всегда шифрует данные (обычно AES-128-GCM или ChaCha20-Poly1305), даже если вы уже используете TLS. Получается «матрешка»: данные шифруются VMess, а затем этот зашифрованный пакет снова шифруется TLS. Это создает лишнюю нагрузку (оверхед). * VLESS: Передает данные как есть. Если вы используете VLESS поверх обычного TCP без TLS, ваши данные будут видны провайдеру в открытом виде (как обычный HTTP). Поэтому VLESS обязан использоваться в связке с TLS, XTLS или Reality.

2. Независимость от системного времени

Одной из самых частых проблем при настройке VMess была ошибка синхронизации времени.

* VMess: Требует, чтобы время на клиенте и сервере отличалось не более чем на 90 секунд. Если часы на вашем роутере сбились, интернет пропадет. * VLESS: Абсолютно безразличен к системному времени. Аутентификация происходит по UUID, и временные метки не участвуют в генерации заголовков протокола. Это делает VLESS идеальным для IoT-устройств или нестабильных сред, где нет NTP-синхронизации.

3. Структура заголовка и Handshake

Процесс установки соединения (рукопожатие) в VLESS упрощен.

Заголовок VLESS содержит: * Версию протокола. * UUID пользователя (для аутентификации). * Информацию о дополнительных протоколах (addons). * Команду (например, TCP или UDP запрос).

В отличие от VMess, заголовок VLESS не содержит сложной криптографии, что упрощает отладку и снижает задержки при установке соединения (RTT).

!Сравнение стека протоколов и слоев шифрования в VMess и VLESS

Сводная таблица отличий

| Характеристика | VMess | VLESS | | :--- | :--- | :--- | | Шифрование | Встроенное, обязательное | Отсутствует (делегируется TLS) | | Зависимость от времени | Критичная (< 90 сек) | Нет | | Архитектура | Stateful (с состоянием) | Stateless (без состояния) | | Оверхед (нагрузка) | Высокий (двойное шифрование) | Низкий | | Безопасность без TLS | Относительно безопасно | Опасно (открытый текст) |

Почему VLESS стал стандартом?

Переход на VLESS был обусловлен развитием технологий анализа трафика (DPI — Deep Packet Inspection). Цензоры научились распознавать «мусорный» трафик, который генерировал VMess.

Чтобы скрыть факт использования VPN, необходимо маскироваться под обычный веб-трафик (HTTPS). Для этого идеально подходит протокол TLS. Поскольку TLS стал обязательным условием для выживания прокси, встроенное шифрование VMess стало ненужным балластом.

VLESS был создан именно для этой новой реальности: быть максимально легкой оберткой для передачи данных внутри мощных криптографических протоколов TLS и XTLS.

Важное предупреждение о безопасности

> Никогда не используйте VLESS без шифрования (TLS/XTLS) в публичных сетях!

Так как VLESS не шифрует данные сам, использование конфигурации VLESS + TCP (без TLS) означает, что любой посредник (провайдер, администратор Wi-Fi) увидит, какие сайты вы посещаете, и сможет перехватить содержимое ваших запросов. VLESS — это транспортный механизм, а не криптографический щит.

Заключение

VLESS — это эволюционный шаг в развитии средств обхода блокировок. Отказавшись от устаревших концепций встроенного шифрования и зависимости от времени, разработчики Xray создали быстрый, легкий и универсальный протокол.

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

Теперь, когда вы понимаете теоретическую базу, давайте проверим ваши знания.

Анатомия протокола: структура заголовков, аутентификация по UUID и механизмы сериализации данных

В предыдущей статье мы рассмотрели концептуальные основы VLESS и выяснили, почему отказ от встроенного шифрования (stateless-архитектура) сделал этот протокол идеальным кандидатом для работы внутри TLS-туннелей. Теперь пришло время заглянуть «под капот».

Чтобы глубоко понимать, как работает Xray и как диагностировать проблемы соединения, необходимо знать, как именно формируются пакеты данных. В этой статье мы разберем байтовую структуру заголовков VLESS, механизм аутентификации пользователя и способы, которыми протокол упаковывает (сериализует) информацию об адресах и командах.

Общая структура коммуникации

Обмен данными в VLESS строго структурирован. В отличие от текстовых протоколов (как HTTP/1.1), VLESS — это бинарный протокол. Это означает, что информация передается не в виде читаемых строк, а в виде последовательности байтов, где каждый бит имеет свое значение.

Жизненный цикл соединения VLESS выглядит так:

Запрос (Request): Клиент отправляет заголовок запроса.

Ответ (Response): Сервер отправляет заголовок ответа (если требуется).

Поток данных (Data Stream): Двунаправленная передача данных (туннелирование).

!Визуализация структуры заголовка запроса VLESS с разбивкой по байтам

Заголовок запроса (Request Header)

Заголовок запроса — это первая порция данных, которую клиент отправляет серверу после установки TCP-соединения (и рукопожатия TLS). Давайте разберем его структуру байт за байтом.

1. Версия протокола (1 байт)

Первый байт всегда указывает версию протокола. На текущий момент актуальная версия VLESS — 0. * Значение: 0x00.

2. Аутентификация: UUID (16 байт)

Сразу за версией следует идентификатор пользователя. В VLESS используется UUID (Universally Unique Identifier). Это 128-битное число, которое в конфигурационных файлах мы привыкли видеть в виде строки (например, 550e8400-e29b-41d4-a716-446655440000).

Однако в заголовке протокола UUID передается не как строка, а как «сырые» 16 байт.

Математически количество возможных комбинаций UUID выражается формулой:

Где: * — общее количество уникальных вариантов UUID. * — основание двоичной системы счисления. * — количество бит в идентификаторе.

Такое гигантское число гарантирует, что подобрать валидный UUID методом перебора (brute-force) практически невозможно за разумное время.

Важный нюанс безопасности: Поскольку VLESS не шифрует заголовок, эти 16 байт передаются в открытом виде. Именно поэтому VLESS обязан работать внутри TLS. Если TLS отсутствует, любой наблюдатель может перехватить эти 16 байт и получить доступ к вашему серверу.

3. Дополнения (Addons)

Это поле делает VLESS расширяемым. Оно состоит из двух частей: * Длина Addons (1 байт): Указывает, сколько байт занимает следующая секция. * Данные Addons (N байт): Сама информация.

Именно здесь передается информация о механизмах управления потоком, таких как flow (например, xtls-rprx-vision). Если вы используете Reality или XTLS-Vision, клиент сообщает об этом серверу именно в этой секции.

4. Команда (1 байт)

Этот байт сообщает серверу, что клиент хочет сделать. Основные команды: * 0x01: TCP. Открыть TCP-соединение с целевым узлом. * 0x02: UDP. Отправить UDP-пакет (используется для DNS-запросов или QUIC). * 0x03: Mux. Использовать мультиплексирование (передача нескольких потоков внутри одного соединения).

5. Порт (2 байта)

Порт целевого узла (например, 443 для HTTPS). * Порядок байт: Big-Endian (старший байт идет первым). Это стандартный сетевой порядок байт.

6. Тип адреса и Адрес назначения

Здесь клиент указывает, куда он хочет попасть (например, google.com или 1.1.1.1).

Сначала идет 1 байт Типа адреса (AddrType), за которым следует сам адрес:

| Значение (Hex) | Тип | Структура данных адреса | | :--- | :--- | :--- | | 0x01 | IPv4 | Ровно 4 байта (IP-адрес) | | 0x02 | Домен | 1 байт (длина домена ) + байт (строка домена) | | 0x03 | IPv6 | Ровно 16 байт (IPv6-адрес) |

Пример сериализации домена: Если мы запрашиваем ya.ru:

Тип адреса: 0x02.

Длина: 0x05 (5 символов).

Адрес: 79 61 2e 72 75 (ASCII коды для "ya.ru").

Заголовок ответа (Response Header)

После того как сервер получил запрос, проверил UUID и установил соединение с целевым сайтом (например, с Google), он отправляет клиенту заголовок ответа. Он значительно проще запроса.

Структура ответа:

Версия (1 байт): Должна совпадать с версией запроса (0x00).

Длина Addons (1 байт): Обычно 0, если сервер не передает специфических инструкций.

Данные Addons (N байт): Если длина > 0.

Сразу после этого заголовка начинается передача реальных данных (поток).

Механизм аутентификации

Как сервер понимает, свой вы или чужой? Процесс аутентификации в VLESS предельно минималистичен, что и обеспечивает его высокую производительность.

!Алгоритм проверки пользователя сервером Xray

Сервер слушает порт.

При поступлении данных он считывает первые 17 байт (1 байт версии + 16 байт UUID).

Сервер сравнивает полученные 16 байт со списком UUID, загруженным в память из конфигурации (config.json).

Если совпадение найдено: Сервер считает пользователя валидным, считывает остальные поля (команду, адрес) и начинает проксирование.

Если совпадение не найдено:

* Если настроен fallback: трафик перенаправляется на сайт-заглушку (например, на локальный Nginx), чтобы имитировать обычный веб-сервер. * Если fallback не настроен: соединение закрывается.

В отличие от VMess, здесь нет вычислений хешей (HMAC) или проверки временных меток. Это простое сравнение байтовых массивов (memcmp).

Сериализация данных

Термин сериализация означает процесс перевода структур данных (объектов, чисел) в последовательность байтов для передачи по сети.

В VLESS используется кастомная бинарная сериализация, а не популярные форматы вроде JSON или Protobuf (Protocol Buffers).

Почему не JSON?

JSON удобен для человека, но избыточен для машины. Строка {"uuid": "..."} занимает лишние байты на скобки, кавычки и названия полей. В VLESS важна каждая миллисекунда и каждый байт, поэтому используется жесткая позиционная структура.

Почему не Protobuf?

Xray использует Protobuf для внутренних коммуникаций (между сервисами ядра), но для заголовка VLESS был выбран еще более простой формат. Это позволяет реализовать клиент VLESS даже на микроконтроллерах с минимальными ресурсами, не подключая тяжелые библиотеки парсинга.

Уязвимость «открытого» заголовка

Теперь, зная анатомию заголовка, вы можете понять главную уязвимость чистого VLESS.

Представьте, что вы используете VLESS через обычный TCP (без TLS). Ваш провайдер или администратор корпоративной сети запускает анализатор трафика (Wireshark).

Он увидит:

Байт версии 00.

Ваш UUID (ключ от двери).

Команду 01 (TCP).

Домен, к которому вы идете (в открытом виде, так как тип адреса 0x02 просто предваряет строку).

Именно поэтому в сообществе Xray существует правило: VLESS без TLS = самоубийство приватности. Протокол спроектирован так, чтобы быть содержимым конверта, а не самим конвертом. Конвертом выступает TLS.

Заключение

Мы разобрали анатомию VLESS: от байтовой структуры заголовка до механизмов проверки пользователей.

Ключевые выводы: * Заголовок VLESS максимально компактен и не содержит криптографии. * Аутентификация происходит путем прямого сравнения 16 байт UUID. * Протокол поддерживает расширения через поле Addons, что критически важно для технологий XTLS и Reality.

Понимание этой структуры поможет вам в будущем, когда мы будем разбирать логи ошибок Xray. Если вы увидите ошибку «invalid version» или «invalid user», вы будете знать, на каком именно байте споткнулся сервер.

В следующей статье мы перейдем к практике и разберем, как эти теоретические знания применяются при настройке клиента и сервера.

Технологии XTLS и Flow: разбор работы XTLS-Vision и управление потоком трафика

Мы продолжаем наш курс по архитектуре VLESS. В прошлых статьях мы выяснили, что VLESS — это «голый» протокол без собственного шифрования. Мы также разобрали его анатомию и узнали, что в заголовке есть специальное поле Addons, предназначенное для передачи служебной информации.

Сегодня мы ответим на главный вопрос: если VLESS не шифрует данные, а просто передает их в TLS, чем это отличается от обычного HTTPS? И почему стандартного TLS недостаточно для защиты от современных систем цензуры?

В этой статье мы разберем технологию XTLS и механизм управления потоком Flow, в частности, современный стандарт XTLS-Vision.

Проблема «TLS внутри TLS»

Чтобы понять, зачем нужен XTLS, нужно сначала осознать проблему, с которой сталкиваются обычные прокси.

Когда вы открываете защищенный сайт (например, Google) через прокси, ваш браузер шифрует данные с помощью TLS. Затем прокси-клиент (Xray) берет этот уже зашифрованный поток и снова оборачивает его в свой слой шифрования (TLS), чтобы доставить до сервера. Получается «матрешка»: TLS браузера внутри TLS прокси.

Для старых систем блокировок это выглядело как обычный шум. Но современные системы DPI (Deep Packet Inspection) научились анализировать паттерны трафика.

Как DPI видит подвох?

У каждого TLS-соединения есть фаза рукопожатия (Handshake). Это обмен приветственными пакетами, где клиент и сервер договариваются о ключах шифрования.

Если вы передаете TLS внутри TLS, то внутри внешнего туннеля передаются пакеты внутреннего рукопожатия. Хотя они зашифрованы, их размер и тайминги (время между отправкой) остаются неизменными. Цензор видит:

Установлено внешнее соединение.

Сразу после этого внутри потока передаются блоки данных специфического размера, характерные для начала еще одного TLS-соединения.

Это явный признак использования прокси или VPN. Именно эту уязвимость закрывает технология XTLS.

!Визуализация проблемы TLS-in-TLS, где паттерны внутреннего трафика видны через внешний слой

Что такое XTLS?

XTLS (Xray TLS) — это не отдельный криптографический протокол, а расширение реализации TLS в ядре Xray. Его задача — оптимизировать передачу данных и маскировать признаки туннелирования.

Изначально XTLS создавался для производительности (режимы xtls-rprx-origin и xtls-rprx-splice), чтобы избегать двойного шифрования на устройствах со слабыми процессорами. Он позволял «сплайсить» (склеивать) данные, передавая их напрямую в ядро ОС без лишней обработки.

Однако с усилением цензуры фокус сместился с производительности на скрытность. Так появился режим XTLS-Vision.

XTLS-Vision: Призрак в доспехах

XTLS-Vision — это актуальный стандарт управления потоком (Flow) в Xray. Его главная цель — сломать паттерны «TLS внутри TLS», чтобы DPI считал, что вы просто посещаете обычный сайт, а не используете туннель.

Как работает Vision?

Когда вы указываете в конфигурации flow: "xtls-rprx-vision", Xray начинает активно вмешиваться в процесс передачи заголовков.

Главный инструмент Vision — это Padding (заполнение пустотой). Протокол искусственно меняет длину пакетов, добавляя к ним случайный мусорный код, который отбрасывается при получении.

Математически длину пакета при использовании Vision можно представить так:

Где: * — итоговая длина пакета, которую видит провайдер. * — полезная нагрузка (реальные данные). * — длина случайного заполнения, которая динамически меняется для каждого пакета.

Благодаря этому слагаемому , размер пакета перестает быть предсказуемым. Если стандартное рукопожатие TLS всегда имеет фиксированный размер (например, 517 байт), то Vision превратит его в пакет случайной длины (например, 624 байта), который не совпадает с сигнатурами DPI.

Механизм работы на уровне заголовков VLESS

Вспомним структуру заголовка VLESS из прошлой статьи. Там было поле Addons. Именно здесь происходит магия Vision.

Клиент отправляет запрос с указанием flow: "xtls-rprx-vision" в поле Addons.

Сервер понимает, что клиент поддерживает Vision.

При передаче внутреннего TLS-рукопожатия (Client Hello), Xray дробит его на части или, наоборот, склеивает с мусорными данными, используя алгоритмы Vision.

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

!Иллюстрация работы механизма Padding в XTLS-Vision

Параметр Flow в конфигурации

Управление потоком настраивается в конфигурационном файле JSON. Поле flow доступно только для протокола VLESS и только при использовании транспорта TLS или Reality.

Пример конфигурации клиента:

Почему только "xtls-rprx-vision"?

Ранее вы могли встречать другие значения: * xtls-rprx-origin * xtls-rprx-direct * xtls-rprx-splice

Все эти режимы считаются устаревшими (deprecated). Они были эффективны для производительности, но уязвимы для активного зондирования и анализа трафика. Начиная с версии Xray 1.8.0+, стандартом де-факто является только Vision.

XTLS vs TLS: Сравнение

Давайте подведем итог, чем отличается обычный VLESS+TLS от VLESS+XTLS-Vision.

| Характеристика | VLESS + TLS (обычный) | VLESS + XTLS-Vision | | :--- | :--- | :--- | | Шифрование | Стандартное TLS 1.3 | TLS 1.3 + манипуляция пакетами | | Защита от DPI | Базовая (скрывает контент) | Высокая (скрывает паттерны протокола) | | Проблема TLS-in-TLS | Присутствует (видны вложенные рукопожатия) | Решена (паттерны размыты) | | Требования к клиенту | Любой клиент | Клиент с поддержкой Xray-core (v2rayNG, v2rayN и др.) | | Сценарий использования | CDN, простые обходы | Страны с жесткой цензурой (Китай, Иран, РФ) |

Заключение

Технология XTLS и режим Flow xtls-rprx-vision — это ответ разработчиков Xray на эволюцию систем слежки. Отказавшись от простого «спрятывания» данных, они перешли к тактике активной маскировки поведения трафика.

Используя случайное заполнение (Padding) и управление фрагментацией пакетов, Vision превращает ваш VPN-трафик в неотличимый от обычного веб-серфинга поток данных. Это критически важный компонент для работы следующей технологии, которую мы разберем — Xray Reality.

В следующей статье мы узнаем, как Reality позволяет вообще отказаться от покупки домена и маскироваться под чужие сервера, используя возможности, заложенные в VLESS и XTLS.

Xray Reality: принципы имитации TLS, работа с SNI и механизмы скрытия проксирования

Мы подошли к кульминации нашего курса по архитектуре VLESS. В предыдущих статьях мы разобрали, как VLESS избавляется от лишнего шифрования (stateless), и как XTLS-Vision маскирует паттерны трафика, делая его похожим на обычный веб-серфинг. Однако оставалась одна фундаментальная проблема, которая требовала решения: наличие домена и сертификата.

До появления Reality, чтобы поднять прокси-сервер, вам нужно было купить доменное имя и настроить TLS-сертификат (обычно от Let's Encrypt). Это оставляло цифровые следы. Цензоры могли видеть, что домен зарегистрирован недавно, или что сертификат выдан на странный поддомен. Более того, сам факт наличия TLS-сервиса на IP-адресе дешевого хостинга уже вызывал подозрения.

В этой статье мы разберем технологию Xray Reality, которая позволяет отказаться от покупки домена, не генерировать собственные сертификаты и при этом проходить проверки самых строгих систем DPI.

Концепция Reality: «Человек посередине»

Традиционный подход к настройке VLESS+TLS выглядел так: вы настраиваете веб-сервер (Nginx/Caddy) или сам Xray, который хранит файлы cert.pem (публичный сертификат) и key.pem (приватный ключ). Когда клиент подключается, сервер предъявляет свой сертификат.

Reality меняет правила игры. Это не просто протокол, это транспортный слой, который заменяет собой стандартный TLS. Он работает по принципу доброжелательного Man-in-the-Middle (MitM).

Вместо того чтобы иметь свой сертификат, сервер Xray с Reality «притворяется» клиентом и устанавливает соединение с реальным популярным сайтом (например, microsoft.com или yahoo.com).

Логика работы

Входящее соединение: Клиент отправляет запрос на ваш сервер.

Проверка свой/чужой: Xray анализирует первый пакет рукопожатия (Client Hello).

Ветвление:

* Если это ваш клиент (знает секретный ключ): Xray перехватывает соединение, устанавливает зашифрованный туннель и передает данные. * Если это цензор/сканер (не знает ключа): Xray прозрачно проксирует запрос на реальный сайт (dest). Сканер получает настоящий валидный сертификат от Microsoft или Apple и видит обычную веб-страницу.

!Логическая схема ветвления трафика в Reality: разделение на авторизованных пользователей и посторонних сканеров

Техническая реализация: Как украсть TLS?

Чтобы эта магия сработала, Reality вмешивается в процесс TLS Handshake (рукопожатие).

В стандартном TLS 1.3 клиент и сервер договариваются о временных ключах шифрования, используя алгоритм Диффи-Хеллмана на эллиптических кривых (ECDH). Reality использует этот механизм для аутентификации.

Ключи вместо паролей

В конфигурации Reality вы не увидите привычных путей к файлам сертификатов. Вместо этого там есть: * PrivateKey (на сервере): Секретный ключ в формате Base64. * PublicKey (на клиенте): Публичный ключ, соответствующий приватному. * ShortId: Короткая строка (hex), используемая как дополнительный идентификатор.

Эти ключи — это пара ключей X25519 (Curve25519). Это современный стандарт криптографии с открытым ключом, который используется в TLS 1.3.

Математика обмена ключами

Понимание безопасности Reality невозможно без понимания базовой математики эллиптических кривых. Процесс выработки общего секрета (Shared Secret), который позволяет клиенту и серверу понять друг друга без передачи пароля, описывается следующим уравнением:

Где: * — общий секрет (Shared Secret), число, которое будет одинаковым у обеих сторон. * — приватный ключ стороны A (например, клиента). * — публичный ключ стороны B (сервера). * — приватный ключ стороны B (сервера). * — публичный ключ стороны A (клиента). * — операция скалярного умножения точки эллиптической кривой.

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

В Reality клиент генерирует эфемерный (временный) публичный ключ особым образом, «подмешивая» в него информацию, которую сервер может проверить, используя свой статический PrivateKey. Если проверка проходит успешно — сервер понимает, что пришел «свой».

Роль SNI и Dest

Для успешной маскировки критически важны два параметра в конфигурации сервера:

Dest (Destination): Адрес реального сервера, куда будет перенаправляться трафик «чужаков» (формат ip:port или domain:port). Именно отсюда Xray будет «заимствовать» сертификат.

ServerNames (SNI): Список доменов, которые клиент может запрашивать в поле SNI (Server Name Indication).

Как это работает в пакете?

Когда клиент инициирует TLS-соединение, он отправляет пакет Client Hello. В этом пакете есть расширение SNI, где открытым текстом написано, к какому домену идет обращение (например, www.samsung.com).

Xray получает Client Hello.

Смотрит на SNI. Он должен совпадать с одним из доменов в списке serverNames.

Xray открывает TCP-соединение с dest (например, www.samsung.com:443).

Xray проксирует Client Hello на dest.

dest отвечает пакетом Server Hello и присылает свой настоящий сертификат.

Xray берет этот сертификат и отдает его клиенту.

Для внешнего наблюдателя (DPI) это выглядит как абсолютно легитимное соединение с Samsung. Сертификат валидный, подписан доверенным центром (DigiCert/Sectigo), IP-адрес сервера отвечает корректно.

Критерии выбора Dest

Не любой сайт подходит на роль «донора». Сайт должен поддерживать: * TLS 1.3: Обязательно, так как Reality базируется на механизмах версии 1.3. * X25519: Алгоритм обмена ключами должен совпадать. * H2 (HTTP/2): Желательно для лучшей производительности.

> Важно: Нельзя использовать сайты, которые находятся за CDN (Cloudflare, Akamai) в режиме, когда IP вашего сервера и IP целевого сайта сильно отличаются географически или по AS (Autonomous System), если вы хотите идеальной маскировки. Но для базовой работы достаточно, чтобы сайт просто поддерживал TLS 1.3.

Защита от активного зондирования (Active Probing)

Главный бич протоколов вроде VMess или Shadowsocks — это активное зондирование. Цензор, заметив подозрительное соединение, отправляет на ваш сервер свои запросы, пытаясь спровоцировать его на специфический ответ.

Reality решает эту проблему радикально.

Если на порт сервера Reality постучится сканер цензора:

Он не предъявит правильный публичный ключ (так как у него нет настроенного клиента).

Xray классифицирует его как «чужого».

Запрос уйдет на dest.

Сканер получит ответ от реального сайта (например, редирект на главную страницу Microsoft).

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

ShortId: Дополнительный слой защиты

ShortId — это короткая строка из шестнадцатеричных символов (например, 1a2b3c), которая генерируется клиентом и проверяется сервером.

Она решает проблему Replay Attacks (атак повторного воспроизведения) и позволяет разграничивать разных клиентов или группы пользователей, если вы используете несколько конфигураций на одном порту. Хотя основная аутентификация происходит через ключи X25519, ShortId добавляет энтропии и уникальности в процесс рукопожатия.

Заключение

Xray Reality — это революция в мире обхода блокировок. Она устранила самое слабое звено — необходимость владеть доменом и управлять сертификатами.

Объединив VLESS (легкий транспорт), XTLS-Vision (скрытие паттернов внутри туннеля) и Reality (имитация TLS и заимствование сертификатов), мы получаем инструмент, который на сегодняшний день практически невозможно обнаружить автоматическими средствами DPI без тотальной блокировки всех неизвестных IP-адресов или белых списков.

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

Практическая архитектура: настройка Inbounds, Outbounds, Fallbacks и оптимизация производительности ядра

Мы подошли к финальной части нашего курса. В предыдущих статьях мы разобрали теорию: как VLESS избавляется от лишнего шифрования, как XTLS-Vision скрывает паттерны трафика и как Reality позволяет заимствовать чужие TLS-сертификаты. Теперь пришло время собрать эти знания в единую рабочую систему.

Xray — это не просто VPN-сервер, это конструктор маршрутизации. Чтобы он заработал, нам нужно правильно соединить три главных компонента: Inbounds (входящие подключения), Outbounds (исходящие подключения) и Routing (правила маршрутизации). Также мы затронем тему оптимизации ядра Linux, чтобы выжать максимум скорости из вашего соединения.

Архитектура конфигурационного файла

Конфигурация Xray обычно хранится в файле config.json. Это сердце вашего сервера. Глобально структуру файла можно представить как систему труб и вентилей.

!Схема движения трафика внутри ядра Xray: от входящего соединения через маршрутизацию к исходящему интерфейсу

Основные секции:

inbounds: Массив объектов, описывающих, как и на каком порту сервер принимает соединения.

outbounds: Массив объектов, описывающих, куда сервер отправляет трафик (в интернет, в «черную дыру» или на другой сервис).

routing: Правила, связывающие первые два пункта.

Настройка Inbound: VLESS + Reality

Это самая важная часть. Здесь мы применяем знания о VLESS и Reality. Наша цель — открыть порт 443 и настроить его так, чтобы для «своих» это был прокси, а для «чужих» — обычный сайт.

Пример конфигурации inbound:

Разбор ключевых параметров

* port 443: Мы используем стандартный HTTPS порт, чтобы трафик не вызывал подозрений. * protocol "vless": Указываем ядру использовать VLESS. * flow "xtls-rprx-vision": Включаем технологию Vision для защиты от активного анализа паттернов (DPI). * security "reality": Активируем транспорт Reality. * dest: Адрес реального сайта, на который будет перенаправлен трафик, если проверка клиента не пройдет. Xray установит с ним соединение и будет транслировать его ответы сканеру. * serverNames: Список доменов (SNI), которые клиент может запрашивать. Они должны совпадать с сертификатом сайта, указанного в dest.

Магия Fallbacks: защита от зондирования

Механизм Fallback (резервный вариант) — это то, что делает VLESS невероятно устойчивым к блокировкам. Если на порт 443 приходит запрос, который не соответствует протоколу VLESS или содержит неверный UUID, сервер не должен разрывать соединение (это подозрительно). Он должен перенаправить его на сайт-заглушку.

В Reality функция Fallback встроена на уровне транспорта (параметр dest), но Xray позволяет настраивать и локальные фоллбеки для более сложных сценариев.

Например, если вы хотите, чтобы при заходе на ваш IP в браузере открывался ваш собственный сайт (Nginx), а не Microsoft, вы можете настроить это так:

Xray слушает порт 443.

Nginx слушает локальный порт 8080 (скрыт от интернета).

В конфиге Xray добавляем fallbacks.

Теперь любой «левый» трафик будет молча передан на локальный Nginx, и сканер увидит обычную веб-страницу.

Настройка Outbounds: Свобода и Блокировка

Секция outbounds определяет, как трафик покидает ваш сервер. Обычно нам нужны минимум два выхода.

1. Freedom (Прямой выход)

Это основной выход в интернет. Тег freedom означает, что Xray просто передает данные по назначению (например, на youtube.com).

2. Blackhole (Блокировка)

Это «черная дыра». Трафик, направленный сюда, исчезает. Это полезно для блокировки рекламы или доступа к локальным ресурсам сервера (чтобы через ваш прокси нельзя было взломать сам сервер).

Оптимизация производительности ядра (Kernel Tuning)

Даже идеально настроенный Xray может работать медленно, если операционная система (Linux) не оптимизирована для работы с современными сетями. Главный враг скорости — это задержки (Latency) и потеря пакетов.

Алгоритм TCP BBR

По умолчанию Linux использует алгоритм контроля перегрузки CUBIC. Он хорош, но не идеален для длинных каналов с потерями (Long Fat Networks). Google разработала алгоритм BBR (Bottleneck Bandwidth and Round-trip propagation time), который значительно ускоряет работу прокси.

Для понимания эффективности BBR нам понадобится формула произведения пропускной способности на задержку (BDP — Bandwidth-Delay Product):

Где: * — объем данных, который может находиться «в полете» (в кабеле) в любой момент времени. * — пропускная способность канала (Bandwidth). * — время круговой задержки (Round Trip Time).

Классические алгоритмы (CUBIC) при потере пакетов резко снижают скорость передачи, думая, что канал перегружен. BBR же моделирует канал и пытается поддерживать скорость передачи равной , игнорируя случайные потери пакетов. Это критически важно для VLESS, так как мы гоняем трафик через полмира.

Как включить BBR: Выполните следующие команды в терминале сервера:

Лимиты файловых дескрипторов

Каждое соединение в Linux — это файл. По умолчанию лимит открытых файлов может быть низким (1024). Для высоконагруженного прокси этого мало. Xray может выдавать ошибку «too many open files».

Решение — увеличить лимиты в systemd-юните Xray:

Итоговая конфигурация (Full Config)

Соберем все вместе. Вот пример минималистичного, но мощного конфига для сервера с VLESS + Reality + Vision.

Заключение курса

Поздравляем! Вы прошли путь от теории stateless-протоколов до настройки профессионального инструмента обхода цензуры.

Мы изучили:

VLESS: Легкий протокол без лишнего шифрования.

XTLS-Vision: Технологию скрытия паттернов трафика.

Reality: Метод имитации TLS и заимствования сертификатов.

Архитектуру Xray: Как связывать входы и выходы для стабильной работы.

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