排查思路: 1. 只抓取了分支vpn上eth0口的包和总部vpn设备eth0上的包(建议是分支电脑和总部服务器都抓取,抓不了也没办法) 2. 因为是终端pc访问服务器的时候经常断开。所以先看在终端侧的数据包,也即是查看zbssleth0这个包 点开之后,先点击Statistics,选中conversation 出现下图界面,选中TCP,看到存在三个连接。说明应该是测试过3次。其中注意到字节数Bytes, 第二个连接有112kB,比其他连接传输的数据都多,那我们就先来看这个连接。 怎么看呢?右键该连接后,照下图操作 wireshark自动过滤该连接,显示如下界面 我们可以点开专家分析来看看,是否存在什么问题。点开之后,记得把Limit to Displayfilter 给勾上,这样才会显示在wireshark过滤后展示页面的信息。 由于不涉及访问卡慢的问题,所以此时我们没必要看重传等信息。重点应该关注是什么导致的连接 断开。此时,明显能看到告警信息中,存在RST包,那我们就可以看下304号包与306号包。
找到304号包与306包后,发现后面就再也没有数据了,说明此时连接是中断了。明明数据传的好好 的,怎么突然客户端10.0.2.132就发送一个RST包呢。此时需要注意的是,我们的数据包是在总部vpn设备上eth0口抓的,也就是说这个流量是从内部传过来的。结合着总部的拓扑情况,出现中断, 可能存在2种情况。要么是客户端自己的问题,要么就是有啥子设备替客户端发送了这个RST数据包
一个直接的办法就是在客户端上抓包。看下客户端有没有发出这个RST包。如果没有,结合着网络拓 扑,那基本就可以确定是AC发了这个RST包了(第一个,客户环境比较简单;第二个,谁叫AC是行 为管控呢)。如果客户端上的抓包有这个RST,那就是客户端的问题。 如果客户说,我电脑上不能安装其他软件(不管为啥,你就当死活不允许好了)。那就是说,我们 不能在客户端上抓包。那好,我们就只能在现有的数据包中获取蛛丝马迹了。 此时,我们还有一个方法判断是不是由客户端发出的这个RST包,那就是通过IP.ID这个参数。 IP.ID是什么鬼?那我们要知道数据包是如何封装的,如下图所示。IP.ID是IP数据报头中的一个字段。表明了一个数据包的身份,比如一个数据内容过大,被传输的 时候就要对这个数据进行切割,即进行分片。当接收方收到这些分片后,需要把这些分片组装起来,那接收方每次收这么多的数据包,它咋知道哪些分片是从同一个数据内容中出来的呢?就要靠IP.ID了,通过IP.ID就可以把这些分片组装起来,还原成最初始的大块数据。就像你玩乐高玩具,乐 高里面这么多零件,如果这些零件中混入了其他玩具的零件。那你想把这个乐高玩具组装起来肯定 需要一个标识来进行识别哪些零件是同属于一个乐高模型的。
上述还只是告诉了你,啥是IP.ID。那回到问题中来,你还需要知道的一个点就是,如果是一个设备 去发数据包,那么他的IP.ID增长是线性的。即一般来说,同一台设备发出第一个包,如果IP.ID是1, 第二个包就是2。就算不符合这规律,那数值起码也不会差太多。 我们再来看下wireshark,299号包的IP.ID=18970。302号包的IP.ID=18971。而304号包的 IP.ID=22566。那RST包和之前的两个包,这数值也差的太多了啊,所以基本能判断这个包不是客户端发出的 |