USG2260 网络存在IP地址欺骗导致服务器业务转发异常

发布时间:  2015-12-18 浏览次数:  223 下载次数:  2
问题描述

【版本信息】

USG2260

V300R001C10SPC200

【组网概述】

如上图,防火墙工作在混合模式:

对于VLAN192,C公司SW与华为S9706设备用于建立OSPF,互通路由,防火墙工作在透明模式。

对于VLAN65,服务器IP10.60.65.14,网关在S9706上,IP10.60.65.1

对于VLAN56,服务器IP10.60.56.4,网关在USG2260上,IP10.60.56.1

对于VLAN100,用于USG2260S9706之间互通三层业务,同时用作设备管理。

S9706上配置静态路由,目的网段10.60.56.0/24,下一跳172.17.0.2

USG2260上配置静态路由,目的网段10.60.65.0/24,下一跳172.17.0.3

该项目为部分搬迁C公司设备项目,上述S9706USG2260均为替换C公司后,1:1复制的原C公司设备配置。

 

【关键配置脚本】

S9706:

#

interface Vlanif65

 ip address 10.60.65.1 255.255.255.0

#

ospf 192 router-id 192.168.200.1                                                

 area 0.0.0.2                                                                  

  network 192.168.200.0 0.0.0.255                                              

#

interface Eth-Trunk0                                                            

 port link-type trunk                                                          

 undo port trunk allow-pass vlan 1

 port trunk allow-pass vlan 56 65 100

#

USG2260:

interface Eth-Trunk1                                                           

 portswitch                                                                    

 port link-type trunk                                                          

 undo port trunk permit vlan 1                                                 

 port trunk permit vlan 56 65 100                              

#                                                                              

interface Eth-Trunk2                                                            

 portswitch                                                                    

 port link-type trunk                                                          

 undo port trunk permit vlan 1                                                  

 port trunk permit vlan 56 65

#                                                                              

firewall zone trust

 add interface Eth-Trunk1

#                                                                              

firewall zone dmz

 add interface Eth-Trunk2

#

ip vpn-instance sicflota

 route-distinguisher 100:1

#

firewall zone vpn-instance sicflota trust

 add interface Vlanif100

#

firewall zone vpn-instance sicflota dmz

 add interface Vlanif56

#

域间策略不是本文重点,这里就略去了,大家可以当做域间策略都是允许的。

C公司SW:

C公司设备由于没有权限查看,此处配置略去。

【关于防火墙配置VPN Instance原因描述】


这里有必要提一下,事实上,防火墙上的VPN实例是没有必要配置的,它既不是MCE,也不是PE,但是老一代防火墙(这里是相对于下一代防火墙提的,比如USG6650)在报文二次经过防火墙时存在缺陷(下一代防火墙USG6650已经测试证实优化了该缺陷),如上图,假如C公司SW想使用源192.168.200.2访问USG2260目的地址172.17.0.2,在防火墙未配置VPN实例的前提下是无法实现的,这里不是本文讨论的重点,就不展开讲述了,有兴趣的朋友可以在“Secoway USG2100&2200&5100 BSR&HSR & USG2000&5000 V300R001C00 维护宝典”中搜索关键字“二次经过防火墙”得到详细解答,这里就直接引用维护宝典中关于这个缺陷的原因描述:

同一个报文两次经过防火墙,第一次走业务口二层转发经过防火墙,第二次走管理口三层转发到防火墙自身。由于防火墙是状态防火墙,报文基于会话表转发,首包创建会话表时,会记录会话表相关信息,后续包基于会话表记录的相关信息转发,不支持上述这种应用场景。

【故障现象】

服务器S1 Ping服务器S2不通。

处理过程

1.     业务路径分析

正常情况下,从S1 Ping S2,Ping Request报文业务的路径走向应该如上图三色线条,S9706收到红色线条Ping Request报文,三层转发给

USG2260,如上图蓝色线条;USG2260收到该报文后,再转发给S2,如上图绿色线条;

2.     实际路径

通过业务流量统计(非本文重点,略去),我们发现S9706的确通过Eth-trunk0接口向USG2260发送了上述Ping请求报文,如下证据:

但是USG2260并没有将该Ping报文转发给S9706,如下证据:


此时,S1发送给S2Ping报文看上去被防火墙给丢弃了,如下图:(绿色虚线表示该业务流向只是我们的假设,实际却没有该业务路径)


3.     问题定位过程

首先,我们怀疑USG2260的域间策略导致了业务报文被丢弃,那么对于如上转发路径的报文,防火墙的源和目的安全区域是什么呢?

由于Ping请求报文经过USG2260三层转发(Vlanif100入,Vlanif56出),而VLANIF100VLANIF56加入了VPN实例siclota,那么域间路径如下:

源安全区域:VPN实例sicflota trust

目的安全区域:VPN实例sicflota dmz

而我们通过如下命令查询,上述路径缺省应该是允许的,如下:(outbound方向为缺省允许)


到这里,可能大家要怀疑是不是防火墙的BUG了,再往下看,有更大的“BUG”;

如上分析,我们进一步查看USG2260的流表如下:


看出问题了吗?Ping报文的源和目的安全区域都是public?这下颠覆理论了,难道我们的防火墙有这么大的缺陷,两个绑定了VPN实例的三层接口之间三层转发报文,源和目的安全区域居然是不带VPN的?

大家先不要怀疑产品质量问题,我们大胆假设,如果这个ICMP报文就是在防火墙上二层转发呢?那我们得先逮到这个报文看一看。

于是,现场在S9706互联S1服务器的物理端口上进行带ACL抓包,如下:(这里跟大家解释一下,现场交互报文太多,ICMP报文确实有抓到,但是忘记保存了,这里就给大家看一个TCP的报文吧,原理是一样的)


眼力好的同学应该发现了吧,目的MAC居然是C公司SWMAC


真相还原,网络中存在一个诈骗犯,那就是C公司SW,如上图所示。原来,本次业务割接需要把C公司SW设备上的VLANIF65网关10.60.65.1割接至S9706上,而割接完成后,客户忘记了在C公司SW上删除VLANIF65,导致问题。

另外,对于之前提到的在防火墙上生成的Public流表,也很容易解释了,因为防火墙将Eth-trunk1加入了trust安全区域,而将Eth-trunk2加入了dmz安全区域,这两个接口加入的都是Public安全区域,所以生成了上述流表。

根因

C公司SW设备上存在与S9706相同的VLANIF65IP地址,导致服务器端学习到了错误的网关MAC,业务中断。

解决方案

C公司SW设备上删除VLANIF65IP地址,业务随即恢复。

建议与总结

当一些难以理解的问题现象出现的时候,不能一味的怀疑产品质量问题,我们应该首先在假设产品没有问题的情况下,大胆假设,抽丝剥茧,定能还原问题真相!

END