Reality и XTLS Vision: как они устроены

Где они живут в подключении

Прежде всего стоит развести понятия, потому что их регулярно перечисляют через запятую, как будто это однородные вещи.

• VLESS — протокол. Описывает, кто подключается и куда переслать данные. Сам не шифрует.
• Reality — транспорт. Тот слой, который шифрует и подтверждает подлинность сервера.
• XTLS Vision — режим потока. Определяет, как обращаться с данными, которые уже зашифрованы.

То есть Reality — альтернатива обычному TLS, а Vision не альтернатива ничему: он работает вместе с транспортом, а не вместо него. Общее устройство подключения разобрано в статье что такое VLESS.

Задача, которую решает Reality

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

• Нужен домен на каждый сервер — это деньги и учёт.
• Сертификат имеет срок действия. Забыли продлить — подключение перестало работать, причём у всех сразу.
• В схеме появляется третья сторона, которой обе стороны обязаны доверять, хотя они и так знают друг друга.

Последний пункт — ключевой. У публичного сайта клиент видит сервер впервые, и посредник действительно нужен. У VPN клиент и сервер принадлежат одному сервису и могут знать друг друга заранее.

Как Reality подтверждает сервер

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

Криптография при этом остаётся прежней — это тот же TLS 1.3, на котором работает весь банковский интернет. Меняется только источник доверия: заранее известный ключ вместо цепочки подписей.

Параметры Reality в настройках

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

• security=reality — какой транспорт используется; альтернатива — обычный tls.
• pbk — публичный ключ сервера. Именно по нему клиент понимает, что подключился куда надо.
• sid — короткий идентификатор, привязывающий клиента к конкретной настройке на сервере.
• sni — имя, которое клиент указывает при рукопожатии.
• fp — отпечаток TLS-библиотеки, которой представляется клиент.

Все они должны в точности совпадать с серверными. Одна опечатка в pbk — и соединение не поднимется, а сообщение об ошибке будет невнятным. Поэтому строку подключения импортируют, а не набирают.

Двойное шифрование: откуда берётся

Теперь ко второй технологии. Откройте любой сайт по HTTPS через туннель — и посмотрите, что происходит с данными.

Сначала браузер шифрует содержимое для самого сайта: это обычный HTTPS, он был бы и без всякого VPN. Затем получившийся уже нечитаемый поток попадает в туннель, и туннель шифрует его ещё раз.

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

Что делает XTLS Vision

Vision — режим, который распознаёт эту ситуацию. Увидев, что внутри потока и так идёт TLS, он перестаёт шифровать повторно и передаёт данные дальше как есть.

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

Незашифрованный трафик — а его в современном вебе почти не осталось — шифруется как обычно. Vision работает избирательно.

Кому выигрыш заметен

Честно: не всем. Экономия процессорного времени видна там, где процессора мало.

• Телефоны и планшеты — заметно, особенно на тяжёлых потоках вроде видео.
• ТВ-приставки и телевизоры — заметно: там процессоры скромные.
• Роутеры — заметно сильнее всего, но там и сам сценарий отдельный.
• Настольные компьютеры — почти нет: аппаратное ускорение справляется и без оптимизаций.

И всё это не отменяет главного: итоговую скорость определяют расстояние до сервера и его загрузка, а не режим потока. Подробности — в разборе о скорости.

Ошибки в настройке

• Flow не совпадает. Если на сервере указан xtls-rprx-vision, а у клиента поле пустое, соединение либо не встанет, либо будет рваться на ровном месте.
• Перепутаны публичный и приватный ключ. Приватный остаётся на сервере и никуда не копируется. Если он оказался в клиентской строке — его нужно считать скомпрометированным и перевыпустить.
• Ручной ввод параметров. Самая частая причина необъяснимых отказов. Импорт ссылки или подписки исключает этот класс ошибок целиком.

Если соединение не поднимается и причина непонятна, пройдите разбор отказов по порядку — он устроен от простого к сложному.

Частые вопросы