单位内用户主机接入认证慢故障分析案例——IT工程师必学

1、情况简介

某单位的用户在接入内网的时候需要在终端上安装接入认证客户端并进行认证，用户反映认证时间较长需要一分钟左右的时间，认证时间超出了用户体验。

2、 分析思路

从用户反映的情况初步怀疑是终端认证出了问题，现选取一台终端安装认证接入客户端进行认证操作并且同时抓包还原整个交换过程，对问题进行确认。

2.1 整个报文过程简述

在安装好客户端后点击认证，大约一分钟后认证成功，通过wireshark过滤会话，截图如下：

整个交互过程

根据交互行为，从手指点击认证开始到认证成功共产生了9个报文，大约经过了60.6635秒后，INFO信息里面反映Success认证成功，这说明在经过了一分钟后认证才成功，那时间到底是在哪里耽误的，具体分析如下：

2.2 第一次30秒延时分析

在手指点击认证的时候客户端先发送了一个报文后等待了30.016秒后又发送了一个广播报文。

第一个报文是一个携带认证协议的二层的单播包，源MAC是客户端地址，目的MAC是为01:80:c2:00:00:03，暂时不清楚是什么设备的MAC。

30.016秒后客户端又发出了一个报文广播的内容，源MAC为客户端地址，目前MAC是全F广播地址，携带认证start开始信息。

紧接着认证服务器就发起了Request Identity请求报文，这第三个报文

该报文具体内容：源MAC是华为核心交换机的网关MAC，说明认证服务器在收到了广播包后迅速做出了回应，发送了认证请求。

2.3 第二次30秒延时

客户端在收到了服务器发送的558号Request Identity请求报文后又向MAC地址01:80:c2:00:00:03回应了一个包号为559的应用信息是Response Identity的报文，意思是回应认证，但是我们发现MAC地址不是华为核心的地址，而且这个目的MAC与第一个8号报文的目的MAC相同。

由于目的地址错误导致认证服务器没有收到，认证服务器在30秒后重新发送了认证请求980号报文，这时客户端向正确的目的地址华为核心MAC进行了回应，发送了981号报文。

2.4 小结

客户端的发送第一个8号报文是一个二层单播MAC，目的MAC地址01:80:c2:00:00:03和本次认证过程无关，导致30秒后客户端发送了557号广播报文，核心应该是开启了代理功能代收并转发了二层广播包给认证服务器，认证服务器向客户端发送了认证请求报文558号，而客户端收到后却发送了目的MAC为01:80:c2:00:00:03的559号的认证回应报文，按道理目的地址应该是网关的MAC，所以网关没有收到该认证回应报文，所以又耽误了30秒。通过分析认定第一个8号和559号目的MAC地址01:80:c2:00:00:03是客户端主动发出的。

通过认证过程的报文交互行为分析，认证慢的原因是认证客户端在认证过程中发送了与认证不相关的目的MAC地址01:80:c2:00:00:03导致的，认证客户端自身存在问题。

把客户端设置选项中的发送方式由之前的智能识别改成广播后，认证时间由原来的一分钟变成了30多秒。

认证报文数量由原来的9个变成了8个，认证时间变成了30.06秒。

产生该现象应该和认证客户端配置文件有关，需要和认证软件厂家的研发进行协作，让厂家修改客户端配置文件解决这30秒的延时，如果修改成功可以再减少30秒的延时。