免责声明：本文仅供网络技术交流与学术探讨。在实际工作中，请务必遵守所在企业的 IT 合规政策与信息安全红线，切勿将相关技术用于违法违规用途。
0. 前言 / 问题背景
近期公司对办公网络进行了安全加固，实施了严格的内外网隔离策略。具体的认证与网络流程如下：
- 电脑连接公司 WiFi、家庭 WiFi 或手机热点；
- 启动公司指定的“专用浏览器/安全客户端”进行账号密码认证；
- 认证成功后，即可访问公司内网系统（如 OA、财务、HR 等）。
然而，加固后的策略带来了一个巨大的痛点：无论连接什么 WiFi（包括自己的手机热点），只要登录认证成功，外网（互联网）就会立刻断开！
这意味着我无法一边查阅百度/StackOverflow 资料，一边在内网敲代码；也无法在电脑上通过企业微信或个人微信收发消息，严重影响了工作效率。
为了兼顾内网办公与外网查资料的需求，我展开了一场针对该管控机制的探索与破解。
1. 技术原理探秘：终端是如何被“切断”外网的？
一开始我好奇：为什么连自己的手机热点，认证后也会断网？
这说明管控并不是在公司路由器/防火墙层施加的，而是在本机客户端（Host-based）上实施的。所谓的“专用浏览器”，实质上是一个集成了 ZTNA（零信任）/ SSL-VPN 技术的安全客户端。
为了搞清楚它在后台做了什么，我在登录前和登录后分别在 Windows CMD 中运行了 route print 查看系统路由表，发现了关键线索：
登录前 vs 登录后路由表对比
登录前（网络正常）：
活动路由:
网络目标 网络掩码 网关 接口 跃点数
0.0.0.0 0.0.0.0 192.168.5.1 192.168.5.180 281此时只有一条默认路由 0.0.0.0/0 指向本地路由器 192.168.5.1，外网畅通。
登录后（外网切断）：
活动路由:
网络目标 网络掩码 网关 接口 跃点数
0.0.0.0 0.0.0.0 192.168.5.1 192.168.5.180 281
0.0.0.0 128.0.0.0 2.1.0.1 2.1.2.194 3
128.0.0.0 128.0.0.0 2.1.0.1 2.1.2.194 3
10.0.0.0 255.0.0.0 2.1.0.1 2.1.2.194 3
172.16.0.0 255.255.0.0 2.1.0.1 2.1.2.194 3劫持原理解析：最长前缀匹配（Longest Prefix Match）
通过对比发现，客户端激活了一个名为 TAP-Windows Adapter V9 的虚拟网卡（分配 IP 2.1.2.194），并使用了教科书般的 VPN 路由劫持技巧（redirect-gateway def1）：
- 它并没有直接删除我原本的默认路由（
0.0.0.0/0->192.168.5.1）。 它把整个 IPv4 地址空间一分为二，注入了两条伪“默认路由”：
0.0.0.0掩码128.0.0.0（即0.0.0.0/1，覆盖0.0.0.0 - 127.255.255.255）128.0.0.0掩码128.0.0.0（即128.0.0.0/1，覆盖128.0.0.0 - 255.255.255.255）
根据 Windows 路由表的匹配规则：子网掩码越长（匹配越精准），优先级越高。
- 普通默认路由的掩码是
/0。 - 客户端注入的掩码是
/1。
- 普通默认路由的掩码是
- 结果：本机所有的互联网流量都被强制塞进了 VPN 虚拟网卡（
2.1.0.1）。而公司网关端拦截了去往外网的流量，最终导致外网断开。
2. 突破方案探索
针对这种控制方式，主要有两种解决思路：
方案 A：虚拟机隔离法（最稳妥）
- 原理：把公司专用浏览器安装在虚拟机（VMware / VirtualBox）中，虚拟机连接内网，宿主机连接外网。
- 文件传输：由于 VM 内部与宿主机相互隔离，可通过开通双虚拟网卡（Host-Only 局域网共享）、VMware Tools 拖拽或本地 HTTP 服务（如
python -m http.server）实现内外网文件互传。
方案 B：手动/脚本恢复路由（最轻量、零成本）
分析路由表后发现，客户端并没有防篡改守卫，也没有删掉本地真实网关。这意味着：只要手动删掉那两条抢占优先级的伪路由，流量就会自动重定向回本地路由器！
尝试在管理员 CMD 中手动运行：
route delete 0.0.0.0 mask 128.0.0.0
route delete 128.0.0.0 mask 128.0.0.0测试成功！ 运行后，百度/微信恢复正常，同时内网系统（10.x.x.x / 172.16.x.x）依然可以通过 VPN 隧道顺畅访问，完美实现了内外网双通！
3. 实战踩坑：批处理脚本自动化与排错
手动敲命令较繁琐，我打算写一个 .bat 批处理脚本，双击自动执行。但在测试脚本时遭遇了两个报错：
坑点 1：中文乱码与字符集（Code Page）问题
执行脚本时终端出现各种乱码字符。
- 原因：Windows CMD 默认采用 ANSI/GBK (Code Page 936) 编码，而现代编辑器（如 VS Code/记事本）默认保存为 UTF-8。当 CMD 解析 UTF-8 编码的脚本时，中文注释会变成乱码。
坑点 2：报错 The route deletion failed: Element not found. (找不到元素)
原因：
- 如果刚才手动执行过了
route delete，路由表中已经不存在这两条路由，再次运行脚本自然会报“找不到元素”。 - 从网页复制脚本代码时，可能带入了网页排版的“不可见特殊字符（如 NBSP 或 UTF-8 BOM 头）”，导致
route.exe无法正确解析参数。
- 如果刚才手动执行过了
终极一键修复脚本（纯 ASCII 防乱码版）
为了彻底避免编码与隐藏字符问题，最终编写了 100% 纯 ASCII 字符 的自动化脚本。
创建文件 FixNetwork.bat：
@echo off
echo ====================================
echo Removing Company Gateway Hijack Routes...
echo ====================================
echo.
:: 删除伪造的 /1 劫持路由
route delete 0.0.0.0 mask 128.0.0.0
route delete 128.0.0.0 mask 128.0.0.0
echo.
echo ====================================
echo Executed!
echo If it says "Element not found", either:
echo 1. The routes are already deleted.
echo 2. VPN is not connected yet.
echo ====================================
pause正确使用工作流：
- 启动专用浏览器认证登录办公网（此时外网被切断）；
- 右键
FixNetwork.bat➔ 选择 “以管理员身份运行”； - 外网瞬间恢复，内外网双通达成！
4. 知识拓展：彻底搞懂 Windows 路由表与 route print
在探索过程中，我也顺便梳理了 Windows 网络路由的底层知识：
Q：图形界面（控制面板\网络连接）能看到路由表吗？
不能。 控制面板中的“网络连接”（ncpa.cpl）只是网卡驱动配置面板。系统的路由表是 TCP/IP 协议栈在内存中实时维护的动态决策表，Windows 没有提供原生 GUI 界面展示（如需图形化查看可使用第三方工具 NetRouteView）。
route print 输出详解
路由表包含 5 个关键字段：
| 列名 | 含义 | 作用 |
|---|---|---|
| 网络目标 (Network Destination) | 目标 IP 或网段 | 数据包要去的目的地址 |
| 网络掩码 (Netmask) | 子网掩码 | 决定匹配的网段范围大小 |
| 网关 (Gateway) | 下一跳（Next Hop）IP | 数据包发往的下一个路由器 IP（若为“在链路上”则代表直接 L2 广播） |
| 接口 (Interface) | 本机网卡 IP | 发送该数据包的本地物理/虚拟网卡 |
| 跃点数 (Metric) | 路径开销/优先级 | 同样匹配度下，Metric 越小优先级越高 |
Windows 路由判定的两大黄金法则
- 法则一：最长前缀匹配（Longest Prefix Match） —— 掩码位数越长（如
/32>/24>/1>/0），优先匹配。 - 法则二：跃点数优先（Metric） —— 掩码长度相同时，Metric 值越小，优先走该接口。
5. 总结
通过对 route print 路由表的抓取与对比，我们精准破译了企业客户端“切断外网”的技术真相。
- 核心原理：客户端利用
/1掩码的最长前缀匹配，接管了本机的默认路由。 - 解决核心：在不破坏内网特定网段路由的前提下，删去伪造的全局
/1路由，将互联网流量交还给本地物理网卡。
希望本文的排查思路与脚本能够帮助到有类似困扰的技术同行！