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

[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

Browse Source
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
Download Patch File Download Diff File Expand all files Collapse all files
family/how-to/kraken-access.md
+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]]
family/how-to/truenas-infrastructure.md
+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 завершён)
family/plans/reverse-xray-3xui-kraken.md
+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 для следующей сессии.**
## Ограничения / риски
personal/tech/xray-reverse-tunnel-kraken-truenas.md
+18 -15
View File
@@ -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 (выполняется)
WS-транспорт подтверждённо не пропускает reverse-payload. Принято решение (Alex согласовал проброс порта) — перевести канал bridge↔portal на **прямой TCP + REALITY**:
### ✅ ВНЕДРЕНО (2026-09-01) — 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"`.
- **bridge** `/home/kraken/xray-reverse/config.json`: outbound `conn` → `mallexxx.duckdns.org:12346` reality.
### 💡 Обновлённая гипотеза (непроверенная)
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 может быть избыточен.
Незавершено (стоп на одобрение lifecycle-операции):
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`.
**Статус: задание НЕ завершено — продолжить со sniffing / пересмотром роли reverse в следующей сессии.**
## ⏳ Открытые вопросы по 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 УДАЛЁН