[2026-10-30] eagle: family/how-to/kraken-access.md personal/tech/xray-reverse-tunnel-kraken-truenas.md
This commit is contained in:
Alexey Martemyanov committed
1 parent
9623dd1e5d
commit
01ce7d2ae9
2 files changed
+44
-77
No files matched your search
@@ -1,27 +1,20 @@
|
||||
# Kraken — Внешний доступ
|
||||
|
||||
> # ✅ 2026-09-23 — КАНАЛ REVERSE ЖИВ + ТОПОЛОГИЯ УТОЧНЕНА
|
||||
>
|
||||
> **1. Reverse-туннель работает** (первая проверка после фикса гонки 2026-09-20): SOCKS `xray-reverse-portal:12345` → `92.62.77.233` ≠ TrueNAS `90.189.160.148`. Детали — [[personal/tech/xray-reverse-tunnel-kraken-truenas]].
|
||||
>
|
||||
> 🔴 **2. IP Кра́кена ИЗМЕНИЛСЯ: `92.62.70.41` → `92.62.77.233`.** Прежний зафиксирован в этом документе и в `truenas-infrastructure.md` — при проверках брать актуальный из живого запроса.
|
||||
>
|
||||
> **3. Топология Кра́кена (проверено `ip -4 addr` + `ip route`, 2026-09-23):**
|
||||
>
|
||||
> ```
|
||||
> eth0 192.168.1.14 metric 100 ← активный default route
|
||||
> wlan0 192.168.1.15 metric 600
|
||||
> default via 192.168.1.1 dev eth0 src 192.168.1.14
|
||||
> wg0 10.99.1.2/24 (VPS qentra удалён — звено мёртво)
|
||||
> ```
|
||||
>
|
||||
> 🔴 **Кра́кен и Mac (`192.168.1.57`) — СОСЕДИ в одной подсети `192.168.1.0/24`**, шлюз `192.168.1.1` (ASUS RT-AC68U). **`192.168.2.2` (OpenWrt) — это шлюз сети TrueNAS, к сети Mac/Кра́кена отношения не имеет.** Не приписывать OpenWrt сети `192.168.1.x`.
|
||||
>
|
||||
> ⚠️ Следствие: с Mac до `192.168.2.197` маршрут идёт `gateway: 192.168.1.1` (проверено `route -n get`), а не через OpenWrt. Схема «статический маршрут `192.168.2.0/24 → 192.168.1.15` на ASUS» **работоспособна**, потому что Кра́кен — сосед в той же подсети, и обратный NAT делает он сам. Нюанс интерфейса (`.14` eth0 vs `.15` wlan0) — в [[personal/plans/lan-via-reverse-tunnel]].
|
||||
>
|
||||
> ⚠️ **ASUS `192.168.1.1` по SSH недоступен** (`Permission denied` → `Connection closed`, порт 22 `closed`). Раньше в доке `home-network-config` вход был описан как `ssh -i ~/.ssh/id_rsa admin@192.168.1.1` — **сейчас не работает**. Правки маршрутов — только через веб-UI.
|
||||
>
|
||||
> **4. `xray-reverse-bridge` не имеет `inbounds`** — ключи конфига только `log`/`outbounds`/`routing`. Слушающих портов нет. Канал работает на отправку, принять трафик от роутера бриджу нечем. Разбор — [[personal/plans/lan-via-reverse-tunnel]].
|
||||
## Действующий доступ и reverse-туннель
|
||||
|
||||
Проверено 2026-10-30:
|
||||
|
||||
```bash
|
||||
ssh kraken@ssh-kraken.qentra.top
|
||||
```
|
||||
|
||||
Внешний SSH работает через Cloudflare. LAN-адрес Kraken: `192.168.1.14` (eth0).
|
||||
|
||||
Reverse-туннель TrueNAS → Kraken работает. Проверенный WAN-IP Kraken: `217.29.24.185`; адрес динамический, получать актуальный живым запросом.
|
||||
|
||||
Monit только сообщает об ошибках Docker и не перезапускает Docker/containerd. Запуском Docker управляет systemd; запуск bridge обеспечивает включённая служба `xray-reverse-bridge.service` после готовности Docker. Зависимость Docker от монтирования диска сохранена. Перезагрузкой хоста новая настройка пока не проверена.
|
||||
|
||||
Конфигурация и команды проверки: [[personal/tech/xray-reverse-tunnel-kraken-truenas#Эксплуатация и автозапуск]].
|
||||
|
||||
> # ✅ 2026-09-20 — НАЙДЕНА ИСТИННАЯ ПРИЧИНА (2026-09-15 поломки): ГОНКА Docker ↔ монтирование USB-диска
|
||||
>
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Xray Reverse Tunnel — Kraken ↔ TrueNAS
|
||||
created: '2026-09-01'
|
||||
updated: '2026-09-23'
|
||||
updated: '2026-10-30'
|
||||
type: tech
|
||||
namespace: personal
|
||||
tags:
|
||||
@@ -18,8 +18,7 @@ related:
|
||||
- '[[family/how-to/kraken-access]]'
|
||||
- '[[family/how-to/rasputin-router]]'
|
||||
- '[[personal/tech/xray-outbound-subscription-3xui]]'
|
||||
downgrade_to_26.4.25: >-
|
||||
portal+bridge BOTH pinned to 26.4.25; required but insufficient by itself.
|
||||
downgrade_to_26.4.25: portal+bridge BOTH pinned to 26.4.25; required but insufficient by itself.
|
||||
verified_fix_2026_09_02: >-
|
||||
Kraken bridge must use Docker network_mode: host; Docker bridge/NAT reset the
|
||||
VLESS reverse mux. REALITY+Vision verified end-to-end with Kraken egress.
|
||||
@@ -27,58 +26,33 @@ verified_fix_2026_09_02: >-
|
||||
|
||||
# Xray Reverse Tunnel — Kraken ↔ TrueNAS
|
||||
|
||||
> ## ✅ 2026-09-30 — ПРИЧИНА НАЙДЕНА И УСТРАНЕНА: `dockerd` УБИТ SIGKILL MID-RESTORE → КОНТЕЙНЕРЫ ЗАПИСАНЫ КАК «ОСТАНОВЛЕННЫЕ ВРУЧНУЮ»
|
||||
>
|
||||
> **Запрос Alex:** почему не работают профили 3x-ui (`reality primary`/`kraken-user`, `cf fallback`/`vless-space`) и обратный прокси через Кра́кен.
|
||||
>
|
||||
> **Итог: `kraken-user` МЁРТВ, `user1` и `vless-space` ЖИВЫ.** Проверено локальными docker-клиентами на Mac:
|
||||
>
|
||||
> | Профиль | Ожидаемый egress | Фактический egress | Статус |
|
||||
> |---|---|---|---|
|
||||
> | `user1` (direct) | TrueNAS `90.189.160.148` | `90.189.160.148` | ✅ жив |
|
||||
> | `kraken-user` (via reverse) | Кра́кен `92.62.77.233` | `92.62.77.233` **после фикса** | ⚠️ **был мёртв 3 дня** |
|
||||
> | `vless-space` (подписка) | Стокгольм `195.72.61.192` | `195.72.61.192` (geo: Sweden/Stockholm) | ✅ жив |
|
||||
>
|
||||
> ⚠️ **Питфолл замера:** `api.ipify.org` отдаёт разные IP в зависимости от edge Cloudflare — при первом тесте `vless-space` показал `104.28.225.223` (это Cloudflare, НЕ egress). **Проверять egress через `ip-api.com` / смотреть geo**, а не только `api.ipify.org`.
|
||||
>
|
||||
> ### 🔴 ИСТИННАЯ ПРИЧИНА (не конфиг, не версия, не REALITY)
|
||||
>
|
||||
> **`xray-reverse-bridge` на Кра́кене был `Exited (2)`, up-time НОЛЬ — 3 дня.** Кра́кен жив (uptime 2 дня 21 ч, LAN `192.168.1.14`), диск `sda1` примонтирован, docker `active`. Мёртв был **только контейнер**.
|
||||
>
|
||||
> **Полная цепочка (доказано journalctl):**
|
||||
>
|
||||
> | Время (локальное +06:00, boot 2026-09-27 16:23) | Событие |
|
||||
> |---|---|
|
||||
> | 16:24:05 | `dockerd` PID **1385** стартует, начинает `Restoring containers` |
|
||||
> | 16:24:08 | `failed to register container name ... "name is reserved"` для sonarr/radarr/jellyfin/prowlarr/rclone/transmission/hermes-kraken/portainer/cloudflared |
|
||||
> | 16:24:40 | восстанавливает контейнер `8a0246d2...` (создаёт scope) |
|
||||
> | **16:25:35** | **`docker.service: State 'stop-sigterm' timed out. Killing.` → `Killing process 1385 (dockerd) with SIGKILL` → `Main process exited, code=killed, status=9/KILL` → `Failed with result 'timeout'`** |
|
||||
> | 16:25:35 | systemd стартует docker заново → `dockerd` PID **3750** |
|
||||
> | 16:26:28 | `Daemon has completed initialization` |
|
||||
>
|
||||
> **Механизм отказа:** systemd убил `dockerd` **посреди восстановления контейнеров**. Контейнеры, не успевшие восстановиться, были записаны в состоянии `exited` с **`Restarts=0`** — а поскольку daemon был убит, а не остановлен gracefully, политика `unless-stopped` сохранилась как «остановлен вручную». Новый daemon (PID 3750) их **не поднял** — для него это были намеренно остановленные контейнеры.
|
||||
>
|
||||
> 🔴 **Это НЕ bridge-специфичный баг.** Тем же сбоем одновременно легли три независимых контейнера:
|
||||
> `radarr` Exit=137 (SIGKILL), `sonarr` Exit=0, `prowlarr` Exit=137 — у всех `Restarts=0`, все с политикой `unless-stopped`, все до сих пор `exited`.
|
||||
>
|
||||
> **Ключевой диагностический признак:** *«контейнер с `unless-stopped` лежит в `Exited`, `RestartCount=0`, а хост живёт неделями»* → смотреть `journalctl -u docker` на `stop-sigterm timed out` / `SIGKILL` вокруг времени последнего boot. Это не конфиг контейнера.
|
||||
>
|
||||
> ### ✅ ФИКС (применён 2026-09-30)
|
||||
> ```bash
|
||||
> ssh kraken@192.168.1.14 'cd /home/kraken/xray-reverse && sudo -n docker compose up -d'
|
||||
> ```
|
||||
> Через ~2 с bridge установил канал: `dialing TCP to mallexxx.duckdns.org:12346` → `received request for udp:reverse:0`.
|
||||
> **Проверка end-to-end:** SOCKS `:12345` → `92.62.77.233` (Кра́кен), портал `ESTABLISHED ::ffff:172.16.1.7:12346 ← ::ffff:92.62.77.233:1963`.
|
||||
>
|
||||
> ### ⚠️ ОСТАЁТСЯ ПРОБЛЕМОЙ (не устранено)
|
||||
> 1. **Причина остановки docker при boot не найдена.** `TimeoutStartUSec=infinity`, но убил **stop**-путь (`TimeoutStopUSec=1min 30s`). Вероятно, кто-то/что-то инициировало `systemctl stop docker`/`restart` в 16:24-16:25 (watchtower? OMV?). **Требует отдельного разбора** — иначе повторится.
|
||||
> 2. **`radarr`, `sonarr`, `prowlarr` до сих пор `exited`** — не подняты (вне задачи, но факт).
|
||||
> 3. **Самолечения нет.** `unless-stopped` при таком сбое не помогает. Кандидат: systemd-timer или healthcheck, поднимающий bridge, если он down.
|
||||
>
|
||||
> ### Обратный прокси (Кра́кен → LAN TrueNAS) — НЕ работает, и это ОЖИДАЕМО
|
||||
> Проверено живьём: портал в **исходном** состоянии (`routing: local → reverse-out` только), бридж — `inbounds: null`. Правило `192.168.2.0/24 → direct` отсутствует. То есть эксперимент 2026-09-23 **откачен корректно**, конфиги не тронуты. Направление «в чужую приватную сеть» reverse-каналом **не реализуется по дизайну Xray** — см. раздел «🚫 АРХИТЕКТУРНЫЙ ПРЕДЕЛ» ниже. Обратный прокси в смысле *egress локальных клиентов через Кра́кен* (`kraken-user`) — **работает** после фикса.
|
||||
>
|
||||
> **Локальные клиенты для проверки (на Mac):** `/Users/admin/xray-test/clients/{user1,kraken-user,vless-space}.json`, порты `10801/10802/10803`. Запуск: `docker run -d --name t-<n> -v /Users/admin/xray-test/clients/<n>.json:/etc/xray/config.json:ro -p <port>:<port> teddysun/xray:26.4.25`. В образе **нет `curl`** — тестировать отдельным контейнером `--network host curlimages/curl`.
|
||||
## Эксплуатация и автозапуск
|
||||
|
||||
Актуально на 2026-10-30. Туннель работает: HTTPS-запрос с TrueNAS через SOCKS `127.0.0.1:12345` выходит с адреса Kraken. При проверке Kraken: `217.29.24.185`, TrueNAS напрямую: `90.189.160.148`. WAN-IP может меняться; сравнивать с живым запросом на Kraken.
|
||||
|
||||
**Причина остановки bridge:** Monit перезапускал containerd и Docker во время загрузки хоста. Docker не завершал остановку за 90 секунд и получал SIGKILL; bridge сохранялся с `HasBeenManuallyStopped=true`, поэтому `unless-stopped` не поднимал его.
|
||||
|
||||
**Действующая настройка Kraken:**
|
||||
- `/etc/monit/conf.d/docker` — только уведомления при отсутствии процесса и ошибке Docker socket; команд запуска, остановки и перезапуска нет. Docker управляется systemd.
|
||||
- Зависимость Docker от монтирования диска в `docker.service.d/mounts.conf` сохранена.
|
||||
- `/etc/systemd/system/xray-reverse-bridge.service` — включённый oneshot-юнит после `docker.service`, подключён к `multi-user.target` и `docker.service`. Выполняет из `/home/kraken/xray-reverse`:
|
||||
`docker compose up -d --no-build --pull never xray-reverse-bridge`.
|
||||
- Юнит обеспечивает запуск при загрузке хоста и запуске Docker; это не периодическая проверка здоровья туннеля. `ExecStop` отсутствует.
|
||||
- Bridge: `teddysun/xray:26.4.25`, `network_mode: host`, `restart: unless-stopped`.
|
||||
|
||||
**Проверка:**
|
||||
|
||||
```bash
|
||||
# Kraken: SSH, служба и контейнер
|
||||
ssh kraken@ssh-kraken.qentra.top 'systemctl is-active xray-reverse-bridge; docker inspect xray-reverse-bridge --format "{{.State.Status}}"; curl -4 -fsS --max-time 15 https://api.ipify.org'
|
||||
|
||||
# TrueNAS: реальный запрос через туннель
|
||||
ssh truenas_admin@mallexxx.duckdns.org 'curl -4 -fsS --max-time 20 --socks5-hostname 127.0.0.1:12345 https://api.ipify.org'
|
||||
```
|
||||
|
||||
Оба запроса должны завершиться успешно и показать один адрес. Сквозной запрос и новое SSH-подключение проверены; Docker и Cloudflare не перезапускались. Автозапуск настроен и включён, но перезагрузкой хоста пока не проверен.
|
||||
|
||||
Для повторного запуска bridge без перезапуска Docker: `sudo systemctl restart xray-reverse-bridge.service`.
|
||||
|
||||
> ## ✅ 2026-09-23 — КАНАЛ ЖИВ, ПРОВЕРЕНО END-TO-END ПОСЛЕ ПОЧИНКИ 20.09. IP КРА́КЕНА ИЗМЕНИЛСЯ.
|
||||
>
|
||||
|
||||
Reference in new issue
Block a user