fix: never bind TUN direct dialer to the easyss TUN device - #119
Merged
Conversation
Since ebbc18b the direct dialer re-detects the default interface by probing 0.0.0.1. On Windows that lookup rejects 0.0.0.0/8 destinations outright, so detection failed and the dialer stayed unbound: with TUN active every direct dial (server connection, direct targets, DNS) fell into the TUN device and looped through tun2socks forever. The fallback interface enumeration could also pick a virtual adapter, breaking all connections with WSAENETUNREACH. - route Windows/Linux TUN traffic from 1.0.0.0/7, mirroring darwin, so 0.0.0.0/8 stays outside the TUN routes for the 0.0.0.1 probe - on Windows read the 0.0.0.0/0 default route from the routing table (GetIpForwardTable), skipping the TUN device's own default route that netsh adds while TUN is active - keep darwin/linux on the 0.0.0.1 probe, which now resolves to the physical interface on every platform - never bind the direct dialer to the easyss TUN device: reject it in the refresh path and fall back to physical interface enumeration at startup
errNoDefaultRoute is only referenced by sys_windows.go, so on darwin/linux builds it was an unused package var and failed the lint CI.
tun-easyss/utun9 were hardcoded in both client/tun.New (device creation) and util.IsTunIface (TUN device recognition); the two could drift apart. Reference sharedconfig.DefaultTunDeviceName(Darwin) in both places.
Keep the GetIpForwardTable approach (the only viable way to find the physical default interface on Windows), but improve readability: name only the used MIB_IPFORWARDROW fields and keep the layout with anonymous placeholders, move the two-call buffer dance into getIpForwardTable, and sort candidates with slices.SortFunc.
IsTunIface matched only the current platform's default device name (tun-easyss on windows/linux, utun9 on darwin), so tests constructing a tun-easyss interface failed on macOS CI: the refresh path treated the TUN device as a plain interface and rebound the direct dialer to it. Match both default names regardless of the platform.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
问题
开启 tun2socks 后出现两类故障：
均源于今日提交
ebbc18b（macOS sleep/wake TUN 恢复）引入的直连 dialer 接口探测逻辑。根因
ebbc18b通过探测0.0.0.1来重新发现默认网卡，但实测发现：0.0.0.0/8选路（GetBestRoute2无条件返回"网络位置不可达"，与路由表内容无关——即使临时加入0.0.0.0/1、0.0.0.1/32精确路由依然失败）→ 探测必然失败 → dialer 无绑定 → TUN 激活后所有直连流量落入 TUN 设备，经 tun2socks 转发回本地代理，代理再拨号又落入 TUN……无限循环修复
0.0.0.0/1改为1.0.0.0/7起（与 darwin 对齐），0.0.0.0/8漏出 TUN 路由，保证0.0.0.1探测在 macOS/Linux 上始终解析到物理网卡GetIpForwardTable读取0.0.0.0/0默认路由（按 metric 排序并跳过 TUN 设备自己的默认路由——netsh配置静态网关时自动添加），TUN 激活时也能拿到物理网卡验证
SysDefaultRoute均返回物理网卡（WLAN），并断言排除 TUN 设备0.0.0.1无条件拒绝选路（Find-NetRoute与 go-netroute 双路验证，含0.0.0.0/1、0.0.0.1/32精确路由实验）go test ./...全绿；win/linux/darwin 三平台交叉编译通过；lint 0 issues