哪个 VRF 到达 VPN 对端，哪个承载数据包？

客户路由上下文中的每条隧道仍然必须到达其远端对端，而这次查找可能发生在完全不同的表中。搞错这一点会产生 VRF 感知 IPsec 中最令人困惑的故障之一：隧道起来了，路由看起来存在，流量却中断，因为两次查找中有一处用了错误的上下文。请按顺序执行下面四个步骤，并把两个目的地分别记录下来。

两次查找，一条隧道

外层封装数据包的目的地址是对端的传输地址，它在任何保护存在之前就被路由。内层数据包的目的地址是客户服务器，它在解封装之后、在客户上下文内被路由。这是两个目的地、两次查找，而且往往是两张不同的表。

Cisco 关于 VRF 感知 IPsec 的文档把它们称为前门 VRF 和内部 VRF。前门承载加密传输，内部上下文承载受保护的流量。把隧道以客户命名，并不会让任何一条路由出现。

因此在改动配置之前，先列出四个事实：对端的传输地址以及到达它的上下文，然后是服务器的前缀以及到达它的上下文。如果四项填不全，你就是在猜。在这个领域猜测代价很高，因为添加到错误表里的路由可能让一条流工作，同时悄悄破坏另一条流。收集这四个事实需要十分钟，却能省下一天的抓包分析。

确认对端的传输查找

从前门开始，因为无法到达对端的隧道永远不会放行任何一个受保护的数据包。在 IOS 上，要在传输 VRF 内部查询到对端的路由，而不是在全局表中查询。

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

第一条命令回答在该上下文中对端地址是否可达，第二条列出实际存在的 VRF，第三条显示是否形成了安全关联。只在全局表中解析的对端地址就是典型的前门错误，它的表现是 IKE 协商始终无法开始。

还要检查接口的归属。文档描述的行为要求隧道的前门 VRF 与 WAN 接口的 VRF 保持一致；不一致可能让数据包发出去，却仍然使回包无法在正确的上下文中被处理。

确认服务器的内部查找

前门得到证实之后，切换到客户上下文，就服务器前缀提出同样的问题。这次查找决定了解封装后的数据包能否继续转发。

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

第一条命令显示内部路由，第二条显示会话状态以及平台与之关联的上下文。如果路由存在，但会话详情写的是错误的内部上下文，那么隧道正在往一张不认识客户前缀的表里转发。

全局表中的路由不是这两次查找中任何一次的凭据。当数据包不与任何 VRF 关联时才使用全局路由，而分配给客户上下文的隧道接口会改变这种关联。如果内部路由缺失，数据包会被解封装，然后因缺少转发表项而被丢弃，看起来像丢包，而不是路由错误。

把设置放在模型期望的位置

同一份文档区分了配置模型，属于其中一个模型的设置未必属于另一个。对于使用隧道保护的隧道接口，内部 VRF 定义在隧道接口上。对于基于 crypto map 的设计，内部 VRF 是 crypto map 条目的一部分。在没有确认作用的情况下，把名称相似的命令从一个模型搬到另一个模型，正是让可用设计变得时好时坏的原因。

路由和身份是两件事。可达性永远不能替代设备会接受的对端配置文件，重命名 VRF 也不得改变所提供的凭据。任何改动之后都要同时检查这两项，因为用错误配置文件协商的隧道仍然可以建立关联，却什么都不转发。

最后，把四个事实以及证明它们的命令记入变更记录。下一位工程师继承的是隧道，而不是推理过程；一段点名两个上下文的简短说明，比一张没人更新的图更有价值。