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

This commit is contained in:
Alexey Martemyanov
2026-09-01 13:42:39 +06:00
parent 3e6e66cde6
commit 63130e117d
4 changed files with 59 additions and 40 deletions
+16 -17
View File
@@ -2,16 +2,18 @@
> Обновлено: 2026-09-01
> Updated: 2026-09-01 23:00 — диск/докер кракена восстановились после перезагрузки.
## Как зайти
Везде `ssh kraken`. Резолвится через `~/.ssh/config` на Eagle:
- **Дома** — напрямую по LAN (`192.168.1.15`)
- **Снаружи** — ⚠️ через WireGuard (`10.99.1.2`) **БОЛЬШЕ НЕ РАБОТАЕТ**: VPS-узло (10.99.0.1/10.99.1.1) qentra.top **удалили 2026-09-01**. Пока нет альтернативы внешнему доступу к Kraken (см. [[tech/xray-reverse-tunnel-kraken-truenas]] — в процессе внедрения: 3x-ui на TrueNAS развёрнут, reverse-клиент на Kraken ещё нет).
- **Снаружи** — ⚠️ через WireGuard (`10.99.1.2`) **БОЛЬШЕ НЕ РАБОТАЕТ**: VPS-узло (10.99.0.1/10.99.1.1) qentra.top **удалили 2026-09-01**. Альтернатива внешнего доступа обсуждается через Xray reverse (см. [[tech/xray-reverse-tunnel-kraken-truenas]]).
> ⚠️ **Kraken Docker-демон нестабилен на 2026-09-01:** `docker ps` по SSH не завершается за ~40s (рвёт соединение). Проверять медленно; возможно нужен ремонт перед деплоем reverse-клиента Xray на Kraken.
> ⚠️ **Kraken-диск был нестабилен 2026-09-01**: USB-диск TOSHIBA в цикле enumeration (`device descriptor read/64 error -110`, `device not accepting address error -62`, `[sda] Read Capacity(10) failed` → `0 B`), Kraken перезагружался (`System is booting up / pam_nologin`). **После повторной перезагрузки диск зарегистрировался**: `sda` 1.8T, `sda1` смонтирован в `/srv/dev-disk-by-uuid-6194539b-...`. Docker стал `active`.
WireGuard split-tunnel: Eagle (10.99.0.2) ↔ VPS ↔ Kraken (10.99.1.2). Подробнее: [[wireguard-vpn]]. **⚠️ VPS-звено мертво на 2026-09-01.**
> ⚠️ **Kraken Docker на 2026-09-01:** Server 29.4.3, Docker Root Dir `/srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f/docker-data`. **30 образов сохранены, но 0 контейнеров** (all прежние контейнеры — jellyfin/transmission/radarr/hermes-kraken и т.д. — потеряны и НЕ пересозданы после сбоя; data-root на HDD был в цикле enumeration). При необходимости — пересоздать из образов.
## Portainer (локально)
@@ -28,26 +30,23 @@ EP=3 # endpoint ID на Кракене = 3, не 1!
`http://kraken:8642/v1/chat/completions` — OpenAI-compatible endpoint.
## Docker контейнеры (2026-06-24)
## Reverse Xray bridge (развёрнут 2026-09-01)
- Контейнер **`xray-reverse-bridge`** в `/home/kraken/xray-reverse/` (compose + `config.json`, образ `teddysun/xray:latest`, Xray 26.7.28 ARM64).
- Outbound VLESS+REALITY TCP → `mallexxx.duckdns.org:12346` (TrueNAS через OpenWrt DNAT), reverse tag `reverse-in`, egress freedom.
-**End-to-end payload НЕ работает** (bridge принимает reverse-канал, но данные от portal до bridge не доходят). Детали: [[tech/xray-reverse-tunnel-kraken-truenas]].
## Docker контейнеры (исторически было 2026-06-24; на 2026-09-01 НЕ восстановлены)
| Имя | Заметки |
|-----|---------|
| flaresolverr | |
| hermes-kraken | |
| homeassistant | |
| jellyfin | |
| portainer | |
| prowlarr | |
| radarr | |
| rclone | |
| sonarr | |
| transmission | |
| cloudflared | |
| watchtower | |
| xray-reverse-bridge | развёрнут 2026-09-01 (единственный активный) |
| flaresolverr / hermes-kraken / homeassistant / jellyfin / portainer / prowlarr / radarr / rclone / sonarr / transmission / cloudflared / watchtower | образы есть, контейнеры потеряны — пересоздать при необходимости |
## Связанные заметки
- [[kraken-network]] — SSH, WG топология
- [[wireguard-vpn]] — полное описание WG
- [[wireguard-vpn]] — полное описание WG (⚠️ VPS-звено мёртво на 2026-09-01)
- [[kraken-portainer-access]]
- [[openmediavault-rpi5]]
+2
View File
@@ -121,6 +121,8 @@ TrueNAS использует **NFSv4 ACL**, а не стандартный POSIX
| mbusd | 3cky/mbusd:latest | — | Modbus |
| modbus-bridge | modbus-bridge | — | — |
| cups-splix | cups-splix | — | принтер |
| xray-admin | ghcr.io/mhsanaei/3x-ui:latest | 2053 (панель), 10095 (vless-ws), 443 (sub) | vpn-panel.mallexxx.duckdns.org, vpn.mallexxx.duckdns.org |
| xray-reverse-portal | teddysun/xray:latest | 12345 (SOCKS), 12346 (VLESS-TCP REALITY interconn) | — (см. `personal/tech/xray-reverse-tunnel-kraken-truenas.md`) |
### cups-splix — принтер Samsung CLX-216x (✅ поднят 2026-08-26; ✅ mDNS-фикс 2026-08-31 завершён)
+23 -8
View File
@@ -145,11 +145,26 @@ WS-вариант reverse НЕ пропускал payload (curl через SOCKS
- ✅ Бэкап firewall OpenWrt: `/mnt/RED_2TB/docker/backups/openwrt-firewall-20260901-130558.txt` (212 строк).
- Порт-форвардинг: `uci add firewall redirect` ... `src_dport``dest_ip=192.168.2.197` `dest_port` `target=DNAT`; `/etc/init.d/firewall reload`.
### ⛔ НЕ ЗАВЕРШЕНО (стоп на одобрение lifecycle-операции)
1. Пересоздать `xray-reverse-portal` на TrueNAS (compose+config REALITY) → `docker compose stop/rm/up` (одобрение истекло).
2. OpenWrt DNAT: redirect `внешний:12346 → 192.168.2.197:12346`.
3. Пересоздать `xray-reverse-bridge` на Kraken (REALITY config).
4. Тест: `curl --socks5 <TrueNAS>:12345 https://api.ipify.org` → ожидать IP Kraken `92.62.70.41`.
### ✅ ВНЕДРЕНО (2026-09-01, после согласия Alex) — TCP+REALITY переход выполнен
Все 4 шага перехода на TCP+REALITY **ВЫПОЛНЕНЫ**:
1. ✅ Пересоздан `xray-reverse-portal` на TrueNAS (compose `12345:12345` + `12346:12346`, config REALITY TCP). Проверено: `ss -tlnp``0.0.0.0:12346 LISTEN`.
2. ✅ OpenWrt DNAT добавлен: redirect `xray-reverse-12346`, `src_dport=12346``dest_ip=192.168.2.197:12346`, `target=DNAT`, `/etc/init.d/firewall reload``DNAT_ADDED`. Проверено: `mallexxx.duckdns.org:12346`**OPEN** извне.
3. ✅ Пересоздан `xray-reverse-bridge` на Kraken (config REALITY TCP). Reverse-канал снова ESTABLISHED: Kraken `172.24.0.2 → 90.189.160.148:12346 ESTABLISHED` + лог `common/mux: received request for udp:reverse:0`.
4.**Тест payload НЕ прошёл даже на TCP+REALITY**: `curl --socks5 127.0.0.1:12345 http://api.ipify.org` на TrueNAS → **всё ещё `code=000`** (прямой curl → 200). Portal: `accepted tcp:8.6.112.0:80 [local -> reverse-out]`, но bridge НЕ логирует приход TCP-payload (`no accepted/received` в `reverse-in`).
### ❌ Дополнительно пробовано: снятие `flow: xtls-rprx-vision`
- Убрал `flow: xtls-rprx-vision` с обеих сторон (portal interconn client + bridge conn outbound), пересоздал оба контейнера (оба `Configuration OK`).
- Результат: **по-прежнему `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 может быть избыточен/несовместим здесь.
**Статус: задание НЕ завершено — end-to-end через reverse НЕ работает. Следующая сессия: продолжить с обновлённой гипотезы (sniffing / пересмотр роли reverse для исходящего прокси клиентов сети TrueNAS).**
### ⚠️ 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`).
@@ -210,9 +225,9 @@ reverse_proxy @rvs xray-reverse-portal:12346
2. ✅ Создан `/mnt/RED_2TB/docker/xray-admin/docker-compose.yml` (deployed версия — см. «Фактически развёрнутый compose»).
3. ✅ Поднят `docker compose up -d` → контейнер Up.
4. ✅ Проверено: панель `https://vpn-panel.mallexxx.duckdns.org/` → HTTP 200, inbound vless-ws:10095 активен.
5. ✅ Создан portal-контейнер `xray-reverse-portal` на TrueNAS (VLESS-WS `interconn`:12346 + SOCKS `local`:12345) + Caddy маршрут `/rvs`.
6. ✅ Создан bridge-контейнер `xray-reverse-bridge` на Kraken (VLESS-WS → TrueNAS, egress direct). Reverse-канал установлен.
7. ❌ End-to-end НЕ работает (curl через SOCKS 12345 → 000; payload теряется на WS). Гипотеза — перевести reverse на прямой TCP + проброс порта (см. секцию «Reverse деплой»). **ВНЕДРЕНИЕ TCP-варианта ОТЛОЖЕНО (незавершено).**
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 для следующей сессии.**
## Ограничения / риски