客户端访问服务器网络卡顿问题处理

前几天室友的客户反馈云桌面客户机访问服务器网络卡顿,刚好那段时间比较空,就向室友了解了下情况并帮忙分析.

网络拓扑如下

客户端-核心交换机-服务器接入交换机-服务器

云桌面客户端和服务器为不同网段,网关均在核心交换机上。

室友已经做了初步的排查：在客户端上ping客户端网关没问题,延迟为1ms,没有丢包现象,访问服务器网段不规律丢包,在相关设备上查看过CRC和接口流量均正常,丢包现象和环路不符,但还是排查过环路问题,没有mac漂移的现象.并在核心上镜像抓包，和我说怀疑是arp和445端口的问题，可能是蠕虫导致的，准备在客户下班后杀毒。我让他把抓包文件传给我一起看一下。

一进来就发现有smb登陆失败的报文,第一反应是有程序在试共享文件的密码(SMB协议是在windows上用于文件共享的).有经验的工程师都知道445端口没有相关应用都会封掉.

通过statistics-summary可以看到抓包248秒,有2M个的报文,抓包文件300+MB,平均速率为11M.

通过statistics-conversation看到tcp连接占大多数

将tcp连接的内容导出到excel,建了数据透视表(也许wireshark有我不知道的更好的分析方式,)

发现存在大量源为客户机,目的端口为445的连接

添加目的ip后发现均为客户机网段访问服务器网段,怀疑客户机频繁访问服务器445端口导致的.在核心交换机上配置了限制源地址为客户机,目的端口为445的ACL后,卡顿的现象好转.

后续是对客户机的杀毒,客户侧最后选择了备份恢复了云桌面客户端.并在防火墙上开启了IPS,(这部分设备和室友并没有关系),据说开启后相关告警立马飙到9999+

 

这个问题是快下班的时候开始和室友交流的,那天上午刚好在看《wireshark网络分析就这么简单》，因为我是做网工的，觉得SMB偏向于应用层，和我关系不大就只是随手翻了一下。没想到傍晚就用上了，wireshark的使用还是有好好看的，刚好在分析的时候用上了。

解决问题的时候思路其实也没这么流畅，看到有2M个包的时候也怀疑过包转发率的问题。

白天在看《wireshark网络分析就这么简单》的时候感觉有种看爽文的感觉，刚好看完就用上也是比较幸运。

需要资料可以来公众号：“我做网工的日子”（2021.3.22后名字生效，原来叫“网络工程师之从零开始”）发送书名获取