[2026-09-02] eagle: family/plans/reverse-xray-3xui-kraken.md personal/tech/xray-reverse-tunnel-kraken-truenas.md

family/plans/reverse-xray-3xui-kraken.md

@@ -242,6 +242,37 @@ reverse_proxy @rvs xray-reverse-portal:12346
 7. 🔑 **End-to-end НЕ работал** (curl через SOCKS 12345 → 000) на WS и на TCP+REALITY (flow и без flow) — **причина найдена (issue #6612)**: с v26.5+ у freedom/direct дефолт блокирует VLESS Reverse payload без явного `finalRules`. **Фикс залит** на bridge-конфиг /home/kraken/xray-reverse/config.json, но **не применён** — Kraken по docker недоступен (USB-HDD `sda`=0B, docker в `activating`). См. «КОРЕНЬ ПРОБЛЕМЫ НАЙДЕН» и «ФИКС ПРИМЕНЁН, но заблокирован» выше. **Статус: задание НЕ завершено — нужен фикс HDD/docker Kraken + пересоздать bridge + тест.**
 8. ⏳ Обновить Obsidian: truenas-infrastructure.md, kraken-access.md, vps-qentra.md. **TODO для следующей сессии.** (Основной tech-doc `personal/tech/xray-reverse-tunnel-kraken-truenas.md` уже обновлён 2026-09-01 с корнем/фиксом.)
 
+## ❌ ФИНАЛ СЕССИИ 2026-09-02: downgrade обеих сторон НЕ помог — reverse по-прежнему мёртв
+
+> Гипотезы выше (#6612, #6242 → «понизить bridge до 26.4.25») были **проверены на практике и НЕ решили проблему**. Это фактический итог — читать вместо старых «корень найден» теорий.
+
+### Выполнено (по согласованию, не трогая vpn.mallexxx/xray-admin)
+- **Bridge (Kraken)** `docker-compose.yml`: образ `teddysun/xray:latest` → **`teddysun/xray:26.4.25`** (бэкап `.bak-26.7.28`). Контейнер на 26.4.25 (arm64).
+- **Portal (TrueNAS)** `/mnt/RED_2TB/docker/reverse-portal/docker-compose.yml`: тоже → **`teddysun/xray:26.4.25`** (бэкап `.bak-26.7.28`). Образ 21.6MB Pull, контейнер пересоздан (amd64).
+- Portal `config.json` → `loglevel: debug` (на время диагностики).
+- Локальные копии на Mac для правки: `~/xray-test/` (`docker-compose.bridge.yml`, `docker-compose.portal.yml`, `portal.config.json`, `config.json` — тестовый xray-клиент vpn.mallexxx).
+- После смены версий bridge перезапускался для переустановки канала к новому portal.
+
+### Результат end-to-end (обе стороны 26.4.25)
+- Reverse-канал у bridge **есть**: `dialing TCP → tunneling → received request for udp:reverse:0`. Portal принимает (`received request for tcp:v1.rvs.cool:0 → dispatching to udp:reverse:0`).
+- **Payload НЕ проходит**: `curl` через `xray-reverse-portal:12345` → `Empty reply from server` / `exit=52`.
+- **Portal debug (ключевое):** `taking detour [reverse-out] for [tcp:api.ipify.org:80]` → **и ничего дальше** (ни dial, ни ошибки). Dispatch в reverse-out молча глотается. Фоново: `common/mux: failed to read metadata ... connection reset by peer` (:12346).
+- **На TrueNAS НЕТ постоянного ESTABLISHED TCP на :12346** от bridge (`ss -tn sport=:12346` пусто) → reverse-канал **не удерживается постоянным** (только эфемерные контрольные прочёты), data-stream до bridge не доходит. Bridge никогда не логирует приём reverse-in TCP-payload.
+
+### Итог
+Проблема **НЕ** регрессия bridge-v26.5+ (#6242) — downgrade до заведомо рабочей пары 26.4.25↔26.4.25 не помог. **Настоящая причина лежит глубже:** VLESS Reverse sub-protocol нестабилен (предупреждение PR #5101) и между разнесёнными docker-реализациями (Kraken arm64 ↔ TrueNAS amd64) reverse-канал не удерживается постоянным на TCP-уровне → портал не может передать данные в bridge.
+
+### Нереализованные гипотезы (на будущее, треб.WB)
+1. Убрать REALITY/camouflage с канала TrueNAS↔Kraken (это внутренний обмен между сервисами, не извне) — оставить чистый VLESS-TCP/простой шифр, исключив REALITY-handshake как источник нестабильного mux.
+2. Аудит конфига bridge — что именно заставляет xray НЕ держать постоянный единственный канал (в reverse bridge обычно держит persistent-соединение).
+3. При необходимости консультация/живой разбор рабочего egress-конфига (канон доки не дал полного рабочего варианта).
+
+### ⚠️ Текущее состояние системы (2026-09-02)
+- **Версии:** portal + bridge сейчас **обе на `teddysun/xray:26.4.25`** (исходно `:latest`=26.7.28). Откат: вернуть в compose образ `teddysun/xray:latest` → `docker compose up -d`.
+- Bridge config содержит фикс #6612 (`finalRules:allow`). Portal config на `loglevel: debug`.
+- `vpn.mallexxx` / `xray-admin` (3x-ui) / Caddy — НЕ тронуты, работают (рабочий Xray-VPN через TrueNAS, end-to-end проверен 2026-09-02).
+- **Reverse к Kraken НЕ внедрён/не работает end-to-end** — остаётся открытой задачей.
+
 ## Ограничения / риски
 
 - Кра́кен в NAT ⇒ только исходящие соединения; reverse-канал держит Kraken.

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

@@ -4,18 +4,27 @@ created: '2026-09-01'
 updated: '2026-09-02'
 type: tech
 namespace: personal
-tags: [xray, reverse, kraken, truenas, tunnel, networking]
+tags:
+  - xray
+  - reverse
+  - kraken
+  - truenas
+  - tunnel
+  - networking
 confidence: medium
 related:
-  - "[[family/how-to/vps-qentra]]"
+  - '[[family/how-to/vps-qentra]]'
-  - "[[family/how-to/truenas-infrastructure]]"
+  - '[[family/how-to/truenas-infrastructure]]'
-  - "[[family/how-to/kraken-access]]"
+  - '[[family/how-to/kraken-access]]'
-  - "[[family/how-to/rasputin-router]]"
+  - '[[family/how-to/rasputin-router]]'
+downgrade_to_26.4.25: >-
+  portal+bridge BOTH downgraded 2026-09-02 — payload still dead (корень глубже
+  #6242)
 ---
 
 # Xray Reverse Tunnel — Kraken ↔ TrueNAS
 
-> **Статус: КОРНЕВАЯ ПРИЧИНА НАЙДЕНА + ФИКС #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`.
+> **Статус: НЕ ВНЕДРЕНО (2026-09-02, финал сессии аудита).** Reverse TrueNAS↔Kraken по-прежнему НЕ работает end-to-end. **Выполнен полный downgrade обеих сторон (portal+bridge) до Xray 26.4.25 — это НЕ помогло**: payload по-прежнему мёртв (`Empty reply`/exit 52). ✅ 3x-ui (`vpn.mallexxx`) жив и работает (рабочий Xray-VPN через TrueNAS). ✅ Kraken восстановлен (диск/docker/контейнеры). ⛔ **Остаётся открытым**: reverse-канал portal↔bridge не удерживается постоянным (нет ESTABLISHED :12346), dispatch портала в reverse-out теряется. Подробности+гипотезы: см. секцию «❌ ФАКТИЧЕСКИЙ РЕЗУЛЬТАТ 2026-09-02» ниже. Не трогать `vpn.mallexxx`.
 > Архитектурное решение: проксировать исходящий трафик локальных клиентов сети TrueNAS через **TrueNAS → Kraken → интернет**.
 
 > ## ✅ ВАЖНО (2026-09-02): `xray-admin` (3x-ui) на TrueNAS — это ОДНОВРЕМЕННО РАБОЧИЙ САМОСТОЯТЕЛЬНЫЙ Xray-VPN-сервер
@@ -242,6 +251,43 @@ docker run --rm --network caddy_default curlimages/curl:latest curl -sv --socks5
 3. reverse-туннель TrueNAS↔Kraken (portal `xray-reverse-portal` + bridge на Kraken) — это про проксирование egress ЛОКАЛЬНЫХ клиентов сети TrueNAS через Kraken. НЕ связан с vpn.mallexxx.
 
 
+## ❌ ФАКТИЧЕСКИЙ РЕЗУЛЬТАТ 2026-09-02: downgrade НЕ помог
+
+> ⚠️ ВАЖНО: вопреки секции «ИСТИННЫЙ КОРЕНЬ #6242» выше (которая была гипотезой, ещё не проверенной полностью), **полный downgrade обеих сторон до Xray 26.4.25 payload НЕ починил**. Это зафиксировано здесь как фактический итог.
+
+### Что было сделано (выполнено по факту, alive-диагностика)
+По согласованию с Alex (не трогая `vpn.mallexxx` / `xray-admin`) выполнено:
+1. Bridge (Kraken): `/home/kraken/xray-reverse/docker-compose.yml` → образ **`teddysun/xray:26.4.25`**. Docker Pull прошёл, контейнер на 26.4.25 (`Xray 26.4.25 ... go1.26.2 linux/arm64`). Бэкап: `docker-compose.yml.bak-26.7.28`.
+2. Portal (TrueNAS): `/mnt/RED_2TB/docker/reverse-portal/docker-compose.yml` → тоже **`teddysun/xray:26.4.25`** (Linux amd64, образ 21.59MB Pull). Бэкап: `docker-compose.yml.bak-26.7.28`. Контейнер `xray-reverse-portal` пересоздан.
+3. Portal `config.json` `loglevel` поднят на `debug` (для диагностики), залит в `/mnt/RED_2TB/docker/reverse-portal/config.json`.
+4. Локальные копии файлов на Mac (для правки): `~/xray-test/` → `docker-compose.bridge.yml`, `docker-compose.portal.yml`, `portal.config.json`, `config.json` (тестовый клиент vpn.mallexxx, удалить не нужно).
+5. После смены версии bridge перезапущен (для переустановки reverse-канала к новому portal).
+
+### Результат end-to-end теста (обе стороны 26.4.25)
+- Reverse-канал у bridge **устанавливается**: лог `dialing TCP to mallexxx.duckdns.org:12346` → `tunneling request to unknown` → `received request for udp:reverse:0`. Portal принимает (лог: `proxy/vless/inbound: received request for tcp:v1.rvs.cool:0` → `dispatching request to udp:reverse:0`).
+- **НО payload по-прежнему НЕ проходит**: тест curl через `xray-reverse-portal:12345` → `Empty reply from server` / `exit=52`.
+- **Portal (TrueNAS) debug-лог полностью проясняет картину:**
+  - При запросе: `[118463829] proxy/socks: TCP Connect request to tcp:api.ipify.org:80` → `[118463829] app/dispatcher: taking detour [reverse-out] for [tcp:api.ipify.org:80]` — **и НИЧЕГО дальше** (ни ошибки, ни dial к bridge). Dispatch в `reverse-out` молча глотается.
+  - Фоновые разрывы: `common/mux: failed to read metadata > read tcp 172.16.1.7:12346->92.62.70.41:3266: connection reset by peer` — portal пытается что-то слать к bridge, но канал рвётся.
+- **Критично:** на TrueNAS **НЕТ постоянного ESTABLISHED TCP-соединения от bridge на :12346** (`ss -tn sport=:12346` пусто). Reverse-канал НЕ держится постоянным — устанавливается эфемерно (per контрольный UDP прочёт), и data-stream по нему не доходит до bridge.
+- Bridge (Kraken) никогда не логирует приём `reverse-in` TCP-payload (только контрольный `udp:reverse:0`).
+
+### Вывод
+Проблема **НЕ** регрессия #6242 фиксируемая версией bridge — иначе downgrade до рабочей по issue пары 26.4.25↔26.4.25 решил бы. После полного downgrade payload по-прежнему мёртв. **Настоящая причина: reverse-канал portal↔bridge не удерживается постоянным на TCP-уровне** (нет стабильного ESTABLISHED :12346), поэтому dispatch портала в `reverse-out` не находит живой транспорт до bridge и молча теряет данные.
+
+Это согласуется с предупреждением PR #5101: **новый VLESS Reverse sub-protocol itself нестабилен** («will break, кросс-версий совместимость не гарантирована») — по-видимому канал между двумя разнесёнными docker-реализациями (Kraken arm64 ↔ TrueNAS amd64, обе 26.4.25) не держится стабильно.
+
+### Дальнейшие гипотезы (НЕ проверены, треб.WB)
+1. Транспортный REALITY mismatch arm64(26.4.25 bridge) ↔ amd64(26.4.25 portal) даёт нестабильный mux → попробовать не-REALITY (простой TCP, т.к. канал только между сервисами TrueNAS↔Kraken, не извне) — убрать REALITY, оставить VLESS-TCP без camouflage.
+2. Перепроверить, что bridge реально удерживает единственное mux-соединение (в xray reverse bridge обычно держит persistent канал, у нас его нет → пере-аудит конфиг bridge: возможно не хватает чего-то, заставляющего держать канал постоянно).
+3. Запросить консультацию/повторно изучить рабочую конфигурацию сбора из живого разбора темы (потому что каноничные примеры из доки и issues не дали полного рабочего egress-конфига).
+
+### ⚠️ ТЕКУЩЕЕ СОСТОЯНИЕ СИСТЕМ (на момент записи, 2026-09-02)
+- **Версии:** BOTH portal и bridge сейчас на **`teddysun/xray:26.4.25`** (исходно были на `:latest` = 26.7.28). Откат при необходимости: поменять образ в compose обратно на `teddysun/xray:latest` и `docker compose up -d`.
+- Конфиг portal имеет `loglevel: debug` (пока). Bridge `config.json` содержит фикс #6612 `finalRules:allow`.
+- `vpn.mallexxx.duckdns.org` / `xray-admin` / Caddy — **НЕ тронуты**, работают (см. секцию «ВАЖНО 2026-09-02»).
+- Reverse к Kraken **НЕ внедрён/не работает end-to-end** — это остаётся открытой задачей.
+
 ## ⏳ Открытые вопросы по reverse (требуют ответа/действия Alex)
 
 ## План реализации (история; Шаг 1 устарел — см. «ВНЕДРЕНО» выше)