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

应用层保活行为

作者：易隐者 发布于：2012-12-17 10:53 Monday 分类：网络分析

        我之前专门针对TCP保活撰写了一篇较为详细的说明文章——《TCP保活（TCP keepalive）》，在传输层主要通过TCP的保活功能来实现连接的保持，当时我也提到应用层的保活功能，但是应用层的保活功能在实际工作中较为少见，因为如果TCP能够提供保活功能的话，应用层一般就可以利用TCP的保活功能来实现连接的保活，但是毕竟应用层跟传输层是有区别的，一方面并不是所有的应用层会话都需要实现保活功能，另一方面TCP是针对传输层的，一旦开启TCP保活功能，将对所有基于TCP的应用产生影响，这些影响可能会是负面的，如我博客里的案例：《由TCP保活引起的业务访问故障案例》，这也是运维管理者不愿意看到的，因此，有些应用自行设计自己的应用层保活行为。

       近期在用户的工作环境中，看到了如下图所示的应用层交互行为： 

       大家可以清晰的看到，这个交互过程具有以下行为特征：
1， 客户端每间隔固定时间（30秒）发出同样的请求；
2， 每次交互的报文都是一致的（客户端的请求、服务器的响应、报文长度等）；

       个人认为这些行为特征足以证明该交互过程是应用层设置的应用连接保活探测行为。

阅读全文>>

标签: TCP 明文 故障 运维管理 保活 行为特征 TCP保活 应用保活

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

可能的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) 浏览(6537)

TCP确认机制异常案例

作者：易隐者 发布于：2012-12-8 15:06 Saturday 分类：案例讨论

缘起
        一个好友通过Sina微博转发了一个兄弟的问题给我，其问题如下：
“AB机器tcp，A发送100字节给B，B返回数据但是其ACK=1，这期间A均正确ACK B的所有序列号，B置FIN位，A发 FIN+ACK 给B，此后B返回的ACK=2，那么此时A是应该重传之前的99字节，还是直接重传之前的FIN+ACK包给B？”。

       通过这样的描述我认为这在实际环境中应该不会存在，结果这个兄弟告诉我是在实际环境中发生的，并将交互的报文传一份给我。

       好奇之余，对这个报文进行了仔细的分析，接下来跟我一起来看一下整个分析的过程。

分析产生这个交互的原因

       选取其中一个TCP会话，查看其具体的报文交互情况，如下图所示： 

       这个报文交互的情况截图结合下面的TCP交互流图一起，看起来更清晰一些：

        通过交互报文的解码，我们可以清晰的看到，服务器192.168.104.229已经对客户端发送的get请求作出了应用层的响应，如下图所示：

       其响应为：HTTP/1.0 403 Forbdden
       但是其ACK号却为1，接收并处理了客户端的应用请求报文，但却并未对其进行确认，这充分证明服务器192.168.114.229的TCP确认机制出现了异常！

       我们再来一起看看客户端主动发送FIN报文之后的交互情况：
 
       客户端在发送FIN报文之后，服务器的ACK号变为2，这对于客户端来说，这是对其应用字段的确认，这说明服务器端仅收到客户端1字节的应用字段，因此客户端将剩下的303字节的应用字段放在FIN报文中一起发给服务器端，而服务器在收到这个报文后，回应客户端的ACK号变为3，客户端接着将剩下的302字节的应用字段放在FIN报文中再次重传给服务器端，如此反复。
       至此，我们已经能够意识到，服务器端的ACK确认并不是针对客户端的应用字段的，而是针对客户端的FIN报文的，服务器的确认机制出现了异常，服务器不再确认客户端的应用字段，而只确认客户端的SYN报文和FIN报文。

分析结论

       此问题产生的原因为：服务器的TCP确认机制出现异常，其只确认SYN报文和FIN报文而不对应用数据进行确认。

       另外，我们还留意到一个有意思的现象：正常情况下，端系统一般都会在发送的数据段获得对端确认之后，才会主动发送FIN报文，释放TCP连接，如果在多次重传之后仍未得到对端的确认，通常会向对端发送RST报文，异常释放TCP连接，但是此处可能为了提高交互的效率，客户端与服务器在发送的数据段未收到对端的确认报文就主动发送FIN报文释放TCP连接。

阅读全文>>

标签: TCP SYN FIN ACK TCP确认机制

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

【转】上网认证页面无法打开案例

作者：易隐者 发布于：2012-11-25 10:40 Sunday 分类：案例讨论

【说在之前】：

1，该案例的确属于疑难故障范畴，若不是通过抓包方式，站在数据包交互的角度进行分析是无法定位、解决该故障的，因此，该案例具有学习参考价值；

2，案例的分析用到了关联分析法和对比分析法，思路非常清晰，但整个文档在图文编辑和措词这块还可以做进一步的加强，考虑到原文的完整性，我不对该文档做任何修改；

3，难能可贵的是作者在找到故障原因并解决故障之后，没有像大部分人那样将这个故障束之高阁， 而是将自己的分析思路、过程整理成文档，分享给大家，另外，发现其中难以解释的、存在疑问的地方，供大家一起讨论，这正是我一直倡导的“自我总结、无私分享、共同探讨、共同进步”的学习方式；

4，针对该案例后面的疑问，我就我的理解作出相关解答，供大家参考。

     针对第一个疑问：AC在此处工作在透明模式下，正常情况下其对报文的干预和处理根本不需要经过路由，也就是说，AC在做HTTP重定向的时候，根本不需要根据路由表，将这个HTTP重定向报文转发给PIX防火墙，而应该直接构造相应HTTP重定向报文发往核心交换机，因此，此处出现这样的问题，我个人认为如果AC是按照路由方式处理的话，其应该有相应的转发表，转发表中会有下一跳、转发接口等相关信息，而出现此案例中的问题，说明AC的转发表出现了异常，可能是其上联口和下联口是属于同一网段，而AC转发表未对其进行区分导致的；

     针对第二个疑问：这里需要明确，AC的管理口和业务口是否是完全独立的，如果是，那么所谓的两条默认路由是完全分开的，没有任何问题，如果不是，那么根据不同的系统处理方式，负载均衡（根据报文或其他）或者选择其中一条都是有可能的，多年前我曾写过一篇《供电局调度所前置机故障解决说明》的文档，就是两条默认路由导致异常的案例，过段时间我把这个案例共享到我的博客供大家参考。

5，该案例作者肖鉴为我以前推出《合肥网络分析技术团队招募学徒》的第一个学员。他不远千里从福建专程请假几十天跟随我学习相关知识，当我第一眼看到他时，我就被他的这种对技术执着追求的行为所感动，他基础不错，学习踏实认真，我个人认为我真正给他的帮助不在于具体技术的成长和进步，而在于影响他对技术的自信、清晰的职业发展方向规划以及行事的风格，在他身上我能看到我以前的影子，他现在深信服的总代，刚获得深信服深信服华南区技术大比武冠军，看到他的成长，我的内心是无比的欣慰。

【原文全文】

1. 网络环境

        故障网络环境如下图所示： 

说明：
1． 出口防火墙工作在路由模式做NAT代理内网上网，E1口IP地址192.168.247.1/24。
2． 上网行为管理工作的网桥模式下，为其网桥IP地址配置192.168.247.3/24、网关IP地址为192.168.247.1用于设备管理，下联三层交换机IP地址为192.168.247.2/24。由于，前置PIX防火墙为阻止192.168.247.0/24网段上网，所以为了上网行为管理能够更新内置规则库，上网行为管理口下联三层核心交换机为其配置IP地址192.168.20.250网关IP地址192.168.20.1。
3．上网行为管理对内网部分网段实行认证上网。

2. 故障现象

       内网无须进行认证PC机访问互联网正常，需进行认证网段PC机上网在正常情况必须得先进行认证输入用户名和密码后方可访问互联网，故障表现为认证网段PC机无法正常跳转至认证界面输入用户名和密码。如下图所示： 

3. 故障分析

3.1 常规分析

       在PC上访问网络时无法跳出登陆界页时，我们手动输入http://192.168.247.3认证登陆页面是正常，如下图所示，并且，输入完认证用户名和密码后可以正常访问互联网。说明网络中并不存在路由问题。那么是否可能是设备本身处理机制出现问题呢？还是，PC机与上网行为管理设备通信出现了其它的异常导致PC机无法正常弹出认证页面？。 

阅读全文>>

标签: 交换机 团队 疑难故障 TCP 网络分析 负载均衡 抓包 深信服 上网行为管理 HTTP重定向 AC 路由表 转发表

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

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) 浏览(110394)