工作中实用的NAT技术分享（黑洞路由、内网使用公网地址访问、内网使用域名方式访问）

最新推荐文章于 2024-09-09 15:42:52 发布

网络之路Blog

最新推荐文章于 2024-09-09 15:42:52 发布

阅读量1k

点赞数 12

分类专栏：华为防火墙实战文章标签：网络服务器运维 USG防火墙华为防火墙华为防火墙端口映射 nat server

文章原创网络之路Blog（其他平台同名，公众号：网络之路博客），用心分享技术的IT人，主要精通思科、华为、H3C路由交换、防火墙、无线、安全系列，希望分享的技术对大家有帮助，原创不易，大家多多支持！

本文链接：https://blog.csdn.net/weixin_46948473/article/details/142041899

版权

华为防火墙实战专栏收录该内容

10 篇文章 0 订阅

订阅专栏

讲解了这么多内容了，这里博主在开一篇，分享下在实际环境中更实用的配置以及经常会遇到的需求经典案例。

源NAT场景下黑洞路由的作用

在讲解NAT到现在这是第一次提到黑洞路由的概念，这个在UTM的产品中其实就有了，但是到了下一代防火墙中还是有这个问题存在，博主为什么说是“还”呢，这里算吐槽下，这个功能其实算是用户自己来修复系统功能带来的一个小bug的这么一个技术，先来了解下。

实验环境很简单，trust网络一个192.168.10.1，想要访问untrust公网用户的服务器，防火墙有多个公网IP，这里用202.100.2.22来做转换，202.100.1.1配置在接口，来感受下小bug的“威力”（这里注意，接口是30位的，运营商又分配了202.100.2.22~25，跟接口不在同一个网段，这种在实际工作中也有的，运营商那边会写路由过来）

配置相关

security-policy

rule name trust_untrust

source-zone trust

destination-zone untrust

source-address 192.168.10.0 mask255.255.255.0

action permit

nat address-group 202.100.2.22

mode pat

section 0 202.100.2.22 202.100.2.25

nat-policy

rule name trust_untrust

source-zone trust

destination-zone untrust

source-address 192.168.10.0 mask255.255.255.0

actionsource-nat address-group 202.100.2.22

iproute-static 0.0.0.0 0.0.0.0 202.100.1.2

alias GE0/METH

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.1 255.255.255.252

service-manage ping permit

firewall zone trust

set priority 85

add interface GigabitEthernet1/0/0

firewall zone untrust

set priority 5

add interface GigabitEthernet1/0/

实际测试

访问外网正常的，成功5，这样看似没任何问题，但是互联网各种探测都有，可能经常调试网络设备的人都有这样的经验，只要这台路由器、防火墙或者其他设备接入了互联网（有公网地址的），会发现很多的telnet、ssh、http的探测，其中还包括Ping，那么假设这个时候互联网有人ping了地址组里面的地址，会发生什么事情？来感受下。

失败了，这个正常，因为接口上面并没有配置关于202.100.2.22的信息，不通属于正常，但是这后面存在很大的问题，抓包看下，这里抓取防火墙的出接口即可

发现了什么，N多的ICMP包出现，发现特别有规律从254、253、252依次递减1，直到TTL0被丢弃，这个就是典型的路由环路了！！！，为什么会出现这样的情况，先分析下。

（1）当61.128.10.1访问202.100.2.22的时候交给外网路由器，外网路由器查看路由表，发现202.100.2.22是给202.100.1.1的。（这里有的朋友可能很迷糊，运营商还会写路由过来？在实际中，你购买了多个IP，运营商可能给你连续的，也可能给你一个对接互联，以及用户的可用IP，这两个可能不在一个网段，这时候运营商那边就会写路由过来）

（2）出口防火墙收到后，发现访问202.100.2.22在会话表中没有任何信息，只能查找路由表

发现路由表只能匹配默认路由，又丢给202.100.1.254（外网路由器，这里防火墙是不知道202.100.2.22其实是调用在NAT组的）。

（3）外网路由器收到后，又重复查找路由表直接转发给防火墙，就这样环路产生了，直到TTL变为0。

解决办法

[USG6000V1] ip route-static 202.100.2.22 32 NULL 0

[USG6000V1] ip route-static 202.100.2.23 32 NULL 0

[USG6000V1] ip route-static 202.100.2.24 32 NULL 0

[USG6000V1] ip route-static 202.100.2.25 32 NULL 0

问题就出现在防火墙感知不到这个202.100.2.22与自己有关联，所以转发给防火墙的时候，防火墙直接又转回去了，解决这个就是让它不转发出去，直接写一条202.100.2.22主机路由进null0，这个null就相当于一个回收站不会转发出去，像黑洞一样，所以这个在防火墙里面也会叫黑洞路由。

这个时候在抓包就只会收到一个了，收到后防火墙匹配这条黑洞路由就给丢弃了，不会在转发给外网路由器。博主在最开始说这个属于系统软件功能设计上面的一个小“bug”，这里谈下博主最开始接触防火墙是思科的PIX以及后面的ASA跟juniper的netscree与SRX，在这些产品里面只要配置了这些都能感知到有这么一个地址存在，不会出现像华为防火墙这样的情况，而华为的防火墙从UTM时代的产品开始到目前的下一代还是没有任何的关联，需要用户去手动解决这个问题，比如一个刚接触华为防火墙的用户，它忘记配置这个功能了，互联网可不跟实验环境一样，简单的重现下环境，探测的人多了去了，同时几百、几千的数据包发过来，对带宽的资源以及设备性能资源消耗都是巨大的，所以这里博主再次提醒，如果工作中遇到了分配的公网地址不在同一个网段的场景，必须必须配置黑洞路由，避免带来上面出现的问题。

假设公网IP在一个网段会出现这样的情况吗？

改动下，这里NAT地址池的地址换成 202.100.1.2（路由器地址改成了202.100.1.254），来看看同一个网段会出现什么样的情况

nataddress-group 202.100.1.2

mode pat

section 0 202.100.1.2 202.100.1.2

nat-policy

rule name trust_untrust

source-zone trust

destination-zone untrust

source-address 192.168.10.0 mask255.255.255.0

action source-nat address-group 202.100.1.2

<Huawei>reset arpall

建议做实验的话情况下外网路由器的ARP表，我们来看一个有趣的地方

这里ping两次，然后抓包发现很有趣的事情出现了。

（1）当61.128.10.1访问202.100.1.2的时候，丢给网关外网路由器，外网路由器发现202.100.1.2是直连网段，发现ARP表中没有关于202.100.1.2的封装信息（刚清理ARP清掉了），发送ARP请求。

（2）防火墙收到后，它响应了这个ARP的请求，对的，这就是有趣的地方，防火墙响应了，第二个抓包报文，是防火墙告诉路由器202.100.1.2的MAC地址是多少，而这个MAC地址是防火墙接口的MAC

（3）路由器得到ARP信息后，可以封装了，直接把这个ICMP的报文（抓包的第三个）发送给202.100.1.2，也就是防火墙。

（4）更有趣的事情来了，防火墙收到后，它发现202.100.1.2是同一个网段的，但是它ARP表项里面没有封装信息，它开始发ARP请求（第四个报文），并没有回应（202.100.1.2没有被配置在接口上面），最终的结果就是被防火墙丢弃这个ICMP报文。

博主觉得有趣的地方就在于路由器发起询问202.100.1.2的MAC是多少的时候，防火墙会回应，但是自己找这个202.100.1.2的时候，防火墙就不知道是谁了（其实202.100.1.2被防火墙调用在NAT池里面。）这里之所以会响应路由器的ARP请求，因为202.100.1.2实际是防火墙被调用在NAT池的，如果对接的外网路由器都不知道它的ARP封装信息，那么内网访问外网的通信就会失败，因为路由器都没ARP的信息，根本不知道如何去回包；但是博主奇怪的就是防火墙竟然够响应路由器的报文，说明它应该是能够感知202.100.1.2存在的，但是当它自己去找这个报文的时候就“犯傻了“。

[USG6000V1]ip route-static 202.100.1.2 32 NULL 0

这里也建议在同一个网段下面也配置一个黑洞路由

这个时候在抓包看，已经看不到ARP的报文了，配置黑洞路由的意义就是可以让防火墙不在去发送ARP的请求，避免资源占用。（公网大量探测这个202.100.1.2的时候，防火墙会大量发送ARP的广播报文）

NAT server 场景下黑洞路由的作用

环境跟源NAT一样，只是把客户端与防火墙的位置互换了下，对于NAT server里面存在一对一以及端口映射，首先来看看一对一，这里先测试实际映射用的与接口不在同一个网段的场景。

[USG6000V1]undo iproute-static 202.100.2.22 255.255.255.255 NULL0

[USG6000V1]undo iproute-static 202.100.1.2 255.255.255.255 NULL0

去掉两条黑洞路由

[USG6000V1]nat server 0global 202.100.2.22 inside 192.168.10.1

security-policy

rule name untrust_trust

source-zone untrust

destination-zone trust

destination-address 192.168.10.1 mask255.255.255.255

action permit

测试下

正常业务访问没什么问题

ping也通了，一对一是不会存在问题的，因为有serve-map存在

它会把所有访问关于202.100.2.22的流量都转换给192.168.10.1，所以就不会存在说路由环路的问题。

端口映射场景

[USG6000V1] undo natserver name 0

去掉之前的一对一配置

[USG6000V1]nat server9898-80 zone untrust protocol tcp global 202.100.2.22 9898 inside 192.168.10.1 80

访问业务正常，但是如果互联网的ping之类的测试呢？打开抓包，ping下202.100.2.22一个包看看！

又出现这样的环路情况了，一对一不会出现是因为server-map表会来访问202.100.2.22的流量全部转换到192.168.10.1，端口映射也会生成server-map表，但是它就多了条件了。

它只会转换访问202.100.2.22的9898会转换成192.168.10.1的80，其余的流量它不管，那就会跟源NAT一样的处理流程，最终直到TTL消失。

解决办法

（1）写一个黑洞路由，ip route-static 202.100.2.22 32NULL 0

（2）NAT server的端口映射还有一种方式，nat server name9898-80 unr-route ，加一个自动添加黑洞路由的参数。

会发现它能自动生成一个黑洞路由，所以在配置nat server端口映射的时候，建议大家加上unr-route的参数。

如果处于直连网段非接口的地址做端口映射，也建议大家加上unr-route参数，这样可以节省防火墙的资源，避免发送大量ARP请求报文。

简单明了的黑洞路由的总结（1）：接口地址做源NAT或者nat server端口映射不需要写黑洞路由（2）：其他非接口地址（不管是否在一个网段）做源NAT或者nat server端口映射，都需要配置黑洞路由，避免资源浪费。

实际案例讲解（一）：内网用户通过公网IP来访问内网服务器内容

在实际环境中，客户有这样的一个需求，特别是测试开发的人员，它希望不管在其他地方或者是公司内部都以公网地址来对服务器的服务进行访问，对于客户而言记住一个地址更加容易，同时去记两个地址对于一个非IT人员有点困难，而开发人员则用公网测试更加方便，在这样的需求下，来看看需要用到什么技术才能够实现这样的需求。（基础环境跟图一样，然后做一个简单的映射，用202.100.1.1的9898映射到192.168.10.10的80端口号，注意客户端服务器的地址设置正确，以及服务器的服务启动正常）

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.1 255.255.255.0

security-policy

default action permit

#安全策略先不管，全部放行，最后来看如何放行

nat server 0 zoneuntrust protocol tcp global 202.100.1.1 9898 inside 192.168.10.10 wwwno-reverse

实际测试

外网的客户端访问是没问题的，我们主要的重心放到内网。

内网访问202.100.1.1的9898不通，来分析下为什么不通，其实配置非常简单的，但是要了解它为什么不通，怎么实现的，对我们排除跟实施有很大的帮助。

首先看会话信息，访问的安全区域是trust---local的，也就是防火墙把这个这个流量当成了访问自己的流量了，但是上面明明是做了端口映射的？来看看server-map表

Type: Nat Server, ANY ->202.100.1.1:9898[192.168.10.10:80], Zone: untrust , protocol:tcp

Vpn: public -> public

问题就出在这个zone上面了，在上一篇博主讲过绑定安全区域与不绑定的区别就是绑定了对应的安全区域，那么流量只有从这个区域进来的流量访问公网地址才会进行匹配，其他区域进来的则按正常流程处理，这里配置是绑定了安全区域的，所以从trust访问会发现防火墙当成访问自己的流量进行处理了，而没有匹配server-map，解决办法两个（1）在添加一个来自于trust的映射（2）把之前的绑定去掉，不进行绑定

配置上去后，在来看看server-map表

这个时候就多了一个trust的安全区域的匹配了，再次测试

这个时候会话表的选项就不一样了，会发现方向是trust到trust，然后192.168.10.1访问了202.100.1.1:9898，也转换成了192.168.10.10:80，但是有一个地方注意就是会发现回包的统计数是0，也就是已经发送过去了，但是回来的流量没有收到，来分析下情况。

（1）客户端以192.168.10.1访问202.100.1.1的9898数据包发送给防火墙

（2）防火墙发现流量是从trust过来访问202.100.1.1的9898的直接匹配server-map表，将202.100.1.1:9898转换成192.168.10.10:80，这里要注意哦源地址还是192.168.10.1

（3）服务器收到以后，发现是192.168.10.1访问过来，直接就回复给192.168.10.1了，因为是直连网段，那它直接就通过交换机就转发了，流量不经过防火墙，客户端收到后就懵逼了，客户端是访问的202.100.1.1的9898，这个时候直接来了个192.168.10.10的80的数据回复，果断丢弃了。

那么可以发现问题就出在当客户端192.168.10.1经过防火墙的时候，防火墙只转换了目的地址，导致服务器回包的时候直接回复给192.168.10.1了，而不经过防火墙了，不经过防火墙那么192.168.10.10无法还原成202.100.1.1，无法还原成202.100.1.1的9898，那么整个会话就会失败（因为客户端最初访问是202.100.1.1的9898，那么回来数据客户端也只认202.100.1.1回复的），所以解决这个问题的关键是在防火墙转发给服务器的时候除了要把202.100.1.1通过server-map表转换成192.168.10.10，还需要把192.168.10.1也转换下，转换成一个与服务器不在同一个网段，这样当服务器回包的时候就把流量再次转发给防火墙，防火墙再次通过会话表还原最终信息进行回复，完成整个通信，之前学过转换源地址的技术叫做源NAT功能，这个场景很特殊，需要同时用到两种技术源NAT+NAT server，这种组合在华为防火墙里面称为双向NAT，也就是同时转换源跟目的。

这里就出现了一个疑问？到底把192.168.10.1转换成哪个地址好呢？

博主给大家一个最直接最简单的，就用防火墙的接口地址进行转换即可，比如这里的trust的G1/0/0地址是192.168.10.254，可以直接转换成192.168.10.254，当服务器回包的时候，虽然192.168.10.254是同一个网段，但是属于防火墙自己的地址，抵达防火墙后会直接匹配会话信息，再次进行转换还原，最终回复给客户端，配置后实际看看。

nat-policy

rule name trust_trust

source-zone trust

destination-zone trust

action source-nat easy-ip

这个时候访问成功了，再来看看它中间发生了什么

（1）192.168.10.1去访问202.100.1.1的9898【源地址192.168.10.1，目的地址202.100.1.1，目的端口号9898】，发送给防火墙处理。

（2）抵达防火墙后，首先匹配server-map表

会变成【源地址192.168.10.1，目的地址192.168.10.10，目的端口号80】，然后继续继续流程，防火墙发现有一个源NAT策略，把来自于trust去往trust的流量都转换成接口地址，192.168.10.1访问转换后的192.168.10.10正好属于源trust到目的trust的流量，这个时候防火墙再次进行源NAT转换，把192.168.10.1转换成192.168.10.254，这个时候就变成了【源地址192.168.10.254，目的地址192.168.10.10，目的端口号80】，然后丢给服务器

（3）服务器收到以后，进行回包，发现目的地址是192.168.10.254，这个时候的信息是【源地址192.168.10.10，源端口号是80，目的地址192.168.10.254】，发送给防火墙。

（4）防火墙收到以后，发现这个数据有会话信息匹配，直接按对应的会话信息进行转换，这里注意转换还是源跟目的都转换，就变成了【源地址202.100.1.1，源端口号是9898，目的地址192.168.10.1】，最终交给PC，完成交互（这里TCP三层握手过程就省略了）

该案例中安全策略该如何放行？

从会话信息来看，数据流动的方向是trust到trust，测试下，直接把default action permit给关闭。

security-policy

default action deny

发现还是可以访问的，这里博主一下流程就懂了，当客户端数据包过来的时候，直接匹配server-map表会把目的地址转换，然后继续检测安全策略，由于方向是trust到trust，属于域内，华为防火墙默认情况下域内是不受安全策略控制的，所以直接放行，接下来匹配NAT策略，直接源地址转换，至此完全不需要安全策略的放行。

博主经验分享下

这里说的不需要安全策略放行指的是同一个安全区域内的，还有的环境是客户端在trust，服务器在DMZ，这个时候就需要放行trust到DMZ的流量了。在提醒下，这个是说的内网通过公网访问的形式，外网访问进来的安全策略该怎么放行还是怎么放行。

实际案例（二）练习：如果客户端跟服务器不在一个安全区域该怎么办？用学习到知识点解决（购买课程的朋友会有视频讲解）