如何用 ASA packet-tracer 建模 VPN 流

ASA 上的 packet-tracer 回答一个很窄的问题：这个包以这个元组从这里进入，是否会被放行，以及它会去哪里。它不回答远端是否收到任何东西。常见错误是：想测试隧道内的应用，却喂给它一个外层 IKE 元组。先修正元组，再读各个阶段，然后对模拟器看不到的一切取得真实证据。

下面的走查假定 ACL、NAT 规则和 tunnel-group 上下文就在你面前。没有它们，输出描述的是一条你无法核对的策略。

第 1 步：用平白的语言写下内层流

在输入任何内容之前先描述应用。内部主机向远端网关后的服务器发起 SSH，是一条具有特定源端口的内层 TCP 流。ACL 和 VPN 过滤器评估的正是这条流，所以要输入的也是这条流。

把它写成一句话，然后逐字段翻译：

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

第 2 步：选择入口和方向

入口是包到达的接口，不是它离开的接口。对于发起连接的 LAN 主机，那就是 inside 接口。对于同一会话的返回包，那就是 outside 接口，元组随之反向。把目的写成源，是第二种最常见的、拿到可信却无关的 ALLOW 的方式。

端口也有方向。对于发起的请求，服务端口属于目的字段，客户端的临时端口属于源字段。一个 TCP 目的为 500 的模型描述的是监听 500 的 TCP 应用；它不会因为命令里出现这个数字就变成 IKE 测试。

第 3 步：按顺序读各阶段

输出中的每个阶段都是一个有归属的决策：路由查找、ACL、NAT，然后是 VPN 或隧道的选择。按打印顺序阅读，并在第一个与设计不符的阶段停下。

NAT 常让人栽跟头。如果转换后的源落在为隧道选择流量的 crypto ACL 之外，这条流可能被放行，却从未被封装。跟踪会打印转换后的地址，所以要把它与隧道的感兴趣流量比较，而不是与原始地址比较。

第 4 步：检查你选了哪些旁路

detailed 形式接受跳过检查的选项，Cisco 文档记录了一个 bypass-checks 选项，涵盖 ACL、VPN 过滤器、uRPF 和 IPsec 欺骗检查。带着这些旁路得到的 ALLOW 只说明路由和 NAT 会工作，并不说明策略会接纳真实包。把选项记录在结果旁边。

如果你需要策略答案，就不要带旁路运行。如果你在隔离一个路由问题，就带旁路运行，并把结果标注为路由答案。

第 5 步：用真实交换弥合差距

模拟的允许止于 ASA。远端网关是否解密了包、服务器是否接受了连接、是否有回复返回，都是彼此独立的观察。使用端点计数器，或者在获准路径上做一次范围受限的抓包。

有些 trace 和 replay 选项会发送包或持久化状态。请遵循你的版本和已获准的诊断流程所记录的文档行为，而不是把每个变体都当作只读查询。

跟踪仍然无法告诉你什么

把四件事记在同一条笔记里：元组、匹配到的 NAT 规则、应该承载这条流的隧道或策略，以及方向相关的观察。没有它们，后来的工程师无法把本地策略决策、已建立的控制平面和正常工作的服务区分开。先失败后成功也不是隧道必须在此期间建立的证据；记录阶段和状态变化。

从内层元组开始，在第一个与设计矛盾的阶段停下，只有之后才去获取端点证据。跟踪是策略的神谕，不是送达回执。