IOS VPN 出口上 NAT 的内外角色分别落在哪个接口

沿着虚拟接口到上行链路，跟踪解密后的客户端数据包。转换应作用于这条内层流量，而不是隧道的外层传输。

提供全隧道互联网出口的路由器同时做两件看起来像一件的事。它终止隧道，并把解密后的客户端数据包转发到互联网。只有第二件事需要转换，而且转换必须匹配内层流量。这一区别决定了哪些接口承担 NAT 角色，以及规则中出现哪个地址范围。

跟着一个数据包穿过路由器

假设位于 10.90.0.25 的客户端正在打开一个公共 HTTPS 服务。该目的地是否会进入隧道，由客户端自己的策略决定。一旦进入，路由器解密数据包并把它交给虚拟接口，再从那里路由到公网上行链路。

该虚拟接口就是转换的内侧。公网上行链路是外侧。如果角色颠倒或缺失，数据包要么带着私有源地址出去，要么在转换之前被丢弃。

StageQuestion to answer
VPN clientDoes the client's policy put this destination inside the tunnel?
Decrypted ingressWhich virtual interface receives the inner packet?
Internet egressWhich route, access policy and source translation apply?
ReplyIs the client's flow translated back before it is delivered over the tunnel?

让转换策略匹配客户端地址池

NAT 规则必须写明客户端实际获得的地址范围，而不是恰好共用上行链路的办公 LAN。只覆盖本地子网的规则会漏掉远程客户端，即使两者都从同一个接口出去。

ip access-list extended NAT-TUNNEL
 permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overload

把私有站点的例外单独保留。发往内部目的地的流量 必须保留其原始源地址，否则目的地会向一个它无法到达的地址回复，回程就会以看起来像路由环路的方式失败。

把角色应用到实际部署设计中的真实接口上。从旧 Easy VPN 答案里抄来的 Virtual-Template 片段并不是完整的当前配置，而所用的隧道类型决定了哪个接口接收解密后的数据包。

把外层传输和内层转换分开

转换解密后的应用源地址，与把 IKE 或受保护数据包推过上游 NAT 设备不是同一种操作。前者改变互联网看到的客户端请求源；后者让隧道穿过中间设备保持存活。

把两者混为一谈会产生两种典型故障。转换自身隧道传输的路由器会破坏对等关系，而从不转换内层流量的路由器会把私有地址转发到互联网。改规则之前先读清你面对的是哪条流量，并检查改动之后隧道是否仍然保持。一条修好了浏览却弄断隧道的规则，只是把问题挪了地方，并没有解决它。

这两种故障都不能靠改另一个来修复。改规则之前先读清你面对的是哪条流量。

在两个边界上都做验证

在互联网边界读取应用源，在回程读取被还原的目的地。前者告诉你转换是否发生；后者告诉你反向映射是否回到了正确的客户端。

然后测试一个走已批准的拆分隧道路径的客户端。该客户端从不经过这台路由器的互联网转换，所以它的表现应该不同，而差异正好确认流量走了哪条路径。

如果两个客户端表现完全相同，说明拆分隧道策略并没有按设计执行。在添加更多转换规则之前先修好这一点，因为为一条未使用的路径写规则只会掩盖真正的问题。

相关文章