Reality — обман DPI без сертификата

Reality (RPRX, январь 2023) — самый революционный шаг в обходе блокировок за последние 5 лет. Главная идея: не маскироваться под HTTPS, а реально проводить HTTPS-handshake с настоящим чужим сайтом. Только в середине этого handshake клиент и сервер «перехватывают» канал. DPI видит идеальный TLS — потому что он идеальный.

1. Проблема, которую решает Reality

До Reality все «маскирующиеся» протоколы (Trojan, VLESS+TLS+WS) имели две слабости:

1. Нужен настоящий домен и сертификат. Покупка домена, привязка к IP, Let's Encrypt, обновление каждые 90 дней. Каждый «свой» домен в blacklist DPI попадает быстро.
2. Active probing. DPI может сам подключиться к подозрительному IP и проверить: «а есть ли тут реальный сайт?». Если нет — забанить.

Reality решает оба за раз: SNI указывает на чужой реальный сайт, и сервер Reality, увидев handshake без нужного «приветствия», проксирует handshake на тот самый чужой сайт. Active probe получит ответ настоящего сервера — не от твоего VPN.

2. Как работает Reality — высокоуровневая схема

3. Как сервер проверяет «свой/чужой» в первом байте

Это сердце Reality. Никакого пароля в plaintext, никакой явной аутентификации. Используется хитрая схема на X25519:

1. На сервере сгенерирована пара (server_priv, server_pub). server_pub кладётся в конфиг клиента.
2. Клиент при handshake генерирует свой ephemeral X25519 e_c. Считает shared = X25519(e_c, server_pub).
3. Использует shared как ключ для шифрования специального auth-tag, который кладётся в случайное место session_id поля ClientHello (32 байта random, как должно быть). Клиент пишет туда зашифрованный «правильный» магический cookie.
4. В Key Share extension клиент кладёт свой e_c. Сервер видит его как обычный TLS Key Share — DPI не подозревает.
5. Сервер получает ClientHello, видит KeyShare, вычисляет shared = X25519(server_priv, e_c), пытается расшифровать session_id. Если magic cookie сошёлся — клиент свой.
6. Если расшифровка не сошлась (это сторонний запрос, например, active probe DPI) — сервер проксирует ClientHello на dest = apple.com:443 и отдаёт обратно настоящие ответы apple.com. Active probe видит реальный сайт.

4. ShortIDs — несколько клиентов на одном сервере

Если у тебя 10 пользователей, у каждого свой UUID — как сервер их различает? В Reality для этого есть ShortIDs — короткие (1-8 байт) hex-строки, которые тоже кладутся в зашифрованную часть session_id.

В конфиге сервера:

"shortIds": [
  "",                  // ← пустой = «любой» (на отладке)
  "01ab",              // пользователь 1
  "02cd",              // пользователь 2
  "03ef",              // пользователь 3
  "0a0b0c0d0e0f1011"   // VIP-пользователь, длиннее (8 байт)
]
  

У клиента в конфиге shortId: "01ab" — он его шифрует в session_id. Сервер расшифровал — сравнил с whitelist'ом — пропустил.

5. Какой dest (SNI-цель) выбирать

Это самый важный конфигурационный параметр Reality. К чему предъявляются требования:

В 2024-2025 популярные хорошие dest'ы:

• www.microsoft.com
• www.apple.com
• dl.google.com
• www.lovelive-anime.jp — японские сайты часто хороши
• www.swift.com
• www.icloud.com

6. Полная конфигурация — сервер и клиент

Сервер (Xray-core)

{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "port": 443,                          // ← наружу 443, как у обычного HTTPS
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "12345678-1234-1234-1234-123456789012",  // ← UUID пользователя
            "flow": "xtls-rprx-vision",                    // ← Vision overlay
            "email": "user1@vpn"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "dest": "www.microsoft.com:443",                  // ← маскируемся под MS
          "xver": 0,
          "serverNames": ["www.microsoft.com"],             // ← валидные SNI
          "privateKey": "SERVER_PRIVATE_KEY_BASE64",        // ← xray x25519
          "minClientVer": "",
          "maxClientVer": "",
          "maxTimeDiff": 0,
          "shortIds": ["", "01ab", "02cd"]
        }
      }
    }
  ],
  "outbounds": [
    { "protocol": "freedom", "tag": "direct" },
    { "protocol": "blackhole", "tag": "block" }
  ],
  "routing": {
    "rules": [
      { "type": "field", "ip": ["geoip:private"], "outboundTag": "block" }
    ]
  }
}
  

Генерация ключей: xray x25519 — выведет priv/pub keys.

Клиент (Xray / sing-box / NekoBox / v2rayN)

{
  "inbounds": [
    { "port": 10808, "protocol": "socks", "listen": "127.0.0.1" }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "VPS_IP",                            // ← IP твоего VPS
            "port": 443,
            "users": [
              {
                "id": "12345678-1234-1234-1234-123456789012",
                "flow": "xtls-rprx-vision",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.microsoft.com",              // ← маскировка под MS
          "fingerprint": "chrome",                         // ← uTLS под Chrome
          "publicKey": "SERVER_PUBLIC_KEY_BASE64",
          "shortId": "01ab",
          "spiderX": "/"                                   // ← путь спайдеринга (см. ниже)
        }
      }
    }
  ]
}
  

7. SpiderX — финальный штрих маскировки

Когда сервер Reality перехватил handshake, он отдал клиенту сертификат настоящего apple.com. После этого происходит обычный TLS application data. Но клиент НЕ открывает apple.com — он шлёт свой VPN-трафик через VLESS.

Чтобы DPI не заметил «странного поведения» (TLS-handshake с apple.com → дальше нет http-запросов к apple), Xray на стороне клиента эмулирует SpiderX: фоновые HTTP-запросы к настоящему apple.com по разным path. DPI видит: «клиент пошёл на apple.com и листает страницы» — нормально.

spiderX: "/" означает: при подключении делать GET / и эмулировать поведение браузера. Можно настраивать паттерн обхода (что и как часто запрашивать).

8. Слабости Reality

Reality не магия. Несколько ограничений:

9. Почему Reality всё ещё работает в 2026

10. Мини-лаба: попробуй прямо сейчас

Ключи Reality и «кражу» чужого TLS можно рассмотреть без поднятия сервера:

# 1. Сгенерируй пару ключей Reality (X25519) — сервер отдаёт публичный клиентам
xray x25519
# Private key: ... / Public key: ...  — та самая асимметрика из урока 2

# 2. Посмотри «жертву маскировки»: реальный TLS-сертификат сайта-донора.
#    Именно ЭТОТ сертификат увидит DPI в твоём Reality-трафике.
openssl s_client -connect www.microsoft.com:443 -servername www.microsoft.com 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

# 3. Проверь пригодность донора: нужен TLS 1.3 + HTTP/2 (X25519) и НЕ за Cloudflare-CDN
openssl s_client -connect www.microsoft.com:443 -tls1_3 2>/dev/null | grep -E "Protocol|Cipher"
curl -sI https://www.microsoft.com | grep -iE "server|alt-svc"

# 4. Сгенерируй ShortID (несколько клиентов на одном сервере)
openssl rand -hex 8

11. Задачи самопроверки — реши, потом раскрой ответ

12. Словарик урока

13. Дальше

Reality — это TCP-стрим. Есть случаи (плохой UDP-канал, мобильник в роуминге, потери), где TCP-туннель страдает. Для этого случая существуют UDP-туннели на QUIC: Hysteria 2, TUIC. Они быстрее на плохих каналах и имеют другой набор противотрюков (port hopping, BBR Brutal). Это урок 08.