蚂蚁网-多维人生，三实而立！

【转】华为防火墙报文处理流程简介

作者：易隐者 发布于：2014-11-25 22:42 Tuesday 分类：参考资料

【原帖作者】：强叔侃墙

【原帖名】：【强叔侃墙 内功心法篇5】扫地神僧是怎样练成的----防火墙报文处理流程简介

【原帖链接】：http://support.huawei.com/ecommunity/bbs/10225529.html

强叔被金庸大侠影响甚深，年少时曾手捧老先生各大部头废寝忘食，至今仍对多个经典情节念念不忘。早在十多年前，便与同道兄弟充分讨论过：金庸作品中，最厉害的招式应是独孤九剑，因令狐冲在内力全失情况下，一剑挑瞎十五人眼睛；而最厉害的内功当属扫地僧的内功，秒掉了萧峰父子和慕容父子，算得上前无古人、后无来者。最要命的是，我们无从得知扫地神僧是怎样练成的，这让强叔一直心痒不已。
而回到强叔开讲的防火墙，强叔绝不能让各位小伙伴一直抓耳挠腮--掌握了防火墙报文处理流程，就是掌握了防火墙实现的精髓，就如练成了扫地神僧的内功。表面上看来还是原来的小伙伴，也许貌不惊人，但其实内心那是相当地强大。当你能够娴熟地定位防火墙配置类故障，无论走到哪里，都会如那漆黑中的萤火虫一样，那样的鲜明，那样的出众，那样的拉风~~

 

在《华为防火墙产品一览》中，强叔曾介绍：华为出品低、中、高端共三个系列防火墙，对应当前的主力产品型号分别为USG2000、USG5000和USG9000。<注>2013年8月发布了下一代防火墙USG6000系列，强叔后续针对性详述。这三个系列产品毫无疑问都基于状态检测与会话机制实现，但是中低端防火墙与高端防火墙在架构实现上有些区别：中低端防火墙采用集中式架构，高端防火墙采用分布式架构，这使得它们在对报文处理的实现上，稍有不同。不过这个稍有不同并不影响主线，强叔的思路是单刀直入，先讲大同的报文处理流程（同样会话机制），再强调求同存异（架构差异影响）。

 

华为大同：全系列状态检测防火墙报文处理流程

下面先以USG5500系列产品为例，梳理防火墙报文处理流程。
状态检测与会话机制是华为防火墙对报文处理的关键点：即防火墙收到报文后，何时、如何创建会话、命中会话表的报文被如何转发。那么可以此关键点为界线延伸，我们将报文经防火墙处理分为查询会话表前、中、后三个阶段，参见如下USG5500报文处理全景图。友情提醒：图很复杂，对三个阶段有印象即可，重点看图下的文字拆解吧。

我们来进一步介绍下每个阶段的目的和处理过程。
1、 查询会话之前的处理过程：基础处理。
这个阶段的主要目的是解析出报文的帧头部和IP报文头部，并根据头部当中的信息进行一些基础的安全检测（单包攻击防范）。
2、 查询会话的处理过程：转发处理，关键是会话建立。
这个阶段到了防火墙对报文转发处理的核心。建立会话表，根据会话表转发报文，是状态检测防火墙的精髓。此部分要梳理清楚思路，耗费很多笔墨，还请小伙伴们耐心观看。
报文到此阶段，防火墙最先判断该报文是否要创建会话。
1）OSPF、IGMP组播报文等一些协议报文是不创建会话的，那么这些报文就会去直接查路由和安全策略。
2）而TCP首包、UDP等报文都需要创建会话，那么判断该报文要创建会话后，接下来马上查询会话表中是否已经创建了该报文的会话。

• A. 对于会话表中不存在匹配任一表项的报文，防火墙判断该报文为某一流量的首包，进行首包处理流程。
• B. 对于会话表中存在匹配表项的报文，防火墙判断该报文为某一流量的后续包，进行后续包处理流程。

这也是强叔在《状态检测和会话机制》一节中提到的“为数据流的第一个报文建立会话，数据流内的后续报文直接根据会话进行转发，提高了转发效率。”
首包处理流程要点：
（1）先使该报文与黑名单匹配，若报文源地址命中黑名单，则此报文被丢弃，不再继续后续流程。
（2）查询该报文是否命中正反向Server-map表，若报文命中Server-map表，记录Server-map表中的信息。

（3）继续根据（2）的记录结果，查询命中哪条路由，优先查询策略路由。若未命中策略路由，则查询正向路由表，决定报文的下一跳和出接口。

         这里说明下：为什么要强调根据（2）的记录结果呢？因为此时报文未进行实质转换，但查询路由是使用虚拟出来的、命中Server-map表经转换后的报文查询，这是为了最终经过防火墙各种处理完毕的报文能够正确转发。

（4）查询是否命中安全策略，已知报文入接口源地址、判断出报文出接口后，可以查询到该出入接口所在安全区域的安全策略配置，若报文没有匹配到安全策略或匹配到安全策略中定义为“阻断”的规则，则报文被丢弃，不再继续后续流程；若报文匹配安全策略中定义为“允许”的规则，则继续后续流程。
（5）查询是否命中源NAT策略，若报文匹配到一条源NAT策略，则记录NAT转换后的源IP地址和端口信息。
（6）顺利通过安全策略匹配检查后，终于走到这一步：根据上述记录结果，创建会话。

后续包处理流程：

很简单，判断会话是否需要刷新。当为首包创建会话的各表项和策略（如路由表、安全策略）变化时，会话需要刷新。若需要则继续查询路由、查询安全策略，若不需要直接进行后续阶段处理。

 

总结：

• 强叔在开篇中提到防火墙与路由器的区别，对于路由器来说可说是使出浑身解数（通过路由表）将报文转发出去，而对于防火墙来说要作为守护神坚决阻挡非法报文（只有通过各种安全检查建立会话表才可能被转发）。所以防火墙丢弃一些报文是正常的处理流程，包括第一阶段的解决IP报文头、单包攻击，第二阶段的黑名单、安全策略，第三阶段的UTM处理、限流等等，是报文的主要丢弃点。
• 进行故障定位时，防火墙上是否创建了指定某条流量的会话，是定位要考虑的关键界线。若未创建会话，则考虑是报文是否到达设备、接口丢包、命中黑名单或安全策略、无路由、或NAT等配置出现问题；而存在会话，则向后续的安全业务处理阶段考虑。

 

3、查询（或创建或刷新）会话的处理过程：进行实质各安全业务处理、及之后的报文去向。

报文在首包处理流程中经一通查询、创建会话后，就与后续包处理流程殊途同归了，即都进入第3阶段。
此阶段首先进行基于IP的限流、IPS等UTM业务处理，报文顺利通过检查之后，到了实质性的地址转换：根据已创建的会话表，进行目的地址转换、源地址转换。
这个目的地址转换、源地址转换对应配置就是NAT Server、源NAT策略等NAT功能，对应报文则是在第2阶段首包流程中已经经过一通查询并创建了会话表。
那么，如果想要在此阶段能够准确地对报文进行源地址转换，有两个常见的points需要关注：

• 一是报文在前面流程中是否命中了Server-map表，尤其是反向Server-map表，若已经命中，那么报文会根据反向Servermap表进行源地址转换，不会再往后匹配源NAT策略了。
• 一是报文在后续流程中是否计划要进行VPN加封装，如果在此时定义该条数据流进行了NAT转换，那么后续就无法进入VPN协商流程了。

而按计划进行目的地址转换问题不大，一般是配置NAT Server，其报文处理优先级很高，报文走入歧途可能性就小。

最后，该转换转换，该过滤过滤，一切安全业务流程顺利通过后，报文终于到了分发十字路口：
A. 如ping、OSPF等路由协议报文是要到防火墙本身，会被上送至管理层面处理；
B. 如VPN报文（防火墙为隧道终点，收到VPN报文）就会被解封装、并在解封装后重走一次上述1、2、3流程；
C. 如准备进入VPN隧道的报文（防火墙为VPN隧道起点）就会被进行VPN封装等等。

 

求同存异：集中式与分布式防火墙差异对报文处理流程影响 

 防火墙大同的报文处理流程介绍完毕，我们来看一下集中式与分布式架构的区别会导致哪些差异。

• 对于集中式低端防火墙，来往报文会被上送至一个集中的CPU模块（可能由多个CPU组成）进行处理。
  集中式防火墙一般为盒式设备，可以插接多种扩展接口卡，但设备的总机性能恒定，即取决于该设备配置的CPU模块处理能力。上述介绍的USG5500产品报文处理流程即为其全部流程。
• 对于分布式高端防火墙，对报文的处理就会比较复杂，有多种情况，上述介绍的报文处理流程是其中一个最核心的子集—SPU板业务处理流程。

分布式防火墙一般为框式设备，以USG9000来说，由两块标配主控板MPU、交换网板SFU、接口板LPU、业务板SPU组成，其中LPU与SPU的槽位可混插，客户按需购买。相比集中式防火墙，分布式防火墙由各种单板组成，每种单板各司其责。

• 主控板MPU：主要负责系统的控制和管理工作，包括路由计算、设备管理和维护、设备监控等。
• 交换网板SFU：主要负责各板之间数据交换。
• 接口板LPU：主要负责接收和发送报文，以及QoS处理等。
• 业务板SPU：主要负责防火墙的安全业务处理，包括安全策略、NAT、攻击防范、VPN等。设备总机性能随插接SPU板的数量增加而线性增加，这是分布式防火墙的特性和价值所在。

那么我们来看一下，各类报文在分布式高端防火墙上是如何被处理的：

已经提到①②是防火墙业务处理的核心，也正是防火墙的安全防护价值所在。③④多用于设备管理、定位故障；⑤⑥多用于网络互联如路由学习。

 

还有一个更复杂的问题：当一台分布式防火墙配置多个业务板时，报文经过接口板处理后，会被送至哪个业务板呢？如上图中的①②③④报文都会经业务板处理，那么会被送至SPU1还是SPU2呢？
这时会有选择“由哪块SPU板进行业务处理”的动作，即USG9000产品文档中提到的hash选板。默认配置是根据报文的源+目地址经过运算选择。----由于配置了多个SPU板，业务可能在防火墙多个业务板分别建立会话。
例如，以PC访问Web服务器来说，假设PC发往Web服务器在业务板SPU1上建立了会话，而Web服务器的回应报文可能会由业务板SPU2处理。一句话就是请求报文与回应报文有可能被分配到防火墙的不同业务板处理。那么可能会产生一个问题：由于请求报文基于业务板SPU1建立了会话，而回应报文查不到反向会话被丢弃。实际上，USG9000在建立业务板的会话表时，同时会进行hash预测，准确预测回应报文会被哪块业务板处理，在该业务板上同步建立起一条反向会话，保证回应报文能够被正确转发。当然，正反向会话间会定时同步，保证同步老化、统计报文信息等等。

配置实例：与防火墙报文处理流程相关的配置技巧

下面我们以实例来说明，熟悉防火墙报文处理流程，不需要再死记配置限制，而是根据逻辑直接判断如何正确配置。
例1，当安全策略遇上NAT Server。
在eNSP模拟器上，PC1（1.1.1.2）----防火墙USG5500----FTP服务器（192.168.1.2）简单组网，在防火墙上配置NAT Server，将FTP服务器地址转化为与PC同一网段的地址，配置如下：

[USG5500] nat server 0 global 1.1.1.5 inside 192.168.1.2

若希望PC1及其他多个PC能且只能访问该FTP服务器，应该如何配置严格的安全策略？实际是基于固定的目的地址配置安全策略问题。

分析：根据防火墙报文处理流程，先进行NAT Server转换、查询Server-Map表，再进行安全策略处理。那么，该固定的目的地址，应配置为该FTP服务器的真实地址（即inside地址）。

[USG5500] dis cu | include policy                          

policy interzone trust untrust inbound                      

 policy 0                                               

  policy destination 192.168.1.2 0.0.0.0    

验证如下：
1）关闭防火墙所有域间缺省包过滤，只保留上述在trust与untrust域间配置的该条安全策略。
2）在PC上访问FTP服务器，可以成功看到FTP服务器的文件列表。 

 

 

3）查看防火墙USG5500会话表，可以看到FTP服务器已经做了NAT Server，且FTP控制通道与数据通道均已建立。

结论：根据防火墙报文处理流程，先查询Server-Map表，根据查询的记录结果再进行安全策略处理。当需求为允许多个外网客户端访问经过NAT Server转换的服务器时，安全策略配置允许到达的目的地址为该服务器的内网真实地址，而非NAT Server的global地址。

 

例2，当源NAT遇上NAT Server。
某公司分部与总部互联组网和关键配置如下，其中HTTP Server无法访问分部资源，而其他通信完全正常。

分析：防火墙上涉及HTTP Server的配置如下：
① NAT Server，将HTTP Server的私网192.168.1.2：80映射成为1.1.1.1：9980
②源NAT，策略定义192.168.1.0网段去往分部不进行源NAT转换
查看防火墙的Server-map表：

NAT Server转换成功，生成正反向Server-map表。且按照反向Server-map表含义，当该HTTP Server主动访问网络时，亦进行NAT Server转换。根据防火墙报文处理流程，优先查询正反向Server-map表，命中反向Server-map表后，源NAT不再生效。这个问题的解决办法是，配置NAT Server时增加no-reverse参数，要求不生成反向Server-map表，这样总可以继续查询NAT策略，使该HTTP Server可以正常访问分部资源。
结论：上述报文处理流程第3阶段时已进行提醒，进行源NAT处理时，注意报文在前面流程中是否命中了Server-map表，尤其不要忽略反向Server-map表，如果已经命中，此时源NAT处理不会再生效。

 

防火墙配置类问题与报文处理流程相关的，可能还有很多，本文难以穷尽，只捡两个实际常用NAT功能的例子抛砖，供小伙伴参考。本文笔墨颇多，逻辑难免有不严谨之处，请小伙伴琢磨指证。

强叔研习金庸多年，可只见一个扫地神僧往来无古今，亦只闻一曲笑傲江湖流传千百年。世上没有什么捷径，掌握防火墙的转发精髓仍需在处理问题实践锻炼中不断琢磨，在参考材料字里行间中不断思考，本文仅提供神功练成的入门之法，强叔与小伙伴们一同继续修行吧。

阅读全文>>

标签: 防火墙 报文处理流程 华为防火墙 状态监测 华为

评论(0) 引用(0) 浏览(13978)

服务器经网关地址映射访问时的注意事项

作者：易隐者 发布于：2013-6-20 22:05 Thursday 分类：网络分析

        有朋友在用户现场遇到一个故障无法定位，网上找我帮忙，大概情况是某内网用户将一台服务器端口映射出去供互联网访问，内部主机通过互联网地址进行访问测试时，发现无法正常连接。

       我让其在服务器区域前端防火墙上抓客户端与服务器交互的报文，如下：

10:33:28.747771 R@eth3 IP 172.16.7.68.8525 > 172.16.2.146.3389: S 3134287530:31
34287530(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//客户端发起SYN请求
10:33:28.747786 X@eth4 IP 172.16.7.68.8525 > 172.16.2.146.3389: S 3134287530:313
4287530(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//防火墙内口转发客户端的SYN请求
10:33:28.748165 R@eth4 IP 172.16.2.146.3389 > 172.16.7.68.8525: S 3568427973:356
8427973(0) ack 3134287531 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//服务器响应客户端的SYN报文
g10:33:28.748172 X@eth3 IP 172.16.2.146.3389 > 172.16.7.68.8525: S 3568427973:356
8427973(0) ack 3134287531 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//防火墙转发服务器响应报文
10:33:28.749519 R@eth3 IP 172.16.7.68.8525 > 172.16.2.146.3389: R 3134287531:313
4287531(0) win 0
10:33:28.749523 X@eth4 IP 172.16.7.68.8525 > 172.16.2.146.3389: R 3134287531:313
4287531(0) win 0
//客户端发送RST报文

       客户端发起SYN连接请求，防火墙转发，服务器响应SYN/ACK报文，这个过程都是正常的，但是紧接着却是客户端发送RST报文，异常释放了这个TCP连接。单从这个数据包交互的过程来看，大部分的人都会认为是客户端的问题。

       但是其实跟客户端完全无关。我很早以前在天融信做工程师时曾今在用户 处遇到过同类型的问题，当时解决完之后曾打算将其作为一个经典案例写下来供大家分享，后来由于时间问题，拖时间长了，原始报文找不到了，只能作罢，今天就 这个案例，我来做一个简单的分析和说明，以供大家参考。

        我们在用户现场经常会遇到这样的客户需求：

1，用户希望通过通过防火墙等设备的端口映射/地址映射功能实现内网服务器对互联网访问者提供服务的需求；

2，为了使用方便，用户一般都会同时要求内部客户端也可以直接通过服务器映射后的互联网地址进行访问。

       第一点需求非常容易实现，在防火墙上做一个常规的地址映射/端口映射，再将服务器对外提供服务的端口放行即可。但是在实现用户第二点需求时，我们需要注意一个关键的问题，那就是客户端与服务器端的报文来回路径不一致问题。

        我们先将故障发生时的报文交互过程跟大家一起分析一下，其交互过程大致如下图所示：
       这个交互的过程具体描述如下：
1）    客户端访问经网关设备映射出去的服务器的互联网地址，向其发送SYN报文；
2）    客户端访问的目的地址经网关转换为内网服务器真实地址之后，转发至内网服务器，此时报文的源IP地址是真实的内网地址（另外一种处理情况为出口网关将该报 文经NAT后至转发出互联网接口，然后再匹配识别为内网服务器的映射的策略，再次将该报文转发至内网服务器，此时报文的原IP、目的IP地址均发生变化 了，此种情况下由于报文原IP地址已经改变为NAT后的互联网地址，因此不在我们的讨论的范畴之内，这个跟网关设备对数据报文处理的流程有关,在此不详细 讨论，有兴趣的同学可仔细思考思考。）；
3）    内网服务器在接受到这个报文之后，直接向客户端内网IP发送SYN/ACK报文；
4）    内网客户端接收到服务器的SYN/ACK报文,但是客户端的TCP连接表中并没有与之相应的信息（因为客户端是与服务器映射后的互联网地址发送SYN请求报文的），因此，客户端向服务器发送RST报文。

5）    服务器端收到这个RST报文之后，其会将这个TCP连接释放，因此客户端连接服务器失败。

       那么，在这种情况下，我们如何解决这个问题呢？

       其实，解决的方式就是在网关处增加一条源地址转换策略，将访问服务器的客户端地址转换为一个互联网地址或网关内部接口地址，如此巧妙的让服务器回包给网关（防火墙），从而保证客户端、服务器的报文来回路径一致。

       NAT在很多复杂环境下的确能够帮助我们巧妙的解决很多令人头疼的问题，我在博客文章《某公司业务系统经ISA防火墙访问正常而经硬件防火墙访问慢故障分析解决案例》中曾今在文章后面留下一个思考问题，至今无人应答，我也没给出答案，其实答案就是NAT。有兴趣的兄弟自行去查看那篇文章吧，在此我不做展开了，当然NAT也可能会带来一些意想不到的问题，以前遇到过一个案例，等我有空的时候再整理发布吧。

       这个用户现场案例，我们通过在防火墙中增加一条源地址转化策略之后，再次以互联网地址访问服务器，正常，数据包交互如下：

10:37:54.637923 R@eth3 IP 172.16.5.253.9182 > 172.16.2.146.3389: S 223750126:
223750126(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
10:37:54.637943 X@eth4 IP 172.16.5.253.9182 > 172.16.2.146.3389: S 223750126:223
750126(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//客户端发起SYN报文
10:37:54.638373 R@eth4 IP 172.16.2.146.3389 > 172.16.5.253.9182: S 892121112:892
121112(0) ack 223750127 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
10:37:54.638379 X@eth3 IP 172.16.2.146.3389 > 172.16.5.253.9182: S 892121112:892
121112(0) ack 223750127 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//服务器响应SYN报文
10:37:54.639048 R@eth3 IP 172.16.5.253.9182 > 172.16.2.146.3389: . ack 1 win 584
00
10:37:54.639052 X@eth4 IP 172.16.5.253.9182 > 172.16.2.146.3389: . ack 1 win 584
00

//客户端确认，连接建立   

        这个案例就到这吧，大家自己多去体会。

阅读全文>>

标签: TCP RST SYN 防火墙 NAT 地址转换 网关 来回路径不一致 映射

评论(3) 引用(0) 浏览(36048)

《某公司QQ掉线分析案例》之我见

作者：易隐者 发布于：2013-4-14 17:52 Sunday 分类：案例讨论

       大致看了分析过程之后，觉得其中存在一些疑问，特地找时间针对这个案例做一个大致的分析，以便大家讨论参考。原本准备做相关交互图示的，由于个人时间问题，这次就免了，还望各位见谅。

1， QQ多人同时掉线，大约1秒就自动连上，浏览网页和其他应用没有问题  

       QQ属于一种终端的应用，一般情况下，局域网内某应用出现同时掉线、缓慢等问题，基本上可以排除是单个终端的问题，因为从这个现象上来看，这是一个全局问题，可能是业务应用本身、业务服务器或者承载业务的网络系统出现了问题。在此故障分析案例中，作者提到QQ同时掉线但是浏览网页和其他应用没有问题。通过这个故障现象的描述，我个人首先可能会想到整个互联网出口是否会出现网络瞬间中断的情况？这是我个人的猜想，因为如果真是互联网出口出现网络瞬间中断，那么HTTP等基于TCP的应用由于TCP的重传机制，在出口网络中断1秒左右的时间内，终端使用者不会有明显的异常感受，而基于UDP等应用，可能会出现掉线等现象，在网络出口恢复正常之后，QQ再次自动上线。这个猜想的原因至少可以很好的解释该案例作者一开始描述的故障现象。

2， QQ掉线是QQ服务器主动RST连接导致的，腾讯给出的解释是由于用户端IP地址出现了变化。

1），QQ大部分情况下应该是使用UDP协议的，少数情况下使用TCP协议。

       QQ是一个较为复杂的应用，其为了满足使用者在各种复杂的环境对QQ的正常使用，其会存在多种模式和网络交互行为，大部分情况下，QQ默认会使用UDP协议进行交互，少数情况下会使用TCP甚至TCP的80端口、443端口进行交互，特殊情况下，根据需要和设置，其还可以通过代理的方式进行交互。

       在该案例中，测试机的QQ似乎使用的是TCP443端口进行交互的，但其实绝大部分情况下，QQ都是基于UDP协议进行交互的。因此在此案例中，按照我个人较为严谨的分析习惯，测试机的选择非常值得做进一步的商榷。

2），就算这个客户网络中所有使用的QQ都是基于TCP协议的，如果真是如腾讯所说，是由于QQ服务器发现用户IP出现了变化，才向客户端发送RST报文的，那么：

该RST报文ACK位是置一的，因此这个RST报文并不是如作者想象的情况下产生的。

       其三，我们再来看另外一张截图：

3，如果真的是防火墙的NAT出现了这种低级的错误和BUG，那么对用户影响最大的应该是HTTP等基于TCP应用。因为很多HTTP应用的动态口令、验证码等都需要通过数个不同的TCP连接与服务器进行交互，一旦出现该案例作者所说的防火墙处理BUG，将导致这些应用出现访问故障。而不会仅仅是无关紧要的QQ应用出现问题。

4，QQ掉线而其他TCP应用正常，很可能是防火墙的UDP会话保持时间过短导致的。

       因为很多人挂QQ并不一直与好友聊天。而一般情况下，防火墙等为节约设备资源，会将UDP的会话超时时间设置为一个较短的数值，如60秒，那么如果用户在这个超时时间内无任何数据交互的话，防火墙会将这个UDP会话从防火墙连接表中删除，当QQ客户端再次尝试与QQ服务器交互时，其发送的QQ状态更新报文就会被防火墙丢弃，导致QQ客户端掉线。QQ掉线后，客户端会再次发起新的连接，此时防火墙将其作为一个新建的UDP连接进行处理，QQ因此再次成功上线。当然这个很难解释QQ同时掉线的现象。

5，在NAT POOL情况下，NAT设备会根据不同的算法（基于源IP的、基于连接的等）实现NAT POOL的地址复用，大部分算法应该都是基于源IP等计算的，如果是基于数据包、连接等进行计算，则很可能会导致各种问题的产生，我以前有一个非常经典的案例——《移动无线VPN客户端隧道建立故障分析》，下次我发布到我的博客，大家可去参考。 

简单总结：

阅读全文>>

标签: TCP RST 五元组 重传机制 防火墙 BUG NAT QQ掉线

评论(3) 引用(0) 浏览(14006)

某公司业务系统经ISA防火墙访问正常而经硬件防火墙访问慢故障分析解决案例

作者：易隐者 发布于：2013-1-25 10:10 Friday 分类：案例讨论

1 故障环境

      这个故障产生的环境较为简单，我们在不影响故障分析的前提下，简化分析网络环境，其故障发生的拓扑结构大致如下所示：

1.1 网络拓扑

1，业务服务器的IP为16.66.252.249/24，网关为16.66.252.254；

2，测试客户端的IP为16.66.180.167/24，网关为16.66.180.1；

3，防火墙与服务器相连的接口地址为16.66.252.254，防火墙与测试客户端相连接口的地址为16.66.180.1；

4，防火墙工作在纯路由模式下；

1.2 业务访问流程

2，测试客户端将数据报文经过硬件防火墙转发至业务服务器端，业务系统根据测试客户端的相关请求，返回业务应用数据报文经硬件防火墙转发给测试客户端；

2 故障现象

       经过与用户的交流和现场的测试，确定故障现象主要表现为以下几点：

1，客户端经过ISA访问业务服务器，测试连接速度非常快；

2，将ISA换成天融信硬件防火墙，硬件防火墙工作在纯路由模式下，测试发现客户端连接业务服务器的大概需要消耗20秒左右的延时；

3，用户反馈，测试过使用cisco的ASA和H3C的硬件防火墙，均有不同程度的较大的连接延时；

3 故障分析

3.1 分析过程

3.1.1 确认是否是硬件防火墙产生的延时

       经过ISA防火墙，业务系统连接测试一切正常，速度很快，但是经过硬件防火墙（TOPSEC/CISCO/H3C）之后，就产生了较大的延时，那么看起来似乎是硬件防火墙产生的延时，我们先从这个角度入手，在测试客户端与业务服务器端同时抓包做对比分析，用于确认是否是硬件防火墙产生的转发延时。

 这个延时不是硬件防火墙产生的，而是业务系统应用产生的。

3.1.2 分析经过ISA防火墙时的业务交互情况

       既然这个延时是业务应用本身产生的，跟硬件防火墙完全无关，那么为什么经过ISA访问的时候，连接测试一切正常呢？

5，应用测试连接成功，客户端主动通过TCP四次握手过程，正常释放TCP连接；

       上述过程清晰的展示了客户端在经过ISA访问服务器时，应用连接建立的时间是非常短的，速度非常快。

3.1.3 分析经过硬件防火墙时的业务交互情况

 NBNS解析成功后，服务器端才向客户端发送应用层连接请求响应数据报文；

 4，通过上图的数据交互情况分析，我们可以得出以下两点结论：

 17秒的延时，就是服务器4次DNS反向解析失败产生的。

3.2 分析结论

       通过上面一系列的分析，我们可以确定，导致该故障产生的核心原因是业务系统程序的处理机制异常导致的。

4 故障解决

       我们知道了经过硬件防火墙访问业务系统变慢的原因是因为业务服务器在接收到客户端的应用请求时，需要针对客户端的IP地址做一个反向名字解析，那么我们可以通过在业务服务器的hosts列表中添加客户端的IP对应的主机名，以此来避开服务器的反向DNS名字解析过程，从而解决了业务系统慢的问题。此方法已经现场测试验证有效。

阅读全文>>

标签: 疑难故障 防火墙 DNS ISA

评论(7) 引用(0) 浏览(10915)

可能的URL超长导致丢包案例

作者：易隐者 发布于：2012-12-10 14:03 Monday 分类：案例讨论

       上周五，有网友兄弟给我发了一个报文，让我帮忙查看是否存在什么异常问题。我查看其TCP会话交互过程，如下图所示： 

       单从这个报文交互来看，客户端与服务器的TCP连接建立正常，客户端已经向服务器发送过get请求，并得到了服务器的确认，问题出在客户端向服务器发送的第二个get请求：“
http://192.168.0.12/Default_Login.aspxusercode=x6x9&password=81xx9xxx52x04xx20036xxx8313xx055&

MyCurrentCompany=&rdnum=0.5966797953405811”。

       客户端发出这个get请求之后，在37秒的时间内重传了5次，服务器端无应用数据需要主动的发给客户端，因此在这个时间段内我们未见来自于服务器的报文，而如果客户端的发送的这个get请求到达了服务器端，则服务器会根据其请求内容作出应用响应，最起码服务器端会对客户端的TCP报文发送ACK确认。但是这些都没有出现，这能够说明客户端的get请求报文根本未到达服务器端，即客户端的这个get请求报文被中间设备丢弃了，我们查看客户端的发送的第二个get请求报文的解码：

       我们发现这个报文除了其请求的URL长度较长（420字节）外，其他似乎也没什么特别的，因此，个人推测其被中间设备丢弃的原因可能是其URL超出了防火墙/负载均衡/WAF/IPS等设备的限制，或者是URL中包含“uesr”、“password”等敏感字段而被中间设备丢弃了。

阅读全文>>

标签: TCP 负载均衡 解码 ACK确认 防火墙 IPS get URL超长 get请求

评论(3) 引用(0) 浏览(6540)