diff --git a/family/how-to/router-bishkek-asus.md b/family/how-to/router-bishkek-asus.md index 726ff572..12521c9f 100644 --- a/family/how-to/router-bishkek-asus.md +++ b/family/how-to/router-bishkek-asus.md @@ -18,6 +18,57 @@ ssh -i ~/.ssh/id_rsa admin@192.168.1.1 Ключ хранится в `/home/root/.ssh/authorized_keys` на роутере. +> ⚠️ **Пользователь — `admin`, НЕ `root`.** Подключение как `root@192.168.1.1` даёт `Connection closed by 192.168.1.1 port 22` (порт при этом **открыт**, `nc -z` проходит) — и это **легко принять за «SSH на роутере сломан»**. Проверено 2026-09-23: полчаса диагностики потеряно именно на этом. Если SSH «не пускает» — первым делом проверить, что пользователь `admin`. + +## Статические маршруты — `nvram lan_route` (НЕ через веб-UI) + +Добавление маршрута в UI **не требуется** — на Merlin/Asuswrt маршруты живут в одной nvram-строке. **Формат: `NET:MASK:GATEWAY:METRIC`**, несколько маршрутов разделяются `>`. + +```bash +# Посмотреть текущее +ssh -i ~/.ssh/id_rsa admin@192.168.1.1 'nvram get lan_route' +# → 192.168.2.0:255.255.255.0:192.168.1.2:25 + +# Бэкап ПЕРЕД правкой (обязательно) +ssh -i ~/.ssh/id_rsa admin@192.168.1.1 \ + 'nvram get lan_route > /jffs/lan_route.bak.$(date +%Y%m%d-%H%M%S)' + +# Правка +ssh -i ~/.ssh/id_rsa admin@192.168.1.1 \ + 'nvram set lan_route="192.168.2.0:255.255.255.0:192.168.1.15:25" && nvram commit' +``` + +### 🔴 `service restart_routing` НЕ перечитывает `lan_route` + +После `nvram commit` живая таблица маршрутизации **остаётся старой** (проверено 2026-09-23 — таблица сохранила прежний шлюз). `service restart_routing` / `restart_wan` не помогают. + +**Применять явно, вручную:** + +```bash +ssh -i ~/.ssh/id_rsa admin@192.168.1.1 \ + 'ip route del 192.168.2.0/24 via <СТАРЫЙ_GW> dev br0 2>/dev/null; \ + ip route add 192.168.2.0/24 via <НОВЫЙ_GW> dev br0 metric 25' + +# Проверка — nvram И живая таблица должны совпадать +ssh -i ~/.ssh/id_rsa admin@192.168.1.1 'nvram get lan_route; ip route | grep 192.168.2' +``` + +> ⚠️ **Расхождение nvram ↔ живая таблица — типовая ловушка.** `nvram get` показывает «уже поправлено», а трафик продолжает идти по старому маршруту. Всегда проверять **обе** стороны. + +### 🔴 Обнаружен битый маршрут `192.168.2.0/24 → 192.168.1.2` (2026-09-23, НЕ исправлен) + +`192.168.1.2` — **мёртвый адрес**: ARP `FAILED`, MAC нулевой (`00:00:00:00:00:00`), порт 22 закрыт. Маршрут ведёт в никуда — **любой** трафик на `192.168.2.x` с клиентов `192.168.1.0/24` умирает молча (timeout). + +Обнаружено попутно; **предсуществующая поломка**, не создана в этой сессии. Оставлено как было по решению Alex. **Кандидат на очистку отдельной задачей.** + +**Диагностический признак битого шлюза:** +```bash +ssh -i ~/.ssh/id_rsa admin@192.168.1.1 'cat /proc/net/arp | grep 192.168.1.2' +# 192.168.1.2 0x1 0x0 00:00:00:00:00:00 * br0 ← MAC нулевой = адреса нет +ssh -i ~/.ssh/id_rsa admin@192.168.1.1 'ip neigh show dev br0 | grep 192.168.1.2' +# 192.168.1.2 FAILED ← подтверждение +``` + ## DNS конфигурация ### Upstream DNS (WAN) diff --git a/personal/plans/lan-access-via-reverse-tunnel.md b/personal/plans/lan-access-via-reverse-tunnel.md index e318710a..00e7e27f 100644 --- a/personal/plans/lan-access-via-reverse-tunnel.md +++ b/personal/plans/lan-access-via-reverse-tunnel.md @@ -11,7 +11,7 @@ tags: - asus - routing - vpn -status: stopped-architectural-deadlock +status: closed-rolled-back updated: '2026-09-23' related: - '[[personal/tech/xray-reverse-tunnel-kraken-truenas]]' @@ -21,22 +21,37 @@ related: --- # Доступ к 192.168.2.0/24 с ASUS через reverse-туннель Kraken→TrueNAS -> ## 🏁 СТАТУС: ОСТАНОВЛЕНО (2026-09-23, вечер). Архитектурный тупик, схема НЕ доведена. +> ## 🏁 СТАТУС: ЗАКРЫТО, ВСЁ ОТКАЧЕНО (2026-09-23, вечер). Архитектурный тупик. Схема НЕ реализована. > -> **Итог:** цепочка «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`. Направление задачи и направление туннеля не совпадают. +> **Итог задачи:** цепочка «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`. Направление задачи и направление туннеля не совпадают. > -> **Решение Alex:** НЕ принято. Варианты в разделе «Развилка» ниже. Откат возможен в одну команду из бэкапов. +> **Решение Alex: ОТКАТЫВАТЬ.** Выполнено 2026-09-23 — все три узла возвращены в исходное состояние. См. раздел «✅ ОТКАТ ВЫПОЛНЕН» ниже. > -> **Что осталось применённым на системах (требует решения — откатить или оставить):** -> - Кра́кен: 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-`, `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` уходил в никуда. Это была **предсуществующая поломка**, не созданная в этой сессии. +> ### ✅ ОТКАТ ВЫПОЛНЕН (2026-09-23) — фактическое состояние систем +> +> | Узел | Что было моё | Стало | Проверка | +> |---|---|---|---| +> | **Кра́кен** | inbound `lan-in` (`dokodemo-door` `0.0.0.0:12345`), outbound `home-lan`, routing `lan-in → conn`, правило `iptables nat PREROUTING` REDIRECT | ✅ исходный конфиг (`inbounds: false`, outbounds `direct`+`conn`, routing `reverse-in → direct`), iptables чист, netns `lantest` удалён | порт 12345 **не слушается**; лог `received request for udp:reverse:0` — канал жив | +> | **TrueNAS портал** | routing-правило `192.168.2.0/24 → direct` + outbound `direct` с `finalRules` | ✅ исходный (`routing = [{local → reverse-out}]`, один placeholder-freedom) | после рестарта `dispatching request to udp:reverse:0` | +> | **ASUS** | `nvram lan_route` → `192.168.1.15` | ✅ возвращён `192.168.2.0:255.255.255.0:192.168.1.2:25` (как было) | `nvram get lan_route` + живая таблица маршрутов совпадают | +> +> **Бэкапы оставлены (не удалялись):** +> - Кра́кен: `config.json.bak-lan-in-20260923-130541`, `config.json.bak-listen0000-20260923-131655`, `config.json.bak-listen0000-20260923-132108`, `config.json.bak-v3-20260923-132753`, `config.json.pre-rollback-`, `iptables.bak-20260923-130541` (в `/home/kraken/backups/`) +> - TrueNAS: `config.json.before-lanroute` (эталон отката), `config.json.pre-rollback` +> - ASUS: `/jffs/lan_route.bak.20260923-131613` +> +> ⚠️ **Не подтверждено:** финальный тест egress через туннель (`92.62.77.233`) не был прогнан — истёк апрув на команду. Оба конца логируют установку канала (`udp:reverse:0` с обеих сторон), поэтому канал живой. Команда для самостоятельной проверки: +> ```bash +> ssh truenas_admin@mallexxx.duckdns.org "docker run --rm --network caddy_default curlimages/curl curl -s --max-time 20 --socks5-hostname xray-reverse-portal:12345 https://api.ipify.org" +> # ожидается 92.62.77.233 +> ``` +> +> ⚠️ **Оставлено как было, сознательно:** маршрут на ASUS `192.168.2.0/24 → 192.168.1.2` **битый** — `192.168.1.2` мёртв (ARP `FAILED`, MAC нулевой, порт закрыт). Это **предсуществующая поломка**, не созданная в этой сессии; Alex решил только откатывать. Кандидат на отдельную задачу — убрать. > > **✅ ПОЛЕЗНЫЕ ПОБОЧНЫЕ НАХОДКИ (сохранить, не терять):** > - ✅ **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-*` фигурирует старый — актуализировать при следующей правке. +> - ⚠️ **WAN-IP Кра́кена изменился:** `92.62.70.41` → **`92.62.77.233`**. В `kraken-access.md` / `xray-reverse-tunnel-*` фигурирует старый — актуализировать при следующей правке (в этой сессии правка тех-доков НЕ выполнялась, см. незакрытый пункт в таблице исполнения). > **Исходный статус на момент планирования: ПРЕДЛОЖЕНО.** План согласован к выполнению 2026-09-23. @@ -75,11 +90,11 @@ TrueNAS 192.168.2.197 ── сеть 192.168.2.0/24 (шлюз OpenWrt 192.168. > ✅ **НОВЫЙ ФАКТ (нет в других доках):** пассивная проверка дала `92.62.77.233` — **WAN-IP Кра́кена изменился** (в доке фигурирует `92.62.70.41`). Канал впервые подтверждён end-to-end после починки гонки docker↔mount 2026-09-20. -## Блокер +## Блокер (историческая фиксация первых часов работы) -`reverse` в Xray **асимметричен**: на бридже (Кра́кен) создаётся виртуальный inbound `reverse-in` (трафик *из* портала *в* бридж), на портале (TrueNAS) — маутбаунд `reverse-out`. Портал сейчас роутит `inboundTag:["local"] → reverse-out`, то есть SOCKS `:12345` на самом TrueNAS. +`reverse` в Xray **асимметричен**: на бридже (Кра́кен) создаётся виртуальный inbound `reverse-in` (трафик *из* портала *в* бридж), на портале (TrueNAS) — маутбаунд `reverse-out`. Портал роутит `inboundTag:["local"] → reverse-out`, то есть SOCKS `:12345` на самом TrueNAS. -**Чтобы ASUS мог что-то отправить, бриджу нужна точка входа. Сейчас её нет** — `inbounds: null`. Пока правка 1 не сделана, схема физически не может работать. +**Первоначальный (ошибочный) вывод:** «бриджу нужна точка входа, `inbounds: null`». Точка входа действительно была добавлена (`dokodemo-door`) и **работала** — но это оказалось входом **не с той стороны**. Реальный блокер вскрыт ниже: портал отказывается выпускать трафик в приватную сеть. См. «🔴 КРИТИЧНАЯ НАХОДКА». ## 🔴 КРИТИЧНАЯ НАХОДКА (2026-09-23) — направление перевёрнуто @@ -295,9 +310,10 @@ TrueNAS: xray-reverse-portal | 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` | ⏳ | +| 11 | **Вывод: архитектурный тупик** | 🏁 зафиксирован | +| 12 | **Решение Alex: откатывать** | ✅ **ОТКАТ ВЫПОЛНЕН** — все 3 узла в исходном состоянии, проверено | +| 13 | Обновить `personal/tech/xray-reverse-tunnel-kraken-truenas.md` (WAN-IP `92.62.77.233`, факт живого канала после 2026-09-20) | ⏳ **НЕ ВЫПОЛНЕНО** — тех-доки не правились | +| 14 | Убрать битый маршрут `192.168.2.0/24 → 192.168.1.2` на ASUS | ⏳ отдельная задача, не входила в команду | ### 🔴 Как правильно проверять сквозной проход @@ -335,11 +351,35 @@ sudo iptables -t nat -A PREROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 \ -p tcp -j REDIRECT --to-ports 12345 ``` -## Откат +## Откат — ✅ ВЫПОЛНЕН (команды, воспроизводимые) -- Кра́кен: вернуть `config.json.bak-lan-in-`, `docker restart xray-reverse-bridge`. -- TrueNAS: вернуть `config.json.bak-lan-route-`, `docker restart xray-reverse-portal`. -- ASUS: удалить маршрут в UI. +```bash +# 1. КРА́КЕН — вернуть конфиг без 'inbounds' (исходный), убрать REDIRECT, перезапустить +ssh kraken 'sudo bash /tmp/rollback-bridge.sh' # скрипт выбирает бэкап с inbounds=false +ssh kraken 'sudo iptables -t nat -D PREROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 -p tcp \ + -j REDIRECT --to-ports 12345' +ssh kraken 'sudo ip netns del lantest; sudo ip link del veth-test-h' # убрать тестовый netns +ssh kraken 'sudo docker restart xray-reverse-bridge' +# проверка: порт 12345 не слушается; лог 'received request for udp:reverse:0' + +# 2. TRUENAS — вернуть портал (папка root-owned → через alpine-контейнер) +ssh truenas_admin@mallexxx.duckdns.org 'docker run --rm \ + -v /mnt/RED_2TB/docker/reverse-portal:/dst alpine sh -c \ + "cp /dst/config.json.before-lanroute /dst/config.json && chown 950:950 /dst/config.json"' +ssh truenas_admin@mallexxx.duckdns.org 'docker restart xray-reverse-portal' +# проверка: routing = [{local → reverse-out}], лог 'dispatching request to udp:reverse:0' + +# 3. ASUS — вернуть nvram и живую таблицу +ssh -i ~/.ssh/id_rsa admin@192.168.1.1 \ + 'nvram set lan_route="192.168.2.0:255.255.255.0:192.168.1.2:25" && nvram commit' +ssh -i ~/.ssh/id_rsa admin@192.168.1.1 \ + 'ip route del 192.168.2.0/24 via 192.168.1.15 dev br0; \ + ip route add 192.168.2.0/24 via 192.168.1.2 dev br0 metric 25' +``` + +⚠️ **Питфолл отката портала:** файл восстанавливается мгновенно, но контейнер держит старый конфиг в памяти — **обязателен `docker restart`**, иначе `docker exec … cat` покажет уже новый файл при работающем старом конфиге (ложное «откатилось»). + +⚠️ **Питфолл отката бриджа:** среди бэкапов есть и «промежуточные плохие» (`bak-listen0000-*`, `bak-v3-*`). Верный исходный — тот, где `has("inbounds")` = `false`. Скрипт `rollback-bridge.sh` выбирает его автоматически; вручную — проверять `jq -r 'has("inbounds")' ` **перед** копированием. ## Связанные заметки diff --git a/personal/tech/xray-reverse-tunnel-kraken-truenas.md b/personal/tech/xray-reverse-tunnel-kraken-truenas.md index 65458902..4f3febe3 100644 --- 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-20' +updated: '2026-09-23' type: tech namespace: personal tags: @@ -56,25 +56,61 @@ verified_fix_2026_09_02: >- > ### Вывод для `kraken-user` > Правило `kraken-user-via-reverse` (user `kraken-user` → outbound `via-kraken` → SOCKS `xray-reverse-portal:12345`) **прописано в шаблоне 3x-ui** и, судя по живому каналу, должно работать. **End-to-end с клиентом `kraken-user` в этой сессии НЕ перепроверялся** — проверен только сам канал через SOCKS портала. Это разные вещи: канал может быть жив, а клиентский маршрут — нет. > -> ### Новый план использования этого канала -> Задача «доступ к `192.168.2.x` как к локальным адресам» (запрос Alex 2026-09-23) разобрана в отдельном плане: **[[personal/plans/lan-access-via-reverse-tunnel]]**. Ключевое открытие оттуда: `xray-reverse-bridge` **не имеет `inbounds`** (ключи конфига только `log`/`outbounds`/`routing`) — канал есть, но принять трафик от роутера бриджу нечем. Это недостающий кусок для схемы. +> ### Новый план использования этого канала — ❌ ЗАКРЫТ +> Задача «доступ к `192.168.2.x` как к локальным адресам» (запрос Alex 2026-09-23) разобрана в плане **[[personal/plans/lan-access-via-reverse-tunnel]]**. Итог: **через Xray reverse не реализуется** — портал отклоняет как forward-proxy (см. раздел «🚫 АРХИТЕКТУРНЫЙ ПРЕДЕЛ» ниже). Эксперимент откачен 2026-09-23. > -> ### 🔧 ЧТО ПРИМЕНЕНО 2026-09-23 (детали — в плане) -> Обе правки конфигов **выполнены и завалидированы** (`xray run -test` → `Configuration OK.` на обоих), контейнеры перезапущены, канал после рестарта жив (`92.62.77.233`). Сквозной проход **не подтверждён** (см. питфолл ниже). +> ### 🔧 ЭКСПЕРИМЕНТ 2026-09-23: ОТКАЧЕН, КАНАЛ НЕ ТРОНУТ (детали — в плане) +> Обе правки конфигов были **выполнены, завалидированы** (`xray run -test` → `Configuration OK.`) и протестированы. Сквозной проход **НЕ получился** — вскрыт архитектурный предел (см. раздел ниже). По решению Alex **всё откачено 2026-09-23**; канал `kraken-user` вернулся в исходное рабочее состояние. > -> | Что | Файл | Изменение | +> | Что | Файл | Изменение (ОТКАЧЕНО) | > |---|---|---| -> | Бридж (Кра́кен) | `/home/kraken/xray-reverse/config.json` | **добавлен inbound** `lan-in`: `dokodemo-door`, `listen 127.0.0.1:12345`, `followRedirect:true`, `sniffing:false` + routing `lan-in → conn` | -> | Портал (TrueNAS) | `/mnt/RED_2TB/docker/reverse-portal/config.json` | outbound `direct` создан с `finalRules:[{action:"allow"}]`; routing-правило `192.168.2.0/24 → direct` **выше** `local → reverse-out` | -> | Хост Кра́кена | iptables | `nat PREROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 -p tcp -j REDIRECT --to-ports 12345` | +> | ~~Бридж (Кра́кен)~~ | `/home/kraken/xray-reverse/config.json` | ~~inbound `lan-in`: `dokodemo-door`, `0.0.0.0:12345`, `followRedirect:true` + routing `lan-in → conn`~~ → **возвращён исходный (`inbounds: false`)** | +> | ~~Портал (TrueNAS)~~ | `/mnt/RED_2TB/docker/reverse-portal/config.json` | ~~outbound `direct` + routing `192.168.2.0/24 → direct`~~ → **возвращён исходный (`local → reverse-out`)** | +> | ~~Хост Кра́кена~~ | iptables | ~~`nat PREROUTING REDIRECT --to-ports 12345`~~ → **правило удалено**, `PREROUTING` чист | > -> Бэкапы: `/home/kraken/xray-reverse/config.json.bak-lan-in-20260923-130541`, `/home/kraken/backups/iptables.bak-20260923-130541`, `/mnt/RED_2TB/docker/reverse-portal/config.json.before-lanroute`. -> -> ⚠️ **`iptables-persistent` на Кра́кене НЕ установлен** — правило REDIRECT не переживёт reboot, нужен systemd oneshot-юнит (не сделан). -> -> 🔴 **ПИТФОЛЛ ДИАГНОСТИКИ `REDIRECT` (стоил ложного вывода):** нельзя проверять проход, запуская `curl` **с того же хоста, где стоит правило**. Локально-исходящий трафик идёт через `nat OUTPUT`, `PREROUTING` его не видит → счётчик правила = 0, `curl` → `HTTP 000`. Это **ложный негатив, а не доказательство поломки**. Проверять только с постороннего хоста (Mac в `192.168.1.x`) либо транзитным трафиком из контейнера с кастомным маршрутом. Контроль — счётчик: `iptables -t nat -L PREROUTING -n -v | grep 12345`. -> -> ⚠️ **Гипотеза, требующая проверки:** в логах бриджа видно `proxy/freedom: applying default private IP blocking policy for inbound vless-reverse`. Если private-IP-политика `freedom` применится и к новому inbound `lan-in`, трафик до `192.168.2.x` не дойдёт. Тот же класс проблемы, что issue #6612. +> Бэкапы (сохранены): `/home/kraken/xray-reverse/config.json.bak-lan-in-20260923-130541`, `config.json.bak-v3-20260923-132753`, `/home/kraken/backups/iptables.bak-20260923-130541`, `/mnt/RED_2TB/docker/reverse-portal/config.json.before-lanroute`. + +## 🚫 АРХИТЕКТУРНЫЙ ПРЕДЕЛ Xray REVERSE: forward-proxy в приватную сеть ЗАПРЕЩЁН (2026-09-23) + +> Это **не** баг конфига, **не** версия и **не** REALITY. Это **намеренная защита Xray**, и её надо знать до того, как планировать подобные схемы. + +**Попытка:** завернуть трафик клиентов `192.168.1.0/24` в адреса `192.168.2.x` (сеть TrueNAS) через reverse-канал Кра́кен↔TrueNAS. + +**Результат — цепочка доходит до портала и там умирает:** + +| Шаг | Лог | Итог | +|---|---|---| +| Mac → Кра́кен `lan-in` | `accepted tcp:192.168.2.197:80 [lan-in -> conn]` | ✅ перехват, трафик ушёл в туннель | +| Туннель → портал | `received request for tcp:192.168.2.197:80` | ✅ дошло до TrueNAS | +| Портал выпускает | `for safety reasons, user a81c3179-… is not allowed to use forward proxy` | ❌ **отклонено** | + +**Официальное обоснование** (дока Xray, outbound `freedom`): +> 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** — попытку использовать сервер как открытый прокси. `finalRules`-allow в принципе позволяет обойти, **но** тогда «домашней» (внутренней) стороной обязан быть **Кра́кен**, а целевой сетью — **его** локалка `192.168.1.x`. Цель `192.168.2.x` при этом недостижима: reverse-канал выдаёт `reverse-out` на портале и `reverse-in` на бридже, а не наоборот. + +**Вывод:** направление задачи («в подсеть TrueNAS из сети Кра́кена») **не совпадает** с направлением, которое поддерживает reverse-архитектура. Через Xray reverse это **не реализуется** — нужна другая технология (WireGuard / обычный forward-прокси на клиенте). + +**Релевантный use case из доки — только «Remote Return Home»** (`xtls.github.io/en/document/level-2/vless_reverse.html`, Use Case 2): клиент → **публичный сервер** → `reverse-out` → туннель → **внутреннее устройство** → его локалка. Ровно это и описано выше. + +**Рассмотренные и отклонённые альтернативы (2026-09-23):** +| # | Вариант | Почему не выбран | +|---|---|---| +| 1 | Отказаться, откатить | ✅ **выбрано Alex** | +| 2 | SOCKS на стороне клиента (Mac) через `vless-proxy :1080` / `xray-admin` | не «через ASUS»; нужен SOCKS-aware клиент или routing на Mac; не работает для других устройств | +| 3 | **WireGuard на TrueNAS** (белый IP + порт есть) | даёт полный IP-стек (ICMP, UDP, Samba-обзор) — **открытый вариант**, если задача вернётся; минус — новая служба на TrueNAS (RAM 17/21 ГБ, на пределе) | + +### Питфоллы, добытые в этом эксперименте (применимы к любой подобной задаче) + +| Питфолл | Суть | +|---|---| +| `dokodemo-door` + `127.0.0.1` **не принимает** REDIRECT-трафик | Пакет приходит с внешнего адреса клиента (`192.168.1.57`) — bind на loopback его отвергает (`HTTP 000` за 0.005 с). Нужен `listen: 0.0.0.0` (+ firewall). | +| `iptables nat PREROUTING` **не действует** на локально-исходящий трафик | Проверка `curl` с того же хоста, где стоит правило = **ложный негатив**: счётчик 0. Нужен посторонний хост либо транзит (netns / контейнер с кастомным маршрутом). | +| `redirect: ""` в `freedom` — невалидно | Пустая строка ломает конфиг. Не использовать как «не менять адрес». | +| `xray run -test` читает stdin | Под SSH **виснет** без `< /dev/null`. Касается и валидации, и любого `sudo`. | +| `sudo` через SSH на Кра́кене | Требует `< /dev/null`; иначе `Connection closed by remote host` / `Broken pipe`. Документированный питфолл — повторён дважды за сессию. | +| На Кра́кене **нет `ifconfig`** | Каждый вызов печатает `command not found` в stderr (засоряет вывод, безвредно). Использовать `ip`/`ip addr`. | +| Тест `PHY`/транзита на однохостовой машине | Для эмуляции «другого хоста в сети» использован `ip netns` + veth — рабочий приём; **обязательно** убирать за собой (`ip netns del`, `ip link del`). | > ## ✅ 2026-09-20 — КОРЕНЬ 2026-09-15 НАЙДЕН: ГОНКА Docker ↔ mount, НЕ конфиг и НЕ версия >