VPN 流量中的 ASA identity NAT 与 IOS NAT 排除

某分支机构在同一台 Cisco 网关上同时运行互联网 PAT 与站点到站点 VPN，而一旦加入 NAT，VPN 立刻失效。隧道内的地址不再与 crypto ACL 所保护的范围一致，或者对端看到的是自己没有路由的转换后地址。Cisco 用两种方式解决：ASA 选择一条把地址映射为自身的 NAT 规则，IOS 则用 ACL 中的 deny 把该流量排除在转换规则之外。两者都保留原始地址，也都不是绕过 NAT 处理。

先记录流量，再选择规则

先把期望保护的流量写下来：本地 LAN 源、远端目的，以及 IPsec 策略保护的确切地址对。要在修改规则之前完成，因为这组信息决定了应当匹配哪条分类器或 NAT 规则。

然后找出实际匹配的规则，而不是你以为会匹配的那条。两个平台的 NAT 都按顺序评估，在你查看例外之前，前面的规则可能已经命中。看起来正确的例外如果输给另一条规则，就永远不会把期望的数据包交给保护策略。症状与缺少例外完全一样，所以必须先读规则顺序再改配置。

ASA 的 identity NAT 是规则，不是绕过

在 ASA 上，identity NAT 是一条转换后地址等于原地址的 NAT 规则。它与其他规则一样被选中，并且仍然安装转换表项，因此数据包并没有跳过 NAT 处理；改变的只是线路上的地址保持不变，而这正是 IPsec 策略需要的。

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

规则涉及的接口与 route-lookup 设置必须与转发设计一致。地址映射正确但套用在错误接口对上的规则不会被你的流量选中。route-lookup 决定转换后的数据包是走路由还是沿用原目的地址，这直接决定回程流量能否从隧道返回。

对 ASA 本身的管理访问是另一回事。若管理流量使用 identity NAT，则适用与版本相关的 route-lookup 要求，从 VPN 示例里抄来的宽泛例外并不能修好 SSH。

IOS NAT ACL 中的 deny 表示此处未被选中

在 IOS 上，互联网 NAT 由源列表驱动，该 ACL 是分类器而不是过滤器。permit 行把流量选入转换；deny 行表示该数据包在此处未被选中。这个 deny 并不像接口 ACL 里的 deny 那样表示丢弃数据包。

此处未被选中也比任何地方都不转换的范围更窄。另一条 NAT 规则、另一个接口或 route-map 仍可能转换该流量，所以要读完整的 NAT 表。数据包仍然需要路由、匹配的 crypto ACL，以及在真实访问控制边界上的放行。

最小的 IOS 配置把 deny 放在同一列表的 permit 之上，并让 overload 规则指向该列表。这样 crypto ACL 保护的就是 deny 排除转换的那一对地址。

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

两种模型共用的一个可验证问题

两种模型回答同一个问题：哪条规则匹配了这条流量，哪些地址离开了接口？在外侧接口抓包，比较网关前后的源地址。然后检查对端对隧道的视角，因为 SA 可能已经建立，而受保护的流量却在别处被转换。

在 ASA 上查看 nat detail 与转换表；在 IOS 上查看 ip nat translations 与对应的 ACL 计数器。完全不增长的规则从未被选中，这说明问题在顺序、接口或方向，而不是 crypto 配置。

配置通常错在哪里

常见故障都是机械性的：deny 排在 permit 之下因而永不命中；分类器被用在错误方向，导致回程流量被转换；identity 规则覆盖了正确地址却用错接口对；crypto ACL 保护的子网已与 NAT 规则呈现的地址不一致。

把原始地址对与呈现地址对记录在规则负责人旁边，让下一位工程师明白为什么分类器拒绝转换、而防火墙却放行应用。要写进变更单，而不是私人笔记。之后每次改动 NAT 都要重跑流量，因为即使规则文本未变，规则顺序也是配置的一部分。隧道起来并不能证明地址得以保留，只有抓到的数据包与对端解封装后的视角才是证据。