119 lines
7.7 KiB
Markdown
119 lines
7.7 KiB
Markdown
---
|
||
title: Xray reverse — граница возможностей (forward proxy в приватные сети)
|
||
created: '2026-09-23'
|
||
type: tech
|
||
namespace: personal
|
||
tags:
|
||
- xray
|
||
- reverse
|
||
- vless
|
||
- vpn
|
||
- networking
|
||
- pitfall
|
||
status: verified
|
||
related:
|
||
- '[[personal/tech/xray-reverse-tunnel-kraken-truenas]]'
|
||
- '[[personal/plans/lan-access-via-reverse-tunnel]]'
|
||
---
|
||
|
||
# Xray reverse — граница возможностей
|
||
|
||
> **Короткий вывод:** Xray reverse **намеренно** не даёт использовать себя как «вход в чужую приватную сеть». Это защита от превращения сервера в открытый прокси — **не баг**, версией Xray не лечится, конфигом не обходится (кроме одного случая, см. ниже).
|
||
|
||
Проверено вживую 2026-09-23 на связке TrueNAS (портал) ↔ Кра́кен (бридж), Xray 26.4.25.
|
||
|
||
## Симптом
|
||
|
||
Настроен рабочий reverse-канал (payload проходит, egress проверен). Подаём в него трафик, адресованный в приватную сеть **публичной** стороны:
|
||
|
||
```
|
||
портал: for safety reasons, user a81c3179-312b-4c5e-8a46-6bf3c30c2941
|
||
is not allowed to use forward proxy
|
||
```
|
||
|
||
Соединение доходит до портала (`received request for tcp:192.168.2.197:80`), но портал **отказывается его выпускать**.
|
||
|
||
## Причина (официальная документация)
|
||
|
||
Из доки Xray, outbound `freedom`:
|
||
|
||
> ⚠️ **Default fallback safety policy** (server-side / reverse-proxy scenarios):
|
||
> - Traffic from **VLESS reverse proxy** blocks **all targets** by default
|
||
> - Traffic from `VLESS`, `VMess`, `Trojan`, `Shadowsocks`, `Hysteria`, or `WireGuard` inbounds blocks **private and reserved IP ranges** by default
|
||
> - Other traffic is **fully allowed** by default
|
||
>
|
||
> To allow clients access to internal services, explicitly configure `allow` rules and limit them to necessary `network`, `ip`, and `port`.
|
||
|
||
Источник: `https://xtls.github.io/en/config/outbounds/freedom.html`
|
||
|
||
Портал классифицирует запрос как **forward proxy** (клиент просит «сходи на `192.168.2.197`») и режет его по политике.
|
||
|
||
## Единственная рабочая конфигурация reverse
|
||
|
||
Use Case 2 из доки Xray — «Remote Return Home»:
|
||
|
||
```
|
||
клиент → PUBLIC SERVER (портал) → reverse-out → туннель
|
||
↓
|
||
INTERNAL DEVICE (бридж)
|
||
↓
|
||
freedom + finalRules[allow ip <локальная сеть>]
|
||
↓
|
||
<сеть «внутренней» стороны>
|
||
```
|
||
|
||
🔴 **Ключевое ограничение:** целевая сеть — **локалка «внутренней» стороны** (той, что держит reverse-соединение). Ходить reverse-каналом в сеть **публичной** стороны **нельзя**.
|
||
|
||
**Пример конфига внутренней стороны (бридж) с разрешением в локалку:**
|
||
|
||
```json
|
||
{
|
||
"protocol": "freedom",
|
||
"tag": "home-lan",
|
||
"settings": {
|
||
"domainStrategy": "AsIs",
|
||
"finalRules": [
|
||
{ "action": "allow", "network": "tcp,udp", "ip": ["192.168.1.0/24"] }
|
||
]
|
||
}
|
||
}
|
||
```
|
||
|
||
И правило роутинга: `{ "inboundTag": ["reverse-in"], "outboundTag": "home-lan" }`.
|
||
|
||
⚠️ `finalRules` применяется **только если freedom — финальный outbound**. Если у outbound задан `sockopt.dialerProxy`, freedom перестаёт быть финальным и `finalRules` **не применяется** (из доки).
|
||
|
||
## Чем ЭТО обходится (а чем нет)
|
||
|
||
| Способ | Помогает? |
|
||
|---|---|
|
||
| `finalRules: [{action:"allow", ip:[...]}]` | ✅ **да** — но только для локалки «внутренней» стороны |
|
||
| Смена версии Xray | ❌ нет, это политика, не регрессия |
|
||
| `allowForwardProxy` в inbound | ⚠️ относится к **обычным** proxy-inbound, не снимает reverse-политику |
|
||
| `dokodemo-door` / TPROXY / REDIRECT | ❌ нет — меняет способ **приёма** трафика, не политику выпуска |
|
||
| Смена `listen` на `0.0.0.0` | ❌ нет — влияет только на приём пакетов |
|
||
|
||
⚠️ **Не путать с issue #6612 / #6242** (регрессии версий, лечатся даунгрейдом/`network_mode: host`). Здесь другой класс: **штатная политика безопасности**, она есть во всех версиях.
|
||
|
||
## Что делать, если нужен доступ в приватную сеть
|
||
|
||
1. **Определить, чья сеть «домашняя».** Reverse пускает только в локалку стороны, держащей соединение. Если нужная сеть — на публичной стороне, reverse не подходит.
|
||
2. **Альтернативы для «полного IP-стека»** (ICMP, UDP, broadcast/Samba-обзор):
|
||
- **WireGuard** на узле с белым IP — даёт настоящий L3-VPN, всё проходит.
|
||
- **SOCKS-прокси на стороне клиента** — только TCP, нужен SOCKS-aware клиент или routing на клиенте.
|
||
- **Прозрачный прокси на клиенте** (TPROXY) — TCP; UDP требует отдельной работы.
|
||
3. **Reverse оставить для того, для чего он есть** — egress через домашний канал (`reverse-in → direct`).
|
||
|
||
## Сопутствующие питфоллы, найденные в той же сессии
|
||
|
||
- **`dokodemo-door` обязан слушать `0.0.0.0`, не `127.0.0.1`.** При `listen: 127.0.0.1` REDIRECT-трафик с внешнего адреса (клиент `192.168.1.57`) не принимается — соединение отбивается мгновенно (`HTTP 000` за ~0.005 с).
|
||
- **`iptables -t nat PREROUTING` НЕ действует на локально-исходящий трафик того же хоста.** Тест `curl`-ом с самого узла, где стоит правило, всегда даст `000` и счётчик `0` — это **ложный негатив**. Проверять с постороннего хоста либо через `ip netns` (трафик станет транзитным).
|
||
- **`redirect: ""` в freedom невалидно** — пустая строка ломает конфиг. Чтобы не менять адрес, использовать `":порт"` (адрес не меняется) либо убрать поле целиком.
|
||
- **`xray run -test` читает stdin** — под SSH без `< /dev/null` виснет.
|
||
- **`sudo` через SSH на Кра́кене требует `< /dev/null`** — иначе `Connection closed by remote host`.
|
||
|
||
## Связанные заметки
|
||
|
||
- [[personal/tech/xray-reverse-tunnel-kraken-truenas]] — рабочий reverse-туннель (egress), архитектура
|
||
- [[personal/plans/lan-access-via-reverse-tunnel]] — попытка использовать reverse как вход в сеть TrueNAS (тупик)
|