Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 36 additions & 3 deletions docs/config/inbounds/tun.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,9 @@ Linux 可选使用该环境变量传入 TUN FD 以进行某些轻量化或非特
"dns": ["1.1.1.1", "8.8.8.8"],
"userLevel": 0,
"autoSystemRoutingTable": ["0.0.0.0/0", "::/0"],
"autoOutboundsInterface": "auto"
"autoOutboundsInterface": "auto",
"autoSystemDnsToGateway": false,
"autoSystemWfpBlockLeak": ["dns", "misconfigtun"]
}
}
]
Expand All @@ -52,11 +54,17 @@ Windows 系统中的网络接口名称描述,默认为 `Wintun`。该字符串

为 TUN 接口配置的地址前缀列表,通常分别填写 IPv4 / IPv6,例如 `"10.0.0.1/16"`、`"fc00::1/64"`。

macOS 系统中,仅 IPv4 会生效,如未设置,则使用 `169.254.10.1/30`。
未配置时,结果取决于系统:在 Linux 上,Xray 不会分配地址;在 Windows 上,系统会自动为 TUN 接口分配链路本地地址(IPv6 立即分配,IPv4 在几秒后从 `169.254.0.0/16` 中分配);在 macOS 和 FreeBSD 上,使用 `169.254.10.1/30`。macOS 和 FreeBSD 只使用第一个 IPv4 前缀。

> `dns`: [string]

该项配置只在 Windows 系统上有效,可为 TUN 接口配置的 DNS 服务器列表,例如 `"1.1.1.1"`、`"8.8.8.8"`。
为 TUN 接口配置的 DNS 服务器列表,例如 `"1.1.1.1"`、`"8.8.8.8"`。

该项配置只在 Windows 系统上有效,服务器会被设置到 TUN 接口上。Windows 除了向它们发送查询,也会向其他网络接口的 DNS 服务器发送查询;`autoSystemWfpBlockLeak` 中的 `"dns"` 会阻止后者。只有当这些服务器在 `gateway` 或 `autoSystemRoutingTable` 的范围内时,发往它们的查询才会经由 TUN 接口。在 Xray 中它们就是发往 53 端口的普通流量:可以用路由规则交给 [DNS 出站](../outbounds/dns.md),否则会像其他流量一样被转发到这些服务器。TUN 接口的地址不会被注册到 DNS 中,并且 TUN 接口启动和停止时会清空 DNS 缓存。

使用 `autoOutboundsInterface` 时,Xray 的 `localhost` DNS 服务器会跳过这些服务器(除非其他接口也在使用它们),因为发往它们的查询会回到 TUN 接口中。

在 Linux 上,系统 DNS 不会从该项获取,参见 `autoSystemDnsToGateway`;在 macOS 上不会配置系统 DNS。

> `userLevel`: number

Expand All @@ -78,6 +86,31 @@ userLevel 的值, 对应 [policy](../policy.md#policyobject) 中 `level` 的值.

默认值为 `null`,即未配置。可填写具体接口名,也可填写 `"auto"` 让 Xray 自动选择。如果配置了 `autoSystemRoutingTable` 但未显式指定此项,Xray 会自动按 `"auto"` 处理。

> `autoSystemDnsToGateway`: true | false

该项配置只在 Linux 系统上有效,默认值为 `false`。

启用后,Xray 会(通过 `resolvectl`)把系统解析器 systemd-resolved 指向 TUN 接口,使系统的域名查询经过 Xray。使用的地址是 `gateway` 中第一个 IPv4 地址加一(例如 `10.0.0.1/16` → `10.0.0.2`),没有 IPv4 地址时使用第一个 IPv6 地址加一(例如 `fc00::1/64` → `fc00::2`);未配置 `gateway` 时 Xray 会报错退出。该地址不取自 `dns`,否则 systemd-resolved 会在 TUN 接口之外直接查询那些服务器。

发往该地址的查询必须由 Xray 应答,因此需要一条路由规则,把该入站的 53 端口交给 [DNS 出站](../outbounds/dns.md)。Xray 会在更改系统 DNS 之前进行检查:如果这样的查询不会到达 DNS 出站,或者 Xray 自身的 [DNS](../dns.md) 可能通过系统解析器解析(没有配置 DNS 服务器,或配置了 `localhost`),会造成循环,则不会更改系统 DNS,Xray 也不会启动。

需要 systemd-resolved 240 或更高版本正在运行。只要无法更改系统 DNS,Xray 就不会启动。Xray 正常退出时会恢复该设置;如果 Xray 被强制结束(例如 `SIGKILL`),可以运行 `resolvectl revert <接口名>` 手动恢复。

> `autoSystemWfpBlockLeak`: [string]

该项配置只在 Windows 系统上有效,默认为空,即不添加过滤器。

该项需要配置 `autoSystemRoutingTable`,否则 Xray 会报错退出。Xray 会按列表中的值添加 Windows 筛选平台(WFP)过滤器,防止其他程序的流量从 TUN 接口之外泄漏:

- `"dns"`(需要配置 `dns`,否则 Xray 会报错退出):DNS(53 端口)只能经由 TUN 接口或由 Xray 自身发出。Windows 会向所有网络接口的 DNS 服务器发送查询,并且无论路由如何都经由各自的接口发出,其他程序也会经由更具体的局域网路由访问本地网络中的 DNS 服务器(例如 DHCP 分配的 `192.168.1.1`),否则这些服务器仍会在 TUN 之外被查询。在 Windows 11、Windows Server 2022 及更高版本上,这些查询还可能使用 DNS over HTTPS 或 DNS over TLS,所以 Windows 的 DNS Client 服务(Dnscache)完全不能在 TUN 接口之外建立连接,本地网络中的名称解析(LLMNR、mDNS)除外。因此 `dns` 中的服务器必须在 `gateway` 或 `autoSystemRoutingTable` 的范围内,需要直连的 DNS 服务器应配置在 Xray 自身的 [DNS](../dns.md) 设置中。
- `"misconfigtun"`:如果 `autoSystemRoutingTable` 中没有某个 IP 版本(IPv4 或 IPv6)的路由,则双向阻止该版本,但 Xray 自身、环回以及 Windows 在本地链路上所需的流量(DHCP、IPv6 邻居发现)除外。TUN 接口承载某个 IP 版本不需要在 `gateway` 中配置该版本的地址:未配置时,Windows 会自动为其分配链路本地地址(IPv6 立即分配,IPv4 在几秒后从 `169.254.0.0/16` 中分配)。

过滤器生效期间,Xray 自身的出站连接也不受 Windows 防火墙阻止规则的限制。

过滤器会在 Xray 退出时自动移除,即使 Xray 崩溃也是如此。如果无法添加过滤器,Xray 不会启动。

该项默认为空,因为这些过滤器会在某些情况下造成问题:`"dns"` 会影响其他程序使用的本地 DNS 解析器(例如 `127.0.0.1:53`)、其他 VPN 的 DNS、在主机上解析域名的虚拟机 NAT,以及登录强制门户(captive portal);`"misconfigtun"` 会影响没有路由通往 TUN 接口的 IP 版本(IPv4 或 IPv6)在本地网络中的通信。不使用这些过滤器时,DNS 可能会如上所述泄漏。如果有意让某个 IP 版本不经过 TUN 接口,同时仍要阻止 DNS 泄漏,只使用 `["dns"]` 即可。

## 使用提示

如果未配置 `autoSystemRoutingTable`,仍需要手动配置路由将数据导向创建的 TUN 接口,否则它只是个接口。
Expand Down
39 changes: 36 additions & 3 deletions docs/en/config/inbounds/tun.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,9 @@ On Linux, this environment variable can optionally be used to pass in the TUN FD
"dns": ["1.1.1.1", "8.8.8.8"],
"userLevel": 0,
"autoSystemRoutingTable": ["0.0.0.0/0", "::/0"],
"autoOutboundsInterface": "auto"
"autoOutboundsInterface": "auto",
"autoSystemDnsToGateway": false,
"autoSystemWfpBlockLeak": ["dns", "misconfigtun"]
}
}
]
Expand All @@ -52,11 +54,17 @@ The MTU of the interface. The default is `1500`.

The list of address prefixes assigned to the TUN interface, usually one for IPv4 and one for IPv6, such as `"10.0.0.1/16"` and `"fc00::1/64"`.

On macOS, only IPv4 takes effect; if not set, `169.254.10.1/30` is used.
If it is not set, the result depends on the system: on Linux, Xray assigns no address; on Windows, the system gives the TUN interface link-local addresses itself (IPv6 at once, IPv4 from `169.254.0.0/16` after a few seconds); on macOS and FreeBSD, `169.254.10.1/30` is used. macOS and FreeBSD only use the first IPv4 prefix.

> `dns`: [string]

This option only takes effect on Windows. The list of DNS servers assigned to the TUN interface, such as `"1.1.1.1"` and `"8.8.8.8"`.
The list of DNS servers assigned to the TUN interface, such as `"1.1.1.1"` and `"8.8.8.8"`.

This option only takes effect on Windows, where the servers are set on the TUN interface. Windows sends name queries to them as well as to the DNS servers of the other interfaces; `"dns"` in `autoSystemWfpBlockLeak` blocks the latter. Queries to these servers only go through the TUN interface when the servers are covered by `gateway` or `autoSystemRoutingTable`. In Xray they are ordinary traffic to port 53: a routing rule can hand them to a [DNS outbound](../outbounds/dns.md), otherwise they are forwarded to the servers like other traffic. The addresses of the TUN interface are not registered in DNS, and the DNS cache is flushed when the TUN interface starts and stops.

When `autoOutboundsInterface` is in use, the `localhost` DNS server of Xray skips these servers (unless another interface uses them too), as its queries to them would lead back into the TUN interface.

On Linux, the system DNS is not taken from this option; see `autoSystemDnsToGateway`. On macOS, the system DNS is not configured.

> `userLevel`: number

Expand All @@ -78,6 +86,31 @@ Equivalent to automatically setting [sockopt](../transports/sockopt.md).interfac

The default value is `null`, which means not configured. You can specify an interface name explicitly, or use `"auto"` to let Xray choose one automatically. If `autoSystemRoutingTable` is configured but this field is omitted, Xray treats it as `"auto"`.

> `autoSystemDnsToGateway`: true | false

This option only takes effect on Linux. The default is `false`.

When it is enabled, Xray points the system resolver, systemd-resolved (through `resolvectl`), at the TUN interface, so that the name lookups of the system go through Xray. The address handed over is the first IPv4 address in `gateway` plus one (e.g. `10.0.0.1/16` → `10.0.0.2`), or without an IPv4 one, the first IPv6 address plus one (e.g. `fc00::1/64` → `fc00::2`); without `gateway`, Xray reports an error and does not start. It is not taken from `dns`, as systemd-resolved would then query those servers directly, outside the TUN interface.

Queries to that address have to be answered by Xray, so a routing rule has to send port 53 of this inbound to a [DNS outbound](../outbounds/dns.md). Xray checks this before changing the system DNS, and does not start if such a query would not reach a DNS outbound, or if Xray's own [DNS](../dns.md) could resolve through the system resolver (no name servers, or a `localhost` one), which would loop.

It needs systemd-resolved 240 or later to be running. Whenever the system DNS cannot be changed, Xray does not start. The setting is reverted when Xray exits normally; if Xray is killed (e.g. with `SIGKILL`), run `resolvectl revert <interface>` to clean up.

> `autoSystemWfpBlockLeak`: [string]

This option only takes effect on Windows. The default is empty, i.e. no filters.

It needs `autoSystemRoutingTable`, otherwise Xray reports an error and does not start. Xray adds Windows Filtering Platform (WFP) filters that keep the traffic of other programs from leaking outside the TUN interface, each chosen by a value in the list:

- `"dns"` (needs `dns`, otherwise Xray reports an error and does not start): DNS (port 53) can only go through the TUN interface or come from Xray itself. Windows sends name queries to the DNS servers of all interfaces, each through its own interface whatever the routes say, and other programs reach a DNS server on the local network (e.g. `192.168.1.1` handed out by DHCP) through its more specific LAN route, so without this, such servers would still be queried outside the TUN. On Windows 11, Windows Server 2022 and later, where these queries can also use DNS over HTTPS or TLS, the Windows DNS Client service cannot connect outside the TUN interface at all, except for name resolution on the local network (LLMNR, mDNS). The servers in `dns` therefore have to be covered by `gateway` or `autoSystemRoutingTable`, and DNS servers that should be reached directly belong in Xray's own [DNS](../dns.md) settings.
- `"misconfigtun"`: an IP version without routes in `autoSystemRoutingTable` (IPv4 or IPv6) is blocked in both directions, except for Xray itself, loopback, and what Windows needs on the local link (DHCP, IPv6 neighbor discovery). An address of that version in `gateway` is not needed for the TUN interface to carry it: without one, Windows assigns it a link-local address itself (IPv6 at once, IPv4 from `169.254.0.0/16` after a few seconds).

While the filters are in place, Xray's own outgoing connections also get past the block rules of Windows Firewall.

The filters are removed when Xray exits, even if it crashes. If they cannot be added, Xray does not start.

It is empty by default, as the filters break some setups: with `"dns"`, a local DNS resolver used by other programs (e.g. on `127.0.0.1:53`), the DNS of another VPN, virtual machines whose NAT resolves names on the host, or signing in to a captive portal; with `"misconfigtun"`, IPv4 or IPv6 on the local network while no route of that version leads to the TUN interface. Without the filters, DNS may leak as described above. To keep an IP version out of the TUN interface on purpose while still blocking DNS leaks, use only `["dns"]`.

## Usage Tips

If `autoSystemRoutingTable` is not configured, you still need to add routes manually to direct traffic to the created TUN interface; otherwise, it remains just an interface.
Expand Down
Loading
Loading