git_admin/obsidian-vault
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
d8d86f37cf9ea06f2e84d3d4e5b54a960698e8db
obsidian-vault/personal/plans/lan-via-reverse-tunnel.md
T

15 KiB
Raw Blame History

title, created, updated, type, namespace, tags, status, confidence, related
title created updated type namespace tags status confidence related
LAN через reverse-туннель — доступ к 192.168.2.x с Кра́кена 2026-09-23 2026-09-23 plan personal
xray
reverse
kraken
truenas
tunnel
routing
asus
networking
plan-created medium
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 — Бэкап (ничего не меняет)

# Кра́кен
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 не перечитает).

"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:

{ "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 отвечает»)

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

Reference in new issue View Git Blame Copy Permalink