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

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

Browse Source
This commit is contained in:
Alexey Martemyanov
2026-09-01 14:02:46 +06:00
parent 63130e117d
commit 150407d50d
2 changed files with 65 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
family/plans/reverse-xray-3xui-kraken.md
+21 -9
View File
@@ -157,14 +157,26 @@ WS-вариант reverse НЕ пропускал payload (curl через SOCKS
- Результат: **по-прежнему `code=000`**. Reverse-канал устанавливается (`udp:reverse:0`), TCP-payload до bridge не доходит.
- **Вывод: проблема НЕ в `flow` и НЕ в WS-транспорте — даже на «каноничном» TCP+REALITY payload между portal-reverse-out и bridge-reverse-in не передаётся.** Ранее выдвинутая гипотеза (WS не пропускает reverse-payload) **опровергнута** переходом на TCP.
### 💡 Обновлённая гипотеза (непроверенная)
Reverse-канал (mux `udp:reverse:0`) стабильно НЕ доставляет инициированный portal'ом inbound TCP-payload (из outbound `reverse-out`). Возможные пути решения, НЕ испробованные:
- Включить `sniffing` (http/tls/quic) на portal inbound `local` (для доменов) — routing по домену в reverse-out.
- Проверить, что свободе на portal нужен как placeholder («freedom outbound must remain, otherwise reverse-out becomes default») — НО это про обратное; тут reverse-out ВЫБРАН явно в routing.
- Возможно, для этой версии reverse требует, чтобы на portal входящий от bridge VLESS был НЕ same как клиент с reverse tag — либо VLESS reverse не пробрасывает произвольный inbound SOCKS-трафик.
- Альтернатива: Kraken тянет свой Xray-SOCKS, а TrueNAS ходит на него обычным VLESS-клиентом (простой исходящий прокси, БЕЗ reverse) — reverse может быть избыточен/несовместим здесь.
### 🔑 КОРЕНЬ ПРОБЛЕМЫ НАЙДЕН (2026-09-01, интернет-поиск) — issue XTLS/Xray-core #6612
**Симптомы точно совпадают с #6612:** канал reverse устанавливается (`udp:reverse:0`), но TCP-payload не проходит; portal логирует `accepted tcp:... -> reverse-out`, bridge НЕ получает входящих reverse-in; curl → 000.
**Причина:** с **Xray v26.5+** у outbound `freedom`/`direct` дефолтная политика безопасности **блокирует VLESS Reverse payload**, пока не задан явный `finalRules`. Reverse-канал при этом живёт — «выглядит подключено», но payload молча дропается.
**Фикс (bridge, место egress reverse-in→интернет):**
```json
{ "protocol": "freedom", "tag": "direct",
"settings": { "domainStrategy": "AsIs", "finalRules": [ { "action": "allow" } ] } }
```
**Ссылки:** #6612 (фикс), #6027 (корень — finalRules у Direct), docs freedom, 3x-ui #4782, #2664 (flow vision на bridge+REALITY), #6242/#6195/#6248 (регресс роутинга reverse v26.5+, кварк = пин v26.4.25).
**Проверено из поиска:** placeholder-freedom на portal нужен (есть); routing `reverse-in→direct` на bridge нужен (есть); у VLESS outbound поле `encryption` обязательно `"none"` (есть).
**Статус: задание НЕ завершено — end-to-end через reverse НЕ работает. Следующая сессия: продолжить с обновлённой гипотезы (sniffing / пересмотр роли reverse для исходящего прокси клиентов сети TrueNAS).**
### ✅ ФИКС ПРИМЕНЁН, но заблокирован (2026-09-01)
Новый bridge-конфиг с `finalRules:[{action:"allow"}]` в `direct` **залит** на Kraken (`/home/kraken/xray-reverse/config.json`, 1098 байт). **НО Kraken по docker НЕДОСТУПЕН:**
- `systemctl is-active docker` → **`activating`** (не `active`), накопились зависшие docker-процессы (ps/run/compose).
- **USB-HDD снова не поднялся:** `lsblk /dev/sda` → **`0B`** (без раздела). Docker data-root `/srv/dev-disk-by-uuid-49e8f586-3839-4c5d-a1e1-58bfc3579ade/docker-data` (на HDD) → daemon ждёт диск, застревает.
- ⚠️ **Расхождение UUID:** data-root сейчас `/srv/dev-disk-by-uuid-49e8f586-...`, ранее в доке фигурировал `6194539b...` (sda1 1.8T). Сейчас `sda`=0B без раздела.
- **`docker compose down/up` для bridge не выполнен** — контейнер всё ещё со старым конфигом.
**Шаг продолжения (нужно подтверждение Alex):** починить HDD/docker на Kraken (reboot или физ. переподключение USB), `cd /home/kraken/xray-reverse && docker compose up -d`, тест `curl --socks5 127.0.0.1:12345 http://api.ipify.org` на TrueNAS → ожидаем IP Kraken.
**Статус: задание НЕ завершено — остаётся применить bridge-фикс после восстановления docker на Kraken.**
### ⚠️ Kraken status — диск/докер были нестабильны
- Несколько `System is booting up` (pam_nologin) — Kraken перезагружался из-за USB-диска в цикле enumeration (`device descriptor read/64 error -110`, `device not accepting address error -62`, `[sda] Read Capacity(10) failed`, `0 B`).
@@ -227,8 +239,8 @@ reverse_proxy @rvs xray-reverse-portal:12346
4. ✅ Проверено: панель `https://vpn-panel.mallexxx.duckdns.org/` → HTTP 200, inbound vless-ws:10095 активен.
5. ✅ Создан portal-контейнер `xray-reverse-portal` на TrueNAS (interconn :12346 + SOCKS `local`:12345) + Caddy маршрут `/rvs`. [Затем: переведён на TCP+REALITY, см. секции «Reverse деплой».]
6. ✅ Создан bridge-контейнер `xray-reverse-bridge` на Kraken (→ TrueNAS, egress direct). Reverse-канал установлен. [Затем: переведён на TCP+REALITY.]
7. ❌ **End-to-end НЕ работает** (curl через SOCKS 12345 → 000). Проверено на WS И на TCP+REALITY (flow и без flow) — payload от portal-reverse-out до bridge-reverse-in **не передаётся** (bridge не логирует приход TCP). Гипотеза про WS опровергнута. **Статус: задание НЕ завершено — продолжить со sniffing / пересмотром роли reverse (см. «Обновлённая гипотеза»).**
8. ⏳ Обновить Obsidian: truenas-infrastructure.md, kraken-access.md, vps-qentra.md. **TODO для следующей сессии.**
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 с корнем/фиксом.)
## Ограничения / риски
personal/tech/xray-reverse-tunnel-kraken-truenas.md
+44 -8
View File
@@ -15,7 +15,7 @@ related:
# Xray Reverse Tunnel — Kraken ↔ TrueNAS
> **Статус: ЧАСТИЧНО ВНЕДРЕН, end-to-end НЕ РАБОТАЕТ (2026-09-01).** ✅ 3x-ui развёрнут и работает. ✅ reverse portal (TrueNAS) + bridge (Kraken) развёрнуты на **прямом TCP+REALITY**, reverse-канал установлен. ⛔ **End-to-end payload НЕ проходит** (curl 000) — проверено на WS И на TCP+REALITY (и с flow `xtls-rprx-vision`, и без flow). Гипотеза «WS блокирует payload» **опровергнута**. OpenWrt DNAT + порт 12346 проброшены. Задание НЕ завершено.
> **Статус: КОРНЕВАЯ ПРИЧИНА НАЙДЕНА + ФИКС ПРИМЕНЁН, но блокируется недоступностью 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.
> Архитектурное решение: проксировать исходящий трафик локальных клиентов сети TrueNAS через **TrueNAS → Kraken → интернет**.
## Контекст / Почему
@@ -147,13 +147,49 @@ WS-транспорт не пропускал reverse-payload; переведё
**Вывод:** проблема НЕ в `flow` и НЕ в WS. **Даже на «каноничном» TCP+REALITY payload от portal-reverse-out до bridge-reverse-in не передаётся** (bridge не получает inbound-TCP). Гипотеза про WS **опровергнута**.
### 💡 Обновлённая гипотеза (непроверенная)
Reverse-канал (mux `udp:reverse:0`) НЕ доставляет инициированный portal'ом inbound TCP-payload из outbound `reverse-out`. НЕ испробовано:
- `sniffing` (http/tls/quic) на portal inbound `local` (routing по домену в reverse-out).
- Возможно, в Xray 26.x reverse не пробрасывает произвольный inbound SOCKS-трафик от portal в bridge корректно.
- Альтернатива: Kraken тянет `xray`-SOCKS, TrueNAS ходит на него **обычным VLESS-клиентом (без reverse)** — простой исходящий прокси, reverse может быть избыточен.
### 🔑 КОРЕНЬ ПРОБЛЕМЫ НАЙДЕН (2026-09-01, интернет-поиск) — issue XTLS/Xray-core #6612
**Статус: задание НЕ завершено — продолжить со sniffing / пересмотром роли reverse в следующей сессии.**
**Симптомы точно совпадают с #6612:** reverse-канал устанавливается (`udp:reverse:0` на месте), но TCP-payload не проходит; portal логирует `accepted tcp:... -> reverse-out`, а bridge НЕ получает входящих reverse-in-соединений; curl → 000.
**Причина:** начиная с **Xray v26.5+** (PR #6027) у outbound `freedom`/`direct` появилась **дефолтная политика безопасности**, которая **блокирует ВСЕ цели для трафика VLESS Reverse**, если не задан явный `finalRules`. Контрольный reverse-канал при этом продолжает устанавливаться — поэтому «всё выглядит подключённым», но реальный payload молча отбрасывается. Это ровно наш случай на версии **26.7.28**.
**Точный фикс** — добавить в freedom `direct` на **BRIDGE** (место реального egress из reverse-in в интернет):
```json
{
"protocol": "freedom",
"tag": "direct",
"settings": {
"domainStrategy": "AsIs",
"finalRules": [ { "action": "allow" } ]
}
}
```
Issue говорит прямо: проблема воспроизводится с обычным Freedom без finalRules вообще, и добавление безусловного `allow` чинит на 26.7.28.
**Релевантные ссылки:**
- **#6612** — главный фикс: `https://github.com/XTLS/Xray-core/issues/6612`
- **#6027** — корень (finalRules у Direct/Freedom): `https://github.com/XTLS/Xray-core/pull/6027`
- Документация freedom: `https://xtls.github.io/en/config/outbounds/freedom.html`
- 3x-ui разбор под reverse: `https://github.com/MHSanaei/3x-ui/issues/4782`
- **#2664** — если finalRules не поможет: `flow: xtls-rprx-vision` на BRIDGE-outbound + REALITY может ломать доставку (держите `flow:""` на reverse-клиенте): `https://github.com/XTLS/Xray-core/issues/2664`
- **Регрессия роутинга reverse v26.5+** (если фикс не поможет): #6242, #6195, #6248 — временный кварк: пинить **v26.4.25**.
**Важные детали из поиска (проверить при продолжении):**
- Портал ДОЛЖЕН иметь placeholder-freedom (у нас есть) — иначе reverse-out станет default. Плейсхолдеру не нужен `finalRules:allow` (он обслуживает только несопоставленный трафик).
- Роутинг `inboundTag:["reverse-in"] -> direct` на bridge — нужен (у нас есть).
- У VLESS outbound поле `encryption` обязательно (`"none"` или парный PQ-ключ к серверному `decryption`) — у нас `"none"`, ок.
### ✅ ФИКС ПРИМЕНЁН, но заблокирован (2026-09-01)
Новый bridge-конфиг с `finalRules:[{action:"allow"}]` в `direct` **залит** на Kraken (`/home/kraken/xray-reverse/config.json`, 1098 байт, проверено `cat | head -5`). НО:
- ⛔ **Kraken по docker НЕДОСТУПЕН**: `systemctl is-active docker` → **`activating`** (не `active`), демон застрял, накоплено множество зависших docker-процессов (ps/run/compose).
- **Причина: USB-HDD снова не поднялся** — `lsblk /dev/sda` → **`0B`** (без раздела). Docker data-root = `/srv/dev-disk-by-uuid-49e8f586-3839-4c5d-a1e1-58bfc3579ade/docker-data` (на этом HDD) → daemon ждёт диск и застревает.
- ⚠️ **Замечено расхождение UUID**: сейчас data-root указывает на `/srv/dev-disk-by-uuid-49e8f586-...`, а в контексте ранее фигурировал смонтированный HDD `/srv/dev-disk-by-uuid-6194539b-...` (sda1 1.8T). Текущий `sda` = 0B без раздела.
- **`docker compose down/up` для bridge не выполнен** — контейнер всё ещё со старым конфигом (больше не деплоится, daemon не отвечает).
**Шаг для продолжения (требует подтверждения Alex):** починить HDD/docker на Kraken (повторить утренний сценарий: `sudo reboot` или физическое переподключение USB-диска), затем пересоздать bridge-контейнер (`cd /home/kraken/xray-reverse && docker compose down && docker compose up -d`), затем тест `curl --socks5 127.0.0.1:12345 http://api.ipify.org` на TrueNAS → ожидаем выход с IP Kraken.
**Статус: задание НЕ завершено — остаётся применить bridge-фикс после восстановления docker на Kraken.**
## ⏳ Открытые вопросы по reverse (требуют ответа/действия Alex)
@@ -189,7 +225,7 @@ Reverse-канал (mux `udp:reverse:0`) НЕ доставляет иниции
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 не проходит** — блокер. WS-вариант не пропускал payload; переведён на TCP+REALITY (ВЫПОЛНЕНО: portal пересоздан, OpenWrt DNAT + порт 12346 проброшен, bridge пересоздан). **НО payload всё равно не проходит** (`code=000`) даже на TCP+REALITY, с flow и без flow (`Configuration OK`). См. секции «ВНЕДРЕНО — TCP+REALITY» и «Обновлённая гипотеза» выше. Задание не завершено.
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.
## Связанные заметки
- [[family/how-to/vps-qentra]] — VPS на 2026-09-01 УДАЛЁН