[2026-09-15] eagle: family/how-to/truenas-infrastructure.md family/how-to/vps-qentra.md

family/how-to/truenas-infrastructure.md

@@ -13,7 +13,7 @@
 > - **⚠️ «Камера на TrueNAS» — ИСПРАВЛЕНО (2026-09-14, вечер-10) + ✅ РЕШЕНО ОКОНЧАТЕЛЬНО (вечер-13):** прежняя запись «камера = USB-вебка на t610, upstream `cam.*:8090` к камере отношения не имеет» — **❌ НЕВЕРНА**. Поиск в `Caddyfile.bak` доказал: **`cam.mallexxx.duckdns.org → 192.168.2.197:8090` — ЭТО И БЫЛА камера** на TrueNAS: отдельный HTTP-MJPEG-сервис (`ustreamer`/`mjpg-streamer`, порт 8090 — канон для «USB-вебка → MJPEG»). **Контейнер УТРАЧЕН** при пересоздании пула (локальный образ не пережил `.ix-apps`; из живого Caddyfile строка удалена — `cam.*` больше нет). **✅ ФИНАЛ (вечер-13):** вебка `046d:0825` физически в **t610**, работает через **аддон `a889bffc_go2rtc-hardware`** → RTSP H.264 `rtsp://192.168.2.176:8554/usb_camera_h264` → **Generic Camera** `camera.192_168_2_176` (зона `kotelnaia`, `unique_id`, **WebRTC работает**, поворот `#rotate=90`). Схема `camera: platform: ffmpeg` в Core — **❌ ОТВЕРГНУТА** (`Resource busy` + нет `unique_id`). Подробно — [[family/how-to/home-automation]] §5-кватер-И-3/И-6.
 > - **Не перенесено с TrueNAS:** ~~погашение TrueNAS-стека (Этап 4 п.6 — заблокировано: Caddy на TrueNAS держит точку входа)~~ → **✅ ЗАКРЫТО 2026-09-14 (ночь): стек автоматизации ПОГАШЕН, Caddy остался на TrueNAS (так и задумано).** См. §5-кватер-Л в [[family/how-to/home-automation]].
 
-> Обновлено: 2026-09-15 (subscription-канал 3x-ui: ссылки `/sub/<subId>` работают, base64 vless-список; раздел `xray-admin` → «SUBSCRIPTION-КАНАЛ»). Ранее: 2026-09-02 (vpn.mallexxx:443 = РАБОЧИЙ Xray-сервер, проверено end-to-end; vless-proxy outbound мёртв)
+> Обновлено: 2026-09-15 (вечер: ПЛАН `vless-space` на внешней outbound-подписке `profilegrid.net` — шаг 1 готов (28 серверов, HTTP 200), стоит на шаге 2 (нужны креды панели, `admin/admin` → 403); подзадача `hermes-taiga` → переключить `vless-proxy` с мёртвого `v.qentra.top`). Ранее: 2026-09-15 (subscription-канал 3x-ui: ссылки `/sub/<subId>` работают, base64 vless-список; раздел `xray-admin` → «SUBSCRIPTION-КАНАЛ»). Ранее: 2026-09-02 (vpn.mallexxx:443 = РАБОЧИЙ Xray-сервер, проверено end-to-end; vless-proxy outbound мёртв)
 
 > ## ⚠️ ПРИОРИТЕТ 2026-09-01: VPS qentra.top УДАЛЁН → vless-proxy и сетевые туннели сломаны
 > - **VPS `91.207.28.205` больше НЕ существует** (вся его Xray/OpenVPN/WG-инфраструктура утрачена). Подробно: [[family/how-to/vps-qentra]].
@@ -286,6 +286,87 @@ arr, caddy, cups, filebrowser, gitea, hermes, immich, inpx-web, inpxer, library,
 >
 > **🔴 ОТКРЫТЫЙ ВОПРОС БЕЗОПАСНОСТИ (задан Alex 2026-09-15, решения НЕТ):** путь `/sub/<subId>` отдаётся **без авторизации** — `/sub/abc` тоже даёт 200. Кто знает `subId` — получает рабочий ключ. Возможный фикс: подписка по токену/`subUpdates`-проверке в настройках панели либо короткий `subId` + ротация. **Ничего не менялось, ждём решения.**
 
+---
+
+> ## ⏳ ПЛАН 2026-09-15: клиент `vless-space` на ВНЕШНЕЙ outbound-подписке (НЕ ВЫПОЛНЕН, стоит на шаге 2 из 6)
+>
+> **Задача Alex:** добавить в `xray-admin` третьего клиента `vless-space`, чей трафик идёт через **внешнюю** Xray-подписку `profilegrid.net` с авто-обновлением серверов. `user1` и `kraken-user` **НЕ трогать**.
+>
+> **Разбор путаницы (обе версии были в диалоге, верна ВТОРАЯ):**
+> - ❌ «Сервер не может ходить через чужую подписку, он только принимает» — **НЕВЕРНО**, я сам себя опроверг в том же ответе.
+> - ✅ **ВЕРНО: 3x-ui так УМЕЕТ** — это функция **`outbound_subscriptions`** (`/panel/api/xray/outbound-subs`, `/panel/api/xray/outbound-subs/parse`). Панель тянет внешнюю подписку, парсит её серверы как свои **outbound**'ы, обновляет по `update_interval`. Это НЕ клиентская подписка (`/sub/<subId>`), а **обратное направление**: сервер сам ходит наружу через чужие серверы.
+> - 🔑 **Два разных «subscription» в 3x-ui — не путать:**
+>   | | Направление | Где | Кто использует |
+>   |---|---|---|---|
+>   | `/sub/<subId>` | сервер → клиентам | `subDomain/subPort/subScheme` | Happ/v2rayN на телефоне |
+>   | `outbound_subscriptions` | панель → тянет извне | таблица `outbound_subscriptions` | сервер как **клиент** чужого VPN |
+>
+> **Целевая схема:**
+> ```
+> [клиент vless-space] → vpn.mallexxx:443 → xray-admin → outbound из подписки profilegrid → интернет (DE/LV/NL…)
+> ```
+>
+> ### ✅ Шаг 1 ВЫПОЛНЕН — подписка проверена фактом (только чтение)
+> - URL Alex: `https://go.profilegrid.net/sub/djMsNDc3MjgsMTc4OTQ1OTg5NA.WjZEVaps9Xl3s5dkD6x7KRyNIGi7MlDUNAVPMKBUOdk`
+> - `curl -sk -m 25` **с TrueNAS** → **HTTP 200**, `size=12412`, `content_type=text/plain; charset=utf-8`
+> - `base64 -d` → **28 серверов**, все `vless://` + `security=reality` + `type=tcp` + `flow=xtls-rprx-vision`
+> - Один UUID на весь список: `c67ce742-d94f-4e56-889e-9f894ae59940`; на каждом сервере свои `pbk`/`sid`/`sni`/`spx`
+> - Хосты: `edge-{de,lv,nl,ee,pl,fr,us}.mirrorgrid.net:443`, `packages-{nl,se}.repocache.com:443`, `md.repodelivery.com:443`
+> - Маскировочные метки в `#`: `🇩🇪 Germany`, `🇱🇻 Latvia | YT`, `🇬🇧 United Kingdom` и т.д.
+> - **Питфолл:** 28 хостов, но реальных адресов ~9 — подписка отдаёт **несколько записей на один хост** с разными `pbk`/`sid` (перебор ключей).
+>
+> ### ⏸️ ГДЕ ВСТАЛИ (продолжать отсюда)
+> **Шаг 2 требует ДОСТУПА К ПАНЕЛИ 3x-ui.** Причины, почему через БД нельзя:
+> - `outbound_subscriptions` содержит сложные поля (`link_identities`, `last_fetched_outbounds`), руками SQL-строку не собрать;
+> - в `x-ui.db` живой **WAL** (4 МБ) + `-shm`, править под работающей панелью = риск;
+> - в контейнере **нет `sqlite3`** (только `strings`), запись невозможна технически.
+>
+> **Проверено:**
+> - `POST https://vpn-panel.mallexxx.duckdns.org/login` с `admin/admin` → **HTTP 403** (дефолт не подходит, креды у Alex).
+> - Список `sub*`-настроек в БД содержит только `subDomain/subPort/subScheme` (усечённый вывод `strings`) — это клиентская подписка, **не** `outbound_subscriptions` (таблицей подтверждена отдельно ниже).
+>
+> ### 📋 ОСТАВШИЕСЯ ШАГИ (план, ждёт доступа)
+> | # | Шаг | Статус |
+> |---|---|---|
+> | 1 | Проверить URL подписки фактом | ✅ **готово** (28 серверов, HTTP 200) |
+> | 2 | Бэкап `x-ui.db` (+`-wal`,`-shm`) и Caddyfile перед правками | ⏳ **блокер: нужны креды панели** |
+> | 3 | Добавить `outbound_subscriptions`: `url=<profilegrid>`, `remark=profilegrid`, `tag_prefix=space-`, `update_interval=600`, `enabled=true` | ⏳ не начат |
+> | 4 | Создать клиента `vless-space` в inbound `in-10095-tcp` (панель сгенерит свой `subId`) | ⏳ не начат |
+> | 5 | Routing-правило `user: ["vless-space"]` → outbound из подписки (`space-*`) | ⏳ не начат |
+> | 6 | Проверка фактом: `curl` через нового клиента → ждём egress **НЕ** `90.189.160.148` и **НЕ** `92.62.70.41`, а IP сервера из подписки | ⏳ не начат |
+>
+> **Выбор Alex по шагу 5 (открыт):** какой сервер из 28 брать — первый/дефолтный, конкретный (`edge-de`), или балансировщик по всем (тогда нужен `routing.balancers`).
+>
+> ### ⚠️ Питфоллы, выявленные в этой сессии
+> - **Панель отдаёт 403 на логин с дефолтными кредами** — не «панель сломана», а `webBasePath`/пароль заданы. Не подбирать.
+> - **`/sub/<subId>` отдаётся без авторизации** (см. вопрос безопасности выше) — при добавлении `vless-space` его sub-ссылка будет так же открыта.
+> - **Xray-сервер ≠ Xray-клиент.** `vless-proxy` — клиент (SOCKS → наружу), `xray-admin` — сервер (принимает). Единственный способ заставить `xray-admin` ходить наружу через чужие серверы — `outbound_subscriptions`.
+> - **`docker run --rm -v /mnt/RED_2TB/docker/...:/d alpine cat ...`** — рабочий приём чтения root-owned конфигов TrueNAS (в этой сессии апрув-запрос на такую команду **истёк**, повтор без подтверждения не делать).
+>
+> ---
+>
+> ## ⏳ ПОДЗАДАЧА 2026-09-15: `hermes-taiga` переключить с мёртвого `vless-proxy` (НЕ ВЫПОЛНЕНА)
+>
+> **Факт:** `hermes-taiga` ходит **НЕ** через `xray-admin`/`user1`, а через **отдельный** контейнер `vless-proxy`.
+> - env: `TELEGRAM_PROXY=socks5://vless-proxy:1080`, `DISCORD_PROXY=socks5://vless-proxy:1080`
+> - сети `hermes-taiga`: `hermes_taiga_net`, `ha_default`; `xray-admin` — в `caddy_default` (**разные сети**, по имени не видят друг друга)
+> - `vless-proxy`: `teddysun/xray:latest`, Up, SOCKS `:1080` + HTTP `:1081`, **единственный outbound → мёртвый `v.qentra.top:443`** (VPS удалён)
+> - **⇒ Telegram/Discord бота сейчас без сети.**
+>
+> **Готовый план (4 поля, `user1` и `kraken-user` не трогаются):**
+> | Поле в `/mnt/RED_2TB/docker/vless-proxy/config.json` | Сейчас | Станет |
+> |---|---|---|
+> | `outbounds[0].settings.vnext[0].address` | `v.qentra.top` | `vpn.mallexxx.duckdns.org` |
+> | `…vnext[0].users[0].id` | `2D9F24C4-21FE-…` | `ce320965-6956-4759-84bb-7cb71cfc6252` (`user1`) — **или** `93a5dc4b-…` (`kraken-user`, egress Kraken, предпочтительнее) |
+> | `streamSettings.tlsSettings.serverName` | `v.qentra.top` | `vpn.mallexxx.duckdns.org` |
+> | `streamSettings.wsSettings.path` / `.headers.Host` | `/qentra` / `v.qentra.top` | `/vless` / `vpn.mallexxx.duckdns.org` |
+>
+> `port: 443`, `security: tls`, `network: ws` — без изменений. Порядок: бэкап → правка **локально на Mac** (не sed на сервере) → залив → `docker restart vless-proxy` → проверка `api.telegram.org` = 200.
+>
+> **Файлы `/mnt/RED_2TB/docker/vless-proxy/`:** `config.json` (1091 б), `config.json.bak-20260707-102922`, `config.json.bak-switch-ws-client-20260707-103233`, `docker-compose.yml` (336 б).
+>
+> **Важное про «auto»:** Xray-клиент (в т.ч. `vless-proxy`) **подписки не умеет** — авто-обновление живёт только в GUI-клиентах (Happ/v2rayN/NekoBox/sing-box). Для контейнера «auto» = **cron-скрипт**: `curl` подписки → `base64 -d` → собрать `config.json` → `docker restart vless-proxy`. Отдельный кусок, не начат.
+
 **Цель:** 3x-ui frontend для Xray-reverse туннеля Kraken↔TrueNAS (выход клиентов сети TrueNAS через Kraken). Подробно: [[personal/tech/xray-reverse-tunnel-kraken-truenas]].
 
 | Параметр | Значение |

family/how-to/vps-qentra.md

@@ -1,7 +1,7 @@
 ---
 title: VPS qentra.top
 created: '2026-05-24'
-updated: '2026-09-01'
+updated: '2026-09-15'
 type: tech
 namespace: personal
 tags: [infra, vps]
@@ -22,6 +22,16 @@ related:
 > - WireGuard Eagle↔VPS↔Kraken: VPS-звено мёртво.
 > - Rasputin-роутер VLESS-туннель (`188.239.191.235` / node3.sysnx.net) — это ДРУГОЙ сервер (не qentra), не трогать.
 > - Замена для выхода клиентов сети TrueNAS → Kraken: см. **[[tech/xray-reverse-tunnel-kraken-truenas]]** (Xray reverse, ЧАСТИЧНО внедрён: 3x-ui на TrueNAS развёрнут 2026-09-01, reverse-клиент на Kraken ещё нет).
+> - **Замена для `vless-proxy` (Hermes-Taiga) — ГОТОВЫЙ ПЛАН, НЕ ВЫПОЛНЕН (2026-09-15, вечер):** переписать 4 поля в `/mnt/RED_2TB/docker/vless-proxy/config.json`. Сейчас outbound ⇒ мёртвый `v.qentra.top:443` (VPS удалён). Станет ⇒ `vpn.mallexxx.duckdns.org:443`, VLESS-WS, path `/vless`, host `vpn.mallexxx.duckdns.org`.
+>   | Поле | Сейчас | Станет |
+>   |---|---|---|
+>   | `outbounds[0].settings.vnext[0].address` | `v.qentra.top` | `vpn.mallexxx.duckdns.org` |
+>   | `…users[0].id` | `2D9F24C4-21FE-4784-9843-F11C384DA67A` (был `taiga` на удалённом VPS) | `ce320965-6956-4759-84bb-7cb71cfc6252` (`user1`, egress TrueNAS) **или** `93a5dc4b-1b8d-4af5-9363-eb0091734293` (`kraken-user`, egress Kraken — предпочтительнее) |
+>   | `streamSettings.tlsSettings.serverName` | `v.qentra.top` | `vpn.mallexxx.duckdns.org` |
+>   | `streamSettings.wsSettings.path` / `headers.Host` | `/qentra` / `v.qentra.top` | `/vless` / `vpn.mallexxx.duckdns.org` |
+>
+>   Порт `443`, `security: tls`, `network: ws`, `alpn: [http/1.1]` — не меняются. Порядок: бэкап папки → правка **локально на Mac** (не sed на сервере) → залив → `docker restart vless-proxy` → проверка `api.telegram.org` = 200. `user1`/`kraken-user` в `xray-admin` при этом **не трогаются**. Подробности — раздел `xray-admin` в [[family/how-to/truenas-infrastructure]].
+>   ⚠️ Клиент `2D9F24C4-…` (email `taiga`) остался только в исторических данных этого дока — на живом `xray-admin` его **нет**.
 
 **IP:** 91.207.28.205  *(недоступен с 2026-09-01)*
 **Stack:** nginx + Python 3.11, Cloudflare proxy  *(исторические данные ниже)*