134 lines
12 KiB
Markdown
134 lines
12 KiB
Markdown
---
|
||
title: Xray Reverse Tunnel — Kraken ↔ TrueNAS
|
||
created: '2026-09-01'
|
||
updated: '2026-09-01'
|
||
type: tech
|
||
namespace: personal
|
||
tags: [xray, reverse, kraken, truenas, tunnel, networking]
|
||
confidence: medium
|
||
related:
|
||
- "[[family/how-to/vps-qentra]]"
|
||
- "[[family/how-to/truenas-infrastructure]]"
|
||
- "[[family/how-to/kraken-access]]"
|
||
- "[[family/how-to/rasputin-router]]"
|
||
---
|
||
|
||
# Xray Reverse Tunnel — Kraken ↔ TrueNAS
|
||
|
||
> **Статус: ЧАСТИЧНО ВНЕДРЕН (2026-09-01).** ✅ 3x-ui развёрнут на TrueNAS и работает. ⏳ Осталось: reverse-клиент на Kraken + reverse-bridge в 3x-ui.
|
||
> Архитектурное решение: проксировать исходящий трафик локальных клиентов сети TrueNAS через **TrueNAS → Kraken → интернет**.
|
||
|
||
## Контекст / Почему
|
||
|
||
- **VPS qentra.top (91.207.28.205) УДАЛЁН** — вся прежняя Xray-инфраструктура на нём (VLESS+REALITY, OpenVPN, WebSocket v.qentra.top) больше не существует.
|
||
- Нужен новый путь для выхода локальных клиентов сети TrueNAS в интернет через другую точку выхода (Kraken).
|
||
- Белый IP есть только у **TrueNAS** (`mallexxx.duckdns.org` = `90.189.160.148`).
|
||
- **Kraken за NAT**, входящие не принимает — только исходящие соединения.
|
||
|
||
## Принятая схема
|
||
|
||
```
|
||
Локальные клиенты (сеть TrueNAS, 192.168.2.x)
|
||
│ шлют трафик на локальный прокси TrueNAS (SOCKS 1080 / HTTP 1081)
|
||
▼
|
||
TrueNAS ←── контроллер / bridge (белый IP, mallexxx.duckdns.org), принимает
|
||
│ TrueNAS заворачивает трафик в reverse-канал
|
||
▼ ▲
|
||
Kraken ──┘ держит ИСХОДЯЩИЙ reverse-канал к TrueNAS, отпускает трафик → интернет
|
||
▼
|
||
интернет
|
||
```
|
||
|
||
**Тип решения: Xray `reverse`.** Роли по Xray:
|
||
|
||
| Узел | Роль | Держит канал? | Выход в интернет? |
|
||
|------|------|---------------|-------------------|
|
||
| **TrueNAS** | bridge/контроллер (inbound `reverse`) | ❌ слушает | ❌ |
|
||
| **Kraken** | outbound reverse-нода + exit | ✅ **исходящий** к TrueNAS | ✅ **да** |
|
||
| **Локальные клиенты** | используют TrueNAS как локальный прокси-шлюз | — | через Kraken |
|
||
|
||
**Ключевое физическое ограничение:** Kraken за NAT не может принимать входящих. Поэтому канал держит **Kraken исходящим** к TrueNAS. Для передачи клиентского трафика TrueNAS → Kraken используются конструкции `dokodemo-door` + `reverse` + policy-маршрутизация (routing rules). Это чуть сложнее "поставить reverse и всё", конфиг нужен аккуратный.
|
||
|
||
## ⚠️ Факты, проверенные 2026-09-01 (важно, ломают прежние допущения)
|
||
|
||
1. **На 443 у TrueNAS НЕ Xray.** Проверено `openssl s_client`: на `mallexxx.duckdns.org:443` отвечает **обычный TLS 1.3 с валидным Let's Encrypt сертификатом для `mallexxx.duckdns.org`** (`issuer=Let's Encrypt/CN=YE2`). Это **Caddy/nginx reverse-proxy**, НЕ Xray REALITY (у REALITY сертификат был бы чужой/поддельный). → Твоя память «на 443 висел xray server» не подтверждается.
|
||
2. **`vless-proxy` на TrueNAS** (контейнер `teddysun/xray:latest`, Up 7 дней):
|
||
- inbound: SOCKS `0.0.0.0:1080`, HTTP `0.0.0.0:1081` (локально в LAN TrueNAS)
|
||
- outbound: VLESS+WS+TLS на `v.qentra.top:443`, path `/qentra`, id `2D9F24C4-21FE-4784-9843-F11C384DA67A` — **указывает на УДАЛЁННЫЙ VPS → сейчас мёртвый**.
|
||
- ⚠️ Используется Hermes-Taiga как SOCKS5-прокси (`vless-proxy:1080`) → **Hermes-Taiga сейчас без рабочего прокси**.
|
||
3. **Kraken→TrueNAS по `mallexxx.duckdns.org`:** открыты **только 22 (SSH) и 443 (HTTPS/TLS)**. `8443/8964/8080/9000` — closed. Порт 443 — TLS (Caddy), не сырой.
|
||
4. **Kraken:** Docker установлен (`/usr/bin/docker`), но демон отвечает медленно/рвёт SSH (проверка `docker ps` не завершилась за 40s). Xray на Kraken **отсутствует** (`which xray` пусто) — нужен Docker-контейнер.
|
||
5. **Связанность Kraken↔TrueNAS по 22/443 — подтверждена** (оба OPEN с Kraken).
|
||
|
||
## ✅ ВНЕДРЕНО 2026-09-01: 3x-ui на TrueNAS (фронтенд + Docker Compose)
|
||
|
||
**Решение Alex:** использовать **3x-ui frontend** + **Docker Compose** (управление клиентами через панель), а не ручной Caddy-pass-through с сырым Xray. Это изменило исходный план реализации (Шаг 1 ниже устарел по способу).
|
||
|
||
### Развёрнут контейнер `xray-admin` (TrueNAS)
|
||
- **Имя контейнера:** `xray-admin` (строго, т.к. Caddyfile резолвит `xray-admin` по имени в docker-сети).
|
||
- **Образ:** `ghcr.io/mhsanaei/3x-ui:latest` (**3.7.0**, Xray **26.7.28**).
|
||
- **Сеть:** `caddy_default` (external) — там же Caddy, чтобы резолвить имя.
|
||
- **Volume:** `/mnt/RED_2TB/docker/xray-admin:/etc/x-ui` (туда лёг существующий `x-ui.db`).
|
||
- **Порт панели:** хостовый `54321 → 54321` (внутри панель реально слушает **2053** — Caddy проксирует `vpn-panel.mallexxx.duckdns.org` → `xray-admin:2053`).
|
||
- **Compose-файл:** `/mnt/RED_2TB/docker/xray-admin/docker-compose.yml` (deployed версия с `TZ=Asia/Novosibirsk`, `PUID/PGID=950`; см. актуальный файл на TrueNAS — отличается от черновика в плане).
|
||
- **Панель доступна:** `https://vpn-panel.mallexxx.duckdns.org/` → **HTTP 200**.
|
||
- **Sub-сервер:** `[::]:443` (path `/sub`), панель `[::]:2053`, inbound `vless-ws:10095` (path `/vless`, host `vpn.mallexxx.duckdns.org`).
|
||
|
||
### Почему это заработало «из коробки» (важно)
|
||
База `/mnt/RED_2TB/docker/xray-admin/x-ui.db` **уже была настроена под эту Caddy-интеграцию** (раньше 3x-ui уже задумывался на TrueNAS): inbound `vless-ws` port 10095 tag `in-10095-tcp`, subDomain `vpn-panel.mallexxx.duckdns.org`, subPort 443, subScheme https. Caddyfile уже содержал (мёртвые до подъёма) блоки:
|
||
- `vpn.mallexxx.duckdns.org` → `@ws path /vless` → `xray-admin:10095` (WS)
|
||
- `vpn-panel.mallexxx.duckdns.org` → `@sub path /sub/*` → `xray-admin:443` + fallback `xray-admin:2053`
|
||
- LE-сертификаты для этих поддоменов уже выданы.
|
||
|
||
### 3x-ui поддерживает reverse
|
||
В бинарнике `/app/x-ui` присутствует **`clientReverseTags`** → reverse-настройка реализуема через панель 3x-ui (3.7.0).
|
||
|
||
### Бэкап (сделан до изменений)
|
||
`/mnt/RED_2TB/docker/backups/reverse-xray-3xui-20260901-113625/` — содержит: `caddy/Caddyfile` (копия из контейнера, 90 строк), `xray-admin/x-ui.db`, `docker-inventory.txt`.
|
||
|
||
### Мелочь/питфолл
|
||
Скопированный в volume `docker-compose.yml` оказался внутри контейнера `/etc/x-ui/` (т.к. volume смонтирован туда) — удалить лишний файл из контейнера: `docker exec xray-admin rm -f /etc/x-ui/docker-compose.yml`.
|
||
|
||
## ⏳ Следующий шаг (НЕ сделан)
|
||
Развернуть **reverse-клиент (outstation) на Kraken** (exit node) и настроить **reverse-bridge в 3x-ui (TrueNAS)** + локальный SOCKS/HTTP для клиентов сети TrueNAS. Механика: `dokodemo-door` + `reverse` + routing; Kraken (outstation) подключается к TrueNAS по публичному `vpn.mallexxx.duckdns.org/vless`, регистрирует локальный SOCKS-выход; bridge (TrueNAS) выставляет алиас-порт для локальных клиентов.
|
||
|
||
## План реализации (история; Шаг 1 устарел — см. «ВНЕДРЕНО» выше)
|
||
|
||
### Шаг 1 — TrueNAS: Xray reverse-server поверх Caddy
|
||
- **Способ (рекомендован): Caddy TLS-pass-through.** Добавить в Caddy TCP-правило: поддомен `xray.mallexxx.duckdns.org:443` → внутренний порт Xray-контейнера (напр. `localhost:8443`). Caddy передаёт сырой TLS-стрим дальше. Xray на TrueNAS принимает VLESS+Reality/TLS. Kraken ходит на `xray.mallexxx.duckdns.org:443`.
|
||
- Плюс: переиспользуем уже открытый/проброшенный 443 на роутере, не трогаем роутер, туннель маскируется под HTTPS.
|
||
- Альтернатива: пробросить отдельный порт на роутере (напр. 8443) → требует доступа к роутеру. Менее предпочтительно.
|
||
- Новый/доразвернутый Xray-контейнер:
|
||
- inbound `reverse`/`dokodemo-door` на 8443 (извне по pass-through)
|
||
- local inbound SOCKS/HTTP (уже есть 1080/1081)
|
||
- routing: трафик клиентов → в reverse-канал к Kraken
|
||
|
||
### Шаг 2 — TrueNAS: бэкап перед изменением
|
||
- Снять копию текущего конфига `vless-proxy` (config.json), в `/mnt/RED_2TB/docker/<app>/backup/` (паттерн как с cups-splix).
|
||
|
||
### Шаг 3 — Kraken: Xray outbound reverse в Docker
|
||
- Контейнер Xray на Kraken (`docker run --restart unless-stopped`, как остальные).
|
||
- outbound vless → `xray.mallexxx.duckdns.org:443` (через Caddy pass-through).
|
||
- inbound SOCKS/HTTP на Kraken — точка выхода.
|
||
- reverse-конфиг: Kraken регистрирует «сервис» (весь трафик через dokodemo-door) наружу через канал к TrueNAS.
|
||
|
||
### Шаг 4 — Проверка связности
|
||
- Kraken → `xray.mallexxx.duckdns.org:443` (TCP).
|
||
- Локальный клиент → TrueNAS:1080 → curl через прокси → должен выйти с IP Kraken.
|
||
|
||
### Шаг 5 — Обновить Obsidian после внедрения
|
||
- Дополнить `family/how-to/truenas-infrastructure.md` (Xray reverse-настройка), `family/how-to/kraken-access.md`; обновить `personal/tech/vps-qentra.md` (VPS удалён, ссылки на него).
|
||
|
||
## Открытые вопросы (требуют ответа Alex)
|
||
|
||
1. **Проброс порта на роутере возможен?** Или туннель обязателен ТОЛЬКО через 443 (Caddy TLS-pass-through)?
|
||
2. **Какой трафик TrueNAS пустить через Kraken** — весь исходящий интернет, или конкретные сервисы/подсети? (Влияет на NAT/masquerade на Kraken.)
|
||
3. **Docker-демон Kraken работает нестабильно** (рвёт SSH) — чинить перед деплоем?
|
||
|
||
## Связанные заметки
|
||
- [[family/how-to/vps-qentra]] — VPS на 2026-09-01 УДАЛЁН
|
||
- [[family/how-to/truenas-infrastructure]] — TrueNAS Caddy/контейнеры
|
||
- [[family/how-to/kraken-access]] — Docker Kraken
|
||
- [[family/how-to/rasputin-router]] — прежний VLESS-туннель на VPS (тоже требует пересмотра, VPS нет)
|
||
- [[family/how-to/wireguard-vpn]] — WG Eagle↔VPS↔Kraken (VPS-звено теперь мёртво)
|