NAT篇 NAT Server 三十二字真言（下篇）

师傅你而

　　本期强叔将会给大家阐释三十二字真言的后半段：一分为二，源进源回；虚实变换，合二为一。
　　一分为二，源进源回
　　防火墙作为出口网关，双出口、双ISP接入公网时，配置NAT Server通常需要一分为二，让一个私网服务器向两个ISP发布两个不同的公网地址供访问。一分为二的方法有两种：
　　第一种是将接入不同ISP的公网接口规划在不同的安全区域中，配置NAT Server时，带上zone参数，使同一个服务器向不同安全区域发布不同的公网地址。
　　[FW] nat server zone untrust1 protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80            
　　[FW] nat server zone untrust2 protocol tcp global 2.2.2.2 9980 inside 10.1.1.2 80            

http://support.huawei.com/ecommunity/showimage-10083617-10118533-dd1a19208b0b8d39ba4571e8620abc0b.jpg

　　第二种是将接入不同ISP的公网接口规划在同一个安全区域中，配置NAT Server时，带上no-reverse参数，使同一个服务器向同一个安全区域发布两个不同的公网地址。
　　[FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80 no-reverse              
　　[FW] nat server protocol tcp global 2.2.2.2 9980 inside 10.1.1.2 80 no-reverse              
　　http://support.huawei.com/ecommunity/showimage-10083619-10118533-56bd4e27351eaa004d89d2ae0a5647e2.jpg
　　
　　看到这里小伙伴们就要问了，强叔强叔，上一期中你不是讲过no-reverse参数是用来除去反向Server map表项自断出路的吗，这里怎么又用到了呢？莫急莫急，且听强叔给你慢慢道来。
　　首先，我们来看下不带no-reverse参数直接配置上面两条命令会发生什么？
　　答案是不带no-reverse参数这两条命令压根就不能同时下发。

http://support.huawei.com/ecommunity/showimage-10083623-10118533-6c182710cfdfc5c7196b054bf2237585.jpg

　　我们再尝试着逆向思考下，假如这两条命令能同时下发，会发生什么？
　　将上面的两条命令分别在两台防火墙上配置，然后查看各自生成的Server map表项。

http://support.huawei.com/ecommunity/showimage-10083625-10118533-f9609fb1219cb6f55249e51be1dc00bc.jpg

http://support.huawei.com/ecommunity/showimage-10083627-10118533-559b5c550bbe6bdd90850ebb7e14b54b.jpg

　　很容易看出来，一台防火墙上的反向Server map表项是将报文的源地址由10.1.1.2转换为1.1.1.1，另一台防火墙上的反向Server map表项是将报文的源地址由10.1.1.2转换为2.2.2.2。试想下，如果这两个反向Server map表项同时出现在一台防火墙上会发生什么？——防火墙既可以将报文的源地址由10.1.1.2转换为1.1.1.1，又可以转换为2.2.2.2。于是乎，防火墙凌乱了~这就是两条命令不带no-reverse参数同时下发会带来的问题。如果配置时带上no-reverse参数，就不会生成反向Server map表项。没有了反向Server map表项，上述的问题也就不复存在了。
　　此外，一分为二时还会存在报文来回路径不一致的问题。例如，公网用户通过防火墙发布给ISP1的公网地址1.1.1.1访问服务器，服务器的响应报文到达防火墙后，防火墙根据目的地址查找路由表，可能会将响应报文由ISP2发送出去，这样就会导致访问速度过慢或无法访问。
　　为了避免这个问题，还需要在防火墙上增加一些的配置，保证报文的源进源回，即请求报文从某条路径进入，响应报文依然沿着同样的路径返回。

http://support.huawei.com/ecommunity/showimage-10083629-10118533-b17e7c15b1893fa678903bfc3cfcbc80.jpg

　　USG9000系列防火墙源进源回功能是通过在公网接口下配置redirect-reverse命令来实现的。例如上图中接入IPS1的公网接口GE1/0/1的源进源回功能配置如下：
　　[FW] interface GigabitEthernet 1/0/1                                                                        
　　[FW-GigabitEthernet1/0/1] redirect-reverse next-hop 1.1.1.254                          
　　配置完成后，如果请求报文从GE1/0/1进入，则响应报文也强制从GE1/0/1发出，而不再是通过查找路由表来确定出接口。
　　USG2000/5000/6000系列防火墙源进源回功能配置思路与USG9000系列相同，配置命令为reverse-route next-hop next-hop-address。
　　虚实变换，合二为一
　　为了让小伙伴们能明白“虚实”二字的含义，需要大家随着强叔穿越到未来的双机热备站，提前了解一点双机热备的知识。
　　如下图所示的双机热备组网中，两台防火墙并不是直接使用GE0/0/1接口的实IP地址与公网通信，而是将GE0/0/1接口加入一个VRRP备份组，使用VRRP备份组的虚拟IP地址与公网通信。配置虚拟IP地址的同时，防火墙会自动为其生成一个虚MAC地址。

http://support.huawei.com/ecommunity/showimage-10083631-10118533-9f442040c634b251b0aa0bfa7c1e2b92.jpg

　　让我们再回到NAT站，强叔这里所说的 “实”指的就是物理接口的实MAC地址，“虚”指的就是虚MAC地址。
　　明白“虚实”的含义后，接下来强叔就要讲讲“虚实”在对NAT Server配置的影响。
　　首先，小伙伴们需要知道这样一个结论：当NAT Server公网地址与公网接口的地址在同一个网段时，防火墙会发送NAT Server公网地址的免费ARP请求报文。我们使用如下组网进行演示：

http://support.huawei.com/ecommunity/showimage-10083633-10118533-610368007af758bcfb30dec78df8fabe.jpg

　　NAT Server的配置如下：
　　[FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80                       
　　在图示处抓包，可以看到防火墙发送的NAT Server公网地址的免费ARP请求报文。报文中携带的1.1.1.1的MAC地址为0000-00e0-bb01，正是公网接口GE0/0/1的MAC地址。

http://support.huawei.com/ecommunity/showimage-10083635-10118533-8068bcad7fa3b3207968fc7a4285ab68.jpg

　　我们在eNSP上模拟了前面的双机热备组网，并在FW1（主设备）上配置了NAT Server：
　　[FW1] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80                     

http://support.huawei.com/ecommunity/showimage-10083637-10118533-b44d08404a651dc2ddf24b973affc9d9.jpg

　　命令一下发，设备就打印如下的IP地址冲突日志：
　　2014-05-11 10:02:22 FW1%%01ARP/4/DUP_IPADDR(l): Receive an ARP packet with
　　duplicate ip address 1.1.1.1 from GigabitEthernet0/0/1, source MAC is 0000-003a-f701!
　　日志中显示冲突源的MAC地址为0000-003a-f701，这个正是FW2的GE0/0/1接口的MAC。稍作分析，就能明白为什么会发生IP地址冲突了。
　　FW1上配置了NAT Server后，由于公网地址为1.1.1.1，和GE0/0/1接口的地址（1.1.1.2/24）在同一个网段，FW1会发送1.1.1.1的免费ARP请求报文。报文中携带的1.1.1.1的MAC地址为GE0/0/1接口的MAC 0000-0006-1901。同时，因为FW1和FW2处于双机热备状态，FW1上NAT Server的配置会同步到FW2上，而FW2 GE0/0/1接口的地址（1.1.1.3/24）和NAT Server公网地址也在同一个网段，这样FW2也会发送1.1.1.1的免费ARP请求报文。报文中携带的1.1.1.1的MAC地址为GE0/0/1接口的MAC 0000-003a-f701。于是，同一广播域中有两个MAC地址对应着同一个IP地址1.1.1.1，产生了IP地址冲突。
　　同时，由于FW1和FW2同时发送免费ARP请求报文，上行设备学习到的1.1.1.1的MAC也会在0000-0006-1901和0000-003a-f701之间不停的切换。如下图就是Client上查看到的ARP表项。

http://support.huawei.com/ecommunity/showimage-10083641-10118533-3a4d039689953f2dc243309decc5f0cd.jpg

　　这样，从Client上访问1.1.1.1时，Client的网卡会时而用0000-0006-1901来封装报文，时而用0000-003a-f701来封装报文。如果用0000-0006-1901来封装报文，则报文会被发往FW1（主设备），业务访问正常。如果用0000-003a-f701来封装报文，则报文会被发往FW2（备设备）。由于FW2作为备设备时是不处理业务的，报文到达FW2后就会被丢弃。于是就会出现业务时通时不通的情况。
　　在配置命令中加上vrrp关键字就能解决这个问题。我们按如下命令重新配置：
　　[FW1] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80 vrrp 1
　　首先，设备上不再打印IP地址冲突日志了。在防火墙和上行交换机之间抓包我们会发现，只有主用防火墙会发送免费ARP报文，且报文中携带的1.1.1.1的MAC地址变成了0000-5e00-0101，VRRP备份组1的虚MAC地址。Client访问1.1.1.1时，网卡会使用0000-5e00-0101来封装报文。这样就能保证报文永远都是向主用设备转发了。是为虚实变换之间，合二为一也。

http://support.huawei.com/ecommunity/showimage-10083643-10118533-ff758d5d892717f304ca3f2a284c8902.jpg

　　至此，NAT Server的三十二字真言阐释完毕。通过强叔的讲解，相信小伙伴们对NATServer的正反Server-map表项作用，配置命令中的两个重要的参数no-reverse、vrrp的使用方法，以及多出口NAT Server的配置等都有了更加全面和深入的了解了吧。