diff --git a/personal/tech/xray-reverse-tunnel-kraken-truenas.md b/personal/tech/xray-reverse-tunnel-kraken-truenas.md index 35ba40f2..db9a811b 100755 --- a/personal/tech/xray-reverse-tunnel-kraken-truenas.md +++ b/personal/tech/xray-reverse-tunnel-kraken-truenas.md @@ -27,6 +27,59 @@ 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-09-23 — КАНАЛ ЖИВ, ПРОВЕРЕНО END-TO-END ПОСЛЕ ПОЧИНКИ 20.09. IP КРА́КЕНА ИЗМЕНИЛСЯ. > > **Первая проверка канала после фикса гонки docker↔mount (2026-09-20). Результат — работает.**