学校或公司的私网通常会有一些服务器需要提供给公网用户访问。但网络部署时，服务器地址一般都会被配置成私网地址，这样服务器就不能直接使用自身的地址来提供服务了。那么，防火墙作为学校或企业的出口网关时，是如何应对这个问题的呢？
如果小伙伴们有读过强叔的源NAT篇，聪明的你一定会想到，防火墙是不是也可以将服务器的私网地址通过NAT转换成公网地址来提供服务呢？
Bingo！你的大方向已经对了。不过，源NAT是对私网用户访问公网的报文的源地址进行转换，而服务器对公网提供服务时，是公网用户向私网发起访问，方向正好反过来了。于是，NAT转换的目标也由报文的源地址变成了目的地址。针对服务器的地址转换，我们赋予了它一个形象的名字――NAT Server（服务器映射）。
下面来看下防火墙上的NAT Server是如何配置和实现的。
在防火墙上配置如下命令，就能将上图中服务器的私网地址10.1.1.2映射成公网地址1.1.1.1。
[FW] nat server global 1.1.1.1 inside 10.1.1.2
但是，如果一台服务器同时存在多种协议和端口的服务项，按照上述配置会将服务器上所有服务项都发布到公网，这无疑会带来很大的安全风险。华为防火墙支持配置指定协议的NAT Server，只将服务器上特定的服务项对公网发布，从而避免服务项全发布带来的风险。例如，我们可以按如下方式配置，将服务器上80端口的服务项映射为9980端口供公网用户访问。
[FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80
这里将80端口映射为9980端口而不是直接映射为80端口是因为，一些地区的运营商会阻断新增的80、8000、8080端口的业务，从而导致服务器无法访问。
小伙伴们是否还记得《安全策略篇 ASPF：隐形通道》中提到的Server-map表，NAT server配置完成之后，也会生成Server-map表来保存映射关系。不过与ASPF Server-map表项的动态老化不同的是，NAT Server的Server-map表项是静态的，只有当NAT Server配置被删除时，对应的Server-map表项才会被删除。
上图就是NAT Server的Server-map表项。图中红框标注的字段就记录着服务器私网地址端口和公网地址端口的映射关系。[]内为服务器私网地址和端口、[]外为服务器公网地址和端口。我们将表项翻译成文字就是：任意客户端（any）向（->）1.1.1.1:9980发起访问时，报文的目的地址和端口都会被转换成10.1.1.2:80。具体的流程如下：
当客户端通过1.1.1.1:9980访问服务器时，防火墙收到报文的首包后，首先是查找并匹配到Server-map表项，将报文的目的地址和端口转换为10.1.1.2:80。然后根据目的地址判断出报文在哪两个安全区域间流动，报文通过域间安全策略检查后，防火墙会建立如下的会话表，并将报文转发到私网。
之后，服务器对客户端的请求做出响应。响应报文到达防火墙后匹配到上面的会话表，防火墙将报文的源地址和端口转换为1.1.1.1:9980，而后发送至公网。后续客户端继续发送给服务器的报文，防火墙都会直接根据会话表对其进行地址和端口转换，而不会再去查找Server-map表项了。
在防火墙的前后抓包，能很清楚地看到NAT Server的效果：
A、转换客户端发往服务器的报文的目的地址和端口。
B、转换服务器响应客户端的报文的源地址和端口。
以上就是防火墙NAT Server的基本配置和工作原理，通过强叔的讲解，小伙伴们想必已掌握其中的奥妙了吧。
但这些仅仅是NAT Server的基础知识，知道这些只能算是初窥门径。要想成为能从容应对现网中各种NAT Server配置的顶级高手，小伙伴们还需要研习并掌握强叔自创的NAT Server三十二字真言：
一正一反，出入自如 去反存正，自断出路
一分为二，源进源回 虚实变换，合二为一
所谓入，是指公网用户访问私网服务器；所谓出，是指私网服务器主动访问公网。下面强叔就要向大家展示下防火墙配置NAT Server后，如何做到公网用户和私网服务器之间的出入自如。以下内容继续围绕基础篇中的组网和配置来展开。
[FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80
在基础篇中强叔展示给大家的Server-map表项其实还隐藏了一部分，完整的表项应该是这样的：
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
没有了反向Server-map表项，也就相当于断去了服务器到公网的出路。那何时需要自断出路呢？首先，让我们来看看下面这个案例。
上图中总部有一台服务器需要提供给公网用户访问，于是在总部防火墙上配置了如下的NAT Server：
[FW] nat server protocol tcp global 1.1.1.1 9980 inside 192.168.1.2 80
同时，总部和分支之间通过IPSec VPN实现互访。总部防火墙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 VPN和分部之间通信了。所以，除了上面这条源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时，总部的防火墙上可以看到这样一条会话：
<FW> display firewall session table source inside 192.168.1.2
icmp VPN: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策略的命中情况：
结果显示，确实没有报文命中源NAT策略。
接下来，让我们取消NAT Server的配置，再次从总部Server ping分部的PC1，并查看源NAT策略的命中情况。这时你会发现，有报文命中源NAT策略了！
所以，肯定是配置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 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表项这一结论，再根据遇到的具体问题灵活运用即可。
