[2026-09-02] eagle: family/how-to/truenas-infrastructure.md personal/tech/xray-reverse-tunnel-kraken-truenas.md

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

@@ -1,7 +1,7 @@
 ---
 title: Xray Reverse Tunnel — Kraken ↔ TrueNAS
 created: '2026-09-01'
-updated: '2026-09-01'
+updated: '2026-09-02'
 type: tech
 namespace: personal
 tags: [xray, reverse, kraken, truenas, tunnel, networking]
@@ -15,7 +15,7 @@ related:
 
 # Xray Reverse Tunnel — Kraken ↔ TrueNAS
 
-> **Статус: КОРНЕВАЯ ПРИЧИНА НАЙДЕНА + ФИКС ПРИМЕНЁН, но блокируется недоступностью Kraken (2026-09-01).** ✅ 3x-ui развёрнут и работает. ✅ reverse portal (TrueNAS) + bridge (Kraken) на **прямом TCP+REALITY**, reverse-канал установлен. 🔑 **Найден корень проблемы payload через интернет-поиск (issue XTLS/Xray-core #6612)**: с v26.5+ у `freedom`/`direct` дефолтная политика **блокирует VLESS Reverse payload**, пока не задан явный `finalRules: [{"action":"allow"}]`. ✅ **Фикс залит** (новый bridge-конфиг с `finalRules` на Kraken, `/home/kraken/xray-reverse/config.json`). ⛔ **БЛОКЕР: Kraken недоступен по docker** — USB-HDD `sda` показывает `0B` (не поднялся), docker демон застрял в `activating`, bridge-контейнер пересоздать невозможно. Задание НЕ завершено — нужен фикс HDD/docker на Kraken.
+> **Статус: КОРНЕВАЯ ПРИЧИНА НАЙДЕНА + ФИКС #6612 ПРИМЕНЁН и НЕ ПОМОГ — настоящий корень: РЕГРЕССИЯ #6242 (bridge-side, v26.5+). НЕ ВНЕДРЕНО (2026-09-02).** ✅ 3x-ui развёрнут и работает. ✅ reverse portal (TrueNAS) + bridge (Kraken) на **прямом TCP+REALITY**, reverse-канал установлен. ✅ Kraken восстановился 2026-09-02 (диск/docker/контейнеры) — bridge перезапущен с фиксом `finalRules:allow`, но **payload по-прежнему НЕ проходит** (test → `Empty reply from server`). 🔑 **ИСТИННЫЙ КОРЕНЬ (интернет-поиск 2026-09-02, issue #6242): регрессия роутинга VLESS Reverse на BRIDGE-стороне в Xray v26.5+** (у нас 26.7.28). `finalRules` (#6612) — отдельная проблема, уже устранена, но не лечит #6242. **Решение: сдаунгрейд БРИДЖА до Xray 26.4.25** (образ `teddysun/xray:26.4.25`), portal-сторона может остаться на 26.7.28. ⛔ План согласован с Alex, выполнение ждёт команды — не трогать `vpn.mallexxx`.
 > Архитектурное решение: проксировать исходящий трафик локальных клиентов сети TrueNAS через **TrueNAS → Kraken → интернет**.
 
 > ## ✅ ВАЖНО (2026-09-02): `xray-admin` (3x-ui) на TrueNAS — это ОДНОВРЕМЕННО РАБОЧИЙ САМОСТОЯТЕЛЬНЫЙ Xray-VPN-сервер
@@ -198,6 +198,50 @@ Issue говорит прямо: проблема воспроизводится
 
 **Статус: задание НЕ завершено — остаётся применить bridge-фикс после восстановления docker на Kraken.**
 
+## ✅ 2026-09-02: Kraken восстановлен (диск/docker) + фикс #6612 применён — НО payload всё равно мёртв → ИСТИННЫЙ КОРЕНЬ #6242 (bridge-side v26.5+)
+
+### Kraken полностью поднялся (проверено живьём по SSH)
+- Uptime 2 мин — Kraken перезагрузился (USB-HDD-сценарий). `systemctl is-active docker` был `activating` первые минуты (ждал поднятия диска), затем стал **`active`**.
+- **Диск `/dev/sda1` поднялся**: 1.8T, смонтирован к `/srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f`, 235G свободно (87% занято). (В отличие от 2026-09-01, когда `sda` был `0B`.)
+- **Все контейнеры восстановились** (в прошлый раз — 0): transmission, sonarr, prowlarr, homeassistant, jellyfin, radarr, hermes-kraken, portainer, rclone, cloudflared, flaresolverr, watchtower, **xray-reverse-bridge**. Docker Root Dir `/srv/dev-disk-by-uuid-6194539b-.../docker-data`.
+- **Bridge-конфиг содержит фикс #6612**: `/home/kraken/xray-reverse/config.json` → `freedom/direct` с `"finalRules":[{"action":"allow"}]`.
+- **Reverse-канал к TrueNAS жив**: bridge лог 2026-09-02 13:12: `dialing TCP to mallexxx.duckdns.org:12346` → `tunneling request` → `received request for udp:reverse:0`. Bridge = Xray **26.7.28** (`teddysun/xray:latest`).
+
+### Portal (TrueNAS) — состояние
+`xray-reverse-portal` Up 22h, reverse-канал от Kraken держится. Лог portal: `accepted tcp:8.6.112.0:80 [local -> reverse-out]` — запрос с локального SOCKS-входа уходит в reverse-out (в сторону Kraken). Конфиг portal без изменений (interconn :12346 REALITY client `a81c3179...` reverse-out; local :12345 SOCKS; routing `local→reverse-out`; placeholder-freedom). Сеть `caddy_default`, curl-контейнер в ней резолвит `xray-reverse-portal:12345` = `172.16.1.7`.
+
+### ❌ End-to-end payload по-прежнему НЕ проходит (даже с фиксом #6612)
+Тест временным контейнером `curlimages/curl` в сети `caddy_default` на TrueNAS:
+```
+docker run --rm --network caddy_default curlimages/curl:latest curl -sv --socks5-hostname xray-reverse-portal:12345 -m 20 http://api.ipify.org
+```
+→ verbos: `Opened SOCKS connection from 172.16.1.8 port ... to api.ipify.org port 80 (via 172.16.1.7 port 12345)` → `Request completely sent off` → **`Empty reply from server`** (соединение закрыто без ответа). Трафик доходит до portal, уходит в reverse-out, НО не возвращается от bridge → ответ теряется.
+
+### 🔑 ИСТИННЫЙ КОРЕНЬ (2026-09-02, интернет-поиск): issue XTLS/Xray-core #6242 — регрессия bridge в v26.5+
+Симптомы точно совпадают с [issue #6242](https://github.com/XTLS/Xray-core/issues/6242) (закрыта "not planned"):
+- Регрессия **только на стороне BRIDGE** (outbound-initiating), версия portal не важна.
+- С **v26.5+** (и 26.6.x) bridge стартует без ошибок, reverse-канал вроде устанавливается (`udp:reverse:0`), но **трафик не маршрутизируется через reverse tunnel**. Ровно наш случай на 26.7.28.
+- **Понижение ТОЛЬКО bridge до v26.4.25 мгновенно возвращает полную работу** без изменений конфига.
+- Связано с #5750 (BurstObservatory не успевает health-check динамически регистрируемых `rproxy-*` outbound'ов — до 10 мин) и обсуждением #5962 (stale-tunnel mappings после рестартов). PR #5101 прямо предупреждал: "reverse sub-protocol unstable, will break, кросс-версий совместимости НЕ гарантировано".
+- **Почему фикс #6612 не помог:** #6612 (`finalRules:allow`) лечит ДРУГУЮ проблему (Freedom блокирует payload) — мы её уже устранили. Но осталась регрессия маршрутизации #6242, которую `finalRules` не обходит.
+
+**Решение/кварк:** сдаунгрейд **bridge** до Xray **26.4.25** (образ `teddysun/xray:26.4.25`, существует на Docker Hub / GitHub Container Registry `ghcr.io/xtls/xray-core:26.4.25`). Portal-сторона (26.7.28) остаётся.
+
+### План внедрения (согласован с Alex — что НЕ трогать `vpn.mallexxx` и `xray-admin`)
+1. На Kraken: остановить `xray-reverse-bridge` контейнер.
+2. В `/home/kraken/xray-reverse/docker-compose.yml` сменить образ `teddysun/xray:latest` → `teddysun/xray:26.4.25`.
+3. `cd /home/kraken/xray-reverse && docker compose up -d` (пересоздаст bridge на 26.4.25).
+4. Проверить reverse-канал: bridge лог `udp:reverse:0`.
+5. Контрольный end-to-end: временный curl-контейнер в сети `caddy_default` на TrueNAS через `xray-reverse-portal:12345` → ожидаем выход с **IP Kraken** (`92.62.70.41`), НЕ IP TrueNAS.
+⛔ НЕ трогать: `xray-admin` / `vpn.mallexxx` / Caddy / portal.
+
+### ⚠️ Важное прояснение для будущих сессий (из этого диалога)
+Запрос юзера "не могу подключиться к xray на truenas до наших измерений" — это была путаница между **тремя** разными сущностями:
+1. `vless-proxy` (teddysun/xray, SOCKS :1080/:1081, outbound на удалённый VPS qentra.top) — **мёртв из-за удаления VPS** 2026-09-01.
+2. `xray-admin` (3x-ui) = **самостоятельный рабочий Xray-VPN из интернета** через `vpn.mallexxx.duckdns.org:443` (см. секцию «ВАЖНО 2026-09-02» выше). Жив, end-to-end проверен.
+3. reverse-туннель TrueNAS↔Kraken (portal `xray-reverse-portal` + bridge на Kraken) — это про проксирование egress ЛОКАЛЬНЫХ клиентов сети TrueNAS через Kraken. НЕ связан с vpn.mallexxx.
+
+
 ## ⏳ Открытые вопросы по reverse (требуют ответа/действия Alex)
 
 ## План реализации (история; Шаг 1 устарел — см. «ВНЕДРЕНО» выше)
@@ -231,8 +275,8 @@ Issue говорит прямо: проблема воспроизводится
 
 1. ✅ (решено) **Проброс порта для reverse** — переведён на TCP+REALITY, ВСЁ ВЫПОЛНЕНО (portal пересоздан с REALITY, OpenWrt DNAT `внешний:12346 → 192.168.2.197:12346` добавлен, bridge на Kraken пересоздан). См. секции «ВНЕДРЕНО — TCP+REALITY» выше. **Компанент работает, но payload НЕ проходит (см. пункт 4).**
 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 не проходил** — **КОРЕНЬ НАЙДЕН (issue #6612)**: с v26.5+ у freedom/direct дефолт блокирует VLESS Reverse payload без явного `finalRules:[{action:"allow"}]`. **Фикс залит** на bridge-конфиг, но **не применён** — Kraken по docker недоступен (USB-HDD `sda`=0B, docker в `activating`). См. секции «КОРЕНЬ ПРОБЛЕМЫ НАЙДЕН» и «ФИКС ПРИМЕНЁН, но заблокирован» выше. Задание не завершено — остаётся восстановить docker на Kraken и пересоздать bridge.
+3. ✅ **Kraken docker** — РАБОТАЕТ, ВОССТАНОВИЛСЯ 2026-09-02: `systemctl is-active docker` → `active`, диск `/dev/sda1 1.8T` смонтирован к `/srv/dev-disk-by-uuid-6194539b-...`, 235G свободно (87% занято). **Все контейнеры восстановились** (в отличие от 2026-09-01, когда было 0): transmission, sonarr, prowlarr, homeassistant, jellyfin, radarr, hermes-kraken, portainer, rclone, cloudflared, flaresolverr, watchtower, **xray-reverse-bridge** (Up).
+4. 🔑 **End-to-end payload НЕ проходит даже после фикса #6612** — **ИСТИННЫЙ КОРЕНЬ НАЙДЕН (2026-09-02, issue #6242)**. Несмотря на то что фикс `finalRules:[{action:"allow"}]` применён на bridge и Kraken полностью восстановлен (docker active, bridge перезапущен с фиксом, reverse-канал `udp:reverse:0` жив), payload всё равно не проходит: тест временным curl-контейнером в сети `caddy_default` через `xray-reverse-portal:12345` → verbos `Opened SOCKS connection... Empty reply from server`. **Причина: регрессия роутинга VLESS Reverse на BRIDGE-стороне в Xray v26.5+** (bridge на `teddysun/xray:latest` = 26.7.28). Issue #6242 закрыта "not planned" — фикса нет. **Решение/кварк: сдаунгрейд bridge до `teddysun/xray:26.4.25`** (образ существует на Docker Hub), portal-сторона (26.7.28) остаётся. План согласован с Alex, выполнение ждёт команды. См. секцию «✅ 2026-09-02: Kraken восстановлен + ИСТИННЫЙ КОРЕНЬ #6242» ниже.
 
 ## Связанные заметки
 - [[family/how-to/vps-qentra]] — VPS на 2026-09-01 УДАЛЁН