iPhone 上 VPN 应用与内置 IKEv2：如何选择
iPhone 的 VPN 应用与内置 IKEv2 客户端解决的是不同问题。应先比较协议支持、身份验证、设备控制与恢复能力。
上周，同事把他的 iPhone 递给我，设置里有两条 VPN 条目：一条由服务商应用留下，另一条来自从支持页面粘贴的 IKEv2 描述文件。它们并不是同一事物的竞争版本。服务商应用是一个可以自带隧道代码的容器，而 Apple 的内置客户端是 IKEv2 客户端，靠手工或描述文件配置。协议、凭据处理、设备控制与恢复能力决定了选择。
应用与原生客户端处在不同层级
Apple 的内置 VPN 客户端实际上就是 IKEv2 客户端。手动表单仍列出已弃用的 基于 IPsec 的 L2TP 和 Cisco IPsec 选项，但没有服务商传输字段，也没有地方粘贴 OpenVPN 或 WireGuard 配置。你要么在“设置 > 通用 > VPN & 设备管理”中填写表单，要么导入带 VPN 载荷的描述文件；界面上只有服务器地址、两个身份、一种认证方式以及可选的按需规则。
服务商应用则高一层。它提供 Network Extension 数据包隧道提供程序，因此协议代码和路由逻辑都在应用里，iOS 只负责转发数据包。有些应用实现 WireGuard 或 OpenVPN，有些实现自家的混淆传输，还有少数只安装 IKEv2 描述文件，再用更漂亮的界面驱动原生客户端。最后一类正是“应用还是描述文件”有时成为伪命题的原因。
后果很实际：.ovpn 或 WireGuard 文件不能替代这些字段，因为握手用的是另一种协议。
比较功能之前，先读载荷
当描述文件是 IKEv2 时，载荷键能解释的故障比任何功能对比都多。Apple 的 IKEv2 设置参考 记录了每个键；精简后的载荷如下：
<key>VPNType</key><string>IKEv2</string>
<key>RemoteAddress</key><string>vpn.example.net</string>
<key>RemoteIdentifier</key><string>vpn.example.net</string>
<key>LocalIdentifier</key><string>[email protected]</string>
<key>AuthenticationMethod</key><string>Certificate</string>
<key>ServerCertificateIssuerCommonName</key><string>Example Issuing CA</string>有三个字段承担了大部分诊断重量。RemoteIdentifier 是客户端期望服务器出示的名称，因此位于 NAT 之后的网关，或证书写的是地址池而非地址的负载均衡器，即使地址正确也会失败。LocalIdentifier 是服务器认为你是谁，在证书认证下它必须与映射到你账户的身份一致。ServerCertificateIssuerCommonName 固定签发 CA，因此证书重签当天描述文件就可能失败，而错误信息完全不会提到证书。
如果 AuthenticationMethod 是 SharedSecret，服务器就是在做 EAP 用户认证，你拿到的密钥实际上是账户凭据。当服务商发来两份文档，一份给用户名和密码、一份给证书，而只有一份与你导入的内容匹配时，这一点很关键。
应用能做到而原生客户端做不到的事
协议选择是显而易见的优势。如果你的服务器使用 WireGuard 或 OpenVPN，应用是唯一能用它的 iOS 客户端，修改原生表单并不会协商它。应用还能实现按目标或按应用的分流、自己的 DNS 处理、类似终止开关的阻断、服务器选择，以及针对自身网络调优的重连。
代价是未经你审计的软件，以网络扩展的权限运行。质量差异比商店页面显示的更大：一个应用能干净地重连，另一个在网络切换后会泄漏几秒钟；应用内的终止开关是该应用的功能，而不是 iOS 的。在受管设备上，先查批准列表。
原生 IKEv2 描述文件的优点
更少的活动部件就是全部理由。IKEv2 客户端及其 IPsec 协议栈随系统提供，因此没有会崩溃的扩展，没有需要保活的应用进程，你和一条可用隧道之间也没有第三方更新周期。描述文件还可以被锁定：在受监督设备上，用户无法移除管理方安装的内容，而 Always On VPN 会在任何网络自动重连、没有用户开关，只存在于这种受监督、由描述文件管理的形式中。
原生路径不给你的是灵活性。没有受管应用就没有按应用 VPN，没有面向用户的终止开关，也没有能在封锁 IPsec 的网络上伪装成 HTTPS 的传输。在丢弃 UDP 500 和 4500 的酒店网络里，原生 IKEv2 没有退路。
一张能解决多数情况的选择表
在实践中，协议问题在功能之前就决定了多数情况。
| What you were given | Device situation | What to use |
|---|---|---|
| An .ovpn or WireGuard config | Personal phone | Provider app; the native form cannot load it |
| IKEv2 host plus CA name | Personal or managed | Profile, or the app's own IKEv2 mode |
| IKEv2 with username and secret | Personal phone | Either; the profile is simpler if you never switch servers |
| A management-installed profile | Supervised, MDM | Native client; do not add a second app entry |
| A per-app tunnelling requirement | Personal phone | App, or accept a full tunnel; iOS cannot split by app without management |
| IPsec blocked on your main network | Any | App with a transport that survives the block |
有两行值得再看一眼。个人手机上的按应用需求，是人们最容易误读的情况： 该设置存在于 iOS 中，但由管理方驱动，所以非受管设备不会提供它。网络被封不是怀疑 IKEv2 的理由；它正是服务商应用存在的原因。
用一次测试验证选择
测试故障模式，而不是连接按钮。连接一次，确认出现 VPN 指示器，然后打开一个回显公网地址的页面，与之前对比。在不碰 VPN 的情况下从 Wi-Fi 切到蜂窝网络，观察是否重连，再让手机走一遍飞行模式。重启后看隧道是否自行恢复：带 OnDemandEnabled 的描述文件应该会，而许多应用需要先打开。
如果它没有恢复，就按是否存在隧道来拆分故障。没有 VPN 指示器意味着隧道从未建立：要么握手在 RemoteIdentifier、固定的 CA 或某个凭据上失败，要么按需规则不匹配、又没有应用发起连接，所以根本没有尝试。有指示器但流量失败，意味着路由、DNS 或服务器端策略问题，重装客户端对这些毫无帮助。
一份简短清单，让下一个人能看懂这台设备：
- 只保留一条 VPN 条目，而不是两条；
- 描述文件或应用以它所连接的服务器命名；
- 把身份值写在你能找到的地方。
先看表格里的协议行，如果它能回答问题就到此为止。