iPhone 的 VPN 锁定是策略，不是协议

VPN 图标显示已连接，网络切换时隧道会短暂断开，本应被拦截的流量经由蜂窝网络发了出去。界面没有任何地方提示这段空档。你所依赖的功能是客户端与平台的策略，设置里的协议名称并不能说明那一秒里发生了什么。

要把锁定描述成一份关于状态的契约，而不是 IKEv2 或 On Demand 的属性。

症状：图标说已连接

图标反映的是客户端对自身状态的看法，而这个看法可能比现实滞后一次重连的时长。缓存页面、快速重连或状态刷新都会掩盖这段间隔。值得追问的不是图标是不是绿的，而是隧道缺席时设备允许了什么。同样的滞后也解释了为什么应用截图是如此薄弱的证据：它记录的是一个状态，而不是一次转换。

只有策略作出定义，这个问题才有答案。

协议实际维持的是什么

IKEv2 维护并续订一条经过认证的 IPsec 关系，移动性特性帮助它在地址变化后恢复。这是关于隧道生命周期的陈述。它对空档期间 iPhone 是否有权发送其他流量只字未提，因为那项许可属于平台与客户端，而不属于密钥交换。一秒钟内重连的设备依然有一段窗口，有意思的行为正发生在这段窗口里。

On Demand 同样只是对激活行为的描述，而不是普遍的拦截保证。

平台给开发者提供了什么

Apple 的 Network Extension 提供了流量范围控制，其路由指南区分了包含全部网络的行为与普通的包含路由，并列出了系统例外。此外还有受监管的 Always On 部署模式，与个人应用的自动连接设置相互独立。某个应用是否用到了其中任何一项，是应用自身的属性，而不是它所使用协议的属性。

开关的名字不能证明应用调用了哪个 API。

把这项功能当成契约来读

请服务商明确五种状态：首次激活、意外丢失隧道、主动断开、退出应用以及设备重启。把这些系统例外和任何有意的 LAN 访问并列在其旁边。然后询问该功能是可选的、由管理强制执行的，还是以某种客户端模式为条件，因为用户主动暂停与组织强制锁定是两种不同的产品。把这五个答案写进部署记录，因为下一位评审者问的正是这些问题。

在意外丢失时拦截、但在主动断开时不拦截的功能，是一个自洽的设计。只是它不是营销页面所描述的那一个。

如何测试这些空档

一次只测一次转换，用无害的流量，在你关心的应用和地址族里进行。确认空档期间允许了什么，而不是之后图标显示了什么。把客户端版本和策略与结果一并记下，因为两者都会变化，而它们都无法从手机的设置界面看到。这是把真正的空档与迟钝的图标区分开的唯一办法。

如果答案对合规有影响，就书面索取，而不是从产品名称去推断。