配置NAT后为什么要同时配置黑洞路由

在NAT篇和拍案惊奇系列中，强叔多次提到配置NAT的同时要配置黑洞路由，避免路由环路，很多人对此不太理解，今天强叔就来为大家详细介绍其中缘由。
首先我们用eNSP模拟一个典型的源NAT环境：

NAT地址池地址是202.1.1.10，防火墙与路由器互联接口地址的掩码是30位，与NAT地址池地址不在同一网段。防火墙上配置了一条缺省路由，下一跳是202.1.1.2，这样就能把私网PC访问公网Server的报文送到路由器。为了保证公网Server的回程报文能够顺利到达防火墙，路由器上还要配置了一条到NAT地址池地址的路由。另外，防火墙上的NAT策略和安全策略也都配置完成了，在此不再赘述。
正常情况下，私网PC访问公网上的服务器Server，生成会话表，源地址也进行了转换，一切都没有问题。

此时，如果公网上的一台PC，主动访问防火墙上的NAT地址池地址，会发生什么情况呢？

我们在公网PC上执行ping 202.1.1.10命令，发现不能ping通：
 
显然，这是正常的结果。因为NAT地址池只有在转换私网地址的时候才会用到，也就是说，私网PC必须先发起访问请求，防火墙收到该请求后才会为其转换地址，NAT地址池地址并不对外提供任何单独的服务。所以当公网PC主动访问NAT地址池地址时，报文到达防火墙后，无法匹配会话表，防火墙肯定就会把报文丢弃了。
但实际情况远没有这么简单，我们在防火墙的GE0/0/1接口抓包，然后再次在公网PC上执行ping 202.1.1.10命令，这次我们使用-c参数，只发送一个ping报文：

GE0/0/1接口上的抓包信息如下：

嚯！不看不知道，一看吓一跳，居然抓到了这么多ICMP报文。经过分析发现，报文的TTL值逐一递减，直到变为1。我们都知道，TTL是报文的生存时间，每经过一台设备的转发，TTL的值减1，当TTL的值为0时，就会被设备丢弃。这说明公网PC主动访问NAT地址池地址的报文，在防火墙和路由器之间相互转发，直到TTL变成0之后，被最后收到该报文的那台设备丢弃。
我们来梳理一下整个过程：
1、路由器收到公网PC访问NAT地址池地址的报文后，发现目的地址不是自己的直连网段，因此查找路由，发送到防火墙。
2、防火墙收到报文后，该报文不属于私网访问公网的回程报文，无法匹配到会话表，同时目的地址也不是自己的直连网段（防火墙没有意识到该报文的目的地址是自己的NAT地址池地址），只能根据缺省路由来转发。因为报文从同一接口入和出，相当于在同一个安全区域流动，缺省情况下也不受安全策略的控制，就这样报文又从GE0/0/1接口送出去了。
3、路由器收到报文后，查找路由，还是发送至防火墙，如此反复。这个可怜的报文像皮球一样被两台设备踢来踢去，最终被残忍丢弃，憾别网络。。。。。
下面我们来看一下配置了黑洞路由的情况。首先在防火墙上配置一条目的地址是NAT地址池地址的黑洞路由，为了避免这条黑洞路由影响其他业务，我们将掩码配置成32位，精确匹配202.1.1.10这个地址：

[FW] ip route-static 202.1.1.10 32 NULL 0

然后在防火墙的GE0/0/1接口上开启抓包，在公网PC上执行ping 202.1.1.10 -c 1命令，还是只发送一个ping报文，查看抓包信息：

只抓到了一个ICMP报文，说明防火墙收到路由器发送过来的报文后，匹配到了黑洞路由，直接将报文丢弃了。此时就不会在防火墙和路由器之间产生路由环路，即使防火墙收到再多的同类报文，都会送到黑洞中，一去不复返。并且，这条黑洞路由不会影响正常业务，私网PC还是可以正常访问公网Server。