Windows 全局模式路由修复

Issue #85 — 让所有软件都走同一条 VPN 路

Windows 11 v1.4.13 代码已修复待实机验证

🚦 问题是什么？

在 Windows 上开启全局 VPN 模式（TUN 模式）时，大多数浏览器等软件都正常走了 VPN。但有用户发现：

🖥️ OpenSSH

Windows 自带的命令行远程连接工具，看起来没有走 VPN 通道。

📡 Termius

一款图形化的远程连接软件，同样可能绕过了 VPN。

这引出了一个更大的疑问：还有多少其他软件也没走 VPN？

💡 全局模式不仅要打开 VPN，还要让 Windows 给所有软件同一条去 VPN 的路；这次修复就是把这条路标清楚。

🏙️ 用城市道路来理解

想象 Windows 是一座城市：

🔵 蓝色隧道 = VPN

加密、安全的路。走这条路的流量受 VPN 保护。

⚫ 灰色公路 = 普通网络

没有加密保护。直接暴露在互联网上。

🚗 小汽车 = 各种软件

浏览器、OpenSSH、Termius……都是在这座城市开车的"司机"。

问题在于：虽然蓝色隧道打开了，但 Windows 的"路标"不够清楚。有些聪明的司机（OpenSSH）找到了一条直接上灰色公路的岔路，绕过了隧道。

🔀 修复前 vs 修复后

点击切换，看看路线有什么不同：

当前显示：修复前 — 部分软件可能绕过 VPN

🔧 修复做了什么？

用非技术的话说：在 VPN 配置里加了更清晰的路标。

📍 什么是 TUN？

TUN 是一种 "虚拟网络隧道"。它在你的电脑里虚拟出一张网卡，然后让所有上网流量都经过这张虚拟网卡 → 进入 VPN 隧道。

🛣️ 什么是路由（Routing）？

路由就是 Windows 决定网络流量走哪条路 的规则。就像城市里的路标，告诉车子该走哪条路。

📝 这次加了什么路标？

我们在配置里明确写了四条路标，覆盖了全部地址空间：

// IPv4 全覆盖（分成两半）
"0.0.0.0/1"      ← 地址 0~127 开头
"128.0.0.0/1"    ← 地址 128~255 开头

// IPv6 全覆盖（分成两半）
"::/1"            ← IPv6 前半
"8000::/1"       ← IPv6 后半

💡 为什么分成两半而不用 0.0.0.0/0？因为用 /1 拆分后，这些路标会比 Windows 自己的默认路由"更具体"，Windows 就会优先选择走 VPN。这是 VPN 行业的标准做法。

📋 给老板看的结论

✅ 要点总结

问题已定位：Windows 全局 VPN 模式下，路由规则不够明确，部分软件（如 OpenSSH、Termius）可能走了普通网络
代码已修复：添加了明确的路由条目（0.0.0.0/1 等四条），让所有正常网络流量都指向 VPN 隧道
代码检查已通过：修复在代码层面经过了验证
影响范围：此修复适用于 Windows 11 + TUN 全局模式，应能解决所有类似"软件没走 VPN"的问题

⚠️ 需要注意

代码层面的修复已完成，但 尚未在真实的 Windows 环境上做最终测试。需要在 Windows 11 上安装新版本，再用 OpenSSH 和 Termius 实际验证。

📝 下一步验证清单

在 Windows 11 上安装包含此修复的新版本
开启全局 VPN 模式（TUN 模式）
打开 OpenSSH，连接一个远程服务器，确认流量走了 VPN
打开 Termius，连接同一服务器，确认流量走了 VPN
可选：用 tracert 命令检查路径是否经过 VPN 网关
可选：检查其他命令行工具（如 curl、ping）的路由情况
确认浏览器等常规软件仍然正常工作
验证通过后，可考虑发布正式版本

🔍 技术附注

配置变更摘要

// TUN 模式配置（修复后）
{
  "auto_route": true,
  "strict_route": true,
  "route_address": [
    "0.0.0.0/1",
    "128.0.0.0/1",
    "::/1",
    "8000::/1"
  ]
}

auto_route + strict_route 保持开启，route_address 中显式声明的 split-default 路由确保覆盖所有流量。

平台：Windows 11 | 应用版本：v1.4.13 | Issue：#85 | 状态：代码已修复，待实机验证