iPhone 重启后的 VPN：首先应该发生什么

「让 VPN 保持开启」这句话大约能撑过三十秒的追问。重启之后还开着吗？在解锁手机之前就开着吗？当 Wi-Fi 还显示登录页面时也开着吗？在隧道建立之前阻断流量，还是让第一个应用尝试直连？这是四条不同的要求，而手机能通过配置保证的只有其中一部分。把答案写成带阶段的时间线，然后在一次真正的重启之后逐段核对。

把要求写成时间线

从业务真正在意的时刻开始：哪项受保护任务不允许在没有隧道的情况下发生，以及启动后多久这项任务会被真正尝试。那个时刻之前的一切都是一个序列，而你要验证的正是这个序列。写着「VPN 必须开启」的备注无法检验，而「隧道建立之前不得有任何流量发往记录主机」可以检验。

然后把个人手机能做的事和受管设备群能做的事分开，因为这两个答案不能互相替代。

第一步：首次解锁之前的状态

不要从解锁之后看到的隧道去推断解锁之前的行为。诚实的测试是：重启、让手机保持锁定，并从另一端观察是否形成了隧道。在大多数个人设置中答案是否，这并不是缺陷；它只意味着在手机解锁之前不应尝试首个受保护任务。

如果某项要求确实依赖解锁之前的覆盖，就把它交给部署负责人，而不是交给客户端里的一个设置。

第二步：网络就绪与登录门户

受管的 Always On 无需用户交互即可激活，并且在配置文件保持安装的情况下跨重启持续生效，而建立连接发生在接口获得 IP 可达性之后。最后一句才是重点：尚未取得地址的手机没有可依托的基础。尚未被接受的酒店门户，正是这个意义上还没准备好的网络，任何记住的 VPN 偏好都不会替你把它补完。

所以验收记录里需要为门户这种情况留一行。要么手机等待，要么用户先通过门户，哪一种可接受取决于谁在出差。把这个选择写下来，因为早上七点重启的人不会自己想到它。要求输入房间号的门户也与只接受勾选框的门户属于不同情况。

第三步：仍然需要人的身份验证

自动激活和自动身份验证是两种不同的能力。使用设备证书的配置文件可以在没有人的情况下完成后者，而要求一次性因子的网关做不到，任何策略也改变不了这一点。在承诺无人值守的启动顺序之前，先确定你要部署的是哪一种。

然后明确记录中间状态：如果身份验证仍在等待，流量是被阻断、被排队，还是被直接放行？这个答案属于计划的一部分，因为这正是错误配置变成泄漏的窗口。测试方法是让网关不可达并观察手机的实际行为，而不是阅读客户端对自身的描述。

第四步：首个受保护任务，然后是一次切换

在计划中的重启之后，打开受保护任务，确认它成功，并确认它确实走了隧道。然后把同一项任务在从 Wi-Fi 切换到蜂窝网络的过程中重复一遍，因为这次移动会重新协商底层网络，也正是只在启动时有效的配置文件开始失败的地方。每次运行记录三件事：连接是否自动建立、你是否需要完成身份验证、预期资源是否有响应。

如果间隙期间的防护是强制要求，就使用部署负责人认可的验证方法。一次成功的页面加载无法证明在此之前没有任何流量走了直连。