Windows sends name queries to the DNS servers of all interfaces, and a
resolver on the local network (e.g. 192.168.1.1 from DHCP) is reached
through its more specific LAN route instead of the TUN, so DNS leaks
past it. IPv6 bypasses a TUN that cannot carry it.
With autoSystemRoutingTable set, 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:
- 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.
- IPv6 is blocked in both directions when the TUN has no IPv6 address or
no IPv6 route, except loopback, neighbor and multicast listener
discovery, and DHCPv6.
- Xray's own traffic is exempt: its connections out with a hard permit,
which Windows Firewall rules do not override (like sing-box's
strict_route), connections to its inbounds with an ordinary one.
If the filters cannot be added, the TUN does not start on Windows 10 and
later (only a warning on 7/8). The new `strictRoute` option (true by
default) turns them off.
Also on Windows:
- 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 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.
The README's Windows section describes all of it.
Tested on Windows 11, elevated, amd64 and 386: the filters, DNS arriving
through a real Wintun adapter and blocked outside it, the IPv6 block,
Windows Firewall rules, and a real Xray run. Windows 7/8 and Windows 10
before 1809 are untested.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Proxy: TUN: Enhance Darwin interface support.
- reduce number of actions done to create/configure the interface in the system
- assign synthetic static link-local ipv4/ipv6 addresses to the interface, that are required by the OS for the routing to work
- make tun_darwin_endpoint be implemented significantly more similar to tun_windows_enpoint, preparing them for potential unification
* Proxy: TUN: Unify Darwin/Windows endpoint, which are now extremely similar, into one GVisorEndpoint.
Making darwin/windows tun implement GVisorDevice with simple readpacket/writepacket methods that GVisorEndpoint untilise
* Proxy: Implement tun raw network interface inbound support for Linux
* Proxy: Tun. Include "android" as build condition for build of tun_default implementation
* Proxy: Tun. Add .Close() cleanup calls to Handler.Init() where needed
* Proxy: Add Tun for Android
* Proxy: Tun. Implement Windows support
---------
Co-authored-by: yuhan6665 <1588741+yuhan6665@users.noreply.github.com>
