iPhone 上的 Always On VPN 与 VPN On Demand：该部署哪一种

两部 iPhone 都可以自称 VPN，行为却可能完全不同。On Demand 在规则匹配时建立隧道，用户仍可在“设置”中关闭它。受管 Always On 在受监督设备上强制保持覆盖，包括隧道无法建立的时刻。选型时要问：当用户什么都不做时，什么必须成立；然后测试各种切换，而不是只测稳态。下面的步骤按部署实际失败的顺序展开。

第 1 步：确认设备能强制什么

Always On 是受监督设备才有的功能。如果设备群不受监督，讨论还没开始就结束了，任何 payload 键都无法把非监督手机变成受强制设备。从管理端和设备端确认监督状态，然后确认配置文件由谁签名。

在手机上打开“设置”，再打开“通用”，再打开“VPN 与设备管理”。配置文件条目会写明其所有者，手动安装的个人配置文件与管理服务下发的配置文件看起来不同。不要根据配置文件名称或供应商的营销标签推断是否强制；标签不是平台策略。

动配置之前先写下三件事：是否受监督、是受管配置文件还是个人配置文件、以及由哪个客户端实现承载隧道。后面每一步都取决于这三点，而把个人手机上的行为套到受管配置文件上，正是让部署按错误基线签收的方式。

第 2 步：读 on-demand 规则，而不是读功能名

On Demand 是一组按顺序求值的规则。每条规则指定一个动作和选中它的条件，条件才是关键：接口类型、Wi-Fi SSID、DNS 域名后缀或探测 URL。永远不会匹配的规则集，就是一个永远不会连接的“功能”。

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

读完整条数组，并对每条规则问两个问题：这个条件在这批设备上可能成立吗？当没有任何规则匹配时会发生什么？企业网络会重命名接入点、合并 SSID、更改 DNS 后缀，每一次改动都会悄悄让规则脱离现实。

DNS 后缀条件在现场最容易出错，因为手机在访客网络上报告的后缀并不是企业解析器所服务的后缀。在信任规则之前，先核实设备实际解析到的名称。

第 3 步：测试切换，而不是静态连接

你看着它时处于连接状态的隧道说明不了什么。逐项刻意执行每种切换并记录设备行为，每次都使用同一个私有资源，以便结果可比：

• 接入规则应当匹配的网络，然后请求私有资源并确认能加载。
• 在应用处于后台时切换到蜂窝网络，再切回前台并重复请求。
• 连接带 captive portal 的 Wi-Fi，观察门户是否可达，或者强制策略是否在你完成认证之前就阻断一切。
• 在受监督设备上手动关闭隧道，观察它是否自行恢复、恢复多快。

如果有非监督设备，在同一台设备上跑同样的清单。两组结果之间的差异才是部署的真实行为，而这正是“已连接”截图永远看不到的部分。

第 4 步：认识两种失败形态

强制覆盖以阻断的方式失败。当隧道无法建立时，设备连同私有资源一起失去普通互联网访问，用户体验是手机在线却无法浏览。重连与阻断是两个独立观察，所以要分别记录，而不是把“没有网络”当成一个症状。

On Demand 以不触发的方式失败。规则不匹配，隧道不出现，私有资源只是超时。这种情况很容易被误判为服务器问题，因为客户端的行为完全符合配置。

captive portal 处于两者之间：它需要先有连通性，隧道才会存在，因此“在隧道建立前阻断一切”的策略必须有一条穿过门户的成文路径。这要在设计阶段决定，而不是在服务台决定。

第 5 步：验证，然后演练回滚

验证应在真实路径上用无害流量进行：请求一个不应公开的私有资源，确认设备对外呈现的地址，并在重启后再做一遍，这样你看到的是启动序列，而不只是热态。

然后在测试设备上演练移除，而不是等到生产环境才需要。移除配置文件会把设备恢复到先前状态，知道它需要多久、用户会看到什么，是手册的一部分。Apple 的 VPN 安全指南是平台对这些策略所记录内容的参考，在编写声称超出平台能力的配置之前值得一读。

把第一步的三件事与规则集、测试结果放在一起。当下一个人问为什么一部手机在某个网络能连、在另一个网络不能连时，这些记录一分钟就能回答，而不必重新搭建。