撞衫不可怕，谁丑谁尴尬。网络世界也一样，撞网段才真叫人头大！

上次我们用子接口实现了VRF流量汇聚（避免路由泄露，不同VPN实例间流量怎么互通？），但忽略了一个经典场景：三个租户的内网网关IP网段一模一样！这就像让邮差分发三个都叫幸福里1号楼101室的包裹，根本无从下手。怎么办？

毕竟在公有云场景中，租户的私网网段重合是常事，那怎么解决呢？

解决思路其实很简单：既然IP地址重名导致无法路由，那我们就在POP设备上给它们分别套上不同的马甲（做NAT地址转换），再送往下一程。这样，在GW看来，流量来自三个不同的、无冲突的网段，路由问题自然迎刃而解。”

组网需求

RT1-RT3分别对应3个内网网关，内网网段相同，均为192.168.1.0/24网段。用户流量在POP上通过VRF进行隔离，同时需要经过GW设备访问SRV服务器。

组网图

VRF路由互通组网图。

实验环境

Windows 10专业版（1909-18363.1556，16 GB内存）HCL 3.0.1MSR 36-20（Version 7.1.064, Release 0821P11）

配置步骤

首先按照组网需求和组网图所示配置各接口的IP地址和掩码，POP设备的接口GE0/1、GE0/2、GE5/0分别绑定VPN实例RT1、RT2和RT3。

对应的子接口下面增加nat outbound配置。

整体没有什么难点，直接上设备配置：

POP

# sysname POP#ip vpn-instance RT1 route-distinguisher 11:11 vpn-target 11:11 import-extcommunity vpn-target 11:11 export-extcommunity#ip vpn-instance RT2 route-distinguisher 22:22 vpn-target 22:22 import-extcommunity vpn-target 22:22 export-extcommunity#ip vpn-instance RT3 route-distinguisher 33:33 vpn-target 33:33 import-extcommunity vpn-target 33:33 export-extcommunity#interface GigabitEthernet0/0ip binding vpn-instance RT1 ip address 192.168.1.1 255.255.255.0#interface GigabitEthernet0/1ip binding vpn-instance RT2 ip address 192.168.1.1 255.255.255.0#interface GigabitEthernet0/2ip binding vpn-instance RT3 ip address 192.168.1.1 255.255.255.0#interface GigabitEthernet5/0.1 ip binding vpn-instance RT1 ip address 10.2.1.2 255.255.255.0 nat outbound vpn-instance RT1 vlan-type dot1q vid 10#interface GigabitEthernet5/0.2 ip binding vpn-instance RT2 ip address 10.2.2.2 255.255.255.0 nat outbound vpn-instance RT2 vlan-type dot1q vid 20#interface GigabitEthernet5/0.3 ip binding vpn-instance RT3 ip address 10.2.3.2 255.255.255.0 nat outbound vpn-instance RT3 vlan-type dot1q vid 30# ip route-static vpn-instance RT1 0.0.0.0 0 10.2.1.1 ip route-static vpn-instance RT2 0.0.0.0 0 10.2.2.1 ip route-static vpn-instance RT3 0.0.0.0 0 10.2.3.1

GW

#interface GigabitEthernet0/0.1 ip address 10.2.1.1 255.255.255.0 vlan-type dot1q vid 10#interface GigabitEthernet0/0.2 ip address 10.2.2.1 255.255.255.0 vlan-type dot1q vid 20#interface GigabitEthernet0/0.3 ip address 10.2.3.1 255.255.255.0 vlan-type dot1q vid 30#interface GigabitEthernet0/1 ip address 10.3.1.2 255.255.255.0 nat outbound

SRV

#interface GigabitEthernet0/0 ip address 10.3.1.1 255.255.255.0

验证配置

此时我们先查看POP设备的VRF路由表信息。

在查看GW设备的路由表信息，因为在POP设备上开启了NAT，所以GW设备上也就不需要添加静态路由了，配置量有所降低。

是骡子是马，拉出来遛遛！配置完毕，最关键的一步——验证。分别从RT1、RT2、RT3向服务器发起Ping测试。

叮！叮！叮！三个回复如期而至，访问都是正常的，全部成功！NAT方案首战告捷。

看一下转发路径。

货比三家，方知优劣。和上次的方案对比一下，可以发现今天的VRF+NAT组合拳方案有两个核心优势：

1、化繁为简。配置同样是主要集中在POP设备上，这次GW设备上不需要增加回程路由了，工作量有少量减少，更适用于对端设备不希望或无法配合添加大量回程路由的场景。

2、一劳永逸。之前的两个方案都需要增加限制策略限制互访，而使用了NAT地址转换之后，不仅解决了地址冲突，更一劳永逸地避免了繁琐的互访限制策略配置，实现了配置即隔离，对于私网网段是相同的还是不同的也不再关注。四两拨千斤，莫过于此。

不过有一个配置的关键点需要注意，你可能也发现了，配置NAT的命令是nat outbound vpn-instance RT1，增加VPN实例名称用于指定地址组中的地址所属的VPN实例。如果不指定VPN实例名称，则表示地址组中的地址不属于任何一个VPN实例，也就是NAT会话在全局表项中，报文可以出去，但回就回不来了。通过debug可以看到。

这种VRF + NAT的组合拳，不仅是解决地址重叠的利器，更是构建多租户网络隔离与互通模型的经典范式。当然，NAT指定VPN实例也可以实现流量的跨VRF互访，这不是本次研究的重点，就不再赘述了。