两台 IPsec 对等体之间的路由器需要 IPsec 吗？

一个写着“在两站点之间配置 IPsec”的实验练习藏着两件不同的工作。两端终结隧道：它们协商、认证、加密与解密。中间的任何路由器只转发外层标头属于两端的数据包，而且它做这件事时并不知道隧道存在。

判断设备被要求做哪件事，是练习的第一步。实验报告中大部分混乱，以及生产拓扑图中相当一部分混乱，都来自把“支持 IPsec”当成一种属性而不是两种。

转发不等于终结

在隧道模式下，外层 IP 标头被发往终结隧道的设备。中间的路由器查询目的地址并转发，与处理任何其他数据包完全一样，它承载的载荷对路由器而言是不透明的。

这种不透明是有意为之。路由器不持有对端的密钥，不参与协商，也不需要策略数据库。它只需要一条通往远端端点的路由，以及转发该数据包的许可。

把两者混为一谈会导致真实错误：要求过境防火墙“允许 IPsec”，而实际需求是允许特定地址之间的协议 50；或者指望中间设备解密以供检查，而它根本没有密钥。

中间设备仍然必须做对什么

转发有自己的要求。路由必须到达两个外部端点，路径上的任何策略都必须放行真实的外层流量，而不是猜测的端口号。因有人假定 TLS 而针对 TCP 443 编写的规则不会匹配协议 50。

原生 ESP 就是 IP 协议 50。它不是 TCP 50，也不是 UDP 50，阻止非 TCP 流量的规则会把它丢掉。如果设计使用 UDP 封装，可见传输会变为封装端口，策略必须与所选设计相符。

数据包大小也很重要。能通过小探测包的路径，并不证明完整的封装交换也能通过。丢大包的路径可能让协商成功而工作负载失败，看起来像应用问题。在归咎于隧道之前，请用与真实工作负载同等大小的流量测试。

为什么模拟器改变了问题

模拟器不是功能列表更短的路由器；它是一个带有已记录子集的模型，并自有一套关于某设备可被配置做什么的规则。思科 Packet Tracer 的常见问题明确说明，设备和协议都是简化模型。

于是问题变成三个问题。被模拟的设备会转发场景所需的数据包吗？同一设备是否提供课程所假定的配置界面？被接受的命令是否意味着行为真正被模拟，而只是被解析？

缺少某条命令可能是模型限制，而不是你配置的错误。存在的命令可能只接受语法，而不复现全部生产行为。在下任何结论之前，先查阅已安装版本中该设备的帮助。

为实验写下通过条件

对于 underlay 课程，通过条件是端点可达，且外层数据包穿过中间设备。用模拟器自身的计数器或数据包视图来证明，并说出你期望看到的协议。

对于 IPsec 课程，再加上协商状态和一条受保护的 LAN 到 LAN 流。如果模拟器显示安全关联，就记录下来。如果没有，请在报告中说明，而不是暗示隧道已经验证。

把模拟器版本、所选设备和学习目标与拓扑文件一起保存。正是这份记录让别人能复现该练习，并理解哪些部分被建模了。

生产配置需要自己的平台证据。绿色的模拟数据包是教学结果，不是关于你将要部署的硬件的兼容性声明。