FTP登陆故障分析

2012-09-01 · 网络分析 · 网络分析 · 25178 次阅读

【写在之前】：

1，此案例涉及到的分析方法，请大家参考本博客文章《疑难网络故障的分析方法和原理之对比分析法》；

2，此案例涉及到的知识点，请大家参考本博客的文章《应用层检测/深度包检测（DPI）》；

3，此案例中谈到的利用防火墙自带的抓包功能tcpdump的使用，请大家参考本博文章《天融信防火墙自带的tcpdump使用》一文，我曾将各种常见系统和网关设备自带的抓包功能的使用整理成《常见系统和网关设备自带抓包功能介绍及操作指南》一文，其他网关型设备自带的抓包功能的使用我会陆续择机发布到本博；

4，设备本身的BUG问题一般都属于疑难杂症级别，在做分析定位时，站在原始数据报文交互的角度抓包分析是比较靠谱的做法；

5，本故障还有另外一种解决的方法，给大家一点提示：ICMP重定向报文，感兴趣的兄弟自行思考，如需协助，可给我留言。

【我的案例】：

故障描述

1 故障拓扑

2 环境说明：

1、客户端的默认网关是主路由器；
2、主路由上设置了相应的策略，凡是FTP/HTTP的应用均交由备路由处理；
3、备路由上会将访问国家局的网段指向国家局路由；
4、核心与路由间均部署防火墙，防火墙工作在透明模式下；
5、客户端访问服务器的数据流走向比较复杂。

故障现象

1、省局到国家局的FTP服务很慢，一般需要40多秒才可以登陆上去，有时根本登陆不上去；
2、在故障机器上Ping国家局服务器，延时很小；
3、省局到国家局的HTTP应用正常。

故障分析

1 前期简单分析

1、Ping延时很小，说明网络层的延时很正常；
2、网络环境复杂，数据流走向复杂，数据包来回路径不一致，中间经过2台防火墙，可能存在状态检测的问题；
3、HTTP的数据流走向跟FTP的数据流走向应该是一样的，HTTP正常，FTP不正常，说明这个跟TCP的状态检测无关，应该是FTP应用层的问题。
暂时没什么头绪，只能先从客户端下手，进行抓包分析，看看大体的情况。

2 数据包分析

 登陆不上时的数据包分析
我们在客户端登录不上FTP服务器时，抓取其跟服务器交互的数据包，查看客户端与服务器的详细交互过程，如下图所示：

通过上图中针对每个交互数据包的详细分析和描述，我们基本上可以知道，在客户端登录不上FTP服务器时，是由于客户端与服务器交互用户名和密码时产生了问题，导致FTP登录时间过长，超出最大会话时间，从而被FTP服务器主动关闭。

 FTP登陆慢时的数据包分析

我们在客户端登录FTP服务器非常想缓慢时，抓取其跟服务器交互的数据包，查看客户端与服务器的详细交互过程，并针对每个交互的数据包做详细的说明和描述，如下图所示：

通过上图详细的分析，我们可以知道，产生较大延时的原因也是在用户名、密码交互的过程。
我们把上述两种场景下，客户端与服务器间用户名和密码交互的过程做一个示意图展现如下：

通过这个示意图，我们可以更加清楚的发现，之所以在客户端与服务器端交互用户名和密码时产生了很大的延时，是由于用户名和密码数据包在交互的过程中被中间设备丢弃导致的。
那么到底是哪个中间设备丢弃了FTP用户名和密码的数据包呢？接下来我们就要找出丢弃用户名和密码数据包的中间设备。

 定位丢包的中间设备

在这个过程中，主要针对我们可以控制操作的中间设备进行排查，首先我们选择可能丢包的关键点。在这个网络环境下，我们首先考虑的就是2台防火墙设备。
我们利用防火墙设备自带的tcpdump抓包功能，专门抓取FTP客户端与服务器交互的数据包（该抓包过程由于现场原因未作记录，在此无法做详细数据包展示），分析其过程，我们可以发现的确是防火墙丢弃了FTP用户名和密码数据包。
那么防火墙为什么会丢弃FTP用户名和密码的数据包呢？
抓包分析我们可以发现被丢弃的包都是FTP传输用户名和密码的包，这个肯定属于FTP应用层的包，防火墙丢弃FTP应用层的数据包，那么问题应该就出在防火墙的FTP应用层检测上。我们登陆上防火墙，查看防火墙针对FTP应用做了哪些应用检测的策略，结果我们发现，其针对FTP应用启用了应用层检测，如下图所示：

至此，我们基本上可以断定是防火墙的FTP应用层检测BUG导致了这个故障的产生。

故障解决

在防火墙上取消FTP应用绑定，让防火墙不要对FTP的数据包进行深度的过滤和检测，再次登陆FTP服务器，一切正常，至此该疑难故障解决。