Когда DPI (Deep Packet Inspection) научился отличать HTTPS-трафик VPN от обычного HTTPS — просто «завернуть всё в TLS» перестало работать. Регистратор смотрит на Server Name Indication (SNI) и сертификат: если там что-то подозрительное или нестандартное — ресетит соединение. Провайдеры обзавелись оборудованием, которое анализирует даже длину пакетов и тайминги handshake’а.
Reality (XTLS) — это протокол, который не маскирует трафик под HTTPS, а буквально «крадёт» TLS-сессию у легитимного сайта. Клиент подключается к реальному серверу (например, `cloudflare.com`), но внутри этого соединения — тоннель к целевому ресурсу. DPI видит безупречный handshake с Cloudflare, видит валидный сертификат — и пропускает. Фокус в том, что Reality не генерирует свой TLS, а использует существующий, перехватывая сессию на уровне транспортного протокола.
Ключевое отличие от предшественников: V2Ray с VMess/VLESS просто шифровали трафик внутри TLS-обёртки, но сертификат и SNI всё равно выдавали «не то». Reality же заимствует SNI и сертификат у публичного сайта — DPI не к чему придраться. Дополнительно протокол использует механизм «pad» (добавление мусорных данных до фиксированной длины пакета), чтобы скрыть сигнатуру протокола по размеру.
Сильные стороны: практически неотличим от обычного HTTPS в пассивном анализе. Работает даже на зашумлённых каналах. Слабые: требует стабильного доступа к серверу-«донору» (если он упадёт — Reality не сможет установить сессию). Активно развивается — XTLS Reality уже v2, с улучшенной обработкой очередей и фиксами утечек памяти.
Сценарий: если ваш провайдер использует Active Probing (активно проверяет, кому принадлежит сервер), Reality не спасёт — при проверке «донор» не ответит на запрос с неверным SNI. Но против пассивного DPI — лучший выбор.
Финал: Reality элегантно решил проблему «а что, если TLS-обёртка тоже под подозрением». Теперь вопрос — когда DPI научится анализировать поведение сессии уже после handshake и отличать «нормальный» веб-трафик от тоннеля?
#Reality #XTLS #DPI #VPN #маскировка
