Android 12 与 IKEv1 VPN：出厂版本、IKEv2 与第三方应用

两部手机在设置里都显示 Android 12，但只有一部仍能启动网关提供的老式 IPsec XAuth 配置。差别不在用户能改的设置上：拦截原生旧版 IKEv1 路径的检查看的是设备出厂时的 SDK 级别，而不只是当前运行的版本。这一个细节决定了整套机型的对比是否有意义，也决定了三条迁移路径中你真正需要哪一条。

两部 Android 12 手机不是同一个测试用例

AOSP 中阻止新设备启动旧版 IKEv1 配置的改动，是把 DEVICE_INITIAL_SDK_INT 与 Android S（即 API 31）比较。在原生旧版启动路径上，符合条件的配置会在任何可用连接建立之前就报出不支持的操作。出厂于 Android 11 并随后升级的手机仍能通过该检查；出厂即 Android 12 的机型则不能。

在开启调试的设备上可以读出这两个数字：

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

第一个值是检查所关心的出厂级别，第二个是手机今天运行的版本。当该属性缺失时，应查阅该机型的支持文档，而不是从营销名称去猜，也不要假设厂商构建会保留基础版本拥有的每一条兼容路径。

还有一个区分能省下一小时的无效支持时间：仍列在 VPN 设置里的已保存配置，并不能证明平台会启动它。重新输入 PSK 或修改路由都无法消除更早执行的协议支持检查，而失败时的表现看起来像凭据问题，其实并不是。

路径一：在旧版协议栈仍可运行的地方保留它

旧版协议栈就是从系统 VPN 界面读取 IPsec XAuth PSK、IPsec Hybrid RSA 和 L2TP/IPsec PSK 配置的那一套。在低于 API 31 出厂的设备上，升级后它仍是可行路径，所以老机型上的试点可以成功，而新机型上同样的配置会失败。

真正重要的比较是按设备类别，而不是按 Android 版本：列出 fleet 中的机型，读出它们的出厂 API 级别，然后分成仍能启动该配置的设备与不能启动的设备。别的做法只会产出一份自相矛盾的支持策略，用户一买新手机就露馅。

路径二：平台 IKEv2 配置

Android 面向 IKEv2 的公开配置模型是另一个对象，不是改了名字的 IKEv1 配置。IKEv2 配置的平台 API 随 API 30 出现，并要求使用网关提供的认证方式，通常是基于证书或 EAP。不存在从 IKEv1 XAuth 或 Hybrid 到 IKEv2 的线路级兼容升级：网关必须为新协议做配置，配置也必须携带匹配的身份。

这是寿命最长的路径，也是暴露真正工作量的那条。身份校验、用户认证、DNS、分离隧道路由和资源授权都必须熬过 IKEv2 迁移；只让握手成功，用户会连上一个什么都到不了的隧道。

部署通常通过 MDM 或受管配置完成，而不是让用户手填字段。如果这套基础设施还不存在，迁移计划就必须把它包含进去，因为逐台手动录入 IKEv2 配置不是服务台能承受的操作。

路径三：第三方客户端应用

有些 VPN 应用自带协议实现，完全不依赖原生旧版协议栈。这让它们成为无法快速迁移的机群的合理过渡方案，但兼容性问题转移到了应用上：它是否实现了网关所用的那一种 IKEv1 模式，并支持网关要求的认证与加密套件。

应把应用自己的支持矩阵当作权威，而不是商店描述，并在推荐之前用一台真机对接真实网关测试。为了恢复被移除的平台路径而 root 手机同样不是可维护的方案；它把问题搬进了一个不受支持的配置，下一次系统更新就可能悄悄弄坏它。

根据网关能提供什么来选择

知道两件事之后决定就收窄了：哪些设备出厂于 API 31 或更晚，以及网关能否以同样的注册模型提供 IKEv2 服务。能，就迁移并停止在旧版配置上投入。还不能，就为仍能启动它的设备保留 IKEv1，并把第三方客户端作为有文档、有期限的例外给新设备，而不是心照不宣的绕行方案。

两点让计划站得住。第一，把每个例外的理由连同机型和出厂级别记录下来，让审计者看到边界是平台检查，而不是未加解释的偏好。第二，把迁移当作计划内的工作：IKEv1 在标准轨道上已被弃用（RFC 9395），这意味着剩下的设备会继续减少，例外也应当随之到期。