- 论坛徽章:
- 12
|
本帖最后由 phanx 于 2015-04-05 01:00 编辑
回复 1# myworkstation
1、说说你的抓包体验,在抓包时遇到的最大困惑与收获分别都是什么?
目前抓包还是很方便的,工具也提供了很多辅助的分析和提示功能。
最大的困惑其实还是对于一些协议的行为的理解,现在的抓包工具也提供了很多分析和提示,已经相当不错了。
最大的收获是通过抓包分析,更清楚的理解了很多程序和应用的行为,不仅是在排障中用到,更为很多功能的学习和理解提供了直接的说明。
例如在对Oracle 客户端与Oracle RAC互交的数据包分析后,了解了Oracle RAC 借助VIP对与实例故障时的一些处理方式。
2、哪类工具用的最多,tcpdump,wireshark或者其它?为什么?
鉴于目前主流的Linux发行版都自带了wireshark,以及在UNIX类系统中更为广泛的tcpdump,因此,抓包还是很方便的。
Windows则需要单独安装wireshark。更早的时候,在wireshark的前身ethereal都还没有流行起来的时候,
Sniffer Pro和Iris Network Traffic Analyzer是Windows平台上常用的抓包工具。Iris当时还可以将捕获的数据包修改后然后发送出去,挺方便的。
现在好像科来也有一个工具可以把科来抓到的包发送出去。
但是大多数抓包工具都有一个问题就是无法长时间持续的进行抓包,数据量太大时容易崩溃又或者在捕获的海量数据中提取需要的数据不是那么容易。
所以很多企业中才部署了更专业的设备和工具,比如Riverbed SteelCentral Netshark(Cascade) 这样的可以持续的捕获,并按照自定义的条件提取捕获的数据的系统。
它提供的功能也不是单机版本的抓包工具所能比拟的。再加上分布式的探针,在数据捕获和分析上就更灵活和精确了。
3、你觉得抓包分析是一项必要的工作技能吗?为什么?
是必备的技能,因为很多情况下,只有从数据包交互的层面才能发现问题的所在。或者说比起去代码中配置中找问题,从数据包这层更容易找到问题。
在我工作中遇到过一些问题,也让我对通过抓包分析故障有更清晰的认识。
一次是在某运营商的DCN网络中,有一个系统,在部份营业厅始终打不开某些页面,但另外的营业厅又正常。当时,甲方自己查了有大概半个月也没有找到问题所在,
又找来各个设备供应商和软件供应商的人查了很久也没有找到问题,最后我被叫到现场去帮忙。我用Ethereal和Httpwatch分析后,发现不能访问的营业厅在
访问这些故障页面的时候,这些URL的地址被PIX防火墙做了NAT。由于这个系统是很多个服务器组成,URL中包含的地址也有很多,只有部份营业厅访问这几个特定的地址的时候会经过这个PIX的NAT。
而这个系统中一些链接用绝对路径的方式写了带IP的URL,所以导致这些被NAT过的地址对于这些营业厅就无法访问,而没有被NAT的URL和营业厅就访问正常。
将这个情况反馈给甲方人员并建议修改URL为相对路径,于是甲方联系了软件开发商,修改了代码,问题就解决了。
还有一次是某银行某省分行的自助查询终端通过IE浏览器访问总行业务系统的时候,总是有某些业务访问不了。省分行的人也搞不清楚为啥,处理了很久也没有找到问题所在。
后来又是叫我去帮忙看看,抓包后发现IE除了访问Web页面以外,还通过了一个ActiveX控件在与总行服务器服务器的一个服务端口在通信,但是里面返回的的数据包中
包含了下一步访问的服务器地址以及URL。但这个返回数据中的地址对于该省分行来讲是不可达的。所以这部分业务就总是出错。
反馈给运维人员后,他们调整了路由和访问规则,业务也就正常了。
还有我最近遇到的一串问题,也是靠抓包分析后才发现了问题的根源。大家有兴趣可以看看我记录的过程。
iptables的nf_conntrack相关参数引起两个问题
|
|