iOS 上的按 App VPN：要对齐 App 的 VPNUUID，而不是 PayloadUUID

两个 UUID 值决定一个受管理的 iPhone App 是否走按 App 隧道，而它们都不是承载它们的描述文件的标识符。App 的 VPNUUID 属性必须等于按 App VPN 载荷中的 VPNUUID。部署的 App 还必须由同一套设备管理服务管理，而你发出的命令必须真的带上这个属性。按顺序走完下面四个阶段，因为每个阶段都会产出一个下一阶段要用的值。

在碰设备之前先收集四个标识符

写下四个值：管理清单里的 bundle 标识符、按 App VPN 载荷的标识符、该载荷内部的 VPNUUID，以及你即将发出的命令的标识符。bundle 标识符指的是接收设置的那个应用，主屏幕上的名称不能替代它。把 PayloadUUID 完全排除在这份清单之外，因为它标识的是描述文件内部的载荷，回答的是另一个问题。只因为两个字段看起来都像 UUID 就拿它顶替，是构造出一种永远对不上的关联的最常见做法。

如果 VPN 管理员没有把按 App 载荷和它的标识符交给你，就去要，而不是从手边随便哪个配置文件里抠一个 UUID。

通过管理通道下发属性

先确认目标 App 在那台设备上处于被管理状态，因为知道 bundle 标识符并不等于让未受管理的安装有资格建立关联。然后通过产品的按 App VPN 指派，或该产品所支持的 Settings 命令实现，发出一条 ApplicationAttributes 类型的设置项。该设置项用 bundle 标识符指明 App，并携带一个 Attributes 字典，其中的 VPNUUID 与载荷一致。这个设置项里没有任何东西是完整的命令信封，也没有任何东西可以手工当作描述文件安装。

移除要和安装一样有意识。架构说明，省略 Attributes 字典会移除该 App 现有的属性，所以半成品更新会悄悄变成一次重置。名字相近的 Managed Application Attributes 命令只是回读属性用于核对，并不设置属性；把它当设置方使用等于白白浪费一个部署窗口。

读命令结果，别看 App 图标

检查所发命令的回执，确认受管理的 App 现在报告了这个属性。状态栏里的 VPN 标记只说明手机某处存在一条隧道。它无法告诉你这个特定的 App 被指派到了按 App 配置；而在隧道按需打开的机器上，这个标记可能根本不会出现。去比对指派里的标识符，而不是寻找视觉提示。

如果同一批设备里存在两套按 App 配置，先比对它们的标识符，再认定你的指派落在了预期的那一套里。

用资源实测，然后把这对值记下来

让有权限的用户从被指派的 App 打开私有资源，观察 按 App 隧道是否会为他升起。然后在同一台手机上用一个未受管理的 App 重做一遍，确认处理方式不同。真正的测试就是这种对比，因为一个能用的私有资源，也可能只是走了变更记录里没人提到的整机隧道。趁设备还在你面前，把结果记下来。

把 bundle 标识符、载荷标识符、共享的 VPNUUID 和命令结果放在一起，让下一次排查从同样这四个值出发，而不是凭记忆。

回滚时不要伤到别的东西

要移除指派，就按产品文档给出的形式，用空的 Attributes 字典重发该 App 属性，而不是把 App 从命令里删掉。之后核对：该 App 不再打开按 App 隧道，其他受管理的 App 仍保留自己的隧道。如果同一台手机还有一套整机 VPN 描述文件，确认它仍和回滚前一样工作，因为一台设备上存在两套 VPN 配置，正是这一步通常出问题的地方。然后更新你保留的记录。

如果审计问起某个 App 当初为什么走了隧道，它要的是那对 UUID 和日期，不是部署说明。