Android VPN 连接 Cisco IOS：先拿到那份契约

手机要连上一台 Cisco 网关。安装哪个客户端，别人早就替你想好了。这正是流程的错位之处，也是为什么反复重输凭据一小时后，隧道依然失败。

你首先需要的是一份连接契约：协议、认证、身份、信任材料、地址分配和路由，由负责网关的人书面给出。

拿到书面材料，客户端的选择就只剩查表。跳过这一步，每次失败看起来都像密码错了。

在安装任何东西之前先做盘点

把一张清单发给网关负责人，要对答案，不要产品名。九项内容足以完整覆盖一个远程接入配置：

1. 客户端要拨号的网关主机名或地址，以及它是否能从外网访问。
2. 协议与版本：IKEv2、另一代 IPsec，还是基于 TLS 的服务。
3. 网关要求的对端身份，以及它自己回过来出示什么。
4. 信任材料：由哪个 CA 签发网关证书，还是使用预共享密钥。
5. 用户认证：证书、EAP 用户名与密码，或者预共享密钥。
6. 客户端落入的地址池，连同掩码和网关。
7. 隧道内要使用的 DNS 服务器，以及客户端是否必须接受它们。
8. 允许的目的地前缀，以及前缀之外的流量是否必须被阻断。
9. 受支持的客户端版本与手机系统版本，以及任何注册要求。

这些条目里有两条造成了大多数本可避免的故障。没有信任材料，你无法验证网关，于是一个正确的客户端也像是坏的。没有允许的前缀，你分不清路由限制和服务故障。

厂商名字不是协议

Cisco IOS 和 IOS XE 提供多种远程接入方案，它们并不共用同一种线上格式。带 FlexVPN 风格配置文件的 IKEv2 并不是旧式 IKEv1 配置的那项服务，而基于 TLS 的客户端服务又是另一个产品，往往位于同一环境中的另一套平台。

所以，名字里带路由器厂商的客户端什么都证明不了。它可能把其中一项服务实现得很好，却完全不支持其他几项。先问清楚配置的是哪项服务，再核对客户端文档是否把这项服务列为受支持。

Cisco 自己的 IKEv2 文档把提案、策略、配置文件和密钥环当作彼此独立的对象。读别人贴给你的配置时，这种结构很有用：它告诉你哪一部分装着对外部手机真正重要的设置，而不是把整个文件当成一团。

Android 内置协议栈覆盖了什么

Android 通过 Ikev2VpnProfile 暴露平台级 IKEv2/IPsec 配置文件，预共享密钥、RSA 证书以及 EAP 用户名与密码各有独立的认证类型。Ikev2VpnProfile 参考文档是判断构建器接受哪些内容的权威，其中也包括网关主机名和用于验证它的服务器根 CA。

那个 API 是能力声明，不是兼容性承诺。它只说明平台能完成这几种认证类型的 IKEv2，并没说某个 OEM 的设置界面会暴露每一个字段，也没说别家产品导出的配置文件一定能导入。

这也意味着，如果网关运行的是平台没有实现的服务，内置协议栈救不了你。那种情况下你需要运营商支持的那家厂商客户端，按运营商的文档安装和配置，而不是在手机不会说的协议上绕一圈。

按契约书写的顺序逐层测试

每次只验证一层，遇到第一个失败就停下，因为在前面的层通过之前，后面的测试没有意义。

信任。如果客户端拒绝网关证书，其他都不必谈。确认给你的 CA 签发的正是网关出示的那张证书，且你拨号的主机名出现在其中。保持验证开启；关掉它等于把身份问题换成被中间人截获的风险。

认证。凭据被拒和提案不匹配会产生不同的错误，但失败的样子很像。网关日志是裁决者：它会在谈及用户之前先说提案是否被接受。

地址与 DNS。确认手机从文档记录的地址池拿到了地址，然后再解析一个内部名称。一个有地址却没有解析器的隧道看起来连着，行为却像什么都没通。

可达性。先用地址、再用名称测试一个允许的目的地。地址通而名称不通，你回到了 DNS。两个都不通，就在动客户端之前，把正在测试的前缀与允许列表比对一遍。

故障模式与回滚

改动任何东西之前，先把上一份可用的配置文件导出并写成文档，包括 CA 别名和地址池。这样回滚意味着恢复一份已知配置，而不是在故障当中凭记忆重搭一份。

跑通之后，把那九项盘点的答案记在配置文件旁边。下一部手机、下一次系统更新、下一次网关改动，都会变成与文档的比对，而不是又一个下午的猜测。