Files

vitya 4fc7cbf688 wiki(nl-vds-3xui): new NL 3x-UI node + Reality PQ×dest root-cause

Reality 443 inbound silently fails: ML-DSA-65 (post-quantum) ClientHello
key-share X25519MLKEM768 relayed to dest www.intel.com (Akamai) -> HRR ->
borrowed-TLS handshake never completes. Plain VLESS 32030 unaffected.
Isolated via replica xray pair (matrix: intel+PQ is the only failing cell).
Fix (NOT applied, awaiting user): switch dest/SNI -> www.microsoft.com
(PQ-capable, verified) on both inbound and client profile.

- new entities/nl-vds-3xui.md
- new concepts/reality-pq-mldsa65-dest-incompatibility.md
- index.md + log.md updated
- creds saved to pass nl-vds-3xui/full-env (not in repo)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-05 11:26:16 +03:00

4.9 KiB

Raw Blame History

title, type, tags, sources, updated

title

type

REALITY + ML-DSA-65 (post-quantum) ломается с не-PQ dest (напр. www.intel.com)

Симптом

Свежий 3x-UI / Xray-инбаунд VLESS+Reality не коннектится (клиент молча висит до таймаута, никакой ошибки в GUI), при этом обычный VLESS на другом порту работает. На сервере (при debug-логе):

transport/internet/tcp: REALITY: processed invalid connection from <ip>: handshake did not complete successfully

Клиент крутит ретраи и сдаётся: proxy/vless/outbound: failed to find an available destination > [EOF].

Root cause

Современный 3x-UI (Xray ≥ 25.x, здесь 26.6.1) для нового Reality-инбаунда по умолчанию включает пост-квантовый режим ML-DSA-65 (realitySettings.mldsa65Seed на сервере + mldsa65Verify у клиента). В этом режиме ClientHello несёт пост-квантовый key-share X25519MLKEM768 (~1.2 КБ).

REALITY-сервер релеит ClientHello на dest/target, чтобы «позаимствовать» его TLS-рукопожатие. Если dest не поддерживает PQ-группу обмена ключами, он отвечает HelloRetryRequest (просит другую группу) — а borrowed-TLS поток REALITY этого не переживает → хендшейк не достраивается. www.intel.com за Akamai именно такой: PQ-обмен не поддерживает.

Ключевой нюанс диагностики: неаутентифицированный гость (обычный openssl s_client) идёт по fallback-пути REALITY (прозрачный релей на dest) и получает настоящий сертификат intel — поэтому сервер кажется «живым». Ломается только аутентифицированный путь, и только в связке с PQ.

Изоляционная матрица (replica-пара, Xray 26.6.1 ↔ 26.6.1, debug)

Полностью подконтрольная пара (свой сервер-инбаунд на 8443 + клиент на socks 10888, ключи выведены из seed):

dest/SNI	ML-DSA-65	Результат
`www.intel.com`	вкл	❌ `handshake did not complete`
`www.intel.com`	выкл	✅ HTTP 204
`www.microsoft.com`	выкл	✅ 204
`www.microsoft.com`	вкл	✅ 204
`www.yahoo.com`	выкл	✅ 204

→ Падает только intel + PQ. Порознь оба компонента исправны. Версии ядер, X25519-ключи, shortId, flow, UUID, seed↔verify, часы — всё проверено и совпадает; ни один из них не виноват.

Fix

Два варианта (рекомендация — первый):

Сменить dest на PQ-совместимый (сохраняет пост-квантовую защиту). На сервере в инбаунде: realitySettings.target → www.microsoft.com:443, serverNames → ["www.microsoft.com"]; в клиенте — SNI → www.microsoft.com. Менять симметрично обе стороны. PQ-совместимость dest проверяется тестом из матрицы выше (или: dest должен уметь TLS1.3 hybrid PQ key-exchange X25519MLKEM768 — Cloudflare/Google/Microsoft умеют, Akamai-фронт обычно нет).
Выключить ML-DSA-65 на инбаунде (убрать mldsa65Seed / пересоздать инбаунд без PQ) — тогда intel работает. Проще, но теряется пост-квантовая стойкость. Брать только если PQ не нужен.

Как воспроизвести/проверить dest на PQ (read-only)

Поднять временную replica-пару xray run -c на localhost-портах с loglevel:debug и curl -x socks5h://… через тоннель — НЕ трогая боевой инбаунд (см. методику в nl-vds-3xui). Признак PQ-несовместимого dest: сервер логирует REALITY: ... handshake did not complete только при включённом seed.

Где встречалось

nl-vds-3xui — инбаунд 443, обнаружено 2026-06-05.

4.9 KiB Raw Blame History Unescape Escape