mirror of
https://github.com/XTLS/Xray-docs-next.git
synced 2026-09-29 10:27:57 +03:00
Wiregurad: Simplify
We only explain in detail the concepts we've introduced and the things people often confuse, rather than over-explaining every single field. (wireguard official doc already has these for advance user)
This commit is contained in:
Fangliding
@@ -1,6 +1,6 @@
|
||||
# WireGuard
|
||||
|
||||
Реализация протокола WireGuard в пространстве пользователя для установления туннеля WireGuard с удалённым узлом и приёма входящего через этот туннель трафика.
|
||||
Реализация протокола WireGuard в пространстве пользователя для установления туннеля WireGuard с удалённым узлом, преобразующая полученные TCP- и UDP-пакеты во внутренние прокси-запросы Xray для обработки и ответа.
|
||||
|
||||
::: danger
|
||||
**Протокол WireGuard не предназначен специально для обхода блокировок. При использовании на внешнем уровне его характерные признаки могут привести к блокировке сервера.**
|
||||
@@ -40,21 +40,11 @@
|
||||
|
||||
Закрытый ключ сервера. Обязательное поле.
|
||||
|
||||
Пару ключей сервера можно создать командой `xray wg`. Укажите здесь полученный `PrivateKey`; выведенный вместе с ним `Password (PublicKey)` является открытым ключом сервера. Если Xray используется в качестве клиента WireGuard, открытый ключ сервера следует указать в `outbounds[].settings.peers[].publicKey`.
|
||||
При создании пары ключей сервера с помощью команды `xray wg` здесь указывается выведенный `PrivateKey`.
|
||||
|
||||
> `peers`: \[ [PeersObject](#peersobject) \]
|
||||
|
||||
Список клиентов WireGuard, каждый элемент которого содержит конфигурацию одного клиента. Если настроено несколько клиентов, Xray сопоставляет адрес источника расшифрованного внутреннего IP-пакета с `allowedIPs` каждого клиента, чтобы определить, какому клиенту принадлежит трафик.
|
||||
|
||||
::: details Сетевая модель входящего подключения Xray WireGuard
|
||||
В обычной сети WireGuard, включая соединения «точка — точка», «точка — сеть» и «сеть — сеть», обе стороны участвуют в IP-маршрутизации через сетевые интерфейсы третьего уровня.
|
||||
|
||||
В отличие от такой схемы, входящее подключение Xray WireGuard не создаёт TUN-интерфейс в системе, а серверу не требуется назначать внутренний IP-адрес туннеля. Расшифрованные внутренние IP-пакеты обрабатываются встроенным сетевым стеком: содержащийся в них TCP- и UDP-трафик преобразуется в прокси-соединения и передаётся системе маршрутизации Xray вместо дальнейшей пересылки исходных IP-пакетов.
|
||||
|
||||
Клиент может отправлять как собственный трафик, так и трафик сетей за ним, выступая в роли шлюза. Сервер Xray не является доступным клиентам узлом третьего уровня внутри туннеля и не передаёт исходные IP-пакеты системному ядру для дальнейшей маршрутизации или NAT.
|
||||
|
||||
`allowedIPs` используется при обработке пакетов в обоих направлениях: при приёме WireGuard проверяет адрес источника расшифрованного внутреннего IP-пакета, а Xray использует этот адрес для определения клиента; при отправке ответных пакетов WireGuard выбирает соответствующего клиента по внутреннему адресу назначения.
|
||||
:::
|
||||
Список пиров-клиентов WireGuard.
|
||||
|
||||
> `mtu`: int
|
||||
|
||||
@@ -93,7 +83,7 @@ MTU внутренних IP-пакетов в туннеле WireGuard. Знач
|
||||
|
||||
Открытый ключ клиента, используемый для проверки. Обязательное поле.
|
||||
|
||||
Если Xray используется в качестве клиента WireGuard, здесь следует указать `Password (PublicKey)`, соответствующий закрытому ключу клиента в `outbounds[].settings.secretKey`.
|
||||
При создании пары ключей с помощью `xray wg` здесь указывается выведенный `Password (PublicKey)`.
|
||||
|
||||
> `preSharedKey`: string
|
||||
|
||||
@@ -105,13 +95,9 @@ MTU внутренних IP-пакетов в туннеле WireGuard. Знач
|
||||
|
||||
> `allowedIPs`: \[ string \]
|
||||
|
||||
Задаёт IP-адреса или подсети, которые этому клиенту разрешено использовать в качестве адреса источника. Каждый элемент указывается в формате CIDR.
|
||||
Задаёт разрешённые для отправки этим клиентом IP-адреса или подсети источника в формате CIDR. Значение по умолчанию — `["0.0.0.0/0", "::/0"]`, то есть разрешены все адреса источников IPv4 и IPv6.
|
||||
|
||||
Значение `address` исходящего подключения клиента должно входить в `allowedIPs` соответствующего пира на сервере. Например, если `outbounds[].settings.address` клиента равно `["10.0.0.2"]`, здесь можно указать `["10.0.0.2/32"]`.
|
||||
|
||||
В `allowedIPs` можно указывать не только внутренний IP-адрес клиента, но и сети, трафик которых маршрутизируется через этот пир. Например, если сторонний клиент WireGuard служит шлюзом для `192.168.10.0/24`, эту сеть можно добавить сюда; на самом клиенте также необходимо настроить маршрутизацию и включить пересылку IP-пакетов.
|
||||
|
||||
При наличии только одного клиента поле можно опустить; значение по умолчанию — `["0.0.0.0/0", "::/0"]`. Если настроено несколько клиентов, необходимо явно указать непересекающиеся значения `allowedIPs`, иначе надёжно различать клиентов будет невозможно.
|
||||
При наличии только одного клиента поле можно опустить; значение по умолчанию — `["0.0.0.0/0", "::/0"]`. При настройке нескольких клиентов, в отличие от `allowedIPs` на стороне клиента, `allowedIPs` здесь не должны пересекаться: в лучшем случае это приведёт к невозможности правильно определить пир клиента, в худшем — к нарушению маршрутизации ответных пакетов.
|
||||
|
||||
> `email`: string
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# WireGuard
|
||||
|
||||
Реализация протокола WireGuard в пространстве пользователя для установления туннеля WireGuard с удалённым узлом и отправки исходящего трафика через этот туннель.
|
||||
Реализация протокола WireGuard в пространстве пользователя для установления туннеля WireGuard с удалённым узлом, инкапсулирующая перенаправленные в это исходящее подключение TCP/UDP-запросы в IP-пакеты и отправляющая их через туннель WireGuard.
|
||||
|
||||
::: danger
|
||||
**Протокол WireGuard не предназначен специально для обхода блокировок. При использовании на внешнем уровне его характерные признаки могут привести к блокировке сервера.**
|
||||
@@ -16,20 +16,15 @@
|
||||
{
|
||||
// ...
|
||||
"protocol": "wireguard",
|
||||
// [!code focus:25]
|
||||
// [!code focus:20]
|
||||
"settings": {
|
||||
"secretKey": "CLIENT_PRIVATE_KEY",
|
||||
"address": [
|
||||
"10.0.0.1",
|
||||
"fd59:7153:2388:b5fd:0000:0000:0000:0001",
|
||||
"and more..."
|
||||
],
|
||||
"address": ["10.0.0.1", "fd59:7153:2388:b5fd:0000:0000:0000:0001"],
|
||||
"peers": [
|
||||
{
|
||||
"endpoint": "SERVER_ADDR",
|
||||
"endpoint": "example.com:2408",
|
||||
"publicKey": "SERVER_PUBLIC_KEY",
|
||||
"allowedIPs": ["0.0.0.0/0", "::/0"]
|
||||
// ...
|
||||
}
|
||||
],
|
||||
"noKernelTun": false,
|
||||
@@ -51,28 +46,26 @@
|
||||
|
||||
Закрытый ключ клиента. Обязательное поле.
|
||||
|
||||
Пару ключей клиента можно создать командой `xray wg`. Укажите здесь полученный `PrivateKey`; выведенный вместе с ним `Password (PublicKey)` является открытым ключом клиента. Если Xray используется в качестве сервера WireGuard, открытый ключ клиента следует указать в `inbounds[].settings.peers[].publicKey`.
|
||||
При создании пары ключей клиента с помощью команды `xray wg` здесь указывается выведенный `PrivateKey`.
|
||||
|
||||
> `address`: \[ string \]
|
||||
|
||||
Задаёт локальные адреса источника для внутренних IP-пакетов, создаваемых исходящим подключением WireGuard, то есть внутренние IP-адреса клиента в туннеле. Можно указать один или несколько адресов IPv4 или IPv6.
|
||||
Список локальных IP-адресов интерфейса WireGuard. При наличии нескольких адресов выбирается автоматически в зависимости от пира.
|
||||
|
||||
Значение по умолчанию — `["10.0.0.1", "fd59:7153:2388:b5fd:0000:0000:0000:0001"]`.
|
||||
|
||||
Xray автоматически выбирает адрес источника нужного семейства в зависимости от адреса назначения. Если настроено несколько адресов одного семейства, подходящий адрес выбирается по внутренним правилам.<br>
|
||||
Конфигурация входящего подключения на сервере WireGuard должна разрешать эти адреса, и каждый из них должен быть уникальным в конфигурации входящего подключения WireGuard на сервере.
|
||||
|
||||
> `noKernelTun`: true | false
|
||||
|
||||
Отключает использование TUN. Значение по умолчанию — `false`; в средах LXC или Docker может потребоваться значение `true`.
|
||||
Принудительно отключает системный TUN независимо от результатов автоматического определения. Значение по умолчанию — `false`; в средах LXC или Docker может потребоваться значение `true`.
|
||||
|
||||
::: details Нужно ли включать `noKernelTun`?
|
||||
При значении `false` Xray автоматически выбирает способ обработки внутренних IP-пакетов: в Linux, если процесс Xray имеет привилегию `CAP_NET_ADMIN`, создаётся TUN-интерфейс и используется сетевой стек ядра; на других платформах или при недостаточных правах используется работающий внутри процесса сетевой стек gVisor. При значении `true` используется только сетевой стек gVisor и TUN-интерфейс не создаётся. Использование TUN обычно обеспечивает более высокую производительность.
|
||||
::: details О kernel TUN
|
||||
Способ восстановления IP-пакетов WireGuard обратно в TCP/UDP-нагрузку в Xray.
|
||||
По умолчанию Xray определяет автоматически: в Linux, если процесс Xray имеет привилегию `CAP_NET_ADMIN`, создаётся TUN-интерфейс и используется сетевой стек ядра; на других платформах или при недостаточных правах используется работающий внутри процесса сетевой стек gVisor. При значении `true` используется только сетевой стек gVisor и TUN-интерфейс не создаётся. Использование TUN обычно обеспечивает более высокую производительность.
|
||||
|
||||
Описанное автоматическое определение не всегда работает точно. Например, некоторые среды LXC могут не позволять использовать TUN даже при наличии привилегии `CAP_NET_ADMIN`, из-за чего исходящее подключение не будет работать; в таком случае установка `noKernelTun` в `true` решает проблему.
|
||||
|
||||
Этот параметр определяет только способ обработки внутренних IP-пакетов. Сам протокол WireGuard по-прежнему обрабатывается пользовательской реализацией Xray и не связан с модулем WireGuard ядра.
|
||||
|
||||
Описанное автоматическое определение не всегда работает точно. Например, некоторые среды LXC могут не позволять использовать TUN даже при наличии привилегии `CAP_NET_ADMIN`, из-за чего исходящее подключение не будет работать. В таком случае установите значение `true`.
|
||||
|
||||
При использовании TUN задействуется таблица маршрутизации IPv6 с номером 10230. Каждое следующее исходящее подключение WireGuard последовательно использует следующую таблицу: например, второе подключение использует таблицу 10231 и так далее.
|
||||
|
||||
Если на том же компьютере запустить второй экземпляр Xray, нумерация таблиц не продолжится: второй экземпляр также попытается использовать таблицу 10230. Поскольку она уже занята первым экземпляром Xray, подключение установить не удастся. Если запуск нескольких экземпляров необходим, используйте этот параметр для отключения TUN.
|
||||
@@ -104,43 +97,19 @@ MTU внутренних IP-пакетов в туннеле WireGuard. Знач
|
||||
|
||||
> `peers`: \[ [PeersObject](#peersobject) \]
|
||||
|
||||
Список серверов WireGuard, каждый элемент которого содержит конфигурацию одного сервера. Если настроено несколько серверов, Xray сопоставляет IP-адрес назначения с `allowedIPs` каждого сервера по префиксу и направляет трафик на совпавший сервер. Таким образом, разные сети назначения можно обслуживать через разные серверы WireGuard.
|
||||
|
||||
::: details Модель пакетов исходящего подключения Xray WireGuard
|
||||
TCP- и UDP-соединения, поступающие в исходящее подключение WireGuard, преобразуются сетевым стеком во внутренние IP-пакеты. Внутренний адрес источника выбирается из `address`, а внутренним адресом назначения становится IP-адрес назначения проксируемого трафика.
|
||||
|
||||
Xray сопоставляет внутренний адрес назначения с `allowedIPs` каждого пира по префиксу. Совпавший пир шифрует и инкапсулирует пакет, после чего внешний UDP-пакет отправляется на `endpoint` этого пира. Таким образом, `address` задаёт внутренние адреса источника клиента, `allowedIPs` служит таблицей маршрутов назначения для выбора пира, а `endpoint` является адресом сервера для внешнего соединения.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
Каждый сервер WireGuard должен разрешать все адреса из `address`, семейство которых совпадает с семейством адресов в его `allowedIPs`: если `allowedIPs` содержит только сети IPv4, необходимо разрешить все IPv4-адреса из `address`; если только сети IPv6 — все IPv6-адреса; если присутствуют сети обоих семейств — все указанные адреса.
|
||||
|
||||
Если в качестве сервера WireGuard используется Xray, перечислите эти адреса в `inbounds[].settings.peers[].allowedIPs`.
|
||||
:::
|
||||
Список удалённых пиров WireGuard для подключения.
|
||||
|
||||
> `remoteDNS`: \[ string \]
|
||||
|
||||
Используется для разрешения целевых доменных имён проксируемого трафика. Каждый элемент должен быть IP-адресом. Значение по умолчанию — `["1.1.1.1", "1.0.0.1", "2606:4700:4700::1111", "2606:4700:4700::1001"]`.
|
||||
|
||||
DNS-запросы отправляются через туннель WireGuard; IP-адрес каждого сервера должен входить в `allowedIPs` одного из пиров и быть доступен через туннель.
|
||||
|
||||
::: details `remoteDNS` и `targetStrategy`
|
||||
В отличие от других исходящих подключений, целью внутри туннеля WireGuard должен быть IP-адрес. Если целью проксируемого запроса является доменное имя, параметр [`targetStrategy`](../outbound.md#outboundobject) исходящего подключения определяет, какой DNS используется для его разрешения:
|
||||
|
||||
- `AsIs`: используется `remoteDNS`.
|
||||
- `UseIP*`: сначала используется встроенный DNS Xray, а при ошибке разрешения выполняется переход на `remoteDNS`.
|
||||
- `ForceIP*`: используется встроенный DNS Xray; ошибка разрешения сразу приводит к ошибке подключения.
|
||||
|
||||
Результаты `UseIP*` или `ForceIP*` должны содержать хотя бы один IP-адрес того же семейства, что и один из адресов в `address`; иначе соединение завершится ошибкой. Несовпадение семейств адресов не считается ошибкой разрешения и не запускает никакой переход на резервный вариант.
|
||||
|
||||
Что выбрать? `remoteDNS` работает сразу, без дополнительной настройки, и отправляет запросы через туннель WireGuard, что обычно позволяет получить результаты CDN, соответствующие расположению выхода из туннеля. Для достижения того же результата с помощью [встроенного DNS Xray](../dns.md) обычно требуется дополнительно настроить DNS-серверы и правила маршрутизации. Однако если встроенный DNS ранее уже разрешил целевое доменное имя — например, при использовании схемы RealIP с TUN/TProxy либо при включённом сниффинге и значении `routing.domainStrategy`, отличном от `AsIs`, — рекомендуется использовать встроенный DNS Xray, чтобы избежать дополнительной задержки RTT из-за повторного разрешения.
|
||||
:::
|
||||
В отличие от других исходящих подключений, адрес цели внутри туннеля WireGuard обязательно должен быть IP-адресом. Если проксируемая цель является доменным именем, необходим DNS-сервер для преобразования доменного имени в IP-адрес. Эти DNS-серверы настраиваются здесь и **отправляют DNS-запросы напрямую через этот туннель WireGuard**. Если вы хотите подключить встроенную систему DNS Xray, рассмотрите возможность предварительного разрешения через [`targetStrategy`](../outbound.md#outboundobject) исходящего подключения.
|
||||
|
||||
### PeersObject
|
||||
|
||||
```json
|
||||
{
|
||||
"endpoint": "SERVER_ADDR",
|
||||
"endpoint": "example.com:2408",
|
||||
"publicKey": "SERVER_PUBLIC_KEY",
|
||||
"preSharedKey": "PRE_SHARED_KEY",
|
||||
"keepAlive": 0,
|
||||
@@ -150,16 +119,13 @@ DNS-запросы отправляются через туннель WireGuard;
|
||||
|
||||
> `endpoint`: address
|
||||
|
||||
Адрес сервера. Обязательное поле.
|
||||
|
||||
Формат URL:порт, например `engage.cloudflareclient.com:2408`<br>
|
||||
Формат IP:порт, например `162.159.192.1:2408` или `[2606:4700:d0::a29f:c001]:2408`
|
||||
Адрес и порт сервера, может быть IP-адресом или доменным именем. Обязательное поле.
|
||||
|
||||
> `publicKey`: string
|
||||
|
||||
Открытый ключ сервера, используемый для проверки. Обязательное поле.
|
||||
Открытый ключ пира, используемый для проверки. Обязательное поле.
|
||||
|
||||
Если Xray используется в качестве сервера WireGuard, здесь следует указать `Password (PublicKey)`, соответствующий закрытому ключу сервера в `inbounds[].settings.secretKey`.
|
||||
При создании пары ключей с помощью `xray wg` здесь указывается выведенный `Password (PublicKey)`.
|
||||
|
||||
> `preSharedKey`: string
|
||||
|
||||
@@ -167,8 +133,8 @@ DNS-запросы отправляются через туннель WireGuard;
|
||||
|
||||
> `keepAlive`: int
|
||||
|
||||
Интервал отправки клиентом этому серверу пакетов persistent keepalive, в секундах. Они поддерживают возможные сопоставления NAT или состояние межсетевого экрана в периоды простоя. Включайте этот параметр только при необходимости и только на стороне клиента. Значение по умолчанию — `0`, то есть пакеты не отправляются.
|
||||
Интервал отправки клиентом этому серверу пакетов persistent keepalive, в секундах, для поддержания возможных сопоставлений NAT или состояния межсетевого экрана во время простоя. Требуется включать только в особых случаях и только на стороне клиента; значение по умолчанию — `0`, то есть пакеты не отправляются.
|
||||
|
||||
> `allowedIPs`: \[ string \]
|
||||
|
||||
Задаёт IP-сети назначения, пересылаемые через этот сервер. Каждый элемент указывается в формате CIDR. При наличии только одного сервера поле можно опустить: значение по умолчанию — `["0.0.0.0/0", "::/0"]`, то есть через сервер направляется весь трафик к адресам IPv4 и IPv6. Если настроено несколько серверов, необходимо явно задать `allowedIPs` для каждого из них и распределить сети назначения между соответствующими серверами; Xray выбирает сервер путём сопоставления префикса IP-адреса назначения.
|
||||
Запросы, которые должны пересылаться через этот пир, в формате CIDR. Значение по умолчанию — `["0.0.0.0/0", "::/0"]`, то есть весь целевой трафик IPv4 и IPv6 пересылается через этот сервер. При совпадении нескольких пиров выбор осуществляется по принципу наибольшего совпадения префикса (longest prefix match).
|
||||
|
||||
Reference in New Issue
Block a user