0 Fork 0

Files

T

Alexey Martemyanov ae27c7f001 [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

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

21 KiB

Raw Blame History

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

title

created

type

namespace

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

🔄 СТАТУС: ЧАСТИЧНО ПРИМЕНЕНО (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.

Задача

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 → коммит ПОСЛЕ.

#	Шаг	Статус
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. Это ложный негатив, а не доказательство поломки.

МОЖНО:

С Mac (посторонний хост): curl -v --max-time 15 http://192.168.2.197/ — до добавления маршрута на ASUS это даст timeout (контроль), после — должен пойти ответ.
Транзитный тест из контейнера с кастомным маршрутом (--network host + ip route add 192.168.2.0/24 via 192.168.1.1) — трафик станет транзитным и попадёт в PREROUTING.
Контроль счётчика: 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 (локально)	эталон нового конфига портала

Команды валидации (использованы, воспроизводимые)

# Валидация конфига живым бинарником — ДО заливки
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

Откат

Кра́кен: вернуть 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 — второй роутер (в этой схеме не участвует)

21 KiB Raw Blame History Unescape Escape