[2026-09-02] eagle: personal/tech/xray-reverse-tunnel-kraken-truenas.md personal/tech/xray-reverse-tunnel-kraken-truenas.md.bak-20260902-1154

This commit is contained in:
Alexey Martemyanov
2026-09-02 12:00:28 +06:00
parent f81a405b85
commit 1090fc66bc
2 changed files with 395 additions and 7 deletions
@@ -11,20 +11,22 @@ tags:
- truenas
- tunnel
- networking
confidence: medium
confidence: high
related:
- '[[family/how-to/vps-qentra]]'
- '[[family/how-to/truenas-infrastructure]]'
- '[[family/how-to/kraken-access]]'
- '[[family/how-to/rasputin-router]]'
downgrade_to_26.4.25: >-
portal+bridge BOTH downgraded 2026-09-02 — payload still dead (корень глубже
#6242)
portal+bridge BOTH pinned to 26.4.25; required but insufficient by itself.
verified_fix_2026_09_02: >-
Kraken bridge must use Docker network_mode: host; Docker bridge/NAT reset the
VLESS reverse mux. REALITY+Vision verified end-to-end with Kraken egress.
---
# Xray Reverse Tunnel — Kraken ↔ TrueNAS
> **Статус: НЕ ВНЕДРЕНО (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`.
> **Статус: ВНЕДРЕНО И ПРОВЕРЕНО END-TO-END (2026-09-02).** TrueNAS SOCKS `:12345` → VLESS Reverse TCP+REALITY+Vision → Kraken → internet работает. HTTP и HTTPS тесты оба вернули выходной IP Kraken `92.62.70.41`. **Истинная причина:** Docker bridge/NAT на Kraken сбрасывал reverse mux; bridge должен работать с `network_mode: host`. Более ранние секции со статусом «не работает» и гипотезами #6612/#6242 сохранены ниже как история диагностики и суперсидированы секцией «Верифицированный фикс».
> Архитектурное решение: проксировать исходящий трафик локальных клиентов сети TrueNAS через **TrueNAS → Kraken → интернет**.
> ## ✅ ВАЖНО (2026-09-02): `xray-admin` (3x-ui) на TrueNAS — это ОДНОВРЕМЕННО РАБОЧИЙ САМОСТОЯТЕЛЬНЫЙ Xray-VPN-сервер
@@ -32,7 +34,7 @@ downgrade_to_26.4.25: >-
> - **Проверено end-to-end 2026-09-02** (временный xray-клиент с Mac): VLESS+WS через `vpn.mallexxx.duckdns.org:443` → HTTP 200, выход IP `90.189.160.148` = TrueNAS. Контейнеры `xray-admin` (Up 21h) + `caddy` (Up 20h) живы.
> - Inbound `in-10095-tcp` (VLESS-WS): client id `ce320965-6956-4759-84bb-7cb71cfc6252` (user1), `security: none`, path `/vless`, host `vpn.mallexxx.duckdns.org`. TLS терминирует Caddy → в клиенте `network: ws` + TLS на домен, **без** двойного TLS внутрь.
> - Полные параметры и pitfalls (вкл. удаление `allowInsecure` в Xray 26.7.28) — в `family/how-to/truenas-infrastructure.md`, раздел `xray-admin`.
> - То есть reverse к Kraken — это ОТДЕЛЬНЫЙ механизм (для проксирования локальных клиентов сети TrueNAS через Kraken-egress); он по-прежнему НЕ внедрён. Сам по себе 3x-ui-сервер уже даёт рабочий VPN-выход через TrueNAS.
> - Reverse к Kraken — это ОТДЕЛЬНЫЙ механизм (для проксирования локальных клиентов сети TrueNAS через Kraken-egress). Он теперь также внедрён и проверен; см. «Верифицированный фикс». 3x-ui-сервер остаётся независимым рабочим VPN-выходом через TrueNAS.
## Контекст / Почему
@@ -251,7 +253,7 @@ 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 НЕ помог
## ❌ ИСТОРИЯ ДИАГНОСТИКИ 2026-09-02: downgrade сам по себе не помог
> ⚠️ ВАЖНО: вопреки секции «ИСТИННЫЙ КОРЕНЬ #6242» выше (которая была гипотезой, ещё не проверенной полностью), **полный downgrade обеих сторон до Xray 26.4.25 payload НЕ починил**. Это зафиксировано здесь как фактический итог.
@@ -322,7 +324,61 @@ docker run --rm --network caddy_default curlimages/curl:latest curl -sv --socks5
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-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» ниже.
4. **End-to-end payload проходит.** #6612/#6242 оказались неполными гипотезами. Верифицированный корень — Docker bridge/NAT на Kraken; решение — Xray 26.4.25 + `network_mode: host` на bridge. См. authoritative-секцию ниже.
## ✅ Верифицированный фикс 2026-09-02 (authoritative)
> Эта секция суперсидирует все более ранние выводы «payload мёртв», «нет persistent ESTABLISHED» и предполагаемые корни #6612/#6242. Фикс найден и проверен живыми A/B-тестами.
### Истинная причина
`xray-reverse-bridge` на Kraken работал в обычной Docker bridge-сети. Docker bridge/NAT на этом узле сбрасывал long-lived VLESS reverse mux после успешной регистрации `udp:reverse:0`. Поэтому portal создавал `reverse-out`, но payload не доходил до `reverse-in`.
Ключевой A/B-тест:
1. Тот же JSON на temporary bridge amd64 внутри TrueNAS заработал сразу → portal/config/routing исправны.
2. Тот же Xray 26.4.25 arm64 + тот же JSON на Kraken в `--network host` заработал сразу → CPU architecture и WAN исправны, отличие только в Docker network mode.
3. После возврата REALITY+Vision туннель остался рабочим → проблема не в REALITY, Vision или TCP transport.
### Постоянная конфигурация
Kraken: `/home/kraken/xray-reverse/docker-compose.yml`
```yaml
services:
xray-reverse-bridge:
image: teddysun/xray:26.4.25
network_mode: host
```
Bridge config возвращён к защищённому VLESS TCP + REALITY + `flow: xtls-rprx-vision`. `direct` сохраняет `finalRules: [{"action":"allow"}]`. Portal на TrueNAS также на `teddysun/xray:26.4.25`, REALITY+Vision. `xray-admin`, Caddy и `vpn.mallexxx.duckdns.org` не менялись.
`network_mode: host` расширяет сетевые права bridge-контейнера. В этом конфиге у него нет физических listening inbounds; `reverse-in` — виртуальный inbound Xray. Не добавлять в этот контейнер обычные inbounds без аудита bind address/firewall.
### Финальная проверка
2026-09-02 после permanent Compose deploy:
- `docker inspect xray-reverse-bridge` → image `teddysun/xray:26.4.25`, network `host`, status `running`, restart count `0`.
- Bridge лог: `received request for udp:reverse:0`, затем TCP payload принят в `reverse-in -> direct`.
- HTTPS через SOCKS `xray-reverse-portal:12345``92.62.70.41`.
- HTTP через тот же SOCKS → `92.62.70.41`.
- `92.62.70.41` — публичный egress Kraken; TrueNAS egress `90.189.160.148` не использовался.
### Бэкапы и rollback
Kraken:
- `/home/kraken/xray-reverse/docker-compose.yml.bak-bridge-network-20260902-1147`
- `/home/kraken/xray-reverse/config.json.bak-plain-host-working-20260902-1146`
- `/home/kraken/xray-reverse/config.json.bak-reality-vision-20260902-1142`
TrueNAS:
- `/mnt/RED_2TB/docker/reverse-portal/config.json.bak-plain-host-working-20260902-1146`
- `/mnt/RED_2TB/docker/reverse-portal/config.json.bak-reality-vision-20260902-1142`
Rollback network fix: вернуть compose-бэкап на Kraken и выполнить `docker compose up -d`. Это вернёт нерабочий Docker bridge mode, поэтому делать только для диагностики/отката.
## Связанные заметки
- [[family/how-to/vps-qentra]] — VPS на 2026-09-01 УДАЛЁН