[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

family/how-to/kraken-access.md

@@ -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 | |
+| xray-reverse-bridge | развёрнут 2026-09-01 (единственный активный) |
-| hermes-kraken | |
+| flaresolverr / hermes-kraken / homeassistant / jellyfin / portainer / prowlarr / radarr / rclone / sonarr / transmission / cloudflared / watchtower | образы есть, контейнеры потеряны — пересоздать при необходимости |
-| 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]]
+

family/how-to/truenas-infrastructure.md

@@ -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 завершён)
 

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

@@ -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-операции)
+### ✅ ВНЕДРЕНО (2026-09-01, после согласия Alex) — TCP+REALITY переход выполнен
-1. Пересоздать `xray-reverse-portal` на TrueNAS (compose+config REALITY) → `docker compose stop/rm/up` (одобрение истекло).
+Все 4 шага перехода на TCP+REALITY **ВЫПОЛНЕНЫ**:
-2. OpenWrt DNAT: redirect `внешний:12346 → 192.168.2.197:12346`.
+1. ✅ Пересоздан `xray-reverse-portal` на TrueNAS (compose `12345:12345` + `12346:12346`, config REALITY TCP). Проверено: `ss -tlnp` → `0.0.0.0:12346 LISTEN`.
-3. Пересоздать `xray-reverse-bridge` на Kraken (REALITY config).
+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** извне.
-4. Тест: `curl --socks5 <TrueNAS>:12345 https://api.ipify.org` → ожидать IP Kraken `92.62.70.41`.
+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`.
+5. ✅ Создан portal-контейнер `xray-reverse-portal` на TrueNAS (interconn :12346 + SOCKS `local`:12345) + Caddy маршрут `/rvs`. [Затем: переведён на TCP+REALITY, см. секции «Reverse деплой».]
-6. ✅ Создан bridge-контейнер `xray-reverse-bridge` на Kraken (VLESS-WS → TrueNAS, egress direct). Reverse-канал установлен.
+6. ✅ Создан bridge-контейнер `xray-reverse-bridge` на Kraken (→ TrueNAS, egress direct). Reverse-канал установлен. [Затем: переведён на TCP+REALITY.]
-7. ❌ End-to-end НЕ работает (curl через SOCKS 12345 → 000; payload теряется на WS). Гипотеза — перевести reverse на прямой TCP + проброс порта (см. секцию «Reverse деплой»). **ВНЕДРЕНИЕ TCP-варианта ОТЛОЖЕНО (незавершено).**
+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 для следующей сессии.**
 
 ## Ограничения / риски

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

@@ -15,7 +15,7 @@ related:
 
 # Xray Reverse Tunnel — Kraken ↔ TrueNAS
 
-> **Статус: ЧАСТИЧНО ВНЕДРЕН (2026-09-01).** ✅ 3x-ui развёрнут и работает. ✅ reverse portal (TrueNAS) + bridge (Kraken) развёрнуты, reverse-канал установлен. ❌ **End-to-end payload НЕ проходит** (curl 000) — предположительно из-за WS-транспорта reverse (гипотеза: нужен прямой TCP). **TCP-вариант + проброс порта = следующая задача (отложена).**
+> **Статус: ЧАСТИЧНО ВНЕДРЕН, 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 проброшены. Задание НЕ завершено.
 > Архитектурное решение: проксировать исходящий трафик локальных клиентов сети TrueNAS через **TrueNAS → Kraken → интернет**.
 
 ## Контекст / Почему
@@ -135,22 +135,25 @@ compose: image `teddysun/xray:latest`, volume `config.json:/etc/xray/config.json
 - **Bridge НЕ логирует received для этого TCP-payload** — данные теряются между reverse-out (portal) и reverse-in (bridge).
 - Kraken имеет прямой интернет (`api.ipify` → `92.62.70.41`), проблема не в egress.
 
-### ✅ РЕШЕНО 2026-09-01: переход на прямой TCP+REALITY (выполняется)
+### ✅ ВНЕДРЕНО (2026-09-01) — TCP+REALITY переход, все шаги выполнены
-WS-транспорт подтверждённо не пропускает reverse-payload. Принято решение (Alex согласовал проброс порта) — перевести канал bridge↔portal на **прямой TCP + REALITY**:
+WS-транспорт не пропускал reverse-payload; переведён на **прямой TCP + REALITY** (Alex согласовал проброс). Все 4 шага ВЫПОЛНЕНЫ:
+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` + `common/mux: received request for udp:reverse:0`.
+4. ❌ **Тест payload НЕ прошёл даже на TCP+REALITY**: `curl --socks5 127.0.0.1:12345 http://api.ipify.org` → **`code=000`**. Portal: `accepted tcp:8.6.112.0:80 [local -> reverse-out]`, но bridge НЕ логирует приход TCP-payload.
 
-**REALITY-ключи (interconn :12346):** server PrivateKey `0JTjeirfviDqCr63wSnisvU7DV6SpR9_9V2l_EUHmkk`; server PublicKey (для bridge) `GhsphQLT_0fwOvK45MHeAgG3sBQsFtw7lQfUIbrLMQU`; shortId `1451ef281caf5905`; serverName/SNI `www.cloudflare.com`; flow `xtls-rprx-vision`.
+### ❌ Дополнительно пробовано: снятие `flow: xtls-rprx-vision`
+Убрал `flow: xtls-rprx-vision` с обеих сторон (portal interconn client + bridge conn outbound), пересоздал контейнеры (оба `Configuration OK`). Результат: **по-прежнему `code=000`**. Reverse-канал устанавливается, TCP-payload до bridge не доходит.
 
-**⚠️ Pitfall Xray 26.x:** VLESS без TLS/шифрования к публичному адресу запрещён (`vless without TLS or other encryption is prohibited unless the server address is a private IP`) → TCP-VLESS обязателен с REALITY.
+**Вывод:** проблема НЕ в `flow` и НЕ в WS. **Даже на «каноничном» TCP+REALITY payload от portal-reverse-out до bridge-reverse-in не передаётся** (bridge не получает inbound-TCP). Гипотеза про WS **опровергнута**.
 
-Обновлённые конфиги (оба `Configuration OK` при `xray run -test`):
+### 💡 Обновлённая гипотеза (непроверенная)
-- **portal** `/mnt/RED_2TB/docker/reverse-portal/config.json`: interconn `:12346` VLESS-TCP reality; local `:12345` SOCKS; compose получил проброс `- "12346:12346"`.
+Reverse-канал (mux `udp:reverse:0`) НЕ доставляет инициированный portal'ом inbound TCP-payload из outbound `reverse-out`. НЕ испробовано:
-- **bridge** `/home/kraken/xray-reverse/config.json`: outbound `conn` → `mallexxx.duckdns.org:12346` reality.
+- `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 может быть избыточен.
 
-Незавершено (стоп на одобрение lifecycle-операции):
+**Статус: задание НЕ завершено — продолжить со sniffing / пересмотром роли reverse в следующей сессии.**
-1. Пересоздать `xray-reverse-portal` (stop/rm/up) на TrueNAS.
-2. OpenWrt DNAT `внешний:12346 → 192.168.2.197:12346` (бэкап firewall уже сделан: `/mnt/RED_2TB/docker/backups/openwrt-firewall-20260901-130558.txt`).
-3. Пересоздать `xray-reverse-bridge` на Kraken.
-4. Тест `curl --socks5 <TrueNAS>:12345 https://api.ipify.org` → ожидать IP Kraken `92.62.70.41`.
 
 ## ⏳ Открытые вопросы по reverse (требуют ответа/действия Alex)
 
@@ -183,10 +186,10 @@ WS-транспорт подтверждённо не пропускает rever
 
 ## Открытые вопросы (требуют ответа Alex)
 
-1. ✅ (решено) **Проброс порта для reverse** — переходим на TCP+REALITY. Реализация НЕ завершена: конфиги подготовлены и валидны, осталось (a) пересоздать `xray-reverse-portal` на TrueNAS с новым compose, (b) OpenWrt DNAT `внешний:12346 → 192.168.2.197:12346`, (c) пересоздать `xray-reverse-bridge` на Kraken. Проброс порта Alex подтвердил «не проблема». См. секцию «РЕШЕНО 2026-09-01» выше.
+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 (конфиги готовы, осталось пересоздать контейнеры + пробросить порт). См. секцию «РЕШЕНО 2026-09-01» выше. Не завершено.
+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» и «Обновлённая гипотеза» выше. Задание не завершено.
 
 ## Связанные заметки
 - [[family/how-to/vps-qentra]] — VPS на 2026-09-01 УДАЛЁН