git_admin/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Alexey Martemyanov
2026-09-02 11:20:13 +06:00
parent 1c4d9bffd5
commit fd3578dd8e
2 changed files with 49 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
family/how-to/truenas-infrastructure.md
+1 -1
View File
@@ -239,7 +239,7 @@ arr, caddy, cups, filebrowser, gitea, hermes, immich, inpx-web, inpxer, library,
| local | `:12345` SOCKS (точка входа для клиентов сети TrueNAS), проброс `12345:12345` |
| Env | `LOGLEVEL` |
**⚠️ Текущее состояние reverse (2026-09-01):** WS-вариант не пропускал payload → решено перевести на **прямой TCP+REALITY**. REALITY-ключи: server PrivateKey `0JTjeirfviDqCr63wSnisvU7DV6SpR9_9V2l_EUHmkk`, PublicKey `GhsphQLT_0fwOvK45MHeAgG3sBQsFtw7lQfUIbrLMQU`, shortId `1451ef281caf5905`, SNI `www.cloudflare.com`. **НЕ ЗАВЕРШЕНО:** конфиги готовы и валидны, осталось пересоздать portal (stop/rm/up) + OpenWrt DNAT `внешний:12346 → 192.168.2.197:12346` + пересоздать bridge на Kraken. См. план-заметку [[family/plans/reverse-xray-3xui-kraken]].
**✅ Reverse внедрён на TCP+REALITY (2026-09-01 выполнен) + ИСТИННЫЙ КОРЕНЬ НАЙДЕН 2026-09-02.** Portal пересоздан на TCP+REALITY (`12346:12346`), OpenWrt DNAT `внешний:12346 → 192.168.2.197:12346` добавлен, bridge на Kraken пересоздан. REALITY-ключи: server PrivateKey `0JTjeirfviDqCr63wSnisvU7DV6SpR9_9V2l_EUHmkk`, PublicKey `GhsphQLT_0fwOvK45MHeAgG3sBQsFtw7lQfUIbrLMQU`, shortId `1451ef281caf5905`, SNI `www.cloudflare.com`. **НЕ ВНЕДРЕНО (ждёт команды):** payload по-прежнему не проходит даже с фиксом #6612 → истинный корень [issue #6242](https://github.com/XTLS/Xray-core/issues/6242) (регрессия bridge в v26.5+, у нас 26.7.28). Решение: сдаунгрейд bridge до `teddysun/xray:26.4.25`. Детали: [[personal/tech/xray-reverse-tunnel-kraken-truenas]].
### Home Assistant — детали
personal/tech/xray-reverse-tunnel-kraken-truenas.md
+48 -4
View File
@@ -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 УДАЛЁН