[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-tunnel-kraken-truenas.md
This commit is contained in:
Alexey Martemyanov committed
1 parent
ef5ba570a3
commit
ae27c7f001
4 files changed
+120
-14
No files matched your search
@@ -157,8 +157,14 @@ EP=3 # endpoint ID на Кракене = 3, не 1!
|
||||
|
||||
- Контейнер **`xray-reverse-bridge`** в `/home/kraken/xray-reverse/` (compose + `config.json`), образ **`teddysun/xray:26.4.25`** + `network_mode: host` (проверенный фикс 2026-09-02).
|
||||
- Outbound VLESS+REALITY TCP → `mallexxx.duckdns.org:12346` (TrueNAS через OpenWrt DNAT), reverse tag `reverse-in`, egress freedom с `finalRules:[{action:allow}]`.
|
||||
- ✅ **End-to-end payload работает** (верифицировано 2026-09-02: SOCKS `12345` → egress IP Kraken `92.62.70.41`). Полная история диагностики (регрессии #6612/#6242, docker bridge/NAT) — в [[tech/xray-reverse-tunnel-kraken-truenas]].
|
||||
- ✅ **End-to-end payload работает** (верифицировано 2026-09-02: SOCKS `12345` → egress IP Кра́кена). Полная история диагностики (регрессии #6612/#6242, docker bridge/NAT) — в [[tech/xray-reverse-tunnel-kraken-truenas]].
|
||||
- ⚠️ 2026-09-15…20 контейнер был **не запущен** (гонка docker↔mount, см. шапку) — это единственная причина «туннель down». После рестарта daemon — снова Up.
|
||||
- ✅ **2026-09-23 — канал перепроверен end-to-end после починки гонки, работает.** Egress Кра́кена = **`92.62.77.233`**.
|
||||
> 🔴 **IP Кра́кена ИЗМЕНИЛСЯ:** `92.62.70.41` (старые записи) → **`92.62.77.233`** (2026-09-23). Во всех доках семейства `family/how-to/*` фигурирует старый `92.62.70.41` — **не доверять ему**, брать актуальный из живого запроса.
|
||||
- 🔧 **2026-09-23 — в конфиг бриджа добавлен inbound** `lan-in` (`dokodemo-door`, `listen 127.0.0.1:12345`, `followRedirect:true`) + правило `lan-in → conn`. Прежде `inbounds` было **`null`** — бридж мог только отправлять в туннель, принимать не мог. Плюс на хосте Кра́кена поставлено правило `iptables -t nat PREROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 -p tcp -j REDIRECT --to-ports 12345`.
|
||||
- Задача и полное состояние: [[personal/plans/lan-access-via-reverse-tunnel]]
|
||||
- ⚠️ **`iptables-persistent` НЕ установлен** — правило REDIRECT слетит при reboot.
|
||||
- ⚠️ Бэкапы: `config.json.bak-lan-in-20260923-130541`, `/home/kraken/backups/iptables.bak-20260923-130541`.
|
||||
|
||||
## Docker контейнеры (обновлено 2026-09-20, после фикса)
|
||||
|
||||
|
||||
@@ -558,7 +558,7 @@ nas_users:x:3000:root,truenas_admin,mallexxx,nas,transmission
|
||||
>
|
||||
> 🔴 **IP Кра́кена ИЗМЕНИЛСЯ: `92.62.70.41` → `92.62.77.233`.** Старый IP зафиксирован ниже в таблицах подписок и per-user egress — при проверках брать актуальный из живого запроса.
|
||||
>
|
||||
> ⚠️ **`xray-reverse-bridge` на Кра́кене не имеет `inbounds`** (ключи конфига: `log`/`outbounds`/`routing`; слушающих портов нет). Канал работает на отправку, но принять трафик от роутера бриджу **нечем**. План «доступ к `192.168.2.x` как к локальным» — [[personal/plans/lan-via-reverse-tunnel]].
|
||||
> ⚠️ **`xray-reverse-bridge` на Кра́кене не имеет `inbounds`** (ключи конфига: `log`/`outbounds`/`routing`; слушающих портов нет). Канал работает на отправку, но принять трафик от роутера бриджу **нечем**. План «доступ к `192.168.2.x` как к локальным» — [[personal/plans/lan-access-via-reverse-tunnel]].
|
||||
>
|
||||
> ⚠️ Проверка канала с TrueNAS (воспроизводимо):
|
||||
> ```bash
|
||||
@@ -568,6 +568,29 @@ nas_users:x:3000:root,truenas_admin,mallexxx,nas,transmission
|
||||
> # ожидаем IP Кра́кена, НЕ 90.189.160.148
|
||||
> ```
|
||||
|
||||
> ### 🔧 КОНФИГ ИЗМЕНЁН 2026-09-23 (задача «192.168.2.x как локальный»)
|
||||
>
|
||||
> **Файл:** `/mnt/RED_2TB/docker/reverse-portal/config.json` (bind-mount `:ro`).
|
||||
>
|
||||
> **Что добавлено:**
|
||||
> 1. **outbound `direct`** с `settings.finalRules:[{action:"allow"}]` + `domainStrategy:"AsIs"` (прежде был только безымянный placeholder `freedom`).
|
||||
> 2. **routing-правило** `{"type":"field","ip":["192.168.2.0/24"],"outboundTag":"direct"}` — поставлено **ВЫШЕ** правила `{"inboundTag":["local"],"outboundTag":"reverse-out"}`, иначе `local` его перехватил бы.
|
||||
> 3. `log.loglevel` сейчас `debug` (для диагностики, оставлен).
|
||||
>
|
||||
> **Валидация:** `docker run --rm -v /tmp:/etc/xray teddysun/xray:26.4.25 xray run -test -c …` → `Configuration OK.` Портал перезапущен (`docker restart`), Up, канал жив (`92.62.77.233`).
|
||||
>
|
||||
> **Заливка в root-owned папку (паттерн):**
|
||||
> ```bash
|
||||
> docker run --rm -v /tmp:/src -v /mnt/RED_2TB/docker/reverse-portal:/dst alpine \
|
||||
> sh -c "cp /src/portal-config-new.json /dst/config.json && chown 950:950 /dst/config.json"
|
||||
> ```
|
||||
>
|
||||
> **Бэкап ДО:** `/mnt/RED_2TB/docker/reverse-portal/config.json.before-lanroute` (плюс исторические `config.json.bak-reality-vision-20260902-1142`, `.bak-plain-host-working-20260902-1146`, `.bak-flow-20260902-1140`).
|
||||
>
|
||||
> **Локальный эталон на Mac:** `/Users/admin/tmp-lan-tunnel/portal-config-new.json`
|
||||
>
|
||||
> 🔴 **Сквозной проход НЕ подтверждён.** Тест с самого Кра́кена дал `HTTP 000` и счётчик REDIRECT-правила `0` — но это **ложный негатив**: локально-исходящий трафик идёт через `nat OUTPUT`, а не `PREROUTING`. Проверять **только с постороннего хоста**. Полное состояние и питфоллы — [[personal/plans/lan-access-via-reverse-tunnel]].
|
||||
|
||||
| Параметр | Значение |
|
||||
|----------|----------|
|
||||
| Папка | `/mnt/RED_2TB/docker/reverse-portal/` |
|
||||
|
||||
@@ -11,7 +11,8 @@ tags:
|
||||
- asus
|
||||
- routing
|
||||
- vpn
|
||||
status: proposed
|
||||
status: partially-applied
|
||||
updated: '2026-09-23'
|
||||
related:
|
||||
- '[[personal/tech/xray-reverse-tunnel-kraken-truenas]]'
|
||||
- '[[family/how-to/truenas-infrastructure]]'
|
||||
@@ -20,7 +21,23 @@ 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`).
|
||||
>
|
||||
> **🔴 НЕ подтверждено — сквозной проход.** Тест дал `HTTP 000` (3 с), счётчик REDIRECT-правила = **0 пакетов**.
|
||||
>
|
||||
> **⚠️ ПИТФОЛЛ МЕТОДИКИ (стоил ложного вывода):** тест запускался `curl`-ом **с самого Кра́кена**. Локально-исходящий трафик идёт через `nat OUTPUT`, а **не** через `PREROUTING` → правило физически не могло сработать, счётчик 0. Это **не** доказывает ни поломку, ни работу схемы. **Проверять только с постороннего хоста** в `192.168.1.x` (Mac), а не с узла, где стоит правило.
|
||||
>
|
||||
> **🔴 ВТОРАЯ ГИПОТЕЗА (не проверена):** в логах бриджа при 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-юнит (пакет ставить не стали).
|
||||
|
||||
> **Исходный статус на момент планирования: ПРЕДЛОЖЕНО.** План согласован к выполнению 2026-09-23.
|
||||
|
||||
## Задача
|
||||
|
||||
@@ -197,18 +214,61 @@ TrueNAS: xray-reverse-portal
|
||||
2. **Много параллельных TCP при 104 мс RTT** — не тестировалось.
|
||||
3. **Транспарентность решена:** выбран `dokodemo-door` + `iptables REDIRECT` (правка 1 переписана). Проверено на Кра́кене: `iptables` есть, `nft` есть, `ip rule` пустой, Xray 26.4.25 поддерживает `dokodemo-door`. TPROXY не нужен, `tproxy`-модуль не загружен и не требуется для TCP.
|
||||
|
||||
## Порядок работ
|
||||
## Порядок работ — ФАКТИЧЕСКОЕ ИСПОЛНЕНИЕ
|
||||
|
||||
Боевые конфиги — **коммит ДО → правка → заливка → ПРОВЕРКА ALEX → коммит ПОСЛЕ**.
|
||||
|
||||
1. Бэкап обоих конфигов (`config.json` на Кра́кене и на TrueNAS) с датой в имени.
|
||||
2. Разрешить открытый вопрос: **SOCKS vs `dokodemo-door`** (см. п.3 «Непроверенное»). Без него правка 1 не имеет смысла.
|
||||
3. Правка 2 (TrueNAS) — сначала, т.к. легче откатить.
|
||||
4. Правка 1 (Кра́кен).
|
||||
5. Проверка: с Mac `curl -v --socks5-hostname 192.168.1.15:12345 http://192.168.2.197:80` или открыть в браузере по IP.
|
||||
6. Правка 3 (ASUS, руками Alex через UI).
|
||||
7. Финальная проверка Alex'ом: открыть `http://192.168.2.197:8096` в браузере Mac **без** прокси.
|
||||
8. Обновить `personal/tech/xray-reverse-tunnel-kraken-truenas.md` + новый раздел в `family/how-to/truenas-infrastructure.md`.
|
||||
| # | Шаг | Статус |
|
||||
|---|---|---|
|
||||
| 1 | Бэкап обоих конфигов + iptables | ✅ выполнено |
|
||||
| 2 | Развилка **SOCKS vs `dokodemo-door`** | ✅ решено — `dokodemo-door` |
|
||||
| 3 | Правка 2 (TrueNAS, портал) | ✅ выполнено, `Configuration OK.`, портал Up |
|
||||
| 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` | ⏳ |
|
||||
|
||||
### 🔴 Как правильно проверять сквозной проход
|
||||
|
||||
**НЕЛЬЗЯ:** запускать `curl` с узла, где стоит правило REDIRECT (Кра́кен). Локально-исходящий трафик идёт через `nat OUTPUT`, `PREROUTING` его не видит → счётчик 0, `curl` даёт 000. Это **ложный негатив**, а не доказательство поломки.
|
||||
|
||||
**МОЖНО:**
|
||||
1. **С Mac** (посторонний хост): `curl -v --max-time 15 http://192.168.2.197/` — **до** добавления маршрута на ASUS это даст timeout (контроль), после — должен пойти ответ.
|
||||
2. **Транзитный тест из контейнера** с кастомным маршрутом (`--network host` + `ip route add 192.168.2.0/24 via 192.168.1.1`) — трафик станет транзитным и попадёт в `PREROUTING`.
|
||||
3. **Контроль счётчика:** `iptables -t nat -L PREROUTING -n -v | grep 12345` — до/после теста. Ненулевой счётчик = правило сработало.
|
||||
|
||||
### Файлы, задействованные в правках
|
||||
|
||||
| Файл | Где | Что |
|
||||
|---|---|---|
|
||||
| `/home/kraken/xray-reverse/config.json` | Кра́кен | inbound `lan-in` + routing `lan-in → conn` |
|
||||
| `/mnt/RED_2TB/docker/reverse-portal/config.json` | TrueNAS | routing `192.168.2.0/24 → direct` + outbound `direct` |
|
||||
| Правило iptables | Кра́кен | `nat PREROUTING` REDIRECT (не персистентно) |
|
||||
| `/Users/admin/tmp-lan-tunnel/bridge-config-new.json` | Mac (локально) | эталон нового конфига бриджа |
|
||||
| `/Users/admin/tmp-lan-tunnel/portal-config-new.json` | Mac (локально) | эталон нового конфига портала |
|
||||
|
||||
### Команды валидации (использованы, воспроизводимые)
|
||||
|
||||
```bash
|
||||
# Валидация конфига живым бинарником — ДО заливки
|
||||
ssh kraken 'sudo docker run --rm -v /home/kraken/xray-reverse:/etc/xray \
|
||||
teddysun/xray:26.4.25 xray run -test -c /etc/xray/ctest.json'
|
||||
# → ожидается "Configuration OK."
|
||||
|
||||
# Заливка на TrueNAS (папка root-owned)
|
||||
docker run --rm -v /tmp:/src -v /mnt/RED_2TB/docker/reverse-portal:/dst alpine \
|
||||
sh -c "cp /src/portal-config-new.json /dst/config.json && chown 950:950 /dst/config.json"
|
||||
|
||||
# Правило перехвата
|
||||
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
|
||||
```
|
||||
|
||||
## Откат
|
||||
|
||||
|
||||
@@ -57,7 +57,24 @@ verified_fix_2026_09_02: >-
|
||||
> Правило `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-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-bridge` **не имеет `inbounds`** (ключи конфига только `log`/`outbounds`/`routing`) — канал есть, но принять трафик от роутера бриджу нечем. Это недостающий кусок для схемы.
|
||||
>
|
||||
> ### 🔧 ЧТО ПРИМЕНЕНО 2026-09-23 (детали — в плане)
|
||||
> Обе правки конфигов **выполнены и завалидированы** (`xray run -test` → `Configuration OK.` на обоих), контейнеры перезапущены, канал после рестарта жив (`92.62.77.233`). Сквозной проход **не подтверждён** (см. питфолл ниже).
|
||||
>
|
||||
> | Что | Файл | Изменение |
|
||||
> |---|---|---|
|
||||
> | Бридж (Кра́кен) | `/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.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.
|
||||
|
||||
> ## ✅ 2026-09-20 — КОРЕНЬ 2026-09-15 НАЙДЕН: ГОНКА Docker ↔ mount, НЕ конфиг и НЕ версия
|
||||
>
|
||||
|
||||
Reference in new issue
Block a user