From 01ce7d2ae9c1e9f0e1a7024f7aa706c2c5d7a9a7 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Fri, 30 Oct 2026 11:59:41 +0600 Subject: [PATCH] [2026-10-30] eagle: family/how-to/kraken-access.md personal/tech/xray-reverse-tunnel-kraken-truenas.md --- family/how-to/kraken-access.md | 37 ++++---- .../xray-reverse-tunnel-kraken-truenas.md | 84 +++++++------------ 2 files changed, 44 insertions(+), 77 deletions(-) diff --git a/family/how-to/kraken-access.md b/family/how-to/kraken-access.md index d77ad595..d90f465b 100755 --- a/family/how-to/kraken-access.md +++ b/family/how-to/kraken-access.md @@ -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-диска > diff --git a/personal/tech/xray-reverse-tunnel-kraken-truenas.md b/personal/tech/xray-reverse-tunnel-kraken-truenas.md index db9a811b..bc4b0e8a 100755 --- a/personal/tech/xray-reverse-tunnel-kraken-truenas.md +++ b/personal/tech/xray-reverse-tunnel-kraken-truenas.md @@ -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- -v /Users/admin/xray-test/clients/.json:/etc/xray/config.json:ro -p : 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 КРА́КЕНА ИЗМЕНИЛСЯ. >