diff --git a/family/how-to/truenas-access.md b/family/how-to/truenas-access.md index 9652c40f..9272cf54 100644 --- a/family/how-to/truenas-access.md +++ b/family/how-to/truenas-access.md @@ -42,6 +42,15 @@ docker run --rm alpine sh -c 'apk add -q openssh sshpass && sshpass -p 1316261 s **Пароль root:** `1316261` +> 💡 **Бэкап firewall OpenWrt перед любой правкой redirect-правил** (вошло в практику 2026-09-01): +> ```bash +> # с TrueNAS: сохранить весь firewall-конфиг OpenWrt в backup-папку TrueNAS +> docker run --rm alpine sh -c 'apk add -q openssh sshpass && sshpass -p 1316261 ssh -o StrictHostKeyChecking=no root@192.168.2.2 "uci show firewall"' +> # → сохранить вывод в /mnt/RED_2TB/docker/backups/openwrt-firewall-YYYYMMDD-HHMMSS.txt +> # Пример сделанного: /mnt/RED_2TB/docker/backups/openwrt-firewall-20260901-130558.txt +> ``` +> Существующие redirect-правила OpenWrt → TrueNAS(192.168.2.197): MQTT 1883, SSH 22, caddy_http 80→8088, caddy_https 443→8443, HomeAssistant 8123 (disabled). + ## Пул и датасеты Пул: RED_2TB (ZFS) diff --git a/family/how-to/truenas-infrastructure.md b/family/how-to/truenas-infrastructure.md index 5d2acf79..a69a6eca 100644 --- a/family/how-to/truenas-infrastructure.md +++ b/family/how-to/truenas-infrastructure.md @@ -209,10 +209,27 @@ arr, caddy, cups, filebrowser, gitea, hermes, immich, inpx-web, inpxer, library, | Env | `TZ=Asia/Novosibirsk`, `PUID=950`, `PGID=950` | | Ports (host) | `54321:54321` (не используется панелью — внутри панель на 2053, можно убрать) | -**Статус (2026-09-01):** контейнер **Up**, панель HTTP 200. Reverse-bridge НЕ настроен ещё — следующий этап. 3x-ui поддерживает reverse (`clientReverseTags`). +**Статус (2026-09-01):** контейнер **Up**, панель HTTP 200. Reverse **портал** развёрнут отдельным контейнером `xray-reverse-portal` (см. ниже). 3x-ui поддерживает reverse (`clientReverseTags`). > ⚠️ База `x-ui.db` была **уже настроена** под эту Caddy-интеграцию (inbound vless-ws:10095, subDomain vpn-panel), поэтому панель заработала «из коробки». Бэкап базы/Caddyfile до изменений: `/mnt/RED_2TB/docker/backups/reverse-xray-3xui-20260901-113625/`. +### `xray-reverse-portal` — Xray reverse portal (TrueNAS, добавлен 2026-09-01) + +**Цель:** portal-часть Xray-reverse туннеля: принимает исходящий трафик локальных клиентов сети TrueNAS (через SOCKS `:12345`) и пересылает по reverse-каналу на Kraken (bridge) → интернет через Kraken. Подробно: [[personal/tech/xray-reverse-tunnel-kraken-truenas]]. + +| Параметр | Значение | +|----------|----------| +| Папка | `/mnt/RED_2TB/docker/reverse-portal/` | +| Контейнер | `xray-reverse-portal` | +| Образ | `teddysun/xray:latest` (Xray 26.7.28) | +| Volume | `config.json:/etc/xray/config.json:ro` | +| Сеть | `caddy_default` | +| interconn | `:12346` VLESS (принимает reverse-канал от Kraken) — **сейчас на TCP+REALITY** (внутр. порт 12346, проброс `12346:12346`) | +| 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]]. + ### Home Assistant — детали - **Image:** `ghcr.io/home-assistant/home-assistant:stable` diff --git a/family/plans/reverse-xray-3xui-kraken.md b/family/plans/reverse-xray-3xui-kraken.md index 89115f7e..5f17da7f 100644 --- a/family/plans/reverse-xray-3xui-kraken.md +++ b/family/plans/reverse-xray-3xui-kraken.md @@ -126,9 +126,41 @@ networks: **Следующий шаг:** ✅ Выполнено — reverse развёрнут (см. ниже). Основной doc архитектуры: `personal/tech/xray-reverse-tunnel-kraken-truenas.md`. -## Reverse деплой — ПОЛНЫЙ СТАТУС (2026-09-01, финал сессии) +## Reverse деплой — ПОЛНЫЙ СТАТУС (2026-09-01) — РЕШЕН переезд на TCP+REALITY -### Развёрнутые контейнеры (фактические конфиги) +### 🔀 РЕШЕНИЕ: WS → прямой TCP+REALITY (принято в сессии 2026-09-01) +WS-вариант reverse НЕ пропускал payload (curl через SOCKS → 000; portal логировал `accepted tcp:... [local -> reverse-out]`, но bridge не получал). Официальный Xray-reverse пример = прямой TCP + flow `xtls-rprx-vision`. Alex согласовал проброс порта → переводим reverse канал Kraken↔TrueNAS на **прямой TCP+REALITY** порт 12346. + +**REALITY-ключи (для interconn :12346):** server PrivateKey `0JTjeirfviDqCr63wSnisvU7DV6SpR9_9V2l_EUHmkk`; server PublicKey (для bridge) `GhsphQLT_0fwOvK45MHeAgG3sBQsFtw7lQfUIbrLMQU`; shortId `1451ef281caf5905`; serverName/SNI `www.cloudflare.com`; flow `xtls-rprx-vision`. + +**⚠️ Pitfall Xray 26.x:** VLESS без TLS/шифрования к публичному адресу ЗАПРЕЩЁН (`vless without TLS or other encryption is prohibited unless the server address is a private IP`). → bridge TCP-VLESS обязателен с REALITY. + +Обновлённые конфиги (оба `Configuration OK` при `xray run -test`): +- **portal** `/mnt/RED_2TB/docker/reverse-portal/config.json`: interconn `:12346` VLESS-TCP reality (dest www.cloudflare.com:443, client a81c3179..., flow xtls-rprx-vision, reverse tag reverse-out); local `:12345` SOCKS; routing local→reverse-out. +- **bridge** `/home/kraken/xray-reverse/config.json`: outbound `conn` VLESS simplified → mallexxx.duckdns.org:12346, flow, reality (publicKey=server PublicKey, shortId, serverName www.cloudflare.com, fingerprint random), reverse tag reverse-in; direct=freedom; routing reverse-in→direct. +- **compose portal**: добавлен проброс `- "12346:12346"`. + +### Доступ к роутеру OpenWrt (TrueNAS сети) — из `truenas-access` +- OpenWrt = main router сети 192.168.2.0/24, SSH `root@192.168.2.2`, пароль root **`1316261`**. Доступ с TrueNAS через docker+sshpass. +- ✅ Бэкап 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 :12345 https://api.ipify.org` → ожидать IP Kraken `92.62.70.41`. + +### ⚠️ 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`). +- Итог: диск появился, Docker `active`, **30 образов целы, 0 контейнеров** (контейнеры потеряны, data-root на HDD). +- Docker Root Dir Kraken: `/srv/dev-disk-by-uuid-6194539b-.../docker-data` (UUID **6194539b**, не 49e8f586). +- Прямой интернет Kraken работает (api.ipify → 92.62.70.41). Контейнеры Kraken (jellyfin/transmission/radarr/hermes-kraken...) НЕ восстановлены — отдельная задача при необходимости. + +### Историческая справка (WS-версия, суперсидившаяся) +- Канал до перехода: Kraken→TrueNAS `172.24.0.2 → 90.189.160.148:443 ESTABLISHED`; portal `172.16.1.7:12346 ← Caddy 172.16.1.3 ESTABLISHED`; bridge лог `common/mux: received request for udp:reverse:0`. payload ❌ НЕ проходил (причина перехода на TCP). + +#### Развёрнутые контейнеры (WS-версия, историческая справка) **TrueNAS — `xray-reverse-portal`** (VLESS/W S, reverse portal): `/mnt/RED_2TB/docker/reverse-portal/` - compose в `/mnt/RED_2TB/docker/reverse-portal/docker-compose.yml`, image `teddysun/xray:latest` (Xray 26.7.28) diff --git a/personal/tech/xray-reverse-tunnel-kraken-truenas.md b/personal/tech/xray-reverse-tunnel-kraken-truenas.md index d129b3cd..ce61d9a7 100644 --- a/personal/tech/xray-reverse-tunnel-kraken-truenas.md +++ b/personal/tech/xray-reverse-tunnel-kraken-truenas.md @@ -135,12 +135,22 @@ 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. -### 💡 Гипотеза (вероятная) и след. шаг -**WebSocket-транспорт не пропускает reverse-payload.** В официальных VLESS-reverse примерах канал bridge↔portal идёт **по прямому TCP** + `flow: xtls-rprx-vision` (REALITY). UDP-reverse создаётся, но TCP-payload по WS не доходит. -**План (отложен):** перевести reverse-канал на **прямой TCP**: -1. TrueNAS: VLESS-inbound `interconn` на отдельном TCP-порту (напр. `:12346` наружу) + проброс на роутере `внешний :12346 → 192.168.2.197:12346` (Alex подтвердил «пробросить не проблема»). -2. Kraken: bridge VLESS-outbound → **TCP** (не WS), address `mallexxx.duckdns.org:12346`. -3. Возможно нужен `flow: xtls-rprx-vision` + шифрование на канале (REALITY) — по доке. +### ✅ РЕШЕНО 2026-09-01: переход на прямой TCP+REALITY (выполняется) +WS-транспорт подтверждённо не пропускает reverse-payload. Принято решение (Alex согласовал проброс порта) — перевести канал bridge↔portal на **прямой TCP + REALITY**: + +**REALITY-ключи (interconn :12346):** server PrivateKey `0JTjeirfviDqCr63wSnisvU7DV6SpR9_9V2l_EUHmkk`; server PublicKey (для bridge) `GhsphQLT_0fwOvK45MHeAgG3sBQsFtw7lQfUIbrLMQU`; shortId `1451ef281caf5905`; serverName/SNI `www.cloudflare.com`; flow `xtls-rprx-vision`. + +**⚠️ 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. + +Обновлённые конфиги (оба `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. + +Незавершено (стоп на одобрение 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 :12345 https://api.ipify.org` → ожидать IP Kraken `92.62.70.41`. ## ⏳ Открытые вопросы по reverse (требуют ответа/действия Alex) @@ -173,10 +183,10 @@ compose: image `teddysun/xray:latest`, volume `config.json:/etc/xray/config.json ## Открытые вопросы (требуют ответа Alex) -1. ❌ **Проброс порта для reverse** — теперь НУЖЕН для перевода reverse-канала на TCP (end-to-end payload не проходит по WS). Alex подтвердил «пробросить не проблема». Параметры: `внешний :12346 → 192.168.2.197:12346` (или отдельный VLESS+REALITY порт). +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» выше. 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 не проходит** — главный блокер (см. секцию «Reverse деплой» выше). Гипотеза WS-проблема → следующий шаг перевести на TCP + проброс порта. Не завершено. +4. ❌ **End-to-end payload не проходит** — блокер. WS-вариант не пропускает payload; переходим на TCP+REALITY (конфиги готовы, осталось пересоздать контейнеры + пробросить порт). См. секцию «РЕШЕНО 2026-09-01» выше. Не завершено. ## Связанные заметки - [[family/how-to/vps-qentra]] — VPS на 2026-09-01 УДАЛЁН