今天分享的华为NAT_SLB和NAT双向技术。在众多的企业场景中会出现多个服务器对外提供相同的内容，外网用户访问企业的服务器应用这时候会出现很大的流量，这就引出这次分享的NAT负载技术。
NAT _SLB负载均衡
这个传统的一对一服务器映射是我之前分享过的，这里简单拿来说一下，为的是为后面的SLB技术进行铺垫。
我现在在拓扑中，先演示一个静态NAT一对一的映射，将server5映射一个219.0.0.1这个公网IP地址。
实验拓扑如下：
我先将Server5的私网地址，映射给219.0.0.1并且只能让电信这条链路来的客户端访问。
图中是否允许服务器上网这个选项，建议勾选，因为一些服务器要在线及时更新补丁，病毒库等。
并且最终测试这条服务器映射策略是连通的。
访问之前，外网用户访问防火墙公网IP地址的网络是正常的。
外网客户端访问内网172.16.0.20这台服务器映射的219.0.0.1这个IP地址：访问是正常的。
SLB的概念：
服务器负载均衡，就适用于内网有多个服务器，并对外提供一致的服务内容，只不过对外的时候虚拟成了一个服务器，对用户而言是形成了访问流量的负载均衡。
如图所示：外网的两个用户同时访问219.0.0.1这个接口地址，我们配置NAT-SLB的防火墙，会让着两个请求报文分别访问内网的两台服务器。
配置NAT-SLB之前，我可以删除之前我配置的一条服务器静态映射策略：
新建一个服务器负载均衡，助理这里面的虚拟服务器地址填写的是公网接口的地址，也就是实验拓扑中219.0.0.1这个地址。
实服务器列表中我们要填写内网的两台服务器地址，最大连接数根据你之前的策略而定。
这样，我们这条SLB负载均衡策略就建立成功了，并且我也能看到服务器健康状态，权值等等数据情况。
如果我们看不到服务器检查状态，就要考虑安全策略中local区域到DMZ区域的策略是否放行：
放行之后，过段时间就可以看到服务器的健康状态了:
其中，在服务器负载均衡中，有个负载均衡算法，具体的意思如下：
①简单轮询：轮流将请求数据交给A B A B A B A B 的意思。
②加权轮询：根据权重，来定义请求给谁，权重越大优先访问。
③最小连接：根据链接数来决定负载，哪个内网服务器的链接数少，设备会认为此服务器处于空闲状态，这时访问请求就会定位给这台服务器。
④加权最小连接：和第二条意思一样。
这里的健康检查是指：我举例用ICMP报文，就是防火墙会间隔一段时间发送Ping包对服务器进行通讯检查！发现服务器正常的时候，防火墙才允许将用户请求交给这台服务器。反之，不转发！
当外网用户访问内网用户访问219.0.0.1这个IP地址，我通过查看服务器日志，能够看到防火墙设备确实是由A B A B A B A B 这样的轮询方式处理请求报文：通过日志中时间段的查看，确实能看到防火墙设备通过轮询的方式，将请求报文负载均衡的处理了。
双向NAT
双向NAT在企业实际应用场景中很具有特色，如果需要同时改变报文的源地址和目标地址，就可以配置“源NAT+NATserver”，我们称此类NAT技术为双向NAT.
需要注意的是：双向NAT不是一个单独的功能，而是源NAT和NAT server的组合。这里的组合的含义是指针对同一条数据流（列如公网用户访问私网服务器的报文），在经过防火墙时会被同时转换报文的源地址和目标地址。初学者误认为在防火墙中同时配置了源NAT和NAT server就可以称之为双向NAT了！因为源NAT和NAT server可能为不同的数据流而配置。
涉及到双向NAT的一些概念，我这里要强调一下：
源NAT根据报文在防火墙上流动的方向分类如下：
①域间NAT
报文在两个不同的安全区域之间流动时对报文进行NAT转换，根据流动方向的不同，又可以分为以下两类：
1>.NAT Inbound
应用在公网用户访问内部网络，防火墙对报文转换的方向是：报文由低安全级别的安全区域向高安全区域方向。不常见。
2>.NAT Outbound
应用在私网用户访问internet，防火墙对报文转换的方向是：报文由高安全级别的安全区域向低安全区域方向。比较普遍。
②域内NAT
默认情况下，域内NAT配合NAT server使用，报文在同一个安全区域中流动时对报文进行NAT转换。
域间双向NAT应用实验
我们先避开繁琐的概念，先来做一下关于域间NAT的实验
实验拓扑如下：
这里面有个场景需要大家注意，某些web集群中，几台服务器通常不会配置网关（比如：有些网站架构中，前端有web服务集群，后端有mysql存储等，MySQL和web服务器直连，数据库服务器只需要和web服务器互相通讯交换数据，MySQL服务器的网关配置就可以不用配置！这样的好处在于外网用户是不能直接访问数据库的，保证了安全性。）
实验大致实验思路：
我先对dmz区域中的server5配置一条服务器一对一映射，将80口映射出去，而server5后续实验中取消网关，我们来看下实验结果，就能明白域间NAT的作用了
其实域间双向NAT在某些特殊场景中，是解决异步路由问题。
由于服务器的配置多个网关时，只能选择一个。数据回包路由出现不是最优路径。域间的双向NAT就是解决将来自外网的数据包的源地址临时替换成网关地址，这样数据就能从哪里来回哪里去，形成直连路由（即使网关配置其他出口，也不会影响数据回包的方向）。
拓扑中防火墙配置默认路由，放行安全策略，添加安全区域，接口地址，模拟web服务等配置上面的实验已做分享，这里略过。
其中，防火墙安全策略方面，在实际企业环境中建议不开启默认策略，我们做一些明细的详细策略。
如图所示：
有些企业对特殊部门访问外网有这特殊的限制，我们可以修改源NAT里面的源地址来限制其他网段或者客户端访问外网。
具体配置如下：
先配置一条源NAT，只允许10.0.0.10/32这个地址用219.0.0.1 进行NAT转换访问！其他内网地址是不可以访问外网！
测试10.0.0.10访问外网通讯正常！
其他客户端访问外网失败，符合之前的需求。
试验前，我们要将之前配置的服务器负载均衡列表删除掉。
以免影响日后我给DMZ区域服务器映射策略。
言归正传
按照拓扑，将DMZ区域中的server5映射给219.0.0.1这个公网IP地址。
服务器映射配置如下：一定要诊断测试连通性，如果不成功检查安全策略是否放行loacl到dmz区域的策略。
我们查看NAT的 server-map表也会发现：
这张表能发现，外网的任意地址访问219.0.0.1都通过80号端口传输转换给172.16.0.20。
配置完成后，拓扑中的外网客户端输入219.0.0.1来访问DMZ区域的server2
如图所示：外网客户端访问成功。
如果还是访问不成功，还要注意添加的是untust区域到dmz区域的明细流量（这里指Http流量）是否为放行。
按照之前的实验步骤，将server2去掉网关配置。
外网用户再次发起访问：如图所示，连接服务失败。
如果在做实验中还能访问的，请注意是否保存server5的清除网关配置或者重启外网客户端。
访问失败的原因在于，当外网用户访问219.0.0.1这个地址的时候，防火墙通过NAT转换来自外网的目的IP（219.0.0.1）地址变为172.16.0.1，但是来自外网数据的源地址(219.0.1.251)没有被转换，这个地址到达服务器的时候，服务器的路由表认为其地址不在同一网段，服务器交给网关，但是我们并没有设置网关，因此数据被丢弃了。
为解决这个问题，我需要在回包的过程中，将源地址219.0.1.251临时转换为网关地址172.16.0.1。
l来自untust1的报文去往dmz区域，转换成出接口的地址即可。
这就是典型的NAT inbound方向的策略：控制着报文从低安全级别区域到高安全级别区域方向流动的报文转换！
命令行如下：
设置完之后，当外网用户再次访问，是可以正常访问的。
通过抓取相关端口的报文，观察NAT转换情况：
当来自外网的数据到达防火墙g1/0/3接口，防火墙查看目的地址是自己的地址，根据配置的服务器映射，它会把目的地址转换成172.16.0.20
当这条数据流出防火墙的时候，我们抓取报文发现，源地址由219.0.0.1变为了172.16.0.1（是DMZ区域接口的地址）这就源NAT转换了出接口地址，sever5回包的时候发现目的地址是自己的网段，就可以顺利转发出去。
这就是在服务器没有配置相关网关时，是典型的域间NAT应用场景。
在防火墙的会话表中：
我也能清楚的看到来自外网的报文中的源地址和目标地址都进行了转换。
如果企业业务需求由trust区域通过公网地址访问DMZ区域的时候，我们只需更改源NAT的配置，称之为NAT bound方向，用的较少，这里不做演示了：
NAT inbound的好处？
我当时在做这个实验的时候，隐约有个疑问（前提DMZ区域服务都配置了相应的网关），在配置了服务器映射之后，我不配置NAT inbound也不会影响我外网用户访问私网服务器啊。如图所示：我禁用NAT inbound方向的策略.
外网用户照样能访问......如图所示：
配置 NAT inbound的好处在于DMZ区域服务器对回应报文的处理方式上！
当服务器回应外网的访问请求，发现自己的地址和目的地址在同一网段，此时私网服务器就不会查找路由表，而是发送ARP广播询问目的地址所对应的Mac地址，这时候防火墙就会将连接DMZ区域的接口Mac地址发给服务器，这就引出既然省去查找路由表，（别忘记了，在企业的真实环境中，很有可能出现防火墙DMZ接口到DMZ区域的服务器会存在复杂的路由可能）我们设置网关的环节可以省略！（尤其是在多台服务器需要配置网关或者修改网关的时候）由于这个端口是系统默认抓取不了的，所以我看不到ARP报文，无法验证这个理论！
域内NAT实验演示
在企业的组网环境中，只有trust区域和Utrust区域，这种组网方式就比较简单。（P112书中详解场景）
域内NAT实验拓扑
防火墙的G1/0/3接口中模拟申请一个219.0.0.2的公网地址，同时也增加一台DNS服务器，为的是更好模拟实际应用场景：
在trust区域中增加一台内网服务器，配置如下：
我先将trust区域中的一个服务器10.0.0.20映射给公网地址219.0.0.2
配置完成后，还不要忘记要给放行一个utrust1区域到trust区域的安全策略放行动作：否则访问会被拦截：
外网用户通过域名访问www.daidai.com就可以访问到我trust区域中的内网服务器了:
如图所示：外网用户通过访问域名可以正常访问到内网服务器的web界面
访问的时候，别忘记调整外网客户端的DNS地址：
实验过程发现客户端不能正常访问，抓取报文得知自己的DNS解析地址出现错误。
关于接口地址，可配置可不配，配的话能够Ping通，不配置也不会影响带域名访问！
上述实验，我们清楚的看到外网用户通过域名访问内部网站是没有任何问题的，但是当同一区域的客户端去访问10.0.0.20呢？？
内部用户访问内部服务器，运维人员都会提供以域名的方式，方便其他员工记忆，因此我需要在客户端的DNS地址之中指向公网DNS
现在，我们通过域名进行访问，如图所示：结果是访问失败。
访问不通的原因在于：当
访问不通的原因在于，在防火墙G1/0/3上通过抓包分析，如图所示：当trust区域客户端用域名解析服务器IP地址，数据报文会经过防火墙发送DNS解析报文，并且能够能到正确的公网地址。
这时候，数据封装完毕，客户端将以源地址是10.0.0.8目标地址是219.0.0.2的IP地址报文发送数据，并建立TCP连接。
防火墙收到这个报文后，查看自己的server-map表如图所示：
通过NAT server转换，会把目的地址（219.0.0.2）转换为10.0.0.20，而源地址是10.0.0.8,
当10.0.0.20这个服务器收到目标地址是自己的报文，从开始进行回包，在这个过程中发生了异步路由问题，如图所示：
server6在解封装发现源地址是10.0.0.8
在建立TCP连接的时候发生了问题，server6会根据目标地址直接发送数据包给客户端1，产生了路径不一致，而客户端接收到这样的数据包，查看源地址发现源地址是10.0.0.20，之前发送的目标地址是219.0.0.2。我们能观察到这个报文属于直连路由，不会经过防火墙
在TCP连接的时候，客户端1会认为接收到的源地址应该是219.0.0.2，可是源地址是10.0.0.20 这样的话，客户端1不会接收这个数据包了。（自建DNS的话不用关心此问题。）
既然发现了问题所在，我们需要让这个回程路由的数据包，经过防火墙后转发给我的客户端。
新建立一个地址池：
新建一个域内NAT策略：
测试内网人员通过域名访问内网服务器：测试成功。
原因在于，server6回程路由的目标地址变了，通过抓取防火墙的g1/0/0接口，我们图中能看到，防火墙转出的报文将210.0.0.2转换成了10.0.0.20
如果不考虑内部访问用域名方式，强硬记忆内部IP地址也是可以访问的。
