0 Fork 0

Files

T

Alexey Martemyanov ef5ba570a3 [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/plans/lan-via-reverse-tunnel.md personal/tech/home-network-config.md personal/tech/xray-reverse-tunnel-kraken-truenas.md

2026-09-23 13:05:58 +06:00

15 KiB

Raw Blame History

title, created, type, namespace, tags, status, related

title

created

type

namespace

Доступ к 192.168.2.0/24 с ASUS через reverse-туннель Kraken→TrueNAS

Статус: ПРЕДЛОЖЕНО, НЕ ВЫПОЛНЕНО. Согласовано к выполнению 2026-09-23. Ни одна из трёх правок не применена.

Задача

Alex хочет, чтобы клиенты сети 192.168.1.0/24 (за роутером ASUS 192.168.1.1) ходили на адреса 192.168.2.x как на локальные — через существующий reverse-туннель Кра́кен↔TrueNAS.

Мотивация: сейчас 192.168.2.x недостижим никак (ни LAN, ни по домену как чистый IP). Jellyfin/WebDAV/порты приходится дёргать через *.mallexxx.duckdns.org.

Топология (проверено 2026-09-23)

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 (шлюз OpenWrt 192.168.2.2)

🔴 ГЛАВНЫЙ ФАКТ, СНЯВШИЙ ЛОЖНУЮ ПОСЫЛКУ: Mac и Кра́кен — соседи в одной сети 192.168.1.0/24, шлюз один (192.168.1.1). Между ними нет OpenWrt. OpenWrt 192.168.2.2 — шлюз сети TrueNAS, к стороне Alex отношения не имеет.

Следствие: схема «статический маршрут на ASUS → Кра́кен» работает. Обратный путь не нужен, ip rule / Rasputin / NAT на стороне Alex не требуются. Ранее предложенные варианты A (iptables NAT на ASUS) и B (политика на Rasputin) были построены на неверной топологии — отброшены.

Проверенное состояние (2026-09-23)

Что	Результат
`xray-reverse-portal` (TrueNAS)	Up 4 дня, `:12346` LISTEN
`xray-reverse-bridge` (Kraken)	Up 2 дня, `teddysun/xray:26.4.25`, `network_mode: host`
ESTABLISHED от бриджа	✅ `172.16.1.7:12346 ← 92.62.77.233:32529`
Payload end-to-end	✅ через SOCKS портала `92.62.77.233` ≠ напрямую `90.189.160.148`
ASUS SSH `192.168.1.1:22`	❌ `Connection closed` — правка только через веб-UI
`inbounds` в конфиге бриджа	❌ `null` — слушающих портов нет вообще
Порты 12345–12350 / 1080 на Кра́кене	пусто

✅ НОВЫЙ ФАКТ (нет в других доках): пассивная проверка дала 92.62.77.233 — WAN-IP Кра́кена изменился (в доке фигурирует 92.62.70.41). Канал впервые подтверждён end-to-end после починки гонки docker↔mount 2026-09-20.

Блокер

reverse в Xray асимметричен: на бридже (Кра́кен) создаётся виртуальный inbound reverse-in (трафик из портала в бридж), на портале (TrueNAS) — маутбаунд reverse-out. Портал сейчас роутит inboundTag:["local"] → reverse-out, то есть SOCKS :12345 на самом TrueNAS.

Чтобы ASUS мог что-то отправить, бриджу нужна точка входа. Сейчас её нет — inbounds: null. Пока правка 1 не сделана, схема физически не может работать.

Три правки

Правка 1 — Кра́кен: прозрачный перехват (`dokodemo-door` + REDIRECT)

Файл /home/kraken/xray-reverse/config.json (bind-mount :ro → /etc/xray/config.json).

🔴 Причина, почему НЕ SOCKS: схема требует доступа по чистому IP (http://192.168.2.197:8096). Обычный socks-inbound ждёт SOCKS-протокол от клиента — браузер и mount_smbfs его не говорят. Нужен прозрачный перехват: Xray молча подбирает сырые пакеты, клиент ничего не знает.

Выбран dokodemo-door + iptables REDIRECT (а не TPROXY): проще, не требует tproxy-модуля ядра, не требует fwmark/второй таблицы маршрутизации. Проверено на Кра́кене 2026-09-23: iptables присутствует, nft есть, ip rule пустой, Xray 26.4.25 умеет dokodemo-door.

Добавить секцию inbounds (сейчас null):

"inbounds": [
  {
    "tag": "lan-in",
    "listen": "127.0.0.1",
    "port": 12345,
    "protocol": "dokodemo-door",
    "settings": {
      "network": "tcp",
      "followRedirect": true
    },
    "sniffing": { "enabled": false }
  }
]

listen: 127.0.0.1 — снаружи порт не виден вообще, доступ только через REDIRECT. Закрывает отметку безопасности из xray-reverse-tunnel-kraken-truenas: «Не добавлять в этот контейнер обычные inbounds без аудита bind address/firewall».
sniffing: false — не нужен, назначение уже известно из SO_ORIGINAL_DST.

Правило routing.rules — inboundTag:["lan-in"] → outboundTag:"conn" (в reverse-канал):

{ "inboundTag": ["lan-in"], "outboundTag": "conn" }

Существующее правило inboundTag:["reverse-in"] → direct оставить без изменений — оно обслуживает обратное направление (интернет-egress через Кра́кен для kraken-user).

Перехват на хосте Кра́кена:

iptables -t nat -A PREROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 -p tcp \
  -j REDIRECT --to-ports 12345

Xray из REDIRECT-сокета читает SO_ORIGINAL_DST → узнаёт настоящий 192.168.2.197:8096 → отправляет через туннель.

⚠️ Правило iptables не переживёт reboot — нужна персистентность (iptables-persistent / netfilter-persistent либо systemd-юнит). Проверить наличие перед правкой; на Кра́кене (OMV/Debian) вероятнее всего отсутствует → создать oneshot-юнит.

⚠️ -d 192.168.2.0/24 обязателен. Без него REDIRECT перехватит весь LAN-трафик Кра́кена, включая его собственный reverse-канал и cloudflared.

⚠️ Только TCP. REDIRECT — TCP-механизм. UDP через эту схему не пройдёт. См. раздел «Что пройдёт, а что нет».

Порт 12345 на Кра́кене свободен (проверено ss -tlnp, 2026-09-23).
Бэкап ДО правки: config.json.bak-lan-in-<date> + iptables-save > /home/kraken/backups/iptables.bak-<date>.

Альтернатива (не выбрана) — TPROXY: даёт UDP, но требует modprobe tproxy (сейчас модуль не загружен), fwmark, отдельную таблицу маршрутизации и tun. Сложнее; брать только если UDP реально понадобится.

Правка 2 — TrueNAS: научить портал выпускать в 192.168.2.0/24

Файл /mnt/RED_2TB/docker/reverse-portal/config.json (bind-mount :ro).

Сейчас: routing.rules = [{inboundTag:["local"], outboundTag:"reverse-out"}], outbound — только placeholder freedom.

Добавить правило, которое после распаковки на бридже отправит целевой трафик локально:

{
  "type": "field",
  "ip": ["192.168.2.0/24"],
  "outboundTag": "direct"
}

⚠️ Требует проверки перед применением: нужен ли на портале direct-outbound с finalRules:[{action:"allow"}] (как на бридже — фикс Xray 26.5+, issue #6612) или достаточно placeholder-freedom. Боль в том, что портал сейчас на teddysun/xray:26.4.25, где #6612 формально не применим, — но версия помечена как «фикс, требующий проверки в рантайме».

Порядок правила важен: правило для 192.168.2.0/24 должно стоять выше правила local → reverse-out, иначе local его перехватит.

⚠️ Правка конфига на TrueNAS: папка /mnt/RED_2TB/docker/reverse-portal/ — права root, truenas_admin писать не может. Класть через docker run --rm -v /tmp:/src -v <dst>:/dst alpine cp … + chown.
Бэкап ДО: config.json.bak-lan-route-<date>.

Правка 3 — ASUS: статический маршрут

SSH закрыт (Connection closed на :22), поэтому — веб-UI: http://192.168.1.1 → LAN → Route → добавить:

Поле	Значение
Network/Host IP	`192.168.2.0`
Netmask	`255.255.255.0`
Gateway	`192.168.1.15` (Кра́кен)
Metric	`1`
Interface	`LAN`

⚠️ Кра́кен имеет два адреса в 192.168.1.0/24: .14 (eth0) и .15 (wlan0). В доке rasputin-router зафиксировано: ARP на Распутине резолвит оба в один lladdr 2c:cf:67:64:03:f3. Использовать .15, как в DNS-записи address=/kraken/192.168.1.15.

⚠️ Правило действует на всем сегменте — все клиенты 192.168.1.0/24 пойдут на 192.168.2.x через туннель. Если нужно выборочно — вместо маршрута на ASUS делать routing на конкретном клиенте, но тогда ASUS не нужен вовсе.

Как это будет работать

Браузер (192.168.1.x):  http://192.168.2.197:8096
   ↓
ASUS: маршрут 192.168.2.0/24 → 192.168.1.15
   ↓
Kraken .15: xray-reverse-bridge, inbound lan-in :12345
   → routing: lan-in → conn (outbound VLESS+REALITY, reverse-in)
   ↓  reverse-канал :12346  (уже поднят)
TrueNAS: xray-reverse-portal
   → правило 192.168.2.0/24 → direct
   ↓
192.168.2.197:8096 отвечает
   ↑ обратно по тому же каналу → Кра́кен → ASUS → клиент

Что пройдёт, а что нет

Протокол	Результат	Комментарий
TCP (8096 Jellyfin, 80, 445, 22)	✅ да	основа схемы
Samba по IP (`mount_smbfs`)	✅ да	TCP/445
Samba auto-discover / browse	❌ нет	broadcast не роутится
UDP	❌ нет	REDIRECT — TCP-механизм. Для UDP нужен TPROXY (не выбран)
ICMP (ping)	❌ нет	туннель port-based

🔴 Честная рамка: это НЕ WireGuard-класс. «True VPN» с полным IP-стеком не получится — ни ICMP, ни broadcast, ни гарантии UDP. Что будет — TCP-доступ к 192.168.2.x по чистым IP.

Непроверенное (не додумывать)

Пропускная способность через туннель. Старые замеры (xray-reverse-tunnel-kraken-truenas) дают ~35–45 Мбит/с с нестабильностью. Для Jellyfin direct-play 20+ Мбит — впритык. Межоператорский путь ~104 мс RTT + per-TCP-flow штраф.
Много параллельных TCP при 104 мс RTT — не тестировалось.
Транспарентность решена: выбран dokodemo-door + iptables REDIRECT (правка 1 переписана). Проверено на Кра́кене: iptables есть, nft есть, ip rule пустой, Xray 26.4.25 поддерживает dokodemo-door. TPROXY не нужен, tproxy-модуль не загружен и не требуется для TCP.

Порядок работ

Боевые конфиги — коммит ДО → правка → заливка → ПРОВЕРКА ALEX → коммит ПОСЛЕ.

Бэкап обоих конфигов (config.json на Кра́кене и на TrueNAS) с датой в имени.
Разрешить открытый вопрос: SOCKS vs dokodemo-door (см. п.3 «Непроверенное»). Без него правка 1 не имеет смысла.
Правка 2 (TrueNAS) — сначала, т.к. легче откатить.
Правка 1 (Кра́кен).
Проверка: с Mac curl -v --socks5-hostname 192.168.1.15:12345 http://192.168.2.197:80 или открыть в браузере по IP.
Правка 3 (ASUS, руками Alex через UI).
Финальная проверка Alex'ом: открыть http://192.168.2.197:8096 в браузере Mac без прокси.
Обновить personal/tech/xray-reverse-tunnel-kraken-truenas.md + новый раздел в family/how-to/truenas-infrastructure.md.

Откат

Кра́кен: вернуть config.json.bak-lan-in-<date>, docker restart xray-reverse-bridge.
TrueNAS: вернуть config.json.bak-lan-route-<date>, docker restart xray-reverse-portal.
ASUS: удалить маршрут в UI.

Связанные заметки

personal/tech/xray-reverse-tunnel-kraken-truenas — архитектура reverse-туннеля (основной док)
family/how-to/truenas-infrastructure — контейнеры TrueNAS, xray-reverse-portal
family/how-to/kraken-access — Кра́кен, бридж
family/how-to/router-bishkek-asus — ASUS
family/how-to/rasputin-router — второй роутер (в этой схеме не участвует)

15 KiB Raw Blame History Unescape Escape