问题:总部PC去访问分支的服务器3389桌面,会出现不定时中断的问题 1. 10.0.2.132为PC10.16.2.200为远程桌面的服务器 2. 拓扑环境 总部:VPN---AC---SW---PC (10.0.2.132) 分支:VPN---SW---- PC (10.16.2.200) 总部有三层环境,AC透明模式部署,分支二层环境,就一个网段 3. 数据包是总部访问分支访问不了的时候抓取的数据包,要求通过数据包,分析问题原因。
排查思路: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包和之前的两个包,这数值也差的太多了啊,所以基本能判断这个包不是客户端发出的
其实在ac上抓包,你就能看到ac给客户端和服务器两边都发了rst包,而服务器与客户端都没有发过。 这也说明了ac设备的强大。不信你看该文档:链路劫持攻击一二三,里面就说了“中断访问型常见于阻止用户访问某些网站,如某些设备禁止用户访问某些站点、某地运营商的禁止ADSL多终端上网功能。其原理就是伪造服务端给用户发RST包阻止TCP连接的建立(单向发包)。某些设备做得比较狠,在冒充服务端给用户发RST包的同时也冒充用户给服务端发RST包(双向发包)。” 同时你参阅上述文章也可以发现,要定位问题,除了可以使用ip.id这个参数,还可以使用ip首部中TTL值来进行问题判断,根据ttl的跳数应该也是可以定位出出问题的设备位置
另带 通过vpn进行数据互访,ping的时候不丢包也不延时,但是使用应用时就是访问卡慢,模块半天显示不出来,如何通过wireshark定位问题。
另2篇文章: |