现网情况:单位有2台DCHP服务器作为主备,为用户提供地址服务,同时用深信用AC作为准入控制器,作为安全准入。 现网拓扑:
故障现象: 收到B区1楼员工集体反馈,无法通过dot1x认证,无法使用办公网络。 故障处理: 因为只收到B区1楼反馈,第一次时间通过堡垒机远程管理B区1楼交换机,发现无法远程,所以首先确定是否链路问题,通过ping交换机管理地址,发现正常,但是交换机无法管理,电话通知领导,交换机可能出现硬件故障。 带上笔记本电脑和同事一起到现场,发现交换机指示灯正常,用cons口线进行管理,发现正常,查看日志,发现如下记录:
存在大量的802.1x认证失败的日志:认证失败的详细原因为记录 18:55:11+08:00 XX-XXW-SW01 %%01CM/5/USER_ACCESSRESULT(s)[106226]:[USER_INFO_AUTHENTICATION]DEVICEMAC:7c-a2-3e-93-9e-b0;DEVICENAME:XXX-YW-SW01;USER:YWgOHRgEPnojRBpgI1Zxc4Q8VXE= lbl8400@DMS;MAC:00-d8-61-69-bf-30;TIME:1255431311;ZONE:UTC+0800;DAYLIGHT:false;ERRCODE:147;RESULT:Authenticate fail;USERGROUP:NULL;AUTHENPLACE:None; 同时有 SSH用户登录失败的日志:(无成功日志) +08:00 xxx-SW01 %%01SSH/4/SSH_FAIL(s)[106565]:Failed to login through SSH. (IP=XXXX 7, UserName=h比, Times=1, FailedReason=The user login timed out) //
马上收集信息,发给厂家确认了,设备本身内存未正确释放导致AAA模块有问题,导致SSH登录、802.1x等需要AAA模块的业务无法正常运行,但是又不影响串口登录设备(串口有独立的逻辑)
解决办法: 临时措施设备重启,内存释放,业务正常 长期有郊的办法,替换了其它交换机
总结:用了dot1x认证后,保护了终端安全,但是跟维护带来不方便,有时无法确定是软件问题,还是网络问题导致无法认证,需要从工作总结,积累经验。 |