git_admin/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
08b6aa560ded743fcd4f53569caa1aa2784b6a57
obsidian-vault/personal/tech/xray-reverse-tunnel-kraken-truenas.md
T

8.3 KiB
Raw Blame History

title, created, updated, type, namespace, tags, confidence, related
title created updated type namespace tags confidence related
Xray Reverse Tunnel — Kraken ↔ TrueNAS 2026-09-01 2026-09-01 tech personal
xray
reverse
kraken
truenas
tunnel
networking
medium
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

Статус: ПЛАН (согласовано направление с Alex, НЕ внедрено). 2026-09-01. Архитектурное решение: проксировать исходящий трафик локальных клиентов сети 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).

План реализации (шаги; НЕ выполнены, ждут OK Alex)

Шаг 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) — чинить перед деплоем?

Связанные заметки

Reference in New Issue View Git Blame Copy Permalink