同一台 ASA 后面的两个远程接入用户可以从同一个 outside 接口发出流量,却得到完全不同的处理。一个去往公网网站,因此数据包需要源地址转换和一条互联网路由。另一个去往站点间隧道的对端服务器,而这条隧道同样终结在该接口上,因此数据包需要身份、匹配的隧道选择器以及返回客户端池的回程路径。同接口放行对两者都是前提条件,却都不是解决方案。

两条分支,一个接口

在敲下 NAT 规则之前先确定你在建哪条分支,因为两类规则不能互换。分支 A 是客户端到互联网:池地址进、转换后的公网地址出、再由同一接口返回。分支 B 是客户端到另一台 IPsec 对端另一侧的私有前缀:池地址保留、重新加密,并送达一个必须知道如何回包给该池的对端。

两者首先需要的是同接口放行。没有它,ASA 拒绝把数据包从它进来的接口再转发出去,而故障看起来像路由问题而不是策略问题:

same-security-traffic permit intra-interface

这一行授权了一种转发安排,正如 ASA NAT 参考文档 对同接口路径的描述。它不添加客户端路由、不授权资源、不做地址转换,也不协商 IPsec 选择器,所以要预期在它之后还要再加三到四件事,别把它的通过当成进展。

分支 A:客户端要上互联网

要做互联网出口,池地址必须在数据包离开设备之前不再是私有地址。在常规 PAT 设计里,规则把池转换成 outside 接口地址,返回状态再把面向客户端的流量还原:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

然后确认客户端确实要求 ASA 承载这份流量。拆分隧道的排除项会把公网目标走手机自己的连接,那根本到不了 ASA,而任何 NAT 规则都修不好一个从未发出的数据包。把组策略的拆分隧道列表和你正在测试的目标对照一遍。

这条分支的其余部分是常规工作:从 outside 接口出去可用的默认或具体路由、允许该流量的访问策略,以及按所选解析器策略处理的 DNS。在此处加上 route-lookup ,理由与下文相同,因为进、出接口是同一个。

分支 B:客户端要访问私有站点

这条分支失败的地方更多,所以要按顺序写。先是客户端路由:目标前缀必须出现在拆分隧道列表里,否则客户端不会把它放进隧道。其次是隧道选择器:站点间加密 ACL 必须覆盖池地址到远端前缀,而不仅仅是本地 LAN 到远端前缀。第三是身份,让池地址在经过时不被转换成互联网 PAT。

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

远端是大家最容易忘记测试的部分。对端需要一条回到池的路由和包含该池的选择器,而且 它自己的策略必须允许它将看到的源地址。如果站点改用转换后的视图访问,那也是有效设计,但那时两端、两个选择器和两张路由表都必须对转换后的地址达成一致。

也要检查规则顺序。位于身份规则之上的宽泛 PAT 规则会在身份规则被评估之前就把私有互通转换掉,症状是站点隧道没有匹配的 SA,而不是 NAT 报错。

能告诉你建了哪条分支的测试

用 ASA 自己的路径评估,而不是读配置然后祈祷。 packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed 会显示一条流的 NAT 决策、路由和 ACL 结果;换一个私有目标再跑一次。如果 NAT 阶段改写了私有到私有的流,那你给一个需要分支 B 的数据包建了分支 A。

再加两条命令就能补上缺口。 show nat detail 会打印 packet-tracer 所遵循的规则顺序,而 show crypto ipsec sa 会显示你所期望的那一对是否存在选择器。缺失 SA 是选择器或对端配置的问题,不是 NAT 规则能修好的。

用它所服务的流量验证每条分支

用客户端一次普通的公网请求验收分支 A,用一次对真实存在的私有资源的请求验收分支 B。然后各自再用一个被拒绝的资源重跑一遍,因为“放行”与“被访问策略允许”不是同一种证据,而从中心发起的 ping 两条客户端路径都没走到。

在工单里把两份测试记录分开:源地址、目标、命中的 NAT 规则和结果。当下一次报告说“VPN 坏了”,这一对记录能在一分钟内告诉你是哪条分支退化了,而答案通常是路由或选择器,不是大家最先怀疑的那行同接口配置。

相关文章