Cisco ASA 隧道默认路由：究竟什么时候才生效

远程接入用户越过 ASA 之后什么都访问不到，可同一台服务器却能回应来自内部 LAN 的 ping。隧道建起来了，客户端也拿到了地址池中的地址，数据包却仍然从互联网默认路由出去，或者干脆消失。这种情形通常意味着解密后的流量没有自己的路由，落到了普通默认路由上。解决办法并不是再加一条 NAT 规则，而是隧道默认路由。

从现象入手，而不是从配置入手

关注数据包实际去了哪里，而不是你以为它该去哪里。会话失败时在外侧接口抓包，会看到解密后的数据包仍带着地址池地址、朝 ISP 网关方向离开；也可能什么都抓不到，因为路由查找失败。无论哪种情况，问题都不在隧道。

在 show vpn-sessiondb 里隧道看起来一切正常，这正是大家一直在排查 IKE 的原因。

把它与 ACL 丢弃区分开的是方向。ACL 丢弃会被记录并计数，而缺少路由只会产生一次查不到匹配项的路由查找失败。对客户端的目的地址执行 show route，读一读 ASA 实际选了什么，包括是否选中了默认路由、选中的是哪一条。

隧道查找有何不同

Cisco 的 ASA 9.23 静态路由指南 记录了一条单独的默认路由，专门用于既无静态路由也无学习路由的解密 VPN 流量。tunneled 关键字标记的正是这条路由，因此解密后的数据包可以落到与 ASA 自身传输所用的下一跳不同的下一跳上。更具体的路由依然优先，所以客户端能经内部网关到达 10.0.0.0/8，却丢掉其余一切。

最小配置保留两条下一跳不同的默认路由。一条承载 ASA 自身的流量，另一条承载没有更优路由的解密流量。两条下一跳仍然必须能从你绑定它们的接口出发可达。

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

如果两条默认路由指向同一个下一跳，这个关键字不会改变任何东西，现象也不会变化。

决定成败的限制条件

同一份指南只允许存在一条隧道默认路由，并明确指出它不支持 ECMP，因此无法在该路径上做负载分担。指南还列出了涉及路由跟踪、反向路径验证以及部分检测与管理流的限制。在围绕该功能做设计之前，请结合你安装的版本逐条阅读。忽略这些限制的设计通常只会在某一个特定环节失败，而不是全面失败，这也正是现象看起来时有时无的原因。

在非对称设计中咬人的是反向路径验证。如果回包会从 ASA 预期之外的接口进来，数据包在路由还未起作用之前就被丢弃了。应当修正拓扑或回程路径，而不是关掉验证去强行指定下一跳。

路由跟踪是另一个陷阱：被跟踪的对象通常守护的是普通默认路由，而不是隧道默认路由。

这个关键字不做什么

它并不决定 ASA 用来构建 IKE 的源地址。外层隧道端点遵循平台自身的接口与源地址选择，隧道默认路由在该决策中没有任何份额。改动它修不好源地址错误的 phase 1。

它也不会把下一跳变成代理。如果目的地期待的是 HTTP CONNECT 交换，把原始 IP 包发给代理主机，只会得到一个并不为你转发这些包的主机。应当改为配置客户端支持的代理机制。

它同样不产生下游转发。你指向的那台网关仍然需要一条回到 VPN 地址池的路由，并在设计需要的地方做源地址转换。

端到端验证路径

路由下发之后，按顺序检查四件事：对地址池需要访问的目的地址执行 show route；在通往新下一跳的接口上抓包；在网关本身上抓包；以及从该网关回到地址池地址的回程路径。前两项证明 ASA 选对了路径，后两项证明那条路径上确实有人在回应。

如果网关有回应而客户端始终收不到，先检查源地址转换和回程路由，再回头动路由表。

记录下你验证时所用的版本，因为限制清单是随版本变化的，在一条版本线上可用的设计，换到另一条线上可能需要另一条路径。这条备注比配置片段活得更久。