个人 VPN 还是数据包隧道：iPhone 的两种 VPN 模型
一种模型配置 iOS 内置的 IPsec 或 IKEv2；另一种则附带实现自有协议的提供方。产品名称并不说明你拿到的是哪一种。
两个 iPhone 应用都能在“设置”里放一条 VPN 记录，都能自称 VPN 客户端，却几乎没有共同的实现。Apple 把其中一种集成叫作个人 VPN，而正是这个名字制造了大部分混乱。个人 VPN 是一套 API，用于创建和管理使用内置 IPsec 或 IKEv2 实现的配置。数据包隧道提供方是另一种模型：应用附带一个扩展，由它实现自有协议的客户端。人们之后从这个标签推断出的一切，从加密算法到归属，再到手机是否必须被管理，都是推断而非陈述。
谁来负责实现隧道
这种分工决定了出问题时谁负责。使用内置 IPsec 或 IKEv2 时，隧道状态机归 iOS 所有，应用只拥有配置和按钮。使用提供方时，两者都归应用所有，于是协议缺陷变成应用更新，而不是系统更新。
如果你问“谁实现了协议”，比较就很简短。
| Integration | Apple interface | Protocol implementation |
|---|---|---|
| Personal VPN | NEVPNManager with a Personal VPN configuration | The system IPsec or IKEv2 client |
| Packet tunnel | NETunnelProviderManager plus the provider extension | Whatever the extension implements |
Personal VPN 文档还提到，应用首次保存配置时会出现明确的用户授权提示，这属于该模型，而不是所有 VPN 应用的共性。
关于这个标签，有两个说法该被放弃
第一是个人 VPN 会选择加密算法。它并不会；协商出的套件来自协议及其配置，个人这个标签并不能说明你会拿到哪一种。第二是个人 VPN 意味着代理或受限隧道。它意味着内置 IPsec 或 IKEv2，只要路由如此，那就是完整隧道。
因此，应用的存在并不能证明线路协议。一个使用 WireGuard 或 OpenVPN 的第三方客户端，从构造上就是提供方应用，因为 iOS 并不原生实现这些协议。
为什么“企业”措辞会误导
Apple 的文档把 NETunnelProviderManager 配置归为普通的企业 VPN 配置。这种措辞是一个 API 分类，却把人推向两个相反的错误：以为消费级应用不能用提供方模型，以及以为手机必须被监管才能用。两者都推不出来。消费级应用经常附带提供方，而监管是一个独立问题：谁能强制执行策略。
管理归属就是第四个问题，它与两种模型都无关。组织安装的配置带有自己的身份、流量范围和生命周期规则，这些随配置描述文件走，而不是随碰巧安装的应用走。要把它和集成模型一起读，因为受管的内置描述文件和不受管的提供方描述文件可以同时存在于同一部手机上。
查证据，而不是看截图
截图是能拿到的最差证据，因为“设置”的分组会随版本变化。受管的描述文件会写明自己的载荷类型：内置描述文件声明 IKEv2 或 IPsec 这类 VPN 类型，而提供方描述文件带一个子类型，写明提供方的包标识符。这在你眼前的设备上就能查，而且能挺过下一次改版。
至于应用本身，所用的类从另一侧回答了同一个问题：是来自个人 VPN API 的配置对象，还是一个提供方管理器及其扩展。
然后按运营方实际提供的东西来选。凡有兼容的原生描述文件，内置路径的活动部件更少，要更新的东西也少一件。凡服务需要 iOS 不提供的协议，提供方应用就是唯一选择，它的发布节奏也就成了你风险的一部分。
让记录跟着连接走
把认证和资源策略绑到连接记录上，而不是绑到应用上，这样重装应用不会把授权模型一起带走。当隧道起来了而别的都不工作时，支持工程师需要的也正是这条记录。
最后值得问的问题不是哪种模型更好。而是你的运营方支持哪种模型，以及凌晨两点你能用手头真正有的工具调试哪一种。