IKEv2 配置已定义但未挂接：追查整条链路

IKEv2 配置就在已保存的配置里，密钥环也在，但隧道仍然起不来。在 Cisco IOS XE 上，配置是承载身份匹配与认证选择的对象，而对象本身什么也不做，直到另一个对象引用它、并且某个接口把它挂到一条路径上。大多数失败的第 1 阶段调试恰恰漏掉了其中一处引用。在改动任何提议或策略之前，先顺着密钥环向外读完整条链路。

配置对象究竟是什么

IKEv2 配置保存远端身份匹配、本地与远端认证方式，以及对密钥环的引用（用于预共享密钥设计）。它描述对端如何被识别、如何证明自己，并不指名任何接口。

密钥环是单独的对象，保存预共享密钥。crypto map 或 IPsec 配置是第三个对象，它引用 IKEv2 配置并提供保护设置。接口挂接是第四步，在这里应用 crypto map 或启用 tunnel protection。每一次跳转都是独立的引用，缺少任何一跳，每个对象单看都仍然正确。

按顺序追查引用链

从配置所指的密钥环开始，然后确认 crypto map 或 IPsec 配置引用的配置名称，再找出使用最后那个对象的接口。把每个名字写在引用它的对象旁边；这份短清单比逐一核对每个预期段落是否存在于配置中更有用。

常见的断点都是机械性的。配置名与 crypto map 引用的名字只差一个字符。crypto map 存在，却从未应用到接口上。tunnel protection 命令指向的 IPsec 配置引用了另一个 IKEv2 配置。没有显式挂接的 responder 是有文档记载的情形，而没有挂接的 initiator 根本就是没有为该路径做配置。

crypto ikev2 keyring KR-SITE
 peer SITE-B
  address 203.0.113.9
crypto ikev2 profile IKEV2-SITE
 match identity remote address 203.0.113.9 255.255.255.255
 keyring local KR-SITE
crypto ipsec profile IPSEC-SITE
 set ikev2-profile IKEV2-SITE
interface Tunnel100
 tunnel protection ipsec profile IPSEC-SITE

把这段配置当作链来读，而不是当作模板。接口指名 IPsec 配置，IPsec 配置指名 IKEv2 配置，IKEv2 配置指名密钥环。断开其中任何一个名字，配置仍然能被解析，所以路由器照样接受，隧道却一直起不来。

Crypto map 与 tunnel protection 是两种替代方案

Cisco 记载了两种挂接方式。crypto map 可以应用到接口，并通过它的 set 命令引用 IKEv2 配置。tunnel protection 把 IPsec 配置挂到隧道接口上。两者都有效，而且并不是要作为双保险同时安装。

隧道的源和目的标识外层投递方式，它们与保护挂接是分开的。LAN 接口、隧道接口和外层源接口扮演三种不同角色。LAN 接口上的 crypto map 并不保护隧道，而启用了保护却没有可达源地址的隧道，永远不会向对端发送报文。

要看加载后的状态，而不只是文本。已安装的版本里有把已配置对象与协商会话关联起来的命令，工单里该引用的正是这些。 已保存的配置只能证明意图；会话表才能证明路径。

Responder 的例外不是 initiator 的规则

IOS XE 指南指出，responder 上显式的 IKEv2 配置挂接可以是可选的。这个例外并没有取消认证或身份检查，也没有让发起连接的一侧把配置变成可选。

如果你的路由器主动发起，就把挂接当作必需项，端到端追查一遍。如果你的路由器只做应答，就要确认究竟是哪一个配置真正匹配了进来的对端，因为 responder 可以按身份而不是按接口引用来选择配置。

检查路径，而不是已保存的配置

挂接关系对齐之后，测试一个被允许的应用，记录它内侧的源、目的和路由。路由器自己发起的请求可能使用与 LAN 转发流量不同的源地址，而保护范围可能只覆盖其中一种。

正确挂接的定义并不能证明选择器、回程路由和接口策略覆盖了你的流量。发送真实流量并读取协商后的状态，然后在重连之后再重复一次，才能确认这条链能经受新一轮协商。把解释限定在 IOS XE IKEv2 范围内；历史上的 IKEv1 crypto map 部署是另一套对象模型，不应拿这条链去调试。

隧道工作正常后，把这四个名字写进变更记录。下一个接手 crypto map 的人会需要它们，而这条链正是运行配置无法解释的那部分设计。