mirror of
https://github.com/XTLS/Xray-docs-next.git
synced 2025-02-22 17:33:13 +03:00
RU Update reverse.md
This commit is contained in:
imbabyninja
parent
a086bb44c6
commit
8bec8af942
@ -1,48 +1,51 @@
|
||||
# Обратный прокси
|
||||
|
||||
Обратный прокси позволяет перенаправлять трафик с сервера на клиент, то есть перенаправлять трафик в обратном направлении.
|
||||
Обратный прокси может перенаправлять трафик с сервера на клиент, то есть выполнять обратную переадресацию трафика.
|
||||
|
||||
Принцип работы обратного прокси:
|
||||
В основе его лежит протокол Mux.cool, который, будучи протоколом мультиплексирования, также обладает свойствами, подобными QUIC. Клиент и сервер равноправны, и обе стороны могут создавать новые подсоединения. Обычно только клиент открывает подсоединения, но здесь открытие подсоединения сервером используется для отправки запросов обратного прокси.
|
||||
|
||||
Принцип работы обратного прокси примерно следующий:
|
||||
|
||||
- Предположим, на хосте A находится веб-сервер, у которого нет публичного IP-адреса и к которому нельзя получить прямой доступ из Интернета. Есть другой хост B с публичным IP-адресом. Нам нужно использовать B в качестве точки входа, перенаправляя трафик с B на A.
|
||||
- На хосте B настраивается Xray для приема внешних запросов, поэтому он называется `portal` (портал).
|
||||
- На хосте A настраивается Xray, который отвечает за соединение переадресации от B с веб-сервером. Он называется `bridge` (мост).
|
||||
|
||||
- `bridge`
|
||||
- `bridge` активно устанавливает соединение с `portal` для регистрации обратного канала. Целевой адрес (домен) этого соединения можно задать самостоятельно.
|
||||
- После получения трафика из Интернета, перенаправленного `portal`, `bridge` пересылает его без изменений на веб-сервер на хосте A. Конечно, для этого требуется настройка модуля маршрутизации.
|
||||
- После получения ответа `bridge` также возвращает его без изменений `portal`.
|
||||
|
||||
- `portal`
|
||||
- Если `portal` получает запрос, и домен совпадает, это означает, что данные ответа пришли от `bridge`. Это соединение будет использовано для установления обратного канала.
|
||||
- Если `portal` получает запрос, и домен не совпадает, это означает, что соединение установлено пользователем из Интернета. Данные этого соединения будут перенаправлены на `bridge`.
|
||||
|
||||
- Предположим, что на хосте A запущен веб-сервер, но у этого хоста нет публичного IP-адреса, и к нему нельзя получить доступ из Интернета.
|
||||
У нас есть другой хост B с публичным IP-адресом.
|
||||
Мы хотим использовать хост B в качестве шлюза и перенаправлять трафик с B на A.
|
||||
- На хосте A настроен Xray, называемый `bridge`, и на хосте B также настроен Xray, называемый `portal`.
|
||||
- `bridge` устанавливает соединение с `portal`.
|
||||
Целевой адрес этого соединения можно настроить произвольно.
|
||||
`portal` получает два типа соединений: соединения от `bridge` и соединения от пользователей из Интернета.
|
||||
`portal` автоматически объединяет эти два типа соединений.
|
||||
Таким образом, `bridge` может получать трафик из Интернета.
|
||||
- После получения трафика из Интернета `bridge` перенаправляет его на веб-сервер на хосте A без изменений.
|
||||
Конечно, для этого требуется настроить маршрутизацию.
|
||||
- `bridge` выполняет динамическую балансировку нагрузки в зависимости от объема трафика.
|
||||
|
||||
::: tip
|
||||
Обратный прокси по умолчанию использует [Mux](../../development/protocols/muxcool/).
|
||||
Не включайте Mux для исходящих подключений, используемых обратным прокси.
|
||||
Как указано выше, обратный прокси по умолчанию использует [Mux](../../development/protocols/muxcool/). Пожалуйста, не включайте Mux повторно на используемых исходящих соединениях.
|
||||
:::
|
||||
|
||||
::: warning
|
||||
Функция обратного прокси находится в стадии тестирования и может работать некорректно.
|
||||
Функция обратного прокси все еще находится в стадии тестирования и может иметь некоторые проблемы.
|
||||
:::
|
||||
|
||||
## ReverseObject
|
||||
|
||||
`ReverseObject` соответствует полю `reverse` в конфигурационном файле.
|
||||
`ReverseObject` соответствует параметру `reverse` в файле конфигурации.
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"reverse": {
|
||||
"bridges": [
|
||||
{
|
||||
"tag": "bridge",
|
||||
"domain": "test.xray.com"
|
||||
"domain": "reverse-proxy.xray.internal"
|
||||
}
|
||||
],
|
||||
"portals": [
|
||||
{
|
||||
"tag": "portal",
|
||||
"domain": "test.xray.com"
|
||||
"domain": "reverse-proxy.xray.internal"
|
||||
}
|
||||
]
|
||||
}
|
||||
@ -51,96 +54,91 @@
|
||||
|
||||
> `bridges`: \[[BridgeObject](#bridgeobject)\]
|
||||
|
||||
Массив, каждый элемент которого представляет собой `bridge`.
|
||||
Настройки каждого `bridge` определяются в [BridgeObject](#bridgeobject).
|
||||
Массив, каждый элемент которого представляет собой `bridge`. Конфигурация каждого `bridge` является [BridgeObject](#bridgeobject).
|
||||
|
||||
> `portals`: \[[PortalObject](#portalobject)\]
|
||||
|
||||
Массив, каждый элемент которого представляет собой `portal`.
|
||||
Настройки каждого `portal` определяются в [PortalObject](#bridgeobject).
|
||||
Массив, каждый элемент которого представляет собой `portal`. Конфигурация каждого `portal` является [PortalObject](#bridgeobject).
|
||||
|
||||
### BridgeObject
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"tag": "bridge",
|
||||
"domain": "test.xray.com"
|
||||
"domain": "reverse-proxy.xray.internal"
|
||||
}
|
||||
```
|
||||
|
||||
> `tag`: string
|
||||
|
||||
Все соединения, исходящие от `bridge`, будут иметь этот тег.
|
||||
Его можно использовать для идентификации соединений в [настройках маршрутизации](./routing.md) с помощью `inboundTag`.
|
||||
Все соединения, исходящие от `bridge`, будут иметь эту метку. Ее можно использовать для идентификации в [конфигурации маршрутизации](./routing.md) с помощью `inboundTag`.
|
||||
|
||||
> `domain`: string
|
||||
|
||||
Доменное имя, которое `bridge` будет использовать для установления соединения с `portal`.
|
||||
Это доменное имя используется только для связи между `bridge` и `portal` и не должно существовать на самом деле.
|
||||
Указывает домен, который `bridge` будет использовать для установления соединения с `portal`.
|
||||
Этот домен используется только для связи между `bridge` и `portal` и не обязательно должен существовать.
|
||||
|
||||
### PortalObject
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"tag": "portal",
|
||||
"domain": "test.xray.com"
|
||||
"domain": "reverse-proxy.xray.internal"
|
||||
}
|
||||
```
|
||||
|
||||
> `tag`: string
|
||||
|
||||
Тег `portal`.
|
||||
Используйте `outboundTag` в [настройках маршрутизации](./routing.md), чтобы перенаправить трафик на этот `portal`.
|
||||
Метка `portal`. Используется в [конфигурации маршрутизации](./routing.md) с `outboundTag` для перенаправления трафика на этот `portal`.
|
||||
|
||||
> `domain`: string
|
||||
|
||||
Доменное имя.
|
||||
Когда `portal` получает трафик, если целевое доменное имя трафика совпадает с этим доменным именем, `portal` считает, что это соединение для связи с `bridge`.
|
||||
Весь остальной трафик считается трафиком, который нужно перенаправить.
|
||||
`portal` идентифицирует и объединяет эти два типа соединений.
|
||||
Домен. Когда `portal` получает трафик, если целевой домен трафика совпадает с этим доменом, `portal` считает, что текущее соединение является соединением связи, установленным `bridge`. Другой трафик будет рассматриваться как трафик, требующий пересылки. `portal` занимается идентификацией этих двух типов соединений и выполняет соответствующую пересылку.
|
||||
|
||||
|
||||
::: tip
|
||||
Один и тот же экземпляр Xray может выступать в роли `bridge`, `portal` или и того, и другого, в зависимости от сценария использования.
|
||||
Один Xray может быть `bridge`, `portal` или одновременно и тем, и другим, чтобы соответствовать требованиям различных сценариев.
|
||||
:::
|
||||
|
||||
## Примеры полных конфигураций
|
||||
## Полный пример конфигурации
|
||||
|
||||
::: tip
|
||||
Рекомендуется сначала запустить `bridge`, а затем `portal`.
|
||||
Во время работы рекомендуется сначала запустить `bridge`, а затем `portal`.
|
||||
:::
|
||||
|
||||
### Настройка bridge
|
||||
### Конфигурация bridge
|
||||
|
||||
`bridge` обычно требуется два исходящих подключения: одно для подключения к `portal`, а другое - для отправки фактического трафика.
|
||||
Другими словами, вам нужно использовать маршрутизацию, чтобы разделять эти два типа трафика.
|
||||
`bridge` обычно требует двух исходящих соединений (outbound): одно для подключения к `portal`, другое для отправки фактического трафика. Другими словами, вам нужно использовать маршрутизацию для различения двух типов трафика.
|
||||
|
||||
Настройки обратного прокси:
|
||||
Конфигурация обратного прокси:
|
||||
|
||||
```json
|
||||
{
|
||||
```jsonc
|
||||
"reverse": {
|
||||
"bridges": [
|
||||
{
|
||||
"tag": "bridge",
|
||||
"domain": "test.xray.com"
|
||||
"domain": "reverse-proxy.xray.internal"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Исходящие подключения:
|
||||
outbound:
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
// Переадресация на веб-сервер
|
||||
"tag": "out",
|
||||
"protocol": "freedom",
|
||||
"settings": {
|
||||
"redirect": "127.0.0.1:80" // Перенаправить весь трафик на веб-сервер
|
||||
"redirect": "127.0.0.1:80"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
// Подключение к portal
|
||||
"protocol": "vmess",
|
||||
"settings": {
|
||||
"vnext": [
|
||||
@ -159,18 +157,23 @@
|
||||
}
|
||||
```
|
||||
|
||||
Настройки маршрутизации:
|
||||
Конфигурация маршрутизации:
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"rules": [
|
||||
{
|
||||
// Запрос от bridge, и домен соответствует настроенному домену,
|
||||
// это означает, что это попытка установить обратный туннель к portal,
|
||||
// маршрутизируем на interconn, то есть подключаемся к portal
|
||||
"type": "field",
|
||||
"inboundTag": ["bridge"],
|
||||
"domain": ["full:test.xray.com"],
|
||||
"domain": ["full:reverse-proxy.xray.internal"],
|
||||
"outboundTag": "interconn"
|
||||
},
|
||||
{
|
||||
// Трафик от portal также будет выходить из bridge, но без указанного выше домена
|
||||
// маршрутизируем на out, то есть перенаправляем на веб-сервер
|
||||
"type": "field",
|
||||
"inboundTag": ["bridge"],
|
||||
"outboundTag": "out"
|
||||
@ -179,28 +182,28 @@
|
||||
}
|
||||
```
|
||||
|
||||
### Настройка portal
|
||||
### Конфигурация portal
|
||||
|
||||
`portal` обычно требуется два входящих подключения: одно для приема соединений от `bridge`, а другое - для приема фактического трафика.
|
||||
Вам также нужно использовать маршрутизацию, чтобы разделять эти два типа трафика.
|
||||
`portal` обычно требует двух входящих соединений (inbound): одно для приема соединений от `bridge`, другое для приема фактического трафика. Вам также нужно использовать маршрутизацию для различения двух типов трафика.
|
||||
|
||||
Настройки обратного прокси:
|
||||
Конфигурация обратного прокси:
|
||||
|
||||
```json
|
||||
{
|
||||
```jsonc
|
||||
"reverse": {
|
||||
"portals": [
|
||||
{
|
||||
"tag": "portal",
|
||||
"domain": "test.xray.com" // Должно совпадать с настройками bridge
|
||||
"domain": "reverse-proxy.xray.internal" // Должно совпадать с конфигурацией bridge
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Входящие подключения:
|
||||
inbound:
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
// Прямой прием запросов из Интернета
|
||||
"tag": "external",
|
||||
"port": 80,
|
||||
"protocol": "dokodemo-door",
|
||||
@ -212,10 +215,11 @@
|
||||
}
|
||||
```
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"port": 1024,
|
||||
// Прием запросов от bridge для установления обратного туннеля
|
||||
"tag": "interconn",
|
||||
"port": 1024,
|
||||
"protocol": "vmess",
|
||||
"settings": {
|
||||
"clients": [
|
||||
@ -227,21 +231,27 @@
|
||||
}
|
||||
```
|
||||
|
||||
Настройки маршрутизации:
|
||||
Конфигурация маршрутизации:
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"rules": [
|
||||
{
|
||||
// Если входящее соединение помечено external, значит, это запрос из Интернета,
|
||||
// маршрутизируем на portal, который в конечном итоге перенаправит его на bridge
|
||||
"type": "field",
|
||||
"inboundTag": ["external"],
|
||||
"outboundTag": "portal"
|
||||
},
|
||||
{
|
||||
// Если входящее соединение от interconn, значит, это запрос от bridge для установления обратного туннеля,
|
||||
// маршрутизируем на portal, который в конечном итоге перенаправит его соответствующему клиенту в Интернете.
|
||||
// Обратите внимание: этот запрос будет содержать домен, настроенный ранее, поэтому portal сможет различать два типа запросов,
|
||||
// маршрутизируемых на portal.
|
||||
"type": "field",
|
||||
"inboundTag": ["interconn"],
|
||||
"outboundTag": "portal"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user