现场组网大致拓扑如下,防火墙F1030作为内网服务器以及终端的出口设备,服务器的网关在S5560-EI交换机上。现场服务器有访问互联网的需求。
现场使用内网服务器访问外网不通,然后首先进行分段测试,发现服务器无法正常ping通防火墙,从防火墙也无法ping通服务器。具体ping测试情况如下。
[F1030]ping -a 10.105.8.2 10.193.97.1
Ping 10.193.97.1 (10.193.97.1) from 10.105.8.2: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
1.对于防火墙到服务器不通这种问题,我们首先的思路是,检查下防火墙的安全策略是否正确放通,以及两边设备的路由是否正常。
(1)首先检查防火墙的安全策略配置:
security-zone name Trust
import interface GigabitEthernet1/0/3 //内网接口
#
security-policy ip
rule 1 name GuideSecPolicy
action pass
source-zone Local
source-zone Trust
source-zone Untrust
source-zone DMZ
destination-zone Untrust
destination-zone DMZ
destination-zone Trust
destination-zone Local
经检查安全策略,local安全域到内网口3口所在的trust安全域是全放通的,另外在防火墙上ping内网直连地址10.150.8.1是正常通的。
(2)其次我们对设备上的路由配置以及服务器网关进行了检查:
ip route-static 0.0.0.0 0 192.168.250.57 //指向出口下一跳的缺省路由
ip route-static 10.193.97.0 24 10.105.8.1
发现设备上出了指向出口下一跳的缺省路由外,就只有去往服务器的一条明细路由了,防火墙路由配置没有问题。
(3)后续检查了下服务器网卡网关配置正确,网关地址为交换机的10.193.97.1地址,并且从服务器上ping交换机的10.150.8.1地址是通的。说明服务器路由正常,报文转发正常。
(4)为了确认下该异常情况是否由防火墙导致,我们在防火墙上进行了ping -a 10.105.8.2 10.193.97.20操作,然后查看对应的会话,情况如下:
[F1030]display session table ipv4 source-ip 10.105.8.2 destination-ip 10.193.97.20 verbose
Slot 1:
Total sessions found: 0
由此测试结果,可以确认问题出现在了防火墙上,由于没有相应会话,那么只有两种可能原因,一种是安全域未放通,另一种是路由转发存在问题。但是对于第一种安全域未放通这个原因,首先可以排除,因为安全策略是全放通的,而且内网接口下联的交换机是能通的。
(5)针对(4)中排查的情况,怀疑是否是路由下发异常导致的,于是查看了路由表:
Destination/Mask Proto Pre Cost NextHop Interface
10.193.97.0/24 Static 60 0 10.105.8.1 GE1/0/3
10.193.97.1/32 Direct 1 0 0.0.0.0 NULL0
10.193.97.2/32 Direct 1 0 0.0.0.0 NULL0
10.193.97.3/32 Direct 1 0 0.0.0.0 NULL0
10.193.97.4/30 Direct 1 0 0.0.0.0 NULL0
10.193.97.8/30 Direct 1 0 0.0.0.0 NULL0
10.193.97.12/30 Direct 1 0 0.0.0.0 NULL0
10.193.97.16/28 Direct 1 0 0.0.0.0 NULL0
10.193.97.32/28 Direct 1 0 0.0.0.0 NULL0
10.193.97.48/28 Direct 1 0 0.0.0.0 NULL0
10.193.97.64/26 Direct 1 0 0.0.0.0 NULL0
10.193.97.128/26 Direct 1 0 0.0.0.0 NULL0
10.193.97.192/28 Direct 1 0 0.0.0.0 NULL0
10.193.97.208/28 Direct 1 0 0.0.0.0 NULL0
10.193.97.224/28 Direct 1 0 0.0.0.0 NULL0
10.193.97.240/30 Direct 1 0 0.0.0.0 NULL0
10.193.97.244/30 Direct 1 0 0.0.0.0 NULL0
10.193.97.248/30 Direct 1 0 0.0.0.0 NULL0
10.193.97.252/32 Direct 1 0 0.0.0.0 NULL0
10.193.97.253/32 Direct 1 0 0.0.0.0 NULL0
10.193.97.254/32 Direct 1 0 0.0.0.0 NULL0
发现在防火墙上,10.193.97.0/24网段的地址,几乎都存在掩码高于24位的,下一跳指向NULL0的路由条目,而导致24位掩码长度的正常路由优先级低,在转发报文的时候,未被启用。但是由于下一跳指向NULL0的路由条目在设备上会被直接丢弃,所以去往该目的网段的报文会被丢弃而无法正常转发。
(6)针对(5)中分析出的情况,又有了疑问,设备上为什么会出现下一跳指向NULL0的路由呢,后来我们仔细检查了下设备的完整配置,发现了如下的配置内容:
nat address-group 1 name server
address 10.193.97.1 10.193.97.254
现场实施工程师在设备上配置了个nat outbound转换用的地址组,该地址组中包含了内网服务器所在的网段。根据设备的报文转发原理,我们在设备添加nat outbound相关配置的时候,设备会自动将nat转换后的地址在设备上生成一条对应的NULL0路由,来保证报文能在设备上进行终结。也正是由于现场做的这个错误配置,导致设备上会生成内网服务器网段的NULL0路由,也导致现场出现的转发异常的情况。
现场错误的配置是由于现场工程师对nat outbound地址转换机制不了解导致的,和现场实施工程师说明相关nat outbound地址转换机制和原理后,修改nat address-group地址组中的地址为其他网段,并保证外网回程路由,能正确将去往该地址组网段的报文转发到防火墙上即可。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作