[2026-09-23] eagle: family/how-to/router-bishkek-asus.md personal/plans/lan-access-via-reverse-tunnel.md personal/tech/xray-reverse-tunnel-kraken-truenas.md
This commit is contained in:
Alexey Martemyanov committed
1 parent
bf2a1aa850
commit
00beffc97f
3 files changed
+163
-36
No files matched your search
@@ -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, НЕ конфиг и НЕ версия
|
||||
>
|
||||
|
||||
Reference in new issue
Block a user