214 lines
15 KiB
Markdown
214 lines
15 KiB
Markdown
---
|
||
title: LAN через reverse-туннель — доступ к 192.168.2.x с Кра́кена
|
||
created: '2026-09-23'
|
||
updated: '2026-09-23'
|
||
type: plan
|
||
namespace: personal
|
||
tags:
|
||
- xray
|
||
- reverse
|
||
- kraken
|
||
- truenas
|
||
- tunnel
|
||
- routing
|
||
- asus
|
||
- networking
|
||
status: plan-created
|
||
confidence: medium
|
||
related:
|
||
- '[[personal/tech/xray-reverse-tunnel-kraken-truenas]]'
|
||
- '[[family/how-to/kraken-access]]'
|
||
- '[[family/how-to/truenas-infrastructure]]'
|
||
- '[[family/how-to/rasputin-router]]'
|
||
- '[[software-development/home-network-config]]'
|
||
---
|
||
|
||
# LAN через reverse-туннель — доступ к `192.168.2.x` с Кра́кена
|
||
|
||
> **Запрос Alex (2026-09-23):** «мы можем поднять реальный VPN через VLESS который щас поднят с кракена до truenas для реверс-прокси? то есть чтобы из этой сети адреса `192.168.2.x` стали как локальные?»
|
||
>
|
||
> **Уточнённая формулировка (Alex):** «я хочу чтобы asus router отправлял запросы в подсеть `192.168.2.x` на кракена. на нем контейнер или что чтобы это обрабатывала и отправляла в туннель. аналогично на truenas.»
|
||
>
|
||
> Вопрос про «true VPN с samba, udp etc» — см. раздел «Честные пределы схемы».
|
||
|
||
## Ответ коротко
|
||
|
||
**Да, реализуемо, и без установки нового софта.** Оба конца (Кра́кен и TrueNAS) уже имеют работающий Xray, канал жив и проверен. Нужны **три правки конфигов** — новых сервисов не требуется.
|
||
|
||
## Проверенные факты (2026-09-23, живьём)
|
||
|
||
### ✅ Канал ЖИВ — первый end-to-end тест после починки 20.09
|
||
|
||
| Проверка | Результат |
|
||
|---|---|
|
||
| Через reverse-канал (SOCKS `xray-reverse-portal:12345`) | **`92.62.77.233`** |
|
||
| Напрямую с TrueNAS | `90.189.160.148` |
|
||
| Вывод | IP разные ⇒ **payload идёт через Кра́кен** |
|
||
| Portal `netstat` | `::ffff:172.16.1.7:12346 ← ::ffff:92.62.77.233:32529 ESTABLISHED` |
|
||
|
||
> 🔴 **IP Кра́кена ИЗМЕНИЛСЯ: `92.62.70.41` → `92.62.77.233`.** Во всех документах зафиксирован старый `92.62.70.41`. При проверках использовать актуальный, а не из доков.
|
||
|
||
### Топология (уточнена — прежнее описание в этой сессии было НЕВЕРНЫМ)
|
||
|
||
```
|
||
Mac 192.168.1.57 ─┐
|
||
├── 192.168.1.0/24, gw 192.168.1.1 (ASUS RT-AC68U)
|
||
Kraken .14/.15 ───┘ ← ОДНА ПОДСЕТЬ, соседи
|
||
│
|
||
│ reverse-туннель VLESS+REALITY TCP :12346
|
||
▼
|
||
TrueNAS 192.168.2.197 ← сеть 192.168.2.0/24 (gw OpenWrt 192.168.2.2)
|
||
```
|
||
|
||
> ⚠️ **Питфолл, который я допустил в этой сессии:** я написал «Кра́кен `.15` и `192.168.2.197` — за `192.168.2.2` (OpenWrt), а твоя сеть `192.168.1.x` — тоже за ним». **Это неверно.** `192.168.2.2` — шлюз **сети TrueNAS**, к сети Mac/Кра́кена отношения не имеет. Проверено: `ip route` на Кра́кене → `default via 192.168.1.1 dev eth0 src 192.168.1.14`; `route get 192.168.2.197` с Mac → `gateway: 192.168.1.1`.
|
||
>
|
||
> **Следствие ошибки:** я построил на ней два «варианта» с NAT на ASUS и с правкой policy routing на Rasputin. **Оба не нужны** — посылка была ложной. Схема Alex'а (статический маршрут на роутере) работает именно потому, что Mac и Кра́кен — соседи в одной подсети.
|
||
|
||
### ❌ Чего сейчас НЕ хватает
|
||
|
||
| Узел | Состояние | Что нужно |
|
||
|---|---|---|
|
||
| `xray-reverse-bridge` (Кра́кен) | **`inbounds` = null**, ключи конфига только `log`/`outbounds`/`routing`. Слушающих портов нет (12345–12350, 1080 — пусто) | **inbound**, который примет трафик от роутера |
|
||
| `xray-reverse-portal` (TrueNAS) | routing: `inboundTag:["local"] → reverse-out`. Правила для `192.168.2.0/24` **нет** | routing-правило `192.168.2.0/24 → direct` |
|
||
| ASUS `192.168.1.1` | SSH: `Connection closed`, порт 22 **closed** | Статический маршрут через **веб-UI** |
|
||
|
||
**Ключевое:** reverse-канал **асимметричен по дизайну**. `reverse-in` создаётся на бридже, `reverse-out` — маутбаунд на портале. Портал сейчас шлёт в `reverse-out` только то, что пришло в SOCKS `:12345`. Чтобы завернуть `192.168.2.0/24` в нужную сторону, порталу нужно явное routing-правило. Бриджу — inbound, куда роутер будет адресовать пакеты.
|
||
|
||
## План (3 правки, порядок обязателен)
|
||
|
||
Порядок работ по боевому конфигу: **бэкап → коммит ДО → правка → заливка → ПРОВЕРКА АЛЕКСОМ → коммит ПОСЛЕ.**
|
||
|
||
### Шаг 1 — Бэкап (ничего не меняет)
|
||
|
||
```bash
|
||
# Кра́кен
|
||
ssh kraken 'sudo cp /home/kraken/xray-reverse/config.json \
|
||
/home/kraken/xray-reverse/config.json.bak-lanvpn-$(date +%Y%m%d-%H%M%S)'
|
||
# TrueNAS
|
||
ssh truenas_admin@mallexxx.duckdns.org \
|
||
'docker exec xray-reverse-portal cat /etc/xray/config.json > /tmp/portal-before-lanvpn.json'
|
||
```
|
||
|
||
### Шаг 2 — Кра́кен: добавить inbound
|
||
|
||
Файл: `/home/kraken/xray-reverse/config.json` (bind-mount `:ro` → после правки `docker compose up -d` обязателен, `restart` не перечитает).
|
||
|
||
```json
|
||
"inbounds": [
|
||
{
|
||
"tag": "lan-in",
|
||
"listen": "0.0.0.0",
|
||
"port": 12345,
|
||
"protocol": "socks",
|
||
"settings": { "auth": "noauth", "udp": true }
|
||
}
|
||
],
|
||
"routing": {
|
||
"rules": [
|
||
{ "inboundTag": ["lan-in"], "outboundTag": "direct" },
|
||
{ "inboundTag": ["reverse-in"], "outboundTag": "direct" }
|
||
]
|
||
}
|
||
```
|
||
|
||
> ⚠️ Правило `lan-in → direct` **обязательно**: без него трафик от роутера заматчится в общий и уйдёт не туда. Существующее правило `reverse-in → direct` сохранить.
|
||
>
|
||
> ⚠️ Порт выбрать после проверки занятости (`ss -tlnp`): 12345 на Кра́кене сейчас свободен, но в сети есть `vless-proxy` на TrueNAS с 1080/1081 — не путать хосты.
|
||
|
||
`network_mode: host` уже стоит (проверенный фикс 2026-09-02) — слушающий порт будет виден в LAN напрямую.
|
||
|
||
### Шаг 3 — TrueNAS: routing-правило на портале
|
||
|
||
В `routing.rules` портала добавить **до** существующего `local → reverse-out`:
|
||
|
||
```json
|
||
{ "type": "field", "ip": ["192.168.2.0/24"], "outboundTag": "direct" }
|
||
```
|
||
|
||
Почему: трафик, пришедший из reverse-канала от роутера, должен `dispatched` в локальную сеть TrueNAS через `direct` (freedom), а не обратно в `reverse-out`.
|
||
|
||
### Шаг 4 — ASUS: статический маршрут
|
||
|
||
**Через веб-UI** (SSH на роутер недоступен):
|
||
|
||
```
|
||
Network Map → LAN → Route
|
||
Network/Host IP : 192.168.2.0
|
||
Netmask : 255.255.255.0
|
||
Gateway : 192.168.1.15 ← Кра́кен (wlan0)
|
||
Metric : 1
|
||
Interface : LAN (или WAN — проверить эмпирически)
|
||
```
|
||
|
||
> ⚠️ У Кра́кена **два IP**: `.14` (eth0, metric 100) и `.15` (wlan0, metric 600). Default route идёт через `.14` (eth0). Для маршрута выбрать интерфейс, который физически надёжнее; если маршрут не поднимется через один — проверить второй.
|
||
|
||
### Шаг 5 — Проверка (приёмка = видно в UI, не «API отвечает»)
|
||
|
||
```bash
|
||
# 1. Порт бриджа слушает?
|
||
ssh kraken 'ss -tlnp | grep 12345'
|
||
|
||
# 2. Маршрут на ASUS виден?
|
||
# веб-UI → System Log → Routing Table, либо traceroute с Mac
|
||
traceroute -n -m 3 192.168.2.197 # 1-й хоп должен быть 192.168.1.15, НЕ 192.168.1.1
|
||
|
||
# 3. Реальный доступ (TCP-канал, которым будешь работать)
|
||
curl -s -o /dev/null -w '%{http_code}\n' --max-time 15 http://192.168.2.197:8096/health
|
||
# ожидаем 200
|
||
|
||
# 4. Не сломалось ли старое
|
||
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
|
||
```
|
||
|
||
## Честные пределы схемы (ответ на «будет true vpn с samba, udp?»)
|
||
|
||
| Протокол | Пройдёт? | Условие / причина |
|
||
|---|---|---|
|
||
| **TCP** (HTTP/S, `:8096`, `:80`, SSH, SMB/445) | ✅ **да** | конфиг умеет, ничего дополнительно |
|
||
| **Samba/SMB по IP** (`mount_smbfs`) | ✅ **да** | TCP/445 пройдёт |
|
||
| **Samba auto-discover** (`smb://` сканер сети, mDNS/broadcast) | ❌ **нет** | broadcast/multicast не роутится через routed-туннель |
|
||
| **UDP** | ⚠️ **НЕИЗВЕСТНО, не проверено** | в SOCKS-inbound заявлен `"udp": true`, но транспорт канала — VLESS+REALITY **по TCP**. Требует отдельного теста. **Не обещать.** |
|
||
| **ICMP** (ping) | ❌ **нет** | туннель port-based, эхо не пробрасывает. Плюс на Rasputin ICMP в транзите зарезан отдельно |
|
||
|
||
> 🔴 **Главное, что нужно сказать вслух: это НЕ WireGuard-класс.** «True VPN» с полным IP-стеком не получится: ни ICMP, ни broadcast/mDNS, ни гарантии UDP. Получится **TCP-доступ к адресам `192.168.2.x`** — то, что сейчас недостижимо ни по LAN, ни через домены.
|
||
|
||
### Про пропускную способность — схема НЕ ускоряет
|
||
|
||
Замеры 2026-09-02 (см. `[[personal/tech/xray-reverse-tunnel-kraken-truenas]]`): оба egress-режима туннеля дают **~35–45 Мбит/с** с нестабильностью; single TCP flow между сетями ~28–45 Мбит (штраф за ~104 мс RTT).
|
||
|
||
**Возврат домой через туннель это не чинит** — трафик всё равно идёт по тому же ТТК→Ростелеком. Jellyfin-«не как локальный» проблема **остаётся**: для direct-play BluRay (20+ Мбит) — впритык.
|
||
|
||
### Нужен ли `dialerProxy`? (отвергнутая альтернатива)
|
||
|
||
Изначально рассматривался `sockopt.dialerProxy` на outbound `direct` в `xray-admin`: он заставляет Xray слать исходящие не самому, а через другой outbound. Рабочая схема, но **хуже**:
|
||
|
||
- бьёт по всем, кто использует `direct` (`user1`, `vless-space`) — если правило промахнётся, ломается существующий рабочий VPN;
|
||
- требует правки боевого `xrayTemplateConfig` 3x-ui (клиенты — только через панель, см. питфоллы).
|
||
|
||
Выбранный путь (inbound на бридже + routing на портале) **не трогает `xray-admin` вообще** — откат = вернуть бэкап конфига портала/бриджа и `docker compose up -d`.
|
||
|
||
## Питфоллы, найденные в этой сессии
|
||
|
||
1. 🔴 **IP Кра́кена изменился** `92.62.70.41` → `92.62.77.233`. Проверять живьём, не по докам.
|
||
2. 🔴 **Топология: Mac и Кра́кен — соседи в `192.168.1.0/24`.** Не приписывать `192.168.2.2` (OpenWrt) сети Mac.
|
||
3. 🔴 **Бридж не имеет inbounds** — канал работает, но «принять трафик от роутера» ему нечем. Это и есть недостающий кусок.
|
||
4. ⚠️ **ASUS по SSH не пускает** (`Connection closed`, порт 22 closed). Правки маршрутов — только веб-UI.
|
||
5. ⚠️ Bind-mount `:ro` → после правки конфига нужен **`docker compose up -d`**, а не `docker restart`.
|
||
6. ⚠️ `jq` на конфиге бриджа: ключа `inbounds` нет вообще → `.inbounds` возвращает `null`, а `.inbounds[]` падает с `Cannot iterate over null`. Проверять существование ключа (`keys[]`) перед итерацией.
|
||
7. 🔴 **Не поднимать лишнего.** Alex явно сказал: задача — схема доступа, а не ACL-фиксы и прочее из соседних доков. Не предлагать работу сверх команды.
|
||
|
||
## Открытые вопросы
|
||
|
||
1. ⏳ **UDP работает или нет** — требует теста. От этого зависит, пройдут ли DNS-через-туннель, VoIP, игровые протоколы.
|
||
2. ⏳ **Пропускная способность через туннель не измерена** после починки 20.09 (старые замеры — 02.09). `iperf3` есть на Кра́кене (3.12), на TrueNAS не проверялся.
|
||
3. ⏳ **Какой интерфейс на Кра́кене использовать для маршрута** — `.14` (eth0, metric 100, основной) или `.15` (wlan0). Определить эмпирически.
|
||
4. ⏳ **`kraken-user` в 3x-ui** — правило `kraken-user-via-reverse` прописано, egress `via-kraken` на SOCKS портала. После починки канала 20.09 end-to-end **не перепроверялся**. Проверить заодно.
|
||
5. ⏳ Нужен ли доступ к `192.168.2.x` **только с Mac** или **со всех клиентов** сети `192.168.1.0/24`. Второе = маршрут на ASUS; первое = маршрут локально на Mac (проще, откат = удалить маршрут).
|
||
|
||
## Статус
|
||
|
||
**План создан, НЕ выполнен.** Все три правки — конфиги боевых сервисов, применять только с подтверждения Alex по шагам.
|