[2026-09-01] eagle: family/how-to/truenas-access.md family/how-to/truenas-infrastructure.md family/plans/reverse-xray-3xui-kraken.md personal/tech/xray-reverse-tunnel-kraken-truenas.md

personal/tech/xray-reverse-tunnel-kraken-truenas.md

@@ -135,12 +135,22 @@ compose: image `teddysun/xray:latest`, volume `config.json:/etc/xray/config.json
 - **Bridge НЕ логирует received для этого TCP-payload** — данные теряются между reverse-out (portal) и reverse-in (bridge).
 - Kraken имеет прямой интернет (`api.ipify` → `92.62.70.41`), проблема не в egress.
 
-### 💡 Гипотеза (вероятная) и след. шаг
-**WebSocket-транспорт не пропускает reverse-payload.** В официальных VLESS-reverse примерах канал bridge↔portal идёт **по прямому TCP** + `flow: xtls-rprx-vision` (REALITY). UDP-reverse создаётся, но TCP-payload по WS не доходит.
-**План (отложен):** перевести reverse-канал на **прямой TCP**:
-1. TrueNAS: VLESS-inbound `interconn` на отдельном TCP-порту (напр. `:12346` наружу) + проброс на роутере `внешний :12346 → 192.168.2.197:12346` (Alex подтвердил «пробросить не проблема»).
-2. Kraken: bridge VLESS-outbound → **TCP** (не WS), address `mallexxx.duckdns.org:12346`.
-3. Возможно нужен `flow: xtls-rprx-vision` + шифрование на канале (REALITY) — по доке.
+### ✅ РЕШЕНО 2026-09-01: переход на прямой TCP+REALITY (выполняется)
+WS-транспорт подтверждённо не пропускает reverse-payload. Принято решение (Alex согласовал проброс порта) — перевести канал bridge↔portal на **прямой TCP + REALITY**:
+
+**REALITY-ключи (interconn :12346):** server PrivateKey `0JTjeirfviDqCr63wSnisvU7DV6SpR9_9V2l_EUHmkk`; server PublicKey (для bridge) `GhsphQLT_0fwOvK45MHeAgG3sBQsFtw7lQfUIbrLMQU`; shortId `1451ef281caf5905`; serverName/SNI `www.cloudflare.com`; flow `xtls-rprx-vision`.
+
+**⚠️ Pitfall Xray 26.x:** VLESS без TLS/шифрования к публичному адресу запрещён (`vless without TLS or other encryption is prohibited unless the server address is a private IP`) → TCP-VLESS обязателен с REALITY.
+
+Обновлённые конфиги (оба `Configuration OK` при `xray run -test`):
+- **portal** `/mnt/RED_2TB/docker/reverse-portal/config.json`: interconn `:12346` VLESS-TCP reality; local `:12345` SOCKS; compose получил проброс `- "12346:12346"`.
+- **bridge** `/home/kraken/xray-reverse/config.json`: outbound `conn` → `mallexxx.duckdns.org:12346` reality.
+
+Незавершено (стоп на одобрение lifecycle-операции):
+1. Пересоздать `xray-reverse-portal` (stop/rm/up) на TrueNAS.
+2. OpenWrt DNAT `внешний:12346 → 192.168.2.197:12346` (бэкап firewall уже сделан: `/mnt/RED_2TB/docker/backups/openwrt-firewall-20260901-130558.txt`).
+3. Пересоздать `xray-reverse-bridge` на Kraken.
+4. Тест `curl --socks5 <TrueNAS>:12345 https://api.ipify.org` → ожидать IP Kraken `92.62.70.41`.
 
 ## ⏳ Открытые вопросы по reverse (требуют ответа/действия Alex)
 
@@ -173,10 +183,10 @@ compose: image `teddysun/xray:latest`, volume `config.json:/etc/xray/config.json
 
 ## Открытые вопросы (требуют ответа Alex)
 
-1. ❌ **Проброс порта для reverse** — теперь НУЖЕН для перевода reverse-канала на TCP (end-to-end payload не проходит по WS). Alex подтвердил «пробросить не проблема». Параметры: `внешний :12346 → 192.168.2.197:12346` (или отдельный VLESS+REALITY порт).
+1. ✅ (решено) **Проброс порта для reverse** — переходим на TCP+REALITY. Реализация НЕ завершена: конфиги подготовлены и валидны, осталось (a) пересоздать `xray-reverse-portal` на TrueNAS с новым compose, (b) OpenWrt DNAT `внешний:12346 → 192.168.2.197:12346`, (c) пересоздать `xray-reverse-bridge` на Kraken. Проброс порта Alex подтвердил «не проблема». См. секцию «РЕШЕНО 2026-09-01» выше.
 2. **Какой трафик TrueNAS пустить через Kraken** — весь исходящий интернет, или конкретные сервисы/подсети? (Влияет на маршрутизацию на Kraken.) — всё ещё открыто.
 3. ✅ **Kraken docker** — РАБОТАЕТ (после перезагрузки 2026-09-01): Server 29.4.3, Docker Root Dir `/srv/dev-disk-by-uuid-6194539b-.../docker-data` (актуальный UUID, HDD смонтирован), **30 образов сохранены, но 0 контейнеров** (all контейнеры не восстановлены после сбоя). Reverse-bridge-контейнер развёрнут поверх. НО: известные контейнеры (jellyfin, ha, transmission и т.д.) требуется пересоздать — отдельная задача, не входила в reverse-сферу.
-4. ❌ **End-to-end payload не проходит** — главный блокер (см. секцию «Reverse деплой» выше). Гипотеза WS-проблема → следующий шаг перевести на TCP + проброс порта. Не завершено.
+4. ❌ **End-to-end payload не проходит** — блокер. WS-вариант не пропускает payload; переходим на TCP+REALITY (конфиги готовы, осталось пересоздать контейнеры + пробросить порт). См. секцию «РЕШЕНО 2026-09-01» выше. Не завершено.
 
 ## Связанные заметки
 - [[family/how-to/vps-qentra]] — VPS на 2026-09-01 УДАЛЁН