[2026-09-23] eagle: family/how-to/kraken-access.md family/how-to/truenas-infrastructure.md personal/plans/lan-access-via-reverse-tunnel.md personal/tech/xray-reverse-limits-private-network.md personal/tech/xray-reverse-tunnel-kraken-truenas.md

personal/plans/lan-access-via-reverse-tunnel.md

@@ -11,7 +11,7 @@ tags:
   - asus
   - routing
   - vpn
-status: partially-applied
+status: stopped-architectural-deadlock
 updated: '2026-09-23'
 related:
   - '[[personal/tech/xray-reverse-tunnel-kraken-truenas]]'
@@ -21,21 +21,22 @@ related:
 ---
 # Доступ к 192.168.2.0/24 с ASUS через reverse-туннель Kraken→TrueNAS
 
-> ## 🔄 СТАТУС: ЧАСТИЧНО ПРИМЕНЕНО (2026-09-23, вечер). Сквозной проход НЕ подтверждён.
+> ## 🏁 СТАТУС: ОСТАНОВЛЕНО (2026-09-23, вечер). Архитектурный тупик, схема НЕ доведена.
 >
-> **Применено и проверено:**
-> - ✅ Бэкапы: Кра́кен `config.json.bak-lan-in-20260923-130541` + `/home/kraken/backups/iptables.bak-20260923-130541`; TrueNAS `config.json.before-lanroute`
-> - ✅ **Правка 2 (портал) ВЫПОЛНЕНА** — добавлено правило `192.168.2.0/24 → direct` (выше правила `local → reverse-out`), outbound `direct` создан с `finalRules:[{action:"allow"}]`. Валидация `xray run -test` → `Configuration OK.` Портал перезапущен → Up, канал жив, egress `92.62.77.233`.
-> - ✅ **Правка 1 (бридж) ВЫПОЛНЕНА** — добавлен inbound `lan-in` (`dokodemo-door`, `127.0.0.1:12345`, `followRedirect:true`, `sniffing:false`) + правило `lan-in → conn`. Валидация `Configuration OK.` Бридж перезапущен → Up.
-> - ✅ **Правило iptables добавлено** на Кра́кене: `nat PREROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 -p tcp -j REDIRECT --to-ports 12345`. Inbound слушает `127.0.0.1:12345` (проверено `ss -tlnp`).
+> **Итог:** цепочка «ASUS → Кра́кен → туннель → TrueNAS → 192.168.2.x» **не реализуется** в Xray reverse. Портал отклоняет: `for safety reasons, user a81c3179-… is not allowed to use forward proxy`. Это **штатная защита** Xray от превращения сервера в открытый прокси, не баг конфига. Обходится только `finalRules`-allow, но тогда «домашней» стороной обязан быть Кра́кен, а целевая сеть — его локалка (`192.168.1.x`), **не** `192.168.2.x`. Направление задачи и направление туннеля не совпадают.
 >
-> **🔴 НЕ подтверждено — сквозной проход.** Тест дал `HTTP 000` (3 с), счётчик REDIRECT-правила = **0 пакетов**.
+> **Решение Alex:** НЕ принято. Варианты в разделе «Развилка» ниже. Откат возможен в одну команду из бэкапов.
 >
-> **⚠️ ПИТФОЛЛ МЕТОДИКИ (стоил ложного вывода):** тест запускался `curl`-ом **с самого Кра́кена**. Локально-исходящий трафик идёт через `nat OUTPUT`, а **не** через `PREROUTING` → правило физически не могло сработать, счётчик 0. Это **не** доказывает ни поломку, ни работу схемы. **Проверять только с постороннего хоста** в `192.168.1.x` (Mac), а не с узла, где стоит правило.
+> **Что осталось применённым на системах (требует решения — откатить или оставить):**
+> - Кра́кен: inbound `lan-in` (`dokodemo-door`, `0.0.0.0:12345`) + routing `lan-in → conn`; правило `iptables nat PREROUTING` REDIRECT (не персистентно). Бэкапы: `config.json.bak-lan-in-20260923-130541`, `config.json.bak-listen0000-20260923-131655`, `config.json.bak-v3-<date>`, `iptables.bak-20260923-130541`.
+> - TrueNAS: правило `192.168.2.0/24 → direct` в портале. Бэкап: `config.json.before-lanroute`.
+> - ASUS: `nvram lan_route` изменён с `192.168.1.2` на `192.168.1.15`. Бэкап: `/jffs/lan_route.bak.20260923-131613`.
+> - ⚠️ **Обнаружен и исправлен битый артефакт:** `lan_route` указывал на мёртвый `192.168.1.2` (ARP `FAILED`, MAC нулевой) — трафик на `192.168.2.x` уходил в никуда. Это была **предсуществующая поломка**, не созданная в этой сессии.
 >
-> **🔴 ВТОРАЯ ГИПОТЕЗА (не проверена):** в логах бриджа при reverse-трафике видно `proxy/freedom: applying default private IP blocking policy for inbound vless-reverse`. Если эта политика применится и к `lan-in`, до `192.168.2.x` не дойдёт — тот же класс, что issue #6612. Требует проверки по факту прохода.
->
-> **Осталось:** (1) сквозной тест **с Mac**; (2) правка 3 — маршрут на ASUS через веб-UI (SSH `192.168.1.1:22` закрыт); (3) персистентность iptables — `iptables-persistent` **НЕ установлен** на Кра́кене, нужен systemd oneshot-юнит (пакет ставить не стали).
+> **✅ ПОЛЕЗНЫЕ ПОБОЧНЫЕ НАХОДКИ (сохранить, не терять):**
+> - ✅ **ASUS SSH РАБОТАЕТ:** `ssh -i ~/.ssh/id_rsa admin@192.168.1.1` (пользователь **`admin`**, не `root`). Порт 22 открыт. Прежний вывод «ASUS не пускает по SSH» — **ошибка**: подключался как `root`. Маршруты правятся через `nvram lan_route` (формат `NET:MASK:GW:METRIC`), не через UI.
+> - ✅ **Reverse-канал ВПЕРВЫЕ подтверждён end-to-end** после починки гонки docker↔mount 2026-09-20: через SOCKS портала `92.62.77.233` ≠ напрямую `90.189.160.148`.
+> - ⚠️ **WAN-IP Кра́кена изменился:** `92.62.70.41` → **`92.62.77.233`**. В `kraken-access.md` / `xray-reverse-tunnel-*` фигурирует старый — актуализировать при следующей правке.
 
 > **Исходный статус на момент планирования: ПРЕДЛОЖЕНО.** План согласован к выполнению 2026-09-23.
 
@@ -80,9 +81,51 @@ TrueNAS 192.168.2.197  ── сеть 192.168.2.0/24 (шлюз OpenWrt 192.168.
 
 **Чтобы ASUS мог что-то отправить, бриджу нужна точка входа. Сейчас её нет** — `inbounds: null`. Пока правка 1 не сделана, схема физически не может работать.
 
-## Три правки
+## 🔴 КРИТИЧНАЯ НАХОДКА (2026-09-23) — направление перевёрнуто
 
-### Правка 1 — Кра́кен: прозрачный перехват (`dokodemo-door` + REDIRECT)
+Прогнано вживую. Цепочка «ASUS → Кра́кен → туннель → TrueNAS → 192.168.2.x» **не работает архитектурно**, а не из-за конфига.
+
+**Что происходит по факту:**
+| Шаг | Лог | Результат |
+|---|---|---|
+| Mac → Кра́кен `lan-in` | `accepted tcp:192.168.2.197:80 [lan-in -> conn]` | ✅ перехват, уход в туннель |
+| Туннель → портал | `received request for tcp:192.168.2.197:80` | ✅ дошло |
+| Портал выпускает | `for safety reasons, user a81c3179-… is not allowed to use forward proxy` | ❌ **отклонено** |
+
+**Причина (официальная дока Xray, freedom outbound):**
+> Traffic from **VLESS reverse proxy** blocks **all targets** by default. VLESS/VMess/Trojan/Shadowsocks inbounds block **private and reserved IP ranges** by default. To allow clients access to internal services, explicitly configure `allow` rules.
+
+Портал видит соединение «клиент просит сходить на `192.168.2.197`» и классифицирует это как **forward proxy** — то есть как попытку использовать сервер как открытый прокси. Отсюда отказ.
+
+**Правильное направление (Use Case 2 «Remote Return Home» из доки Xray):**
+
+```
+клиент → PUBLIC SERVER (TrueNAS, портал) → reverse-out → туннель
+                                                            ↓
+                                      INTERNAL DEVICE (Кра́кен, бридж)
+                                                            ↓
+                                              freedom + finalRules allow
+                                                            ↓
+                                                  192.168.2.0/24
+```
+
+То есть **точка входа должна быть на TrueNAS (портал)**, а `reverse-in → freedom с finalRules[allow ip 192.168.2.0/24]` — **на Кра́кене (бридж)**.
+
+🔴 **Мой план был построен на перевёрнутой схеме** — «ASUS → Кра́кен → в подсеть». В этой архитектуре Кра́кен выступает «домашней» стороной, и именно ему нужен allow-rule, а вход — на TrueNAS.
+
+**Проверенные факты по пути (сохранить):**
+- `dokodemo-door` **обязан** слушать `0.0.0.0`, не `127.0.0.1` — иначе REDIRECT-трафик с внешнего адреса не принимается.
+- `iptables -t nat PREROUTING` **не действует** на локально-исходящий трафик с самого хоста — для теста нужен отдельный netns либо реальный клиент из сети.
+- `redirect: ""` в freedom — невалидно; пустая строка ломает конфиг.
+- Xray 26.4.25: `xray run -test` **читает stdin** и виснет под SSH без `< /dev/null`.
+- Кра́кен: `sudo` через SSH требует `< /dev/null` на каждой команде, иначе `Connection closed by remote host`.
+- На Кра́кене **нет `ifconfig`** — каждый вызов печатает `command not found` в stderr (безвредно, но засоряет вывод).
+
+## Три правки (СУПЕРСИДЕД — см. находку выше)
+
+### Правка 1 — Кра́кен: `dokodemo-door` + REDIRECT (сделано, но НЕ тот вход)
+
+Файл `/home/kraken/xray-reverse/config.json`. Применено, канал работает, но это вход **не с той стороны** — см. находку выше. Требует пересмотра.
 
 Файл `/home/kraken/xray-reverse/config.json` (bind-mount `:ro` → `/etc/xray/config.json`).
 
@@ -162,22 +205,44 @@ Xray из REDIRECT-сокета читает `SO_ORIGINAL_DST` → узнаёт
 - ⚠️ Правка конфига на TrueNAS: папка `/mnt/RED_2TB/docker/reverse-portal/` — права root, `truenas_admin` писать не может. Класть через `docker run --rm -v /tmp:/src -v <dst>:/dst alpine cp …` + `chown`.
 - Бэкап ДО: `config.json.bak-lan-route-<date>`.
 
-### Правка 3 — ASUS: статический маршрут
+### Правка 3 — ASUS: статический маршрут ✅ ВЫПОЛНЕНО (не через UI)
 
-SSH закрыт (`Connection closed` на `:22`), поэтому — **веб-UI**:
-`http://192.168.1.1` → LAN → Route → добавить:
+✅ **ASUS доступен по SSH** — прежняя запись «SSH закрыт, только веб-UI» **ОШИБОЧНА**. Правильный вход:
+```bash
+ssh -i ~/.ssh/id_rsa admin@192.168.1.1     # пользователь admin, НЕ root
+```
+Порт 22 открыт; подключение как `root` даёт `Connection closed` — отсюда ложный вывод.
 
-| Поле | Значение |
-|---|---|
-| Network/Host IP | `192.168.2.0` |
-| Netmask | `255.255.255.0` |
-| Gateway | `192.168.1.15` (Кра́кен) |
-| Metric | `1` |
-| Interface | `LAN` |
+**Механизм статических маршрутов — `nvram`, не UI.** Формат `NET:MASK:GW:METRIC` в одной строке:
+```bash
+nvram get lan_route     # → 192.168.2.0:255.255.255.0:192.168.1.2:25
+nvram set lan_route="192.168.2.0:255.255.255.0:192.168.1.15:25"
+nvram commit
+```
+⚠️ `service restart_routing` **НЕ перечитывает** `lan_route` (проверено — таблица осталась со старым шлюзом). Применять явно:
+```bash
+ip route del 192.168.2.0/24 via 192.168.1.2 dev br0
+ip route add 192.168.2.0/24 via 192.168.1.15 dev br0 metric 25
+```
+Бэкап: `nvram get lan_route > /jffs/lan_route.bak.$(date +%Y%m%d-%H%M%S)`
 
-⚠️ Кра́кен имеет **два** адреса в `192.168.1.0/24`: `.14` (eth0) и `.15` (wlan0). В доке `rasputin-router` зафиксировано: ARP на Распутине резолвит оба в **один** lladdr `2c:cf:67:64:03:f3`. Использовать **`.15`**, как в DNS-записи `address=/kraken/192.168.1.15`.
+⚠️ Кра́кен имеет **два** адреса в `192.168.1.0/24`: `.14` (eth0, metric 100) и `.15` (wlan0, metric 600), **разные MAC** (`…03:f3` / `…03:f4`). Использовать **`.15`**, как в DNS-записи `address=/kraken/192.168.1.15`.
 
-⚠️ Правило действует на всем сегменте — **все** клиенты `192.168.1.0/24` пойдут на `192.168.2.x` через туннель. Если нужно выборочно — вместо маршрута на ASUS делать routing на конкретном клиенте, но тогда ASUS не нужен вовсе.
+⚠️ Маршрут действует на всём сегменте — **все** клиенты `192.168.1.0/24` пойдут на `192.168.2.x` через `.15`. Если нужно выборочно — routing на конкретном клиенте, но тогда ASUS не нужен.
+
+## 🏁 РАЗВИЛКА — решение НЕ принято (2026-09-23)
+
+Тупик: Xray reverse **по дизайну** не пропускает forward-proxy трафик в приватные сети. Направление «ASUS → Кра́кен → в сеть TrueNAS» реализовать нельзя — только обратное («дом = Кра́кен», цель = `192.168.1.x`), что не решает задачу.
+
+| # | Вариант | Что даёт | Цена |
+|---|---|---|---|
+| **1** | **Отказаться**, откатить всё из бэкапов | возврат к исходному состоянию | теряется только то, чего и не было |
+| **2** | SOCKS-прокси на стороне **клиента** (Mac) — через существующий `vless-proxy` (SOCKS `:1080`) / `xray-admin` | доступ к `192.168.2.x` с Mac | не «через ASUS»; нужен SOCKS-aware клиент или routing на Mac; не работает для других устройств |
+| **3** | **WireGuard на TrueNAS** (белый IP + открытый порт уже есть) | **полный IP-стек**: ICMP, UDP, Samba-обзор, «как локальный» | новая служба на TrueNAS; TrueNAS на пределе RAM (17/21 ГБ) |
+
+**Рекомендация:** вариант **3** — если нужен реально «true VPN» с UDP и Samba; вариант **2** — если хватит доступа с одного Mac.
+
+⚠️ **Вариант 2 ограничен:** `docker exec vless-proxy wget` **не проверяет SOCKS** (wget не умеет SOCKS5, вернёт локальный IP) — проверять только через `curl --socks5-hostname`.
 
 ## Как это будет работать
 
@@ -226,13 +291,13 @@ TrueNAS: xray-reverse-portal
 | 4 | Проверка, что канал не порвался после рестарта портала | ✅ egress `92.62.77.233` |
 | 5 | Правка 1 (Кра́кен, бридж) | ✅ выполнено, `Configuration OK.`, бридж Up |
 | 6 | Правило iptables REDIRECT на Кра́кене | ✅ добавлено, inbound слушает |
-| 7 | **Сквозной тест** | 🔴 **НЕ ПРОЙДЕН** — тест с Кра́кена методологически неверен |
-| 8 | Повторный тест **с Mac** (посторонний хост) | ⏳ ждёт апрува команды |
-| 9 | Фикс private-IP-политики (если подтвердится) | ⏳ по результату п.8 |
-| 10 | Персистентность iptables (systemd-юнит) | ⏳ не начато |
-| 11 | Правка 3 — маршрут на ASUS через UI | ⏳ руками Alex |
-| 12 | Финальная проверка Alex'ом: `http://192.168.2.197:8096` в браузере | ⏳ |
-| 13 | Обновить `personal/tech/xray-reverse-tunnel-kraken-truenas.md` + `family/how-to/truenas-infrastructure.md` | ⏳ |
+| 7 | **Сквозной тест** | ✅ **ПРОЙДЕН ЧАСТИЧНО** — перехват работает, но портал режет forward-proxy |
+| 8 | Повторный тест **с Mac** (посторонний хост) | ✅ выполнен — `HTTP 000` + отказ портала |
+| 9 | Диагностика отказа портала | ✅ `not allowed to use forward proxy` — **штатная защита Xray** |
+| 10 | Диагностика ASUS-маршрута | ✅ SSH найден, битый `lan_route` → `.2` исправлен на `.15` |
+| 11 | **Вывод: архитектурный тупик** | 🏁 зафиксирован, решение Alex **не принято** |
+| 12 | Откат или переход к варианту 2/3 | ⏳ ждёт решения |
+| 13 | Обновить `personal/tech/xray-reverse-tunnel-kraken-truenas.md` | ⏳ |
 
 ### 🔴 Как правильно проверять сквозной проход