--- 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 по шагам.