TUN inbound: Add autoSystemWfpBlockLeak on Windows (blocks "dns" and "misconfigtun" IPv4/IPv6 traffic leaks outside the TUN); Rename autoSystemDNS to autoSystemDnsToGateway on Linux (and change some behaviors)

[patterniha]

Windows sends name queries to the DNS servers of all interfaces, each out through its own interface whatever the routes say, so DNS leaks past the TUN; on Windows 11 even as DNS over HTTPS or TLS, when that is set up for an interface. Other programs reach a resolver on the local network (e.g. 192.168.1.1 from DHCP) through its more specific LAN route. And an IP version that isn't routed to the TUN bypasses it entirely.

With autoSystemWfpBlockLeak, which needs autoSystemRoutingTable (the config is rejected otherwise), the Windows TUN now adds Windows Filtering Platform filters, all in one transaction and in a dynamic session, so that they are removed when Xray exits, even if it crashes or is killed. The option is a list, and each value blocks one kind of leak, e.g. "autoSystemWfpBlockLeak": ["dns", "misconfigtun"]:

• "dns" (needs dns, the config is rejected otherwise): DNS (port 53) only goes through the TUN, in both directions: its local address, and the interface it leaves or arrives by, must be the TUN's. The only exception is the DNS of the Xray process itself, which may leave through the other interfaces. On Windows 11 and Server 2022 and later, the DNS Client service may only connect through the TUN, so DoH or DoT set up for another interface cannot leave through it either; only its mDNS and LLMNR stay allowed. The filters match the service by its SID, as Windows Firewall's own rules for it do.
• "misconfigtun": IPv4 or IPv6 is blocked in both directions when autoSystemRoutingTable has no route of it, the leak of a config that routes only one of them, except for the Xray process, loopback, DHCP, and for IPv6 neighbor and multicast listener discovery. Addresses don't matter: without one of a version in gateway, Windows gives the TUN a link-local one (fe80:: at once, 169.254.x.x after a few seconds), and what is routed to the TUN goes through it.

Either value works alone, e.g. ["dns"] to block DNS leaks while an IP version stays out of the TUN on purpose; unknown values are rejected. Xray's own traffic is exempt: its connections out with a hard permit, which Windows Firewall rules do not override, connections to its inbounds with an ordinary one.

If the filters cannot be added, Xray does not start. autoSystemWfpBlockLeak is empty by default, so no filters are added unless it is set.

Also on Windows:

• With "dns", a warning for dns servers outside gateway and autoSystemRoutingTable, as queries to them cannot go through the TUN and are blocked.
• While DNS is restricted and autoOutboundsInterface is in use, Xray resolves the names it would ask Windows for itself (Go's resolver on its own sockets). Those lookups, and the localhost DNS server whenever autoOutboundsInterface is in use (even without autoSystemWfpBlockLeak), skip the TUN's DNS servers, unless another interface uses them too, instead of looping back into the TUN.
• The DNS cache is flushed when the TUN starts and stops, and DNS registration is turned off on the TUN (through netsh before Windows 10 1809).
• Close no longer panics when registering the route or interface change callbacks failed.

On Linux, autoSystemDNS (#6773, not released yet) is renamed to autoSystemDnsToGateway, to match, and without an IPv4 address in gateway it now falls back to the first IPv6 one plus one. It now needs gateway (the config is rejected otherwise), and when it cannot set the system DNS, Xray does not start instead of only logging it.

The README describes all of it, and XTLS/Xray-docs-next#903 documents the options, what each system does without gateway, and dns in more detail.

Tested on Windows 11, elevated: that Windows accepts all the filters (amd64 and 386), and on amd64, DNS arriving through a real Wintun adapter and blocked outside it, DoH set on an adapter (per adapter, per network profile, and by global auto-upgrade) blocked outside the TUN while names still resolve through it, IPv4 and IPv6 blocked or carried depending on the routes (with and without addresses in gateway), each value of autoSystemWfpBlockLeak on its own, Windows Firewall rules, and a real Xray run. Windows 7/8 and Windows 10 before 1809 are untested. The Linux changes are covered by unit tests only, not run on a real Linux system.

[PhoenixNil]

来个二进制让我测试下，真不想动所有网卡的dns
原来还是用了WFP啊

[patterniha]

来个二进制让我测试下，真不想动所有网卡的dns 原来还是用了WFP啊

https://github.com/XTLS/Xray-core/actions/runs/36379083407

[patterniha]

原来还是用了WFP啊

First, I just blocked requests to the DNS servers of other interfaces, but I found that this was not a good idea, so I (we) implemented an improved version of the sing-box method. Yes, we need WFP anyway.

[PhoenixNil]

我简单测试了下，配置了dns是不泄露的，但是没有配置还是泄漏（这个和之前的行为一样可以不管）

[patterniha]

我简单测试了下，配置了dns是不泄露的，但是没有配置还是泄漏（这个和之前的行为一样可以不管）

Yes, that's intended: without dns, the TUN has no DNS server of its own, so Windows can only use the other interfaces' DNS servers. Blocking them would break name resolution completely, so the DNS filter is only added when dns is set.

[LjhAUMEM]

我写的 wfp 不要让我来审别人的 wfp 是什么玩意，wintun 我只动过路由，其他的你们想怎么来怎么来

[RPRX]

所以这个是 WFP 吗？为啥不给 Windows 也实现一个 autoSystemDNS 改所有网卡的 DNS？虽然感觉会影响虚拟机

[patterniha]

Yes, it's WFP, like sing-box's strict_route. On Linux, autoSystemDNS changes systemd-resolved at runtime, but Windows has nothing like it: we would have to change the DNS of every adapter, which Windows saves in the registry, so if Xray crashes or is killed (for example, when the user shuts down the PC without turning off the TUN, which is very common), the DNS stays broken even after a reboot. Windows removes the WFP filters by itself when Xray exits, even if it crashes or is killed. They can affect VMs too, which is why strictRoute is off by default.

[patterniha]

Also, it is better to resolve domestic domains with the default DNS that the ISP sets in the modem. Most modems act as a DNS proxy, so DHCP hands out modem address (e.g. 192.168.1.1) as the DNS server; if we change it, we lose the ISP's default DNS for domestic websites.

[RPRX]

但还是那个问题：网卡配置个 DoH 就拦不住了 #6478 (comment) ，要不就两个方案都弄 #6478 (comment)

[RPRX]

话说这个 PR 是完全借助 WFP 吗？这选项是不是以后在其它平台上没用？如果是的话改名 autoSystemWFP 吧，又对齐了

[patterniha]

You're right, I tested it: Windows' DNS client sends DoH (and plain DNS) for an adapter's DNS server out through that adapter, even when the TUN has a more specific route. Apps that do their own DoH (e.g. Chrome) follow the routes into the TUN; it's the Windows DNS Client service (Dnscache) itself that ignores them.

So the new rule is: the DNS Client service may connect only through the TUN.

I'll add a WFP filter that blocks the DNS Client service outside the TUN. WFP can match it by its service SID, the same way Windows Firewall's own rules for this service do. This covers DoH/DoT set on any adapter, with no need to change the adapters' DNS, and like the other filters, it's removed when Xray exits or is killed.

Please wait ...

[patterniha]

但还是那个问题：网卡配置个 DoH 就拦不住了

Fixed: edd916b
Now the DNS Client service may connect only through the TUN, so DoH/DoT set on an adapter can't leave outside the TUN either (Windows 11 / Server 2022 and later; older versions have no DoH in the DNS client).

如果是的话改名 autoSystemWFP 吧

Yes, it only uses WFP, Done.

[RPRX]

回顾了下 #6478 (comment) #6454 (comment) ，Windows 上若要改所有网卡的 DNS 的话也是改到 TUN gateway

既然如此就继续更名对齐字符吧，这个 PR 的改成 autoSystemWfpBlockLeak，顺便把另一个改成 autoSystemDnsToGateway

这样可以体现出 WFP block 了更多 leak，且以后在 Windows 实现另一个方案的话也准确，不过另一个方案没管 IPv6 相关 leak

[RPRX]

#6862 (comment)

[patterniha]

yes i tested and it works.

no, only error is shown for both linux and windows, wait for fix ...

[patterniha]

Done: on Windows, autoSystemWfpBlockLeak without autoSystemRoutingTable, or "dns" in it without dns, and on Linux, autoSystemDnsToGateway without gateway, are now config errors. and if the filters can't be added (now on every Windows version) or the system DNS can't be set on Linux, Xray fails to start instead of logging and running.

also #6246

[PhoenixNil]

if the filters can't be added (now on every Windows version) or the system DNS can't be set on Linux, Xray fails to start instead of logging and running.

你的意思是说现在tun模式必须配置你说的这个filter 不然无法启动了嘛？

[patterniha]

@RPRX

i tested windows and it works correctly.
and also ask Opus to review the Linux code, it seems it has serious problems...

[patterniha]

Opus 5.5 (max) review on #6773:

I also reviewed the Linux side (autoSystemDnsToGateway, from #6773). The changes in this PR are fine, but the takeover itself has some issues:

1. Xray's own lookups can loop. After the takeover, resolved sends every query into the TUN, including Xray's own. For example, an outbound's server address given as a domain, with the default AsIs strategy, goes Go resolver → 127.0.0.53 → resolved → TUN → DNS outbound → Xray's DNS. If Xray's DNS queries go through that same outbound (the default when no rule routes them elsewhere), the lookup waits on itself and nothing works; with fakedns it gets a fake IP. A common setup hits this: server given as a domain, DNS through the proxy. Windows avoids it by resolving Xray's own lookups directly on the physical interface; Linux has no equivalent, and the preflight can't see it.
2. The takeover can succeed without effect. If /etc/resolv.conf doesn't point at resolved's stub (127.0.0.53), e.g. a static file with the router's address or dnsmasq on 127.0.0.1, resolvectl still succeeds and Xray starts, but programs keep querying the LAN resolver directly. We could check /etc/resolv.conf first and fail otherwise.
3. Global DNS-over-TLS or DNSSEC breaks it at runtime. With DNSOverTLS=yes, resolved queries the TUN address on port 853, which the port 53 rule doesn't catch; with DNSSEC=yes, it rejects Xray's unsigned answers. Turning both off for the TUN link (resolvectl dnsovertls / dnssec) would fix it.
4. Names under another link's search domain (e.g. printer.lan from DHCP's lan) still go to that link's DNS, by resolved's design, and single-label names go out via LLMNR.
5. Queries other than A/AAAA (MX, TXT, SRV, PTR…) get empty answers from the DNS outbound by default.
6. The README's SIGKILL note isn't needed: the TUN that Xray creates isn't persistent, so when Xray dies, the interface and its DNS settings go away with it.

I can fix 2 and 3 in this PR (small changes) and document 1, 4 and 5; a real fix for 1 needs testing on a real Linux system. What do you think?

[RPRX]

你的意思是说现在tun模式必须配置你说的这个filter 不然无法启动了嘛？

并非，仔细看讨论，正确配置了 autoSystemWfpBlockLeak 但它操作 WFP 失败时才会报错退出（不合理配置也会报错退出）

and also ask Opus to review the Linux code, it seems it has serious problems...

Linux 上的 autoSystemDnsToGateway 是 @yiguodev 说可以合并的 #6773 (comment)

Opus 列出的那些问题可能存在，但我倾向于先不大改，先发版测测，毕竟 Linux 桌面用户比 Windows 少得多所以还好

你也先实测下，毕竟 AI 有时候会胡言乱语

[RPRX]

@patterniha 你有空的话先试试实现 #6853 (comment) 吧，我觉得至少把流量 redirect 到 Xray Tunnel inbound 是可行的

但是让它们带上原始目标二元组，以及伪造 UDP 回包来源二元组，这两点不一定能轻易做到

[yiguodev]

dns 回环问题是一直存在的，不是 linux tun 的修改才引入的。在所有流量均通过代理且使用 local dns 的场景，除 Apple 平台外，都会出现 dns 回环。而大部分 GUI 客户端都会配置一个 direct 的 dns server，从而解决了回环后的 dns query 。彻底的解决方案应该是给默认的 Go DnsResolver 增加 protect 和 bindInterface，不过这就是另外一个改动了。还有，Windows Tun 完全没问题，恰恰是解决了这个问题。

[patterniha]

@patternihaIf you have time, try implementing #6853 (comment) . I think at least redirecting traffic to Xray Tunnel inbound is feasible.

However, getting them to include the original target tuple and the forged UDP return source tuple is not necessarily easy.

WinDivert is a better tool for this (I wrote SNI-Spoofing with WinDivert by hand, before AI, so I know it well), WFP alone can't redirect traffic, but WinDivert has a signed driver and works on packets, so both points are easy. Xray keeps the original destination in its own NAT table for the Tunnel inbound, and we can change the src IP/port of UDP replies easily.

Anyway, with two years of Claude Max and a steady salary, I could build all of this and more :)

[55575455]

测试了最新版本，在 Windows 11 的 Hyper-V 虚拟机环境（Default Switch 默认交换机）下，仍然存在较严重的 DNS 泄漏问题：

1. 现象：虽然公网出口 IP 显示为代理节点，但 DNS 泄漏测试仍然返回了大量宿主机本地运营商（中国移动）的 IPv4 与 IPv6 解析服务器。
2. 环境：
   • 宿主机：Windows 11
   • 虚拟机：Hyper-V（默认 NAT 网络）
   • Xray 版本：v26.9.30

[patterniha]

The latest version was tested, and a significant DNS leak issue still exists in a Windows 11 Hyper-V virtual machine environment (Default Switch).

1. Phenomenon : Although the public network exit IP shows as a proxy node, the DNS leak test still returned a large number of IPv4 and IPv6 resolution servers of the host's local operator (China Mobile).

2. environment :

   • Host machine: Windows 11
   • Virtual machine: Hyper-V (default NAT network)
   • Xray version: v26.9.30

config?

[55575455]

[55575455]

双栈直通穿透：Default Switch 会直接打通宿主机的 IPv6 路由。即使虚拟机内启动了代理客户端，Windows 的多网卡并发解析机制也会把 IPv6 查询沿此虚拟交换机透传至宿主机的物理运营商

[55575455]

测试了最新版本，在 Windows 11 的 Hyper-V 虚拟机环境（Default Switch 默认交换机）下，仍然存在较严重的 DNS 泄漏问题：

1. 现象：虽然公网出口 IP 显示为代理节点，但 DNS 泄漏测试仍然返回了大量宿主机本地运营商（中国移动）的 IPv4 与 IPv6 解析服务器。
2. 环境：
   • 宿主机：Windows 11
   • 虚拟机：Hyper-V（默认 NAT 网络）
   • Xray 版本：v26.9.30

[55575455]

vless+enc+xhttp+really

[55575455]

[55575455]

[55575455]

[55575455]

终于发送成功了

[patterniha]

v2rayN has added these changes: 2dust/v2rayN@50023a5, but they haven’t released a new version yet.

[55575455]

无论是自动配置系统代理，还是 不改变系统代理，清除系统代理三种模式 都会造成泄漏

[55575455]

Hyper-V 作为裸金属虚拟机 根本不会 遵从系统代理

[55575455]

Sandboxie-Plus 在沙箱中的浏览器也会存在泄露 但不确定的是删除沙箱之后 新建个沙箱就不泄露了 没有进行过任何其他操作

[55575455]

Sandboxie-Plus 默认也是不遵从本地代理的如果非付费赞助用户