如何在受感染的宿主上测试全量断网开关的覆盖范围

打开全量断网开关，把隧道服务器下线，然后观察这台机器还在做什么。这个测试值得做，因为它能区分防火墙实际强制执行的内容与你以为它会强制执行的内容，而且结论比多数产品页面暗示的更窄。全量断网开关管的是网络路径，管不了设备上已经在运行的软件。凡是客户端声称 fail-closed 的机器，我都会跑一遍这个流程，大约需要十分钟。

从客户端开始，而不是从服务器开始

执行点在你所坐的这台主机上：操作系统的防火墙、某个辅助服务，或者 VPN 客户端自带的驱动。这一点很重要，因为开关能做的一切都受限于该层能看到什么。如果客户端用路由规则加标记来实现拦截，那么任何权限足够的对象都能添加自己的规则；如果它用的是内核防火墙表，同样的权限就能改表。加密强度从来不进入这个问题。

所以首先要确定的是：这台设备上的策略归谁所有，它又被允许覆盖什么。在受管的工作机上，答案通常是组织的终端代理，而个人 VPN 无论隧道怎么配置，都去不掉这些能力。

第一步：在你认为它覆盖的路径上确认拦截

在远端而不是在客户端断开隧道，这样客户端仍以为自己应该处于连接状态。然后试试一个人真正会试的东西：

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

你要的是快速、干净地失败的客户端，而不是一直挂到浏览器超时的客户端。挂住通常意味着数据包被一条没有拒绝动作的规则静默丢弃，这可以接受，但也可能意味着客户端留下了一条指向已死接口的过期默认路由。隧道断开时读一下路由表：仍指向隧道设备的默认路由，与只拦截新建出站连接的防火墙规则，是两种不同的状态，而且只有一种是 fail-closed。

把客户端的允许局域网选项分别打开和关闭，重复同样的命令。这个开关正是大多数意外所在，因为它会重新打开一条策略其余部分本要关掉的路径。

第二步：把 DNS 和 IPv6 当作独立路径来检查

域名解析是多数实现都活下来的缺口，因为查询可以绕开系统解析器从别处出去。用一个忽略你解析器配置的工具来查询，同时检查 v6 那一侧：

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

隧道断开时，两个名字查询都返回空，就是你要的结果。如果第二个查询有应答，说明写死的解析器地址可达，隧道并非离开这台机器的唯一路径。如果只有 v6 请求成功，说明策略覆盖 IPv4 而忽略 IPv6，这是同一处泄漏换了个地址族。

浏览器让这件事更难从外部读取，因为配置了 DNS over HTTPS 的浏览器用 HTTPS 请求来完成解析：查询只在那条到该端点的 443 端口被拦住的范围内被拦住。在策略允许本地子网的主机上，该请求仍可能到达局域网里的解析器。

第三步：把网络暴露与端点暴露分开

现在是没有防火墙规则能触及的部分。全量断网开关拦的是离开机器的路径；它阻止不了机器上的软件在加密之前读取数据，也阻止不了这些软件合法地使用隧道。键盘记录器、恶意扩展、没锁屏的屏幕、权限过宽的同步客户端：它们全都通过开关乐于放行的连接搬运信息。

雇主特意安装的监控软件也一样。拦截路由去不掉它，买一台新的 VPN 服务器也不是修复，因为暴露点在隧道的上游。

一个会把内容上传到云账号的剪贴板管理器把这一点说得很尖锐。流量是加密的，目的地是允许的，而全量断网开关全程都报告健康状态。

第四步：写下你的测试能支持的结论

断网测试之后，你可以陈述具体事实：哪些应用失败、哪些路径中断、DNS 与 IPv6 表现如何，以及隧道掉线时拦截是否守住了。你不能说操作系统是干净的，也不能说远端的某个服务会保证你的登录私密。

把两个问题分开，并各自给出控制手段：

• 全量断网开关：已定义的失败要求，用每次客户端升级后都要重做的断网测试来验证。
• 设备信任：受支持的更新、来自可信来源的端点防护、对不明权限与认证请求的复核。
• 事件：怀疑被入侵时按平台或组织的流程处理；换一台新服务器不是清理步骤。
• 披露：求助时不要粘贴私钥或整份诊断归档，因为日志和截图与连接携带同样的秘密。

下一次更新之后再把流程跑一遍，因为全量断网开关是随版本变化的配置。只有这个测试能证明你依赖的行为仍然是你实际得到的行为。