Долгое время стандартный сценарий обхода глубокой инспекции пакетов (DPI) выглядел так: поднимаешь TLS-туннель, маскируешься под легитимный HTTPS, и живёшь спокойно, пока цензоры не разберут твой сертификат в пух и прах. Шифрование само по себе перестало быть панацеей — блокировщики научились анализировать не только заголовки, но и паттерны рукопожатий (TLS handshake fingerprint). Тут на сцену выходит Reality — протокол, который не просто шифрует трафик, а притворяется обычным HTTPS-соединением к реально существующему сайту. Это принципиально иная философия: не «я — зашифрованный туннель», а «я — браузер, заходящий на Amazon».
Как это работает. Reality использует связку XTLS (это не протокол, а расширение транспортного уровня) и технологии TLS 1.3 с публичным сертификатом реального сайта. Клиент подключается к серверу, который проксирует запрос через Cloudflare или другой CDN, а на стороне клиента трафик выглядит как обычный TLS-хендшейк с site.com. Никаких кастомных сертификатов — только публичные, которые уже есть в системе. DPI видит: 1) SNI (Server Name Indication) указывает на легитимный домен; 2) рукопожатие по стандарту TLS 1.3 с валидной цепочкой сертификатов; 3) трафик шифрован, но неотличим от обычного HTTPS. Никаких сигнатур протоколов обхода. Ключевой нюанс: Reality умеет делать «утку» — сервер, получив запрос к site.com, либо отдаёт настоящую страницу site.com (если это обычный браузер), либо перенаправляет трафик в туннель (если запрос от клиента Reality). DPI не может отличить одно от другого, потому что клиент и сервер договариваются о «своём» трафике на уровне сессии, а не через дополнительные заголовки.
Сильные стороны: — противодействие активному зондированию (если цензор сам попробует подключиться к серверу Reality, он получит реальную страницу site.com, а не ошибку или таймаут) — минимальный overhead; — не требует фиксированного IP-сервера (можно за CDN). Слабые: — сложность настройки (нужно правильно подобрать реальный site.com с устойчивым TLS-стеком, чтобы DPI не заподозрил подмену) — на Windows может конфликтовать с системными настройками прокси — производительность при большом количестве одновременных сессий проседает из-за частой верификации сертификатов.
Текущий статус: активно развивается, последние коммиты в репозиторий XTLS — это доработки паттернов маскировки под разные версии TLS. Стабилен на Linux, экспериментален на мобильных. Финальная мысль: Reality — это не «волшебная кнопка», а инструмент, который требует понимания, как работает TLS на уровне битов. Если вы не знаете разницы между ClientHello и ServerHello, возможно, стоит начать с чего-то попроще. Вопрос к залу: как думаете, сколько времени пройдёт, пока цензоры начнут анализировать время отклика CDN и статистические отклонения в паттернах трафика?
