欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

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

作者:易隐者 发布于: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) 浏览(33397)

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

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

       前段时间看到CSNA论坛上有一篇QQ掉线故障分析的案例,原文是PDF格式的,我就不转载其全文了,其链接如下 : http://www.csna.cn/network-analyst-50520-1-1.html,大家可自行通过上述链接下载查看。

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

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这种特殊应用工作机制的多样性和复杂性,导致我们在遇到其故障时,给我们的分析定位带来了难度。在该案例中,由于QQ是大规模的出现掉线现象,我们在分析处理时,其实根本搞不清楚不同使用者的QQ到底是工作在何种模式之下,其网络行为特征千差万别,因此,我们很难通过某一台测试机来全面分析验证QQ故障的原因。

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

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

       其一,不同的QQ客户端与QQ服务器是单独建立连接的,暂且不论QQ服务器的多样性(不同的QQ客户端很可能会与网络中的N个不同的QQ服务器之间建立交互链接),不同的QQ客户端与QQ服务器之间建立不同的交互连接,那么即使防火墙在做NAT时出现BUG,突然改变了某些已有连接的源IP地址,也应该绝少出现同时改变N个不同QQ客户端与服务器之间已有连接的源IP,换句话说,如果原因真是如该案例作者所说,很难解释QQ同时掉线的现象。
       其二,那么我们站在QQ服务器的角度来分析一下此种情况真的发生时,QQ服务器会作何处理?QQ服务器收到源IP地址变化的QQ客户端报文后,QQ服务器会把他作为一个新的TCP连接来处理(因为五元组不一样),而QQ服务器并没有这个TCP连接信息,因此服务器会直接RST该报文,而这种RST报文,其ACK位肯定不会置一的,但是我们看到这个案例中作者的截图如下:
 点击查看原图

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

       其三,我们再来看另外一张截图:

点击查看原图
        看此交互截图,QQ服务器已经对客户端的报文作出了确认(序号2230的包),紧接着(0.000045秒后),QQ服务器向客户端发送RST报文(序号 2232的包),这个报文可以肯定在服务器紧接着发出序号2230的包之后发出的,如果按照作者的说法,RST报文至少应该是序号为2231的客户端报文经防火墙源地址转换之后(源IP变化),到达QQ服务器,QQ服务器发现源地址变化,再向客户端发送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同时掉线的现象。

       另外一种情况是,如果防火墙的UDP连接表出现异常,防火墙突然清空其UDP连接表,也可能会导致该案例中故障现象的产生。

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

简单总结:

       防火墙在NATPOOL情况下,变化地址是正常的,关键看防火墙的NAT算法。QQ掉线应该跟这个无关,案例中分析来自于QQ服务器的RST报文跟NAT后源地址变化无关。

阅读全文>>

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

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

TCP/IP 数据包处理路径

作者:易隐者 发布于:2012-11-13 16:09 Tuesday 分类:参考资料

简介

       随着 Microsoft® Windows® XP Service Pack 2 和 Windows Server™ 2003 Service Pack 1 新增了 Windows 防火墙,以及 Internet 协议安全 (IPsec) 在公司 Intranet 中日益广泛的应用,信息技术 (IT) 专业人士需要了解 TCP/IP 协议及 Windows 中的相关组件处理单播 Internet 协议 (IP) 数据包的具体方式。有关 IP 数据包处理路径的详细知识,可以让您更轻松地掌握配置数据包处理和筛选组件,以及进行相关疑难解答的具体方法。

        本文所介绍的内容如下:

• 用于 IP 版本 4 的 TCP/IP 协议的基本体系结构以及其它一些用于处理数据包的组件。
• 基于 Windows 的计算机所发送、接收和转发的单播流量的数据包处理路径。

         注意:为了简要起见,本文将不讨论多播、广播、分段或隧道数据包。

用于数据包处理的 TCP/IP 体系结构

         下图为 TCP/IP 协议驱动程序 (Tcpip.sys) 及其用于在 Windows XP Service Pack 2 和 Windows Server 2003 Service Pack 1 中处理 IP 数据包的相关组件的简要示意图。 

点击查看原图

         下列组件可处理 IP 数据包:

• IP 转发 为发送或转发的数据包确定下一跃点接口和地址。
• TCP/IP 筛选 允许按 IP 协议、TCP 端口或 UDP 端口,指定可为传入的本地主机流量(发往主机的数据包)所接受的流量类型。可以在“网络连接”文件夹中,从 Internet 协议 (TCP/IP) 组件高级属性的“选项”选项卡,配置 TCP/IP 筛选。
• 筛选器挂钩驱动程序 该 Windows 组件可使用筛选器挂钩 API,筛选传入和传出的 IP 数据包。在运行 Windows Server 2003 的计算机上,筛选器挂钩驱动程序为 Ipfltdrv.sys,属于“路由和远程访问”的一个组件。启用后,“路由和远程访问”允许用户使用路由和远程访问管理单元,对每个接口配置单独的入站和出站 IP 数据包筛选器。Ipfltdrv.sys 会同时检查本地主机和中转 IP 流量(不发往主机的数据包)。
• 防火墙挂钩驱动程序 该 Windows 组件可使用防火墙挂钩 API,检查传入和传出的数据包。在运行 Windows XP 的计算机上,防火墙挂钩驱动程序为 Ipnat.sys,由 Internet 连接共享和 Windows 防火墙双方共享。Internet 连接共享是一种基础网络地址转换器 (NAT)。Windows 防火墙是一种基于主机的状态防火墙。Ipnat.sys 可同时检查本地主机和中转 IP 流量。在运行 Windows Server 2003 的计算机上,Ipnat.sys 由 Internet 连接共享、Windows 防火墙和路由和远程访问的 NAT/基本防火墙组件三方共享。如果启用了路由和远程访问的 NAT/基本防火墙组件,就不能再启用 Windows 防火墙或 Internet 连接共享了。
• IPsec IPsec 组件——Ipsec.sys——是 IPsec 在 Windows 中的实现,可对 IP 流量提供加密保护。Ipsec.sys 可同时检查本地主机和中转 IP 流量,并可允许、阻止或保护流量。

数据包处理路径

       下面几节介绍了针对以下流量的具体的数据包处理路径:
• 源流量 由基于 Windows 的发送主机发起。
• 目标流量 达到最终的基于 Windows 的目标主机。
• 中转流量 由基于 Windows 的 IP 路由器转发。
       这里只讨论 Windows Server 2003 或 Windows XP 所附带的组件,不涉及 Windows 套接字分层服务提供程序或 NDIS 中间微型端口驱动程序。

源流量

        源流量的数据包处理路径如下图所示。 

点击查看原图

1. IP 数据包形成后,Tcpip.sys 就会将其传递给防火墙挂钩驱动程序 (Ipnat.sys) 进行处理。

        Windows 防火墙检查该流量是否属于所要阻止的特定的 Internet 控制消息协议 (ICMP) 消息类型。如果 ICMP 消息被阻止,Windows 防火墙就将丢弃该数据包。
       Windows 防火墙检查该流量是否属于点对点隧道协议 (PPTP) 隧道维护流量。如果属于的话,Windows 防火墙将分析该流量,确定用于识别特定 PPTP 隧道的通用路由封装 (GRE) 调用 ID,从而允许 PPTP 隧道的基于 GRE 的传入流量。
       如果需要,Windows 防火墙会在例外列表中添加一个动态项目,来允许响应流量。
       处理完后,Ipnat.sys 会将该 IP 数据包传回给 Tcpip.sys,而后者会使用 IP 转发组件,确定下一跃点 IP 地址和接口。有关详细信息,请参阅认识 IP 路由表。

2. Tcpip.sys 将数据包传递给筛选器挂钩驱动程序 (Ipfltdrv.sys) 进行处理。

       Ipfltdrv.sys 根据下一跃点接口,将该数据包与已配置的出站 IP 数据包筛选器进行对比。
       若出站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该数据包。若出站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该数据包传回给 Tcpip.sys。

3. Tcpip.sys 将该数据包传递给 Ipsec.sys 进行处理。

       Ipsec.sys 根据 IPsec 筛选器组,决定是否允许、阻止或保护该数据包。若允许的话,Ipsec.sys 会在不修改该数据包的情况下,将其发回给 Tcpip.sys。若阻止的话,Ipsec.sys 会在不发出任何提示的情况下,丢弃该数据包。若要进行保护的话,Ipsec.sys 会在将数据包传回给 Tcpip.sys 之前,对其添加适当的 IPsec保护。Tcpip.sys 随后会通过下一跃点接口,将该数据包发送到下一跃点 IP 地址。

目标流量

       目标流量的数据包处理路径如下图所示。 

点击查看原图

1. 接收到 IP 数据包后,Tcpip.sys 会将其传递给 Ipsec.sys 进行处理。

       若数据包带有 IPsec 保护(指示验证头 [AH] 或封装式安全措施负载 [ESP] 的 IP 协议字段值),将对其进行处理并加以移除。若对计算机应用了“Windows 防火墙:允许已验证的 IPSec 跳过”组策略设置,Ipsec.sys 将设置一个与该数据包相关联的 IPsec Bypass 标记。Ipsec.sys 将结果数据包传回给 Tcpip.sys。
若数据包不带有 IPsec 保护,Ipsec.sys 就会根据 IPsec 筛选器组,决定是否允许、阻止或保护该数据包。若允许的话,Ipsec.sys 会在不修改该数据包的情况下,将其发回给 Tcpip.sys。若数据包被阻止或需要保护,Ipsec.sys 就会在不发出任何提示的情况下,丢弃该数据包。

2. Tcpip.sys 将该数据包传递给 Ipfltdrv.sys 进行处理。

       Ipfltdrv.sys 根据接收数据包的接口,将该数据包与已配置的入站 IP 数据包筛选器进行对比。若入站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该数据包。 若入站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该数据包传回给 Tcpip.sys。

3. Tcpip.sys 将该数据包传递给 Ipnat.sys 进行处理。

       若启用了 Internet 连接共享或 NAT/基本防火墙,并且接收数据包的接口是连接到 Internet 的公共接口,Ipnat.sys 就会将该数据包与其 NAT 转换表进行对比。若找到了匹配项,就将转换该 IP 数据包,并将结果数据包视为源流量。
       Windows 防火墙检查与该数据包相关联的 IPsec Bypass 标记。若设置了 IPsec Bypass 标记,Windows 防火墙就会将该数据包传回给 Tcpip.sys。
       若未设置 IPsec Bypass 标记,Windows 防火墙就会将该数据包与其例外列表进行对比。若数据包与某个例外匹配,Ipnat.sys 就会将该 IP 数据包传回给 Tcpip.sys。若不匹配,Ipnat.sys 会在不发出提示的情况下,丢弃该 IP 数据包。

4. Tcpip.sys 将 IP 数据包与已配置的 TCP/IP 筛选允许的那组数据包进行对比。

       若 TCP/IP 筛选不允许该数据包,Tcpip.sys 将在不发出提示的情况下,丢弃该数据包。若 TCP/IP 筛选允许该数据包,Tcpip.sys 将继续对其进行处理,并最终将该数据包有效负载传递给 TCP、UDP 或其它上层协议。

中转流量

       中转流量的前半部分路径如下图所示。 

点击查看原图

1. 接收到 IP 数据包后,Tcpip.sys 会将其传递给 Ipfltdrv.sys 进行处理。

       Ipfltdrv.sys 根据接收 IP 数据包的接口,将该数据包与已配置的入站 IP 数据包筛选器进行对比。
若入站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该 IP 数据包。若入站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该 IP 数据包传回给 Tcpip.sys。Tcpip.sys 将数据包传递给 IP 转发组件,由后者确定用于转发该数据包的下一跃点接口和地址。

       中转流量的后半部分路径如下图所示。 

点击查看原图

2. Tcpip.sys 将该数据包传递给 Ipnat.sys。

       若启用了 Internet 连接共享或 NAT/基本防火墙,并且接收数据包的接口是连接到 Intranet 的专用接口,Ipnat.sys 就会将该数据包与其 NAT 转换表进行对比。若 Internet 连接共享或 NAT/基本防火墙找到了匹配项,将转换该 IP 数据包,并将结果数据包当作源流量。若 Internet 连接共享或 NAT/基本防火墙未找到匹配项,将创建一个新的 NAT 转换表项,转换 IP 数据包,并将结果数据包当作源流量。若未启用 Internet 连接共享,Ipnat.sys 就会将 IP 数据包传回给 Tcpip.sys。

3. Tcpip.sys 将该数据包传递给 Ipfltdrv.sys。

       Ipfltdrv.sys 根据下一跃点接口,将该数据包与已配置的出站 IP 数据包筛选器进行对比。若出站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该 IP 数据包。若出站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该 IP 数据包传回给 Tcpip.sys。

4. Tcpip.sys 将该数据包传递给 Ipsec.sys 进行处理。

       Ipsec.sys 根据 IPsec 筛选器组,决定是否允许、阻止或保护该数据包。若允许的话,Ipsec.sys 会在不修改该数据包的情况下,将其发回给 Tcpip.sys。 若阻止的话,Ipsec.sys 会在不发出任何提示的情况下,丢弃该数据包。若要进行保护的话,Ipsec.sys 会在将数据包传回给 Tcpip.sys 之前,对其添加适当的 IPsec保护。
       Tcpip.sys 随后会通过下一跃点接口,将该 IP 数据包发送到下一跃点地址。

       对于运行 Windows XP SP2 或 Windows Server 2003 SP1 并采取常规配置的客户端或服务器计算机(不充当路由器或 NAT,并禁用了 TCP/IP 筛选),源流量的数据包处理路径涉及以下组件:
1. Windows 防火墙
2. IPsec
       对于上述采用常规配置的基于 Windows 的计算机来说,目标流量的数据包处理路径涉及以下组件:
1. IPsec
2. Windows 防火墙

       若使用了 IPsec,并启用了 Windows 防火墙,那么可能需要配置这两个组件,以允许想要的流量。譬如,要是您正在配置一台 Web 服务器,并使用 IPsec 保护发往该服务器的 Web 流量,就必须配置以下项目:
1. 一个 IPsec 规则(要求发往和发自该服务器的 IP 地址和 TCP 端口 80 的安全性)。
2. 一个 TCP 端口 80 的 Windows 防火墙例外。
       该 IPsec 规则可确保发往 Web 服务器服务的流量受到保护。该 Windows 防火墙例外可确保 Windows 防火墙不会丢弃未经请求的传入请求,来通过 TCP 端口 80 创建到 Web 服务器的连接。由于 IPsec 和 Windows 防火墙都作为单独的组件处理 IP 数据包,因此必须同时配置这两个组件。要是不想让 Windows 防火墙处理受 IPsec 保护的数据包,请配置“Windows 防火墙:允许已验证的 IPSec 跳过”组策略设置。有关详细信息,请参阅对 Microsoft Windows XP Service Pack 2 部署 Windows 防火墙设置。

阅读全文>>

标签: TCP 防火墙 安全 IPS UDP NAT TCP/IP API IPsec Windows 数据包 数据包处理路径 路由转发 IP转发

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

网页打开慢但HTTP下载快故障分析案例

作者:易隐者 发布于:2012-10-10 16:06 Wednesday 分类:网络分析

【说在之前】:

1,用到了疑难杂症网络分析过程中最基本、最核心的两个分析方法:对比分析法关联分析法

2,该案例涉及到的知识点主要有SYN重传连接数限制等,大家可参考本博客中相关知识点的文章。

【我的案例】:

故障环境

       某单位大体的网络结构如下图所示: 

点击查看原图


内部办公人员通过交换机到流控设备,再通过防火墙做NAT访问互联网。

故障现象

1,在地矿局进行互联网时,打开网页的速度非常的慢,有的网页要刷新几次才可以正常显示;
2,但是使用下载工具或是基于HTTP的下载速度却很快。

故障分析

1 确认故障原因

        我们找一台主机,访问互联网的某网站,发现的确比较慢,我们抓取故障时的交互数据包,如下图所示: 

点击查看原图

       通过上图,我们可以发现,客户端在与服务器建立TCP连接时,其SYN请求报文被客户端重传了一次,这个重传导致了2.88秒的延时。TCP重传一般是中间设备丢包导致的,那么到底是在什么地方丢包的呢?我们首先需要界定一下可能丢包的故障关键点。

2 选择故障关键点

       该故障环境相对简单,在办公用户访问互联网时,数据包只通过了交换机、流控设备和防火墙,而交换机主要负责转发数据,不会对数据包进行深度的检测和过滤等操作,所以在该环境下主要的关键故障点是流控设备和防火墙,如下图所示:

点击查看原图

 

3分析流控设备是否丢包

       关键故障点确定之后,我们首先在流控设备的前后同时抓包做对比分析,以确定是否是流控设备丢包,如下图所示: 

点击查看原图


       通过我们还原故障现象时,在流控设备前后抓取数据包的对比分析,结论显示,流控设备前后数据包交互的过程是一样的(这个对比分析通过五元组关联同一会话之后,对比查看数据交互过程的差异即可,由于流控设备前后的数据交互过程完全一样,在此不做具体详细的分析说明),这说明,在打开页面较慢时,流控设备并未丢弃任何交互的数据报文。

4 分析防火墙是否丢包

       同样,我们再在防火墙的进出口同时抓包,通过比较防火墙前后数据包的交互情况来确定造成故障的原因,部署图如下所示: 

点击查看原图


1, 在访问某网站出现缓慢现象时,在防火墙前后同时抓取数据包,并保存,为下面的对比分析提供原始的数据报文。
2,我们先分析防火墙内网口抓取的数据,在科来网络分析系统的“TCP会话”视图,我们发现了一个web连接持续的时间为6秒,并且其在三次握手过程中,存在重传现象,如下图所示: 

点击查看原图


这个TCP会话的源端口是1124,目的地址为58.30.236.11,目的端口是80
3,我们通过关联分析法,在进行网页访问时,我们在防火墙前后同时进行抓包,下图就是在防火墙出口处抓取到的数据包: 

点击查看原图

       我们知道防火墙在网络运行中起到防护作用,会将未经授权的报文过滤,但是防火墙一般不会阻止正常的数据包,我们在比较上面两张图发现,在防火墙后捕获到的数据包第一次发送同步请求没有成功,然后又重传了一次同步数据包,才成功建立了连接;而在防火墙前面抓取到的数据包却没有看到重传的数据包(黑框标记的部分),这很清晰的说明,第一个SYN报文被防火墙丢弃了。

4 分析结论

       通过上面的分析,我们可以得出如下结论:

       由于防火墙在转发数据包时,随机丢弃了客户端发送的SYN报文而造成的。可能是防火墙配置不当(连接数限制)或防火墙BUG(在处理TCP新建连接时不稳定)导致的。

总结

       经过分析知道是由于防火墙不规律丢弃SYN报文导致的网页打开慢现象,但是为什么HTTP下载的速度却很快?这是因为防火墙仅随机丢弃SYN报文,而HTTP下载在刚开始建立TCP连接时,防火墙有可能会丢弃其SYN报文,但是下载行为决定其会不断发起SYN报文进行连接建立的尝试,而一旦连接建立成功,则防火墙不会丢包,给用户的感觉就是速度也非常快。

阅读全文>>

标签: TCP 对比分析法 关联分析法 丢包 SYN 防火墙 重传 BUG NAT 连接数限制 SYN报文

评论(4) 引用(0) 浏览(8975)

某业务系统由于连接数限制导致间歇性访问慢故障分析案例

作者:易隐者 发布于:2012-9-26 18:05 Wednesday 分类:网络分析

【说在之前】:

1,该案例为端系统设置连接数限制导致的应用间歇性缓慢故障,在实际工作环境下,我们更容易遇到的是中间系统对连接数限制导致的一些范访问异常,令人头疼的是,并不是所有开启连接数限制功能的中间系统在丢包后都会向源主机发送ICMP差错报文,这会给大家分析定位带来难度,大家在实际工作中需要留意;

2,该案例涉及到的知识点主要为“ICMP主机管理性禁止差错报文”和“连接数限制”,关于ICMP主机管理性禁止差错报文,大家可参考本博客《ICMP通讯管理性过滤禁止差错报文(type 3,code 13)》一文,虽然“type 3,code 10”与“type3,code 13”有些差异,但是差别不大,可以借鉴;关于连接数相关知识点,大家可参考本博客《连接数相关知识》一文;

【我的案例】:

1 故障环境

网络拓扑:

点击查看原图


说明:
1,内部办公机器都是192.168.1.0/24段的,内部办公主机通过防火墙做NAT,转换为X.X.X.138访问互联网;
2,内部办公服务器的地址为192.168.1.191,其通过防火墙映射为公网地址X.X.X.139对外提供6888端口的web服务。
业务访问流程:
       内部办公机器都是通过NAT后的公网地址X.X.X.138访问办公服务器的公网地址X.X.X.139。其流程如下图所示: 

点击查看原图


2 故障现象

       故障现象主要表现为:
1,部分内网办公主机经常出现打开主页慢、登录慢或者某些页面不显示的情况,如下图所示: 

点击查看原图

打开主页时的长时间等待页面截图 

点击查看原图

登录时长时间等待页面截图

2,这些故障现象间歇性出现,有时多刷新几次页面后,打开的速度会恢复正常。
3,外网用户访问业务系统一直正常,该故障已经持续数月。

3 故障分析

       通过故障现象,我们可以看出,这是比较典型的部分系统出现问题的案例,由于其不具备全体的故障特征,又是间歇性的发生,因此,此类故障按照常规的分析方法很难找到真正的故障原因,我们还是先在客户端抓取一下故障时交互的数据包,站在数据包的角度来分析一下可能的原因。
1,找一台出现故障的主机192.168.1.167,捕获其打开主页面缓慢时的数据包。
2,查看缓慢时的数据交互情况,如下图所示: 

点击查看原图

       我们通过delta tima值可以看到,这个交互的过程存在较大的延时,并且我们发现,在交互的过程中存在数个“ICMP主机通讯管理性禁止”的差错报文,这些报文都是X.X.X.139发给故障主机192.168.1.167的。
3,我们双击其中一个ICMP主机通讯管理性禁止报文,查看其封装的被过滤的原报文相关信息,如下图所示:

点击查看原图

       我们发现,被X.X.X.139管理性过滤掉的报文是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文。
4,我们再结合上下数据包交互的情况,我们可以发现,这个ICMP主机通讯管理性禁止报文的前一个报文正是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文,如下图所示: 

点击查看原图

       这充分说明当故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求时,被服务器管理性过滤禁止了。
5,那么服务器为什么会管理性禁止故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求报文呢?难道服务器上设有针对源端口为4075的禁止访问策略吗?服务器显然没有做这种针对源端口过滤的必要,另外,我们还发现除了故障主机以源端口4075访问服务器的SYN报文被管理性禁止外,还有其他源端口的SYN请求报文被服务器管理性禁止,如下图所示: 

点击查看原图

       这里被服务器禁止的报文的源端口有4078、4083、4086等。
       另外,通过上图中的“delta time”值,我们也可以发现正是这些报文导致了故障主机在建立新的TCP连接之前花费了数秒的连接建立尝试时间(SYN重传时间,大家可参考本博客《TCP重传》一文),从而导致了页面打开缓慢的现象出现。
6,这个现象具有明显的针对TCP的随机性的过滤特性,因此,我们很容易就可以联想到是否是服务器在TCP传输层存在某些检测过滤机制?而在传输层最为常见的就是TCP连接数限制了。
       一般而言,在服务器上实现针对单IP访问服务器的TCP连接数进行限制是一件简单的事情,一个独立的IP只允许与服务器建立少量的TCP连接,这对于那些对外提供服务的服务器来说是一种较为常见的防护措施,在正常情况下,单个客户端与服务器的正常交互所需要的TCP连接数并不是很多,而限制的数值一般都会高于正常的需求,但是在有些情况(如经过NAT或代理后对业务的访问)下,这将导致问题的产生。
7, 上述推理非常合理,我们通过检查服务器的相关设置,验证了我们的分析和推论结果。
8, 分析结论:
       这个故障是由于业务服务器端设置了针对单IP访问连接数限制功能,而内部办公网主机都是通过防火墙NAT地址转换后对业务服务器进行访问,这直接导致在业务访问高峰时,出口NAT IP地址访问业务服务器的连接数超出限制,业务服务器对后续的TCP连接建立请求发出ICMP差错报文,等一些TCP连接释放后,才允许新建TCP连接,这导致访问业务系统非常缓慢。并且这种特性决定了故障现象表现为间歇性发生。

4 故障解决

       通过修改服务器Apach对单一IP地址的连接数的限制后,故障得到解决。

阅读全文>>

标签: 疑难故障 TCP icmp差错 SYN 连接数 NAT 地址转换 业务慢 连接数限制 ICMP主机管理性禁止差错报文 Type 3 Code 13 type 3 code 10

评论(2) 引用(0) 浏览(8113)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1