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

开心123

　　NAT Server基础篇放出来后，论坛的小伙伴大呼不过瘾。为了感谢大家的支持，强叔挑灯夜战，总算是把三十二字真言的前半段内容给赶制出来了。还记得真言前十六个字的内容吗？—— 一正一反，出入自如；去反存正，自断出路。
　　一正一反，出入自如
　　
　　所谓入，是指公网用户访问私网服务器；所谓出，是指私网服务器主动访问公网。下面强叔就要向大家展示下防火墙配置NAT Server后，如何做到公网用户和私网服务器之间的出入自如。以下内容继续围绕基础篇中的组网和配置来展开。

http://support.huawei.com/ecommunity/showimage-10083227-10118533-da72a17b8ecc03964567a8a40d244ccd.jpg

　　[FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80                       
　　在基础篇中强叔展示给大家的Server-map表项其实还隐藏了一部分，完整的表项应该是这样的：

http://support.huawei.com/ecommunity/showimage-10083229-10118533-8020f38c93970e6351e96699a6576b5b.jpg

　　Nat Server, any -> 1.1.1.1:9980[10.1.1.2:80]为正向Server-map表项，其作用为入。在公网用户访问服务器时对报文的目的地址做转换。
　　Nat Server Reverse, 10.1.1.2[1.1.1.1] -> any为反向Server-map表项，其作用为出。当私网服务器主动访问公网时，可以直接使用这个表项将报文的源地址由私网地址转换为公网地址，而不用再单独为服务器配置源NAT策略。这就是防火墙NAT Server做的非常贴心的地方了，一条命令同时打通了私网服务器和公网之间出入两个方向的地址转换通道。
　　请注意强叔此处的用词，通道前面加上了“地址转换”四个字。没错，不论是正向还是反向Server-map表项，都仅能实现地址转换而已，并不能像ASPF的Server-map表项一样打开一个可以绕过安全策略检查的临时通道。因此，公网用户要能访问私网服务器或者服务器要能访问公网，还需要配置正确的域间安全策略。
　　去反存正，自断出路
　　
　　顾名思义，去反存正就是删除反向Server-map表项。配置NAT Server时带上no-reverse参数就能让生成的Server-map表项只有正向没有反向。
　　[FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80 no-reverse               

http://support.huawei.com/ecommunity/showimage-10083249-10118533-8a3b8d962f91ff42f7cbbf71065dad8e.jpg

　　没有了反向Server-map表项，也就相当于断去了服务器到公网的出路。那何时需要自断出路呢？首先，让我们来看看下面这个案例。

http://support.huawei.com/ecommunity/showimage-10083247-10118533-3f32f39ae80a2e09b804bf9671be0101.jpg

　　上图中总部有一台服务器需要提供给公网用户访问，于是在总部防火墙上配置了如下的NAT Server：
　　[FW] nat server protocol tcp global 1.1.1.1 9980 inside 192.168.1.2 80                     
　　同时，总部和分支之间通过IPSec ***实现互访。总部防火墙IPSec的部分配置如下：
　　#
　　acl number 3000      //*定义需要进行IPSec封装的数据流*//                              
　　rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 10.0.0.0 0.0.0.255               
　　#                                                                             
　　ipsec policy map1 10 manual                                                      
　　security acl 3000    //*引用acl，只有符合acl3000的数据流才会被送入IPSec隧道封装*//         
　　proposal tran1                                                                 
　　…                                                                           
　　因为总部192.168.1.0/24网段员工需要访问公网，所以还配置了如下的源NAT策略：
　　#                                                                             
　　nat-policy interzone trust untrust outbound                                          
　　policy 5                                                                     
　　action source-nat                                                              
　　policy source 192.168.1.0 mask 24                                                
　　easy-ip GigabitEthernet0/0/1                                                   
　　不过仅配置这条源NAT策略是不够的。因为这条源NAT策略会将trust区域中192.168.1.0/24网段发往untrust区域的所有报文的源地址都转换成GE0/0/1接口的地址1.1.1.1。熟悉IPSec的小伙伴们应该知道，报文源地址如果变成了1.1.1.1，就不会匹配到ACL 3000，也就不会进入IPSec隧道进行封装，这样总部就别想通过IPSec ***和分部之间通信了。所以，除了上面这条源NAT策略，还需要配置一条对总部访问分部的流量不做源地址转换的NAT策略，具体如下：
　　#                                                                              
　　nat-policy interzone trust untrust outbound                                         
　　policy 0                                                                     
　　action no-nat                                                                  
　　policy source 192.168.1.0 mask 24                                                
　　policy destination 10.0.0.0 mask 24                                               
　　注意：上面两条源NAT策略，policy0的匹配条件要比policy5更加严格，所以配置完成后需要确认策略列表中policy0在policy5之上。否则报文匹配到条件宽松的policy5后就直接做了源地址转换，而不会再匹配到policy0了。
　　配置完成后，我们发现了一个很奇怪的现象：分部的员工可以访问总部服务器的私网地址192.168.1.2，总部192.168.1.0/24网段的员工也能正常和分部的10.0.0.0/24网段通信。但总部的服务器却无法访问分部10.0.0.0/24网段的资源，删除NAT Server配置后就能正常访问。
　　很明显，问题就出在NAT Server上，但因为总部的服务器需要提供给公网用户访问，我们不能随意将NAT Server配置去掉，那该如何解决这个问题呢？下面就让强叔来给小伙伴们分析下根因所在并给出解决办法。
　　总部Server ping分部PC时，总部的防火墙上可以看到这样一条会话：
　　 display firewall session table source inside 192.168.1.2                           
　　icmp  ***:public --> public 192.168.1.2:512[1.1.1.1:512]-->10.0.0.2:2048               
　　可以看出，防火墙将报文的源地址由192.168.1.2转变成了1.1.1.1。但我们明明已经配置了一条对192.168.1.0/24网段发往10.0.0.0/24网段的报文不做源地址转换的NAT策略啊，为什么源地址还是被转换了呢？
　　我们先使用display nat-policy all命令来查看和确认下源NAT策略的命中情况：

http://support.huawei.com/ecommunity/showimage-10083251-10118533-841fedf6d4cc8bed4066d39d8def45a6.jpg

　　结果显示，确实没有报文命中源NAT策略。
　　接下来，让我们取消NAT Server的配置，再次从总部Server ping分部的PC1，并查看源NAT策略的命中情况。这时你会发现，有报文命中源NAT策略了！

http://support.huawei.com/ecommunity/showimage-10083253-10118533-ee6b60f876e040f8058c41a05378bc4c.jpg

　　所以，肯定是配置NAT Server时引入的什么东东先把地址给转换了，导致匹配不到源NAT策略。说到这里，再联想下真言的前八个字，相信小伙伴们已经知道问题所在了吧。没错，幕后的“黑手”正是NAT Server生成反向Server-map表项：
　　Nat Server Reverse, 192.168.1.2[1.1.1.1] -> any, Zone: ---                              
　　防火墙的报文处理流程中，反向Server-map表项是比源NAT策略优先匹配的，报文匹配到反向Server-map表项后，源地址被转换为1.1.1.1。这样，报文就不再满足源NAT策略的条件，也就不会命中源NAT策略了。
　　找到问题的根因所在，解决办法也就有了。配置NAT Server时加上no-reverse参数，不生成反向Server-map表项就可以了。
　　[FW] nat server protocol tcp global 1.1.1.1 9980 inside 192.168.1.2 80 no-reverse           
　　当然，no-reverse参数不仅限于这个场景中使用，后面我们还会提到它。小伙伴们只需要记住配置了这个参数后，就不会生成反向Server-map表项这一结论，再根据遇到的具体问题灵活运用即可。
　　以上就是三十二字真言前半段的所有内容了，不知小伙伴们是否领悟到了其中的真谛？下一期强叔将会向大家解释后半段的含义，敬请期待。