Fail-open 与 fail-closed：VPN 终止开关决定什么
两个术语描述的都是隧道消失后会发生什么，而不是加密有多强。你选择的范围决定了流量是否真的泄漏。
有种误解认为 fail-closed 是安全设置，fail-open 是疏忽大意。两者描述的都是隧道消失后流量会怎样，都不改变该隧道的加密强度。一份例外清单很长的 fail-closed 策略，在从不离开办公网络的设备上，可能比 fail-open 策略泄漏更多。选择你能向流量所有者解释清楚的结果。
标签描述的是结果，不是强度
这些词来自控制系统：fail-open 在组件故障时允许运行，fail-closed 则拒绝。用在 VPN 上，发生故障的组件是隧道，问题是流量能否改走别的路径继续。加密算法、密钥长度和协议是另外的决定。
这种混淆之所以持续，是因为终止开关听起来像安全功能，厂商也这样宣传。从机制上说，它是一条路由与防火墙规则，用来阻断本该由隧道承载的流量，实现在客户端、操作系统或网关上。由哪一层执行，就决定了它的覆盖范围，而一层的规则覆盖不了另一层。网关上的规则无法保护已经切换到其他网络的笔记本电脑。
每种结果是什么样
同一条策略会因遇到的故障不同而表现迥异，所以要比较事件，而不是比较标签。
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
最后一行提醒那些以为终止开关就是一个开关的人。为 IPv4 路由表写的规则会放过 IPv6 默认路由，应用程序可能正好照用不误。
范围决定是否泄漏
先问策略覆盖了什么，再问它是哪种模式。按应用划分的规则只保护一个应用，设备级规则保护除例外之外的一切，网关规则只保护到达该网关的流量。DNS 需要单独决定，因为发给本地解析器的查询即使载荷被阻断，也可能暴露域名。
本地网络例外是为打印机、投屏和强制门户存在的，每一条都是阻断上的一个洞。把它们写在策略旁边，否则接手配置的人会把 fail-closed 当成绝对。
重连与阻断也是彼此独立的控制。客户端可以自动重连却从不阻断，也可以阻断而不重连，二者组合决定了用户在中断期间的体验。
在切换过程中验证
测试稳定状态什么也证明不了。故意断掉隧道，再试那个本应受保护的应用，然后检查它是否连上了网络。把客户端的指示与实际结果对照，因为仍然显示已连接的指示，恰恰就是这条策略存在的理由。如果受保护的应用成功联网，模式叫什么就不重要了；你确实存在泄漏。
在登录前从冷启动重做一遍，在 Wi-Fi 切换到蜂窝网络时，以及受保护应用处于后台时。如果阻断由客户端进程执行，还要测试该进程被强杀而不是正常关闭时会发生什么。
最后检查清理路径。如果在规则仍然生效时卸载客户端，请使用厂商文档给出的卸载流程，而不要关闭操作系统防火墙——那样会移除无关的保护，却没有回答残留规则归谁管。