[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

personal/plans/lan-access-via-reverse-tunnel.md

@@ -0,0 +1,225 @@
+---
+title: Доступ к 192.168.2.0/24 с ASUS через reverse-туннель Kraken→TrueNAS
+created: '2026-09-23'
+type: plan
+namespace: personal
+tags:
+  - xray
+  - reverse
+  - kraken
+  - truenas
+  - asus
+  - routing
+  - vpn
+status: proposed
+related:
+  - '[[personal/tech/xray-reverse-tunnel-kraken-truenas]]'
+  - '[[family/how-to/truenas-infrastructure]]'
+  - '[[family/how-to/kraken-access]]'
+  - '[[family/how-to/router-bishkek-asus]]'
+---
+# Доступ к 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`):
+
+```json
+"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-канал):
+
+```json
+{ "inboundTag": ["lan-in"], "outboundTag": "conn" }
+```
+
+Существующее правило `inboundTag:["reverse-in"] → direct` **оставить без изменений** — оно обслуживает обратное направление (интернет-egress через Кра́кен для `kraken-user`).
+
+**Перехват на хосте Кра́кена:**
+
+```bash
+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`.
+
+Добавить правило, которое после распаковки на бридже отправит целевой трафик локально:
+
+```json
+{
+  "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.
+
+## Непроверенное (не додумывать)
+
+1. **Пропускная способность через туннель.** Старые замеры (`xray-reverse-tunnel-kraken-truenas`) дают ~35–45 Мбит/с с нестабильностью. Для Jellyfin direct-play 20+ Мбит — впритык. Межоператорский путь ~104 мс RTT + per-TCP-flow штраф.
+2. **Много параллельных TCP при 104 мс RTT** — не тестировалось.
+3. **Транспарентность решена:** выбран `dokodemo-door` + `iptables REDIRECT` (правка 1 переписана). Проверено на Кра́кене: `iptables` есть, `nft` есть, `ip rule` пустой, Xray 26.4.25 поддерживает `dokodemo-door`. TPROXY не нужен, `tproxy`-модуль не загружен и не требуется для TCP.
+
+## Порядок работ
+
+Боевые конфиги — **коммит ДО → правка → заливка → ПРОВЕРКА ALEX → коммит ПОСЛЕ**.
+
+1. Бэкап обоих конфигов (`config.json` на Кра́кене и на TrueNAS) с датой в имени.
+2. Разрешить открытый вопрос: **SOCKS vs `dokodemo-door`** (см. п.3 «Непроверенное»). Без него правка 1 не имеет смысла.
+3. Правка 2 (TrueNAS) — сначала, т.к. легче откатить.
+4. Правка 1 (Кра́кен).
+5. Проверка: с Mac `curl -v --socks5-hostname 192.168.1.15:12345 http://192.168.2.197:80` или открыть в браузере по IP.
+6. Правка 3 (ASUS, руками Alex через UI).
+7. Финальная проверка Alex'ом: открыть `http://192.168.2.197:8096` в браузере Mac **без** прокси.
+8. Обновить `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]] — второй роутер (в этой схеме **не участвует**)

personal/plans/lan-via-reverse-tunnel.md

@@ -0,0 +1,213 @@
+---
+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 по шагам.