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

省厅A登陆省厅B预算系统异常应急处置

作者：竹林再遇北极熊 发布于：2017-11-28 21:59 Tuesday 分类：网络分析

1 情况概述

1.1 拓扑结构

   如上拓扑所述，省厅A的客户端1和客户端2属于两个不同的安全域，通过防火墙代理，经过互联网，访问省厅B一台层层安全防护的预算系统服务器。

1.2 情况简介

   预算系统分别使用B/S、C/S架构对外提供服务，服务端域名是xxx.com，解析后的公网IP分别是X.X.X.155和X.X.X.22，浏览器访问比客户端访问多...

阅读全文>>

标签: 疑难故障 应用故障 策略误报

评论(1) 引用(0) 浏览(9022)

又遇TCP协议栈异常问题

作者：易隐者 发布于：2013-10-29 16:47 Tuesday 分类：案例讨论

       大家还记得我以前写的《TCP确认机制异常案例》(链接为：http://www.vants.org/?post=200)吗？今天在一个用户那边再次遇到了一个TCP协议栈异常的问题。

       用户反馈的问题现象是业务交互出现异常，难以定位异常出现的原因，我在用户现场分析了异常出现时的报文交互情况，如下图所示：

点击查看原图

       由F5设备主动向服务器发送SYN连接请求报文，服务器响应SYN/ACK报文，F5发送ACK报文确认后，向服务器连续发送3个大小分别为1514、1514、350大小的应用请求报文，但是1.199秒之后，F5重传了应用请求的第一个报文（该报文序列号为No7，该数据报其实是序号为No4的报文的重传），紧接着，2秒后，看到服务器的SYN/ACK的重传报文（该报文序列号为No8，该报文为No2报文的重传报文），后面数十秒的交互，基本是都是F5对应用请求报文的重传和服务器SYN/ACK报文的重传，在40秒之后，由F5主动发送RST报文释放该TCP连接。

       由整个交互的过程，我们可以清晰的看到，服务器不断重传SYN/ACK报文，说明服务器没有正常处理F5的ACK报文（序列号为No3的报文），站在F5的角度，TCP连接已经建立成功，但是站在服务器的角度，却认为TCP连接未建立完成，因此服务器不断重传SYN/ACK报文，为什么服务器在明确收到了F5的三次握手的ACK报文，却没有正确处理呢？而且后续F5重传的应用请求报文（No7、No10、No11、No14、No17）都可以说是对服务器SYN/ACK报文的确认，但是服务器全部忽略了，因此，这基本上可以判断为服务器端系统的TCP协议栈出现异常，导致了应用出现了异常。

阅读全文>>

标签: TCP F5 应用故障 SYN 重传 TCP协议栈 应用异常

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

策略误报导致应用保存失败的分析案例

作者：易隐者 发布于：2013-4-20 14:13 Saturday 分类：案例讨论

       某用户应用，需要将一些修改信息提交保存至业务服务器，在这个保存过程中出现无法保存的现象（保存失败，点击保存按钮后，IE页面进度条长时间处于加载状态），我出于帮忙，到用户现场捕获了业务保存时的交互报文，如下图所示：
点击查看原图

       查看这个交互的过程，我们可以非常清晰的看到，客户端与服务器TCP三次握手正常，问题出在客户端提交POST请求的报文被中间设备丢弃了。比较有趣的是，客户端在尝试两次重传之后，较为聪明的将这个POST请求字段（长度为859B）拆分为两个长度分别为536B和323B的字段，并先将长度为536B的应用字段重传给服务器，我们清楚的看到服务器对这个应用字段作出了确认，这说明这个长度的应用字段正常到达了应用服务器，但是后续长度为323B的应用字段一直被丢弃，这很容易想到是中间设备策略误报一直丢弃某些固定报文导致的，我们来看一下这个应用字段里到底封装的是什么应用数据，我们首先看这个报文的应用字段解码如下：

点击查看原图

       这个看得有点头晕，我们将这段字符解码一下，如下图所示：
点击查看原图
       解码之后，我们可以看到这个应用字段中存在“varchar(60)”等关键字，这可能引起WAF、IPS等设备将此报文误报为SQL注入的尝试。      

阅读全文>>

标签: 应用故障 IPS 策略误报 POST WAF SQL注入

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

[转]F5负载均衡环境下某应用故障分析案例

作者：易隐者 发布于：2012-7-18 13:45 Wednesday 分类：案例讨论

       本文来自互联网，非我原创，原文章名为《高级TCP/IP网络排错》，该案例出自其第三节：用OmniPeek解决网络中的难题。

       如该案例作者看到我的转载请跟我联系，可以做个朋友，切磋一下技术问题，如果哪位网友知道该案例的原作者，也烦请留言告知。

【我的点评】：

1，充分运用了中间设备自带的抓包功能（对中间设备自带抓包功能感兴趣的兄弟，请参阅我的文章《常见系统和网关设备自带抓包功能介绍及操作指南》），提高了分析效率；

2，整个过程使用对比分析法（参见我的文章《疑难网络故障的分析方法和原理之对比分析法》），发现进出F5报文的差异，快速界定异常问题产生的原因是F5、客户端还是服务器；

3，在做数据包分析之前，确定了业务报文交互路径，明确可能的故障点，为下一步的排查提供了基础，但是从作者给的拓扑结构上看，出来F5之外，这个数据路径应该还会经过那台旁接的防火墙；

4，“F5日志中报端口无法到达”，此问题不太像是指物理端口不可达，个人感觉是指UDP端口不可达的可能性更大一些；

阅读全文>>

标签: 负载均衡 F5 omnipeek RST 应用故障 端口不可达

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

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