0 Fork 0

Files

T

Alexey Martemyanov ea6e19f4f8 [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-limits-private-network.md personal/tech/xray-reverse-tunnel-kraken-truenas.md

2026-09-23 13:31:20 +06:00

28 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, вечер). Архитектурный тупик, схема НЕ доведена.

Итог: цепочка «ASUS → Кра́кен → туннель → TrueNAS → 192.168.2.x» не реализуется в Xray reverse. Портал отклоняет: for safety reasons, user a81c3179-… is not allowed to use forward proxy. Это штатная защита Xray от превращения сервера в открытый прокси, не баг конфига. Обходится только finalRules-allow, но тогда «домашней» стороной обязан быть Кра́кен, а целевая сеть — его локалка (192.168.1.x), не 192.168.2.x. Направление задачи и направление туннеля не совпадают.

Решение Alex: НЕ принято. Варианты в разделе «Развилка» ниже. Откат возможен в одну команду из бэкапов.

Что осталось применённым на системах (требует решения — откатить или оставить):

Кра́кен: inbound lan-in (dokodemo-door, 0.0.0.0:12345) + routing lan-in → conn; правило iptables nat PREROUTING REDIRECT (не персистентно). Бэкапы: config.json.bak-lan-in-20260923-130541, config.json.bak-listen0000-20260923-131655, config.json.bak-v3-<date>, iptables.bak-20260923-130541.

TrueNAS: правило 192.168.2.0/24 → direct в портале. Бэкап: config.json.before-lanroute.

ASUS: nvram lan_route изменён с 192.168.1.2 на 192.168.1.15. Бэкап: /jffs/lan_route.bak.20260923-131613.

⚠️ Обнаружен и исправлен битый артефакт: lan_route указывал на мёртвый 192.168.1.2 (ARP FAILED, MAC нулевой) — трафик на 192.168.2.x уходил в никуда. Это была предсуществующая поломка, не созданная в этой сессии.

✅ ПОЛЕЗНЫЕ ПОБОЧНЫЕ НАХОДКИ (сохранить, не терять):

✅ ASUS SSH РАБОТАЕТ: ssh -i ~/.ssh/id_rsa admin@192.168.1.1 (пользователь admin, не root). Порт 22 открыт. Прежний вывод «ASUS не пускает по SSH» — ошибка: подключался как root. Маршруты правятся через nvram lan_route (формат NET:MASK:GW:METRIC), не через UI.

✅ Reverse-канал ВПЕРВЫЕ подтверждён end-to-end после починки гонки docker↔mount 2026-09-20: через SOCKS портала 92.62.77.233 ≠ напрямую 90.189.160.148.

⚠️ WAN-IP Кра́кена изменился: 92.62.70.41 → 92.62.77.233. В kraken-access.md / xray-reverse-tunnel-* фигурирует старый — актуализировать при следующей правке.

Исходный статус на момент планирования: ПРЕДЛОЖЕНО. План согласован к выполнению 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 не сделана, схема физически не может работать.

🔴 КРИТИЧНАЯ НАХОДКА (2026-09-23) — направление перевёрнуто

Прогнано вживую. Цепочка «ASUS → Кра́кен → туннель → TrueNAS → 192.168.2.x» не работает архитектурно, а не из-за конфига.

Что происходит по факту:

Шаг	Лог	Результат
Mac → Кра́кен `lan-in`	`accepted tcp:192.168.2.197:80 [lan-in -> conn]`	✅ перехват, уход в туннель
Туннель → портал	`received request for tcp:192.168.2.197:80`	✅ дошло
Портал выпускает	`for safety reasons, user a81c3179-… is not allowed to use forward proxy`	❌ отклонено

Причина (официальная дока Xray, freedom outbound):

Traffic from VLESS reverse proxy blocks all targets by default. VLESS/VMess/Trojan/Shadowsocks inbounds block private and reserved IP ranges by default. To allow clients access to internal services, explicitly configure allow rules.

Портал видит соединение «клиент просит сходить на 192.168.2.197» и классифицирует это как forward proxy — то есть как попытку использовать сервер как открытый прокси. Отсюда отказ.

Правильное направление (Use Case 2 «Remote Return Home» из доки Xray):

клиент → PUBLIC SERVER (TrueNAS, портал) → reverse-out → туннель
                                                            ↓
                                      INTERNAL DEVICE (Кра́кен, бридж)
                                                            ↓
                                              freedom + finalRules allow
                                                            ↓
                                                  192.168.2.0/24

То есть точка входа должна быть на TrueNAS (портал), а reverse-in → freedom с finalRules[allow ip 192.168.2.0/24] — на Кра́кене (бридж).

🔴 Мой план был построен на перевёрнутой схеме — «ASUS → Кра́кен → в подсеть». В этой архитектуре Кра́кен выступает «домашней» стороной, и именно ему нужен allow-rule, а вход — на TrueNAS.

Проверенные факты по пути (сохранить):

dokodemo-door обязан слушать 0.0.0.0, не 127.0.0.1 — иначе REDIRECT-трафик с внешнего адреса не принимается.
iptables -t nat PREROUTING не действует на локально-исходящий трафик с самого хоста — для теста нужен отдельный netns либо реальный клиент из сети.
redirect: "" в freedom — невалидно; пустая строка ломает конфиг.
Xray 26.4.25: xray run -test читает stdin и виснет под SSH без < /dev/null.
Кра́кен: sudo через SSH требует < /dev/null на каждой команде, иначе Connection closed by remote host.
На Кра́кене нет ifconfig — каждый вызов печатает command not found в stderr (безвредно, но засоряет вывод).

Три правки (СУПЕРСИДЕД — см. находку выше)

Правка 1 — Кра́кен: `dokodemo-door` + REDIRECT (сделано, но НЕ тот вход)

Файл /home/kraken/xray-reverse/config.json. Применено, канал работает, но это вход не с той стороны — см. находку выше. Требует пересмотра.

Файл /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: статический маршрут ✅ ВЫПОЛНЕНО (не через UI)

✅ ASUS доступен по SSH — прежняя запись «SSH закрыт, только веб-UI» ОШИБОЧНА. Правильный вход:

ssh -i ~/.ssh/id_rsa admin@192.168.1.1     # пользователь admin, НЕ root

Порт 22 открыт; подключение как root даёт Connection closed — отсюда ложный вывод.

Механизм статических маршрутов — nvram, не UI. Формат NET:MASK:GW:METRIC в одной строке:

nvram get lan_route     # → 192.168.2.0:255.255.255.0:192.168.1.2:25
nvram set lan_route="192.168.2.0:255.255.255.0:192.168.1.15:25"
nvram commit

⚠️ service restart_routing НЕ перечитывает lan_route (проверено — таблица осталась со старым шлюзом). Применять явно:

ip route del 192.168.2.0/24 via 192.168.1.2 dev br0
ip route add 192.168.2.0/24 via 192.168.1.15 dev br0 metric 25

Бэкап: nvram get lan_route > /jffs/lan_route.bak.$(date +%Y%m%d-%H%M%S)

⚠️ Кра́кен имеет два адреса в 192.168.1.0/24: .14 (eth0, metric 100) и .15 (wlan0, metric 600), разные MAC (…03:f3 / …03:f4). Использовать .15, как в DNS-записи address=/kraken/192.168.1.15.

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

🏁 РАЗВИЛКА — решение НЕ принято (2026-09-23)

Тупик: Xray reverse по дизайну не пропускает forward-proxy трафик в приватные сети. Направление «ASUS → Кра́кен → в сеть TrueNAS» реализовать нельзя — только обратное («дом = Кра́кен», цель = 192.168.1.x), что не решает задачу.

#	Вариант	Что даёт	Цена
1	Отказаться, откатить всё из бэкапов	возврат к исходному состоянию	теряется только то, чего и не было
2	SOCKS-прокси на стороне клиента (Mac) — через существующий `vless-proxy` (SOCKS `:1080`) / `xray-admin`	доступ к `192.168.2.x` с Mac	не «через ASUS»; нужен SOCKS-aware клиент или routing на Mac; не работает для других устройств
3	WireGuard на TrueNAS (белый IP + открытый порт уже есть)	полный IP-стек: ICMP, UDP, Samba-обзор, «как локальный»	новая служба на TrueNAS; TrueNAS на пределе RAM (17/21 ГБ)

Рекомендация: вариант 3 — если нужен реально «true VPN» с UDP и Samba; вариант 2 — если хватит доступа с одного Mac.

⚠️ Вариант 2 ограничен: docker exec vless-proxy wget не проверяет SOCKS (wget не умеет SOCKS5, вернёт локальный IP) — проверять только через curl --socks5-hostname.

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

Браузер (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	Сквозной тест	✅ ПРОЙДЕН ЧАСТИЧНО — перехват работает, но портал режет forward-proxy
8	Повторный тест с Mac (посторонний хост)	✅ выполнен — `HTTP 000` + отказ портала
9	Диагностика отказа портала	✅ `not allowed to use forward proxy` — штатная защита Xray
10	Диагностика ASUS-маршрута	✅ SSH найден, битый `lan_route` → `.2` исправлен на `.15`
11	Вывод: архитектурный тупик	🏁 зафиксирован, решение Alex не принято
12	Откат или переход к варианту 2/3	⏳ ждёт решения
13	Обновить `personal/tech/xray-reverse-tunnel-kraken-truenas.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 — второй роутер (в этой схеме не участвует)

28 KiB Raw Blame History Unescape Escape