技术背景：
在很多场景中，比如企业、学校、甚至家里都有一些对外访问的业务提供，比如门户网址、NAS、ERP等，在实际部署中，这些提供访问的服务器都属于内网内，配置的是内网地址，导致的情况是公网用户没法对私网地址直接进行访问，学过上篇内容的源NAT功能是把私网用户的源地址转换成可上网的地址（当然可上网的就分私网跟公网了，由运营商分配的）然后发送出去，那么NAT Server的作用正好相反， 它是当其他公网用户访问我们服务的公网地址时候，进行目的地址转换（注意一定要是公网地址），在华为防火墙里面的这个功能叫做—NAT server（服务器映射），可能大家都奇怪，为什么标题里面有端口映射、甚至DMZ，这个主要是各个厂商的叫法不一样，可能客户只会某一种叫法，导致在了解需求的时候，有点懵！
不过不要紧，学完本篇后就都会很清晰了，下面来看看多个场景下使用什么样的技术。
NAT Server之一对一映射：
这里先说下一对一映射的功能的作用，它是完全把这个地址映射给内网的某个服务器地址，一旦映射后，当有人访问这个公网的任何服务，注意这里说的是任何（比如HTTP、FTP、ping）都原封不动的丢给映射后的服务器，先来感受下，然后博主来说说在什么场景下建议使用，以及注意什么。
环境比较简单，在互联网的另外一边有路人甲用户需要访问左边服务器提供的FTP、HTTP服务，由于服务器配置的是私网192.168.10.1的地址，需要防火墙做NAT server，把202.100.1.12映射到192.168.10.1，这时候外网用户只需要访问202.100.1.12即可。
基础的对接：
#interfaceGigabitEthernet1/0/0 undo shutdown ip address 192.168.10.254 255.255.255.0#interfaceGigabitEthernet1/0/1 undo shutdown ip address 202.100.1.11 255.255.255.0#ip route-static 0.0.0.00.0.0.0 202.100.1.1#firewall zone untrust set priority 5 add interface GigabitEthernet1/0/1#firewall zone dmz set priority 50 add interface GigabitEthernet1/0/0#一对一映射配置： [USG6000V1]natserver global 202.100.1.12 inside192.168.10.1 没错就一条命令，非常的简单的，难点就在于，安全策略如何放行，之前博主介绍过一个解决方法，在不知道如何放行安全策略的时候，直接把默认安全策略改为permit。 临时安全策略放行：[USG6000V1]security-policy[USG6000V1-policy-security]default action permit
实际测试：
通了，配置非常非常的简单，但我们需要了解的不单单是配置，而是它为什么通的，策略应该如何去放行。
看会话表似乎看不出来什么，跟源NAT一样，一对一映射的202.100.1.12被转换成了192.168.10.1，安全策略还是不知道如何放行，我们来看一个神奇的地方！
神奇不神奇？服务器能够直接上外网，转换的是202.100.1.12出去的，但是博主这里是没有配置任何的源NAT策略的，只有一对一的映射配置，这里就要说一下 NAT server配置后，它会生成server-map表，这个表项在学习多通道协议的时候遇见过，来看看NAT Server 生成的server-map表有哪些内容。
与多通道协议生成的server-map不一样的地方，可以发现这个表项是没有时间的，也就是说是静态的，只要配置了nat server，那么就会自动生成表项，细心的会发现，这里有两个表项。
(1)正向 server-map表，Type: Nat Server, ANY ->202.100.1.12[192.168.10.1], , 这个的意思是什么呢，当任意地址（any）向（->）202.100.1.12发起访问的时候，报文的目的地址和端口号会被转换成192.168.10.1，包括端口号，这个的作用就是当公网用户访问服务器时能够正常的进行目的地址转换，完成映射。
(2)反向server-map表，Type: Nat Server Reverse, 192.168.10.1[202.100.1.12] -> ANY，这个的作用是当私网192.168.10.1主动发起访问外网的时候，直接可以通过该反向表转将源地址转换成202.100.1.12，从而能够让私网用户访问外网的操作，不需要在单独的做源NAT策略。也就是一旦配置了nat server后，一条命令同时打通了两个方向的地址转换。
（3）注意的是这里的server-map仅仅是转换的功能，并没有绕过安全策略的通道，所以可以发现在会话表里面不管是外网访问服务器的地址，还是内网服务器主动访问外网，都能够匹配上default的安全策略。 但是这里博主说下，nat server的server-map虽然不能过绕过安全策略，但是它处理的流程还是一样的优先查看server-map表，明白了这个，把整体流程整理下就应该知道如何放行安全策略了。
整体的流程就是，公网的某个路人甲用户（61.128.0.1）发起对于202.100.1.12的WWW或者FTP的访问，防火墙收到这个报文后首先会匹配server-map表，发现有匹配项，直接把202.100.1.12转换成了192.168.10.1，然后查找路由，找到出接口，根据入与出接口所在的安全区域，得到报文在哪两个安全区域之间流动，然后进行安全策略匹配， 所以这里得到的结论就是服务器转换的过程在安全策略之前，那么安全策略放行服务器的流量的时候，则放行的是真实的服务器地址与端口号，并不需要去关心公网IP与服务是多少。
实际的安全策略配置：
[USG6000V1] security-policy
[USG6000V1-policy-security]defaultaction deny#先还原默认的策略为deny [USG6000V1-policy-security]rulename untrust_dmz[USG6000V1-policy-security-rule-untrust_dmz]source-zoneuntrust[USG6000V1-policy-security-rule-untrust_dmz]destination-zonedmz[USG6000V1-policy-security-rule-untrust_dmz]destination-address192.168.10.1 32[USG6000V1-policy-security-rule-untrust_dmz]service http[USG6000V1-policy-security-rule-untrust_dmz]service ftp[USG6000V1-policy-security-rule-untrust_dmz]actionpermit [USG6000V1-policy-security]rulename DMZ_untrust[USG6000V1-policy-security-rule-DMZ_untrust]source-zonedmz[USG6000V1-policy-security-rule-DMZ_untrust]destination-zone untrust[USG6000V1-policy-security-rule-DMZ_untrust]source-address192.168.10.1 32[USG6000V1-policy-security-rule-DMZ_untrust]actionpermit
这里配置了两个策略：
（1）第一个策略配置的是从untrust到DMZ抵达192.168.10.1的http/ftp流量放行，博主这里比较建议，实际中对外提供什么样的服务，那么安全策略就放行对应的服务端口号即可，不建议用any，一对一会把所有的端口号都映射给服务器，但是这样带来的安全隐患太大了，安全策略里面加以控制。
（2）第二个策略是配置的DMZ到untrust，让服务器能够正常的访问外网的流量。
这个时候看会话表中的安全策略已经匹配对应的了。
一对一映射使用场景、带来的问题以及跟DMZ有什么关系？
1、 先聊聊DMZ，不知道大家在家用路由器以及软路由或者是光猫里面有没有见到过有一个DMZ的配置选项，防火墙安全区域里面也有一个DMZ，博主在介绍区域的时候讲解DMZ的作用提到过，当有对外网提供服务的服务器主机的时候，可以把它放到DMZ区域，这样对内网的安全多了一层保护，那么这些家用路由器、光猫、软路由上面的DMZ实际指的是DMZ主机，当你在配置后它的作用就是跟华为防火墙的一对一映射效果是一样的，所以当客户跟你说要实现DMZ主机功能或者是DMZ映射的时候，那就是说的一对一的转换。
2、 带来的问题是什么呢？在理想的实验环境下，发现访问www/ftp这些，只要配置对了就没任何问题，但是现实环境中，往往就不一样了，就拿80、443、8080这些主流的WEB端口号来说，目前的运营商默认情况下大部分都是过滤禁止了，就是你配置了80，8080，会发现访问不成功，这个是很多刚接触网络或者在实施映射的时候最常见的一件事情，对于80、443、8080这些端口号运营商是要求你提供的WEB服务已经备案过了，这个时候运营商才会给你开通80、443、8080端口号，但是实际中往往很多比如ERP、临时测试的业务内网都是用的80端口号，没到需要备案的地步，一对一或者说DMZ带来的问题就是，外网用户发对映射地址的80访问，就会被转换到内网服务器的80，它们之间端口号是一致的，不能实现说外网访问9999，映射到内网的80这样的效果；再一个问题就是安全性问题，一对一的映射是把所有端口号都给映射出去了，比如这台服务器就对外提供了FTP服务，但是还运行了3389、iis等应用，一对一配置后，把不想对外提供的服务也给映射出去了，虽然可以通过安全策略来控制，但是实际是消耗了设备的性能的，因为中间会通过server-map表转换一次。
3、 一对一使用的场景主要是（1）公网地址特别多，内网服务器也多的情况 （2）需要映射的端口号比较多，比如10001到12500，这个时候还是比较建议用一对一来减少工作量的。
NAT Server之端口映射
端口映射从字面意思其实就容易理解，它的功能就是对需要对外提供服务的端口号已经映射发布，这样解决了一对一映射带来的问题，而且比较灵活，灵活的地方在于一对一必须内外网相同的端口号，而端口号映射则不一样，比如内网使用80、3389，而外网端口号可以自定义其他的，灵活性跟安全性都可以，唯一的缺点就是一次只能映射一条，不过华为防火墙提供了批量范围配置的功能。
还是上面的环境与配置，只是这次对外提供的只有 WWW 服务了，考虑到标准的 80 、 8888 、 8080 这些端口号被运营商禁止了，外网端口号采用非标准的端口号 9898 来进行映射。
端口映射配置:
[USG6000V1]nat server protocol tcp global 202.100.1.12 9898 inside 192.168.10.1 80
安全策略配置：
之 前一对一映射是会生成正反server-map表项，端口映射也会生成正反，但是跟一对一有点小区别，多了一个端口号。
（1）正向server-map：Type: Nat Server, ANY ->202.100.1.12:9898[192.168.10.1:80], Zone:—, protocol:tcp，这个的意思是当任何外网客户端访问202.100.1.12:9898，会把目的地址转换成192.168.10.1:80，并且规范了协议是TCP。
（2）反向server-map：Type: Nat Server Reverse, 192.168.10.1[202.100.1.12] -> ANY, Zone:—, protocol:tcp，之前一对一是允许192.168.10.1通过源地址转换成202.100.1.12出去上网，但是端口映射里面多 一个规范 protocl:tcp，那是不是异味只能访问TCP的流量呢？来验证下。
[USG6000V1] security-policy
[USG6000V1-policy-security]rulename untrust_dmz[USG6000V1-policy-security-rule-untrust_dmz]source-zoneuntrust[USG6000V1-policy-security-rule-untrust_dmz]destination-zonedmz[USG6000V1-policy-security-rule-untrust_dmz]destination-address192.168.10.1 32[USG6000V1-policy-security-rule-untrust_dmz]service http[USG6000V1-policy-security-rule-untrust_dmz]actionpermit [USG6000V1-policy-security]rulename DMZ_untrust[USG6000V1-policy-security-rule-DMZ_untrust]source-zonedmz[USG6000V1-policy-security-rule-DMZ_untrust]destination-zone untrust[USG6000V1-policy-security-rule-DMZ_untrust]source-address192.168.10.1 32[USG6000V1-policy-security-rule-DMZ_untrust]actionpermit 跟一对一映射一样，放行了内外网双方向。
实际测试：
首先公网的路人甲访问是没任何问题的，注意端口号是9898.
没通，看会话表的情况是包出去了，没有回包，没回包是正常的，因为192.168.10.1并没有被转换，那么这个私网地址跑到公网去，肯定是没法回复的，最终丢弃了，那么是不是真的只转换TCP的流量呢？
可以把客户端与服务器对换下位置，然后在来测试下。
确实TCP的流量直接被转发了，但其他协议的流量是不会转换的，所以端口映射的反向转发流量取决于protocol定义的协议来决定能否转发，如果定义的TCP，那么在没有配置源NAT策略的时候，只转换TCP流量，所以这个时候如果内网的服务器需要访问外网，建议单独配置一个源NAT策略。
nat-policy
rule name DMZ_untrust source-zone dmz destination-zone untrust source-address 192.168.10.0 mask255.255.255.0 action source-nat easy-ip
这个时候能够访问了，但是注意的是这里转换的是出接口的地址 202.100.1.11，而不是用的server-map反向直接转换的。
如果公网地址就一个怎么办呢？
在实际的场景中，很多时候公网地址只有一个，那么这一个就是会配置在接口上面，即提供源NAT功能，如果有需要对外提供服务的时候，还需要做NAT server，映射的方式是一样的，但是这里博主讲解几个需要注意的地方。
（1）能用端口映射解决的就用端口映射，不要用一对一。
（2）如果端口号非常多，只能使用一对一的方式的话，会造成防火墙本身的管理访问受影响，比如HTTPS、TELNET、SSH等，都会被映射转换。
（3）如果对接外网的方式是PPPOE方式，是动态公网IP的话，需要关联DDNS（主流的花生壳或者3322都可以），关联后，映射配置不要使用WEB配置，用命令行配置，WEB会有一个非常坑的地方，WEB关联的是地址，而不是接口，而PPPOE拨号的地址是会变化的，命令行是可以直接关联接口的，这样不管怎么变化都没关系。（这个在后面实际案例中会详细讲解，这里先提及下）。
实际案例：假设有100个端口（10501-10600）需要映射，怎么办？
如果是在UTM时代是不支持批量映射的以及在下一代防火墙早期版本也是不支持，到了后面版本（具体多少开始的查不到了），开始支持批量范围的设置了，但是现实就没这么美好，华为防火墙设备根据性能的不同，批量映射支持的范围也不一样
比如模拟器或者博主真机的6307E的低端系列测试的结果是一次性只能映射64个，超过64个提示映射的范围太大，而且会发现这些系列 nat server的条目也差不多在64个左右，多了就不让创建了，而性能好一些的创建范围在200个都没问题，但是在多就不行了，博主这里也没法给一个具体值，只能自己实践下测试或者是问华为的400。
一对一映射和端口映射如何选择？
（1）如果公网IP就一个的情况下，能使用端口映射尽量使用端口映射
（2）一对一映射比较适合在映射端口号非常多，而公网IP有多个的情况下
（3）在实在没办法只能一对一映射的情况下安全策略尽量做到精细匹配，保证业务不受影响的情况下，尽可能的保障安全。
“承上启下”
对于单一出口的场景，博主主要的内容都介绍完毕了，在实际工作中可能客户还存在这样的情况，多出口（联通、电信），这样的场景下该如何去部署NAT server功能呢？答案下篇认真学，可以解决这个疑问！~
原文链接：https://blog.csdn.net/thlzjfefe/article/details/127600115?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522168466843816800226566569%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=168466843816800226566569&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-2-127600115-null-null.blog_rank_default&utm_term=NAS%E3%80%81%E7%BE%A4%E6%99%96%E3%80%81%E9%98%BF%E9%87%8C%E4%BA%91%E3%80%81%E5%9F%9F%E5%90%8D%E8%A7%A3%E6%9E%90%E3%80%81%E5%86%85%E7%BD%91%E7%A9%BF%E9%80%8F%E3%80%81ipv6%E3%80%81ddns%E3%80%81%E8%BD%BB%E9%87%8F%E7%BA%A7%E4%BA%91%E6%9C%8D%E5%8A%A1%E5%99%A8%E3%80%81%E9%93%81%E5%A8%81%E9%A9%AC%E3%80%81%E5%A8%81%E8%81%94%E9%80%9A%E3%80%81DSM%E3%80%81DSM6.0%E3%80%81%E7%BE%A4%E6%99%96nas%E3%80%81%E4%BA%91%E6%9C%8D%E5%8A%A1%E5%99%A8%E3%80%81%E8%9C%97%E7%89%9B%E6%98%9F%E9%99%85%E3%80%81%E9%BB%91%E7%BE%A4%E6%99%96%E3%80%81docker%E3%80%81%E5%AE%B9%E5%99%A8%E9%95%9C%E5%83%8F%E3%80%81%E5%9F%9F%E5%90%8D%E6%B3%A8%E5%86%8C%E3%80%81%E5%AE%9D%E5%A1%94%E3%80%81%E5%8F%8D%E5%90%91%E4%BB%A3%E7%90%86%E3%80%81nginx%E3%80%81frp%E3%80%81%E5%8A%A8%E6%80%81%E5%9F%9F%E5%90%8D%E8%A7%A3%E6%9E%90
