服务器未发送成功请检查错误信息,iMC-EIA结合iNode进行portal认证成功后提示安全认证失败“未收到服务器回应，即将强行下线，请检查终端能否正常访问网络或者与管理员联系”导致下线经验案例...

对于此类问题，我们需要了解认证上线以及安全检查的过程，过程如下

1、iNode使用客户端拨号进行认证；

2、认证成功后，终端发送安全检查请求报文给策略服务器(EAD服务器)

3、策略服务器回应安全检查请求报文，并给终端下发安全检查策略

4、终端根据服务器侧下发的安全检查策略，进行安全检查，根据检查结果，确认终端是在线还是强制下线。

根据以上思路，结合现场具体情况分析如下：

一、分析iNode日志：

1、首先收集iNode侧详细级别日志，从而确定是服务器没有发送相关报文给iNode终端，还是服务器侧发送了相关报文但是iNode侧没有收到，iNode侧日志分析如下：

2、iNode给策略服务器发送了EAD1号报文(见1中截图)，服务器也正常回应了EAD2号报文，如下：

3、EAD2号报文之后，iNode给策略服务器发送了EAD97号报文，即ACL请求报文，如下所示：

4、策略服务器给iNode发送了EAD98号ACL下发报文，如下所示：

5、继续分析iNode日志，iNode随后给策略服务器发送了EAD3号报文，即按全认证检查结果上报报文，报文如下：

但是此后，策略服务器没有给iNode发送回应报文，而根据iNode报文重传机制，如果没有收到服务器的报文，则5s后重传一次，重传三次(默认三次)后自动下线，并提示“未收到服务器回应”，在报文中能够看到重传的报文，如下所示：

二、分析策略服务器日志&抓包：

1、分析策略服务器调试日志，确认服务器是否发送了回应报文，但是在服务器日志中，搜索该用户的相关信息，发现iNode发送给该策略服务器的EAD3号报文服务器并没有收到，如下所示：

2、从上图策略服务器日志看，策略服务器日志中并没有liang7227用户的三号报文。为了进一步确认服务器是否接收到了该报文，同步在iMC服务器和Client出进行抓包分析。

(1)server端抓包：查看Server侧抓包，通过ip和udp9019过滤，发现服务器并没有收到该EAD3号报文，如下所示：

(2)client端抓包：查看client侧抓包，通过ip和udp9019过滤，发现终端网卡并没有发送该EAD3号报文，如下所示：

三、经过以上排查可以确认问题出自iNode和终端网卡之间，即一开始终端和策略服务器是通的，但是中间环节出现了不通的情况，再细看iNode日志发现：现场配置的隔离acl是禁止所有目的ip，感觉有可能是acl下发导致网不通了，进而后续的报文没有发给策略服务器。日志见下：