Portal对接故障启示录 - 管理猿 2019 年 08 月 12 日 |访问: 154 次

Portal对接日志调试
适用版本:所有卓迈Portal
适用对接:所有基于标准Portal协议的设备对接(CMCCV1&V2,华为&华三&锐捷)
推荐工具:xshell+notepad
说明:所有在系统中执行的命令都以黄色背景标记
一.认证平台开启日志调试
kaiq.png
将tomcat日志打开。然后保存即可。
二.打开日志目录,下载或在线输出日志内容

[root@localhost logs]# find / -name catalina.out #由于安装可能不统一,使用命令查找认证的日志目录
/LSM/portal/logs/catalina.out
[root@localhost logs]# cd /LSM/portal/logs/  #进入已经查找到的日志目录

在线输入出日志内容『适合认证未上线,只有零星的几个用户在测试认证的时候』

[root@localhost logs]# tail -f catalina.out

匹配关键字输出日志内容『下文示例为输出有关192.168.100.5的前后10行信息』

[root@localhost logs]# tail -f catalina.out | grep -10 '192.168.100.5'

清空日志文件『日志文件较大,需要重新查询日志文件的时候适用』

[root@localhost logs]# > catalina.out

将日志复制到Portal目录,然后下载日志到本地分析

[root@localhost logs]# cp -r catalina.out ../webapps/ROOT/

浏览器输入http://portalIP地址:端口/catalina.out下载日志文件。如『http://192.168.100.63/catalina.out
删除已经复制过去的日志文件,防止信息泄露

[root@localhost logs]# rm -rf ../webapps/ROOT/catalina.out

三.日志文件分析
1.认证流程分析
portalc.png
认证流程中如果有错误产生,则认证就会失败。开启日志后日志会反映出整个认证流程的所有情况。根据日志反馈的情况做相应的处理即可。
认证因为协议差异有V1版本和V2版本,日志也有所不同。
下面贴出两个版本的成功日志并进行分析

- Do Record Online Count Service !!  ##在线统计服务,日志无视
 - Online Count=1 2019-8-9 week=5 HH=15 ##统计数量
 - Request Auth User: aaa IP: 172.0.0.70  ##收到一个由认证页面提交过来的认证用户数据
 - 【iKuai对接   准备portal协议报文发送】  ip: 172.0.0.70 mac: e8:e8:b7:86:be:29 user: aaa basip: 192.168.100.1  #开始Portal协议对接,将数据发送到对接设备192.168.100.1的UDP2000端口。
 - REQ Auth[010301006b340000ac00004600000003010561616102056161610b1365383a65383a62373a38363a62653a3239]  
 - [Receive ]ip=192.168.100.1,port=4975,code=1,identifier=0,length=75,authenticator=b626ec50c01d69ccd7f61b6b40cd9db0,attributes=010561616102124963be10ad9a83ea05f140eb5768f2e91f1365383a65383a62373a38363a62653a32393d06000000132007696b756169
 ##收到一条来自192.168.100.1的认证数据,源端口为4975,长度75,参数为attribute后面的一串,解析出来也就是下面的内容
 - [192.168.100.1]>>Access-Request   ##request为Radius的认证请求,说明已经进入到Radius流程
 - [192.168.100.1]>> User-Name(1)=aaa  ##请求认证的Radius账号,非账户密码认证一般调用的公共账户
 - [192.168.100.1]>> User-Password(2)=4963be10ad9a83ea05f140eb5768f2e9  ##用户的密码,没有challenge的为PAP的请求认证,CHAP必须有challenge,也有部分厂商使用authenticator作为challenge参数。
 - [192.168.100.1]>> Calling-Station-Id(31)=e8:e8:b7:86:be:29  ##认证用户的MAC地址
 - [192.168.100.1]>> NAS-Port-Type(61)=Wireless-802.11(19)   ##认证用户的类型,由BAS设备标记传递
 - [192.168.100.1]>> Nas-Identifier(32)=ikuai     ##这里一般是对接的BAS设备的主机名称
 - [Access-Request]MacAuth=false,ip=192.168.100.1,port=4975,name=aaa,password=4963be10ad9a83ea05f140eb5768f2e9  #匹配MAC校验,绑定一类
 - [192.168.100.1]Database PWD=aaa:::: Req PWD=aaa   ##匹配数据库中用户的密码.
 - [192.168.100.1]code=0,Login Success.     ##认证结果,认证平台校验成功。返回0,如果校验失败会跟具体错误。参考修改对应设置即可。
 - [192.168.100.1]Access-Request Print Finish !!  ##输出认证请求内容结束
 - [Access-Accept]ip=192.168.100.1,port=4975,code=2,identifier=0,length=66,authenticator=581373a15ed187d55c6644a27ad51986,attributes=01056161611217636f64653d302c4c6f67696e20537563636573732e1b06000151801c060000025855060000012c
  ##将认证结果返回给BAS设备,这里将数据回送给BAS设备的UDP4975端口,数据长度66,身份校验为authenticator,具体参数包含在attribute中,也是下面内容。
 - [192.168.100.1]>> User-Name(1)=aaa   ##返回给BAS设备认证的用户名
 - [192.168.100.1]>> Reply-Message(18)=code=0,Login Success.  ##返回给BAS设备的结果,部分设备会将这个信息前台提示给用户,如Mikrotik。
 - [192.168.100.1]>> Session-Timeout(27)=86400   ##本地认证可用时长,秒。
 - [192.168.100.1]>> Idle-Timeout(28)=600       ##空闲超时时长,在Radius对接中统一设置,意义为用户多长时间无流量将用户执行下线操作。BAS设备不一定会执行
 - [192.168.100.1]>> Acct-Interim-Interval(85)=300  ##记账更新间隔时间,Radius对接中统一设置,时间60到300秒内有效,较小或较大均无效。
 - [192.168.100.1]Send OK !!  ##发送状态已经发出。
 - ACK Auth[010401006b340000ac00004600000000]
 - 认证成功,准备发送AFF_ACK_AUTH!!!
 - AFF_Ack_Auth[010701006b340000ac00004600000000]
 - 发送AFF_Ack_Auth认证成功回复报文成功!!!  ##认证页面通知用户认证已经成功
 - [Accounting Receive ]ip=192.168.100.1,port=4975,code=4,identifier=1,length=97,authenticator=116f2a6a7b8a91737a5ce5d5b35cd0a2,attributes=2c10354434443235384236304433303001056161612806000000011f1365383a65383a62373a38363a62653a32392d06000000010806ac0000463d06000000132007696b756169290600000000
  ##第一条记账报文,类型start,如果无此报文。用户可能上线不成功。检查Radius对接中的设备类型。
 - [192.168.100.1]Accounting>>Accounting-Request        ##Radius的记账请求。
 - [192.168.100.1]>> Acct-Session-Id(44)=5D4D258B60D300  ##session,会话唯一。
 - [192.168.100.1]>> User-Name(1)=aaa                    ##记账的用户名
 - [192.168.100.1]>> Acct-Status-Type(40)=Start(1)       ##记账类型,开始计费,还有Interim-Update(3)和stop,inter是在认证平台更新用户的状态,如使用时长,使用流量等,stop是用户已经下线后BAS设备发送回来的参数,收到后认证平台会移除用户的在线状态
 - [192.168.100.1]>> Calling-Station-Id(31)=e8:e8:b7:86:be:29  ##记账用户的MAC地址
 - [192.168.100.1]>> Acct-Authentic(45)=RADIUS(1)        ##记账类型,radius
 - [192.168.100.1]>> Framed-IP-Address(8)=172.0.0.70     ##记账用户的IP地址
 - [192.168.100.1]>> NAS-Port-Type(61)=Wireless-802.11(19) ##用户的连接的物理介质。由BAS设备标记传递
 - [192.168.100.1]>> Nas-Identifier(32)=ikuai    ##bAS设备的身份标识符号,一般为BAS设备的主机名称
 - [192.168.100.1]>> Acct-Delay-Time(41)=0       ##尝试重发记账多少秒未收到来自计费服务器的确认。
 - [192.168.100.1]Accounting-Request Print Finish !!  ##记账报文输出完毕
 - [accountingResponse]ip=192.168.100.1,port=4975,code=5,identifier=1,length=20,authenticator=445724157518258398c46cef810e981a,attributes=
 - [192.168.100.1]Accounting Send OK !!      ##回送给BAS设备,告知记账报文已经收到了。发送失败或者端口不可达,BAS设备会在规则内重新发送
 - [Accounting Receive ]ip=192.168.100.1,port=4975,code=4,identifier=2,length=127,authenticator=e2cf507029f07c4d37754533b0ad11c9,attributes=2c10354434443235384236304433303001056161612806000000032d06000000012e060000012c2a06000478572b06001a8dec3406000000003506000000000806ac0000461f1365383a65383a62373a38363a62653a32393d06000000132007696b756169290600000000
  ##收到第二条记账报文,类型Interim-Update(3),由BAS设备的UDP4975端口发送,报文长度127,报文参数为attributes后面的,也就是下面部分
 - [192.168.100.1]Accounting>>Accounting-Request  ##记账请求
 - [192.168.100.1]>> Acct-Session-Id(44)=5D4D258B60D300   ##会话唯一
 - [192.168.100.1]>> User-Name(1)=aaa        ##记账用户的用户名
 - [192.168.100.1]>> Acct-Status-Type(40)=Interim-Update(3)  ##记账类型,还有start和stop
 - [192.168.100.1]>> Acct-Authentic(45)=RADIUS(1)   ##记账认证类型 radius。
 - [192.168.100.1]>> Acct-Session-Time(46)=300      ##可用时间减少
 - [192.168.100.1]>> Acct-Input-Octets(42)=292951   ##这个时间段用户使用的input流量
 - [192.168.100.1]>> Acct-Output-Octets(43)=1740268  ##这个时间段用户使用的output流量
 - [192.168.100.1]>> Acct-Input-Gigawords(52)=0    ##同上,单位为GB
 - [192.168.100.1]>> Acct-Output-Gigawords(53)=0   ##同上,单位为GB
 - [192.168.100.1]>> Framed-IP-Address(8)=172.0.0.70  ##记账用户的IP地址
 - [192.168.100.1]>> Calling-Station-Id(31)=e8:e8:b7:86:be:29  ##记账用户的MAC地址
 - [192.168.100.1]>> NAS-Port-Type(61)=Wireless-802.11(19)   ##记账用户的物理连接类型
 - [192.168.100.1]>> Nas-Identifier(32)=ikuai  ##BAS设备的身份标识符号
 - [192.168.100.1]>> Acct-Delay-Time(41)=0  ##超时确认
 - [192.168.100.1]Accounting-Request Print Finish !!  ##记账请求输出完毕
 - [accountingResponse]ip=192.168.100.1,port=4975,code=5,identifier=2,length=20,authenticator=00780f2a7dbf1eef881dd51009a4145d,attributes=
 - [192.168.100.1]Accounting Send OK !!  ##返回报文给BAS设备的UDP4975端口,告知记账报文已经收到了。

2.URL传参解析
URL传参格式化,将BAS的参数名重命名与认证平台的URL参数一致,否则无法解析参数。参数不加密,以UTF-8传输。

wlanacip
参数名称    字段含义
basip    bas的公网IP地址(需要对等通信),部分厂商为nas-ip
nasname    bas的系统名称
apip    认证终端所连接的AP的IP地址
apmac    认证终端所连接的AP的MAC地址
wlanuserip    认证终端的IP地址
mac    认证终端的MAC地址
url    认证终端访问的外部网络资源地址
ssid    认证终端所链接的AP的SSID名称

BAS如果无法设置对等IP,请删除掉wlanacip的传参,将BAS的系统名称修改为BAS的公网IP地址,设置BAS系统名称的传参为

  其中最重要的是basip这个参数,弹出的认证页面携带这个参数,系统根据这个参数去匹配对应的认证方案。将此IP认定为BAS设备的IP地址,回送给BAS设备的2000端口就是发送给这个Ip地址的。如果出现错误则认证不太可能成功。

3.错误日志分析

A.用户连接WIFI后无法弹出认证页面。

终端连接WIFI后让用户从浏览器访问qq.com。
直接打开了腾讯手机网。说明用户本身已经认证成功或者不需要认证。没有任何问题。
打开白屏,有DNS类的字样,浏览器的地址栏未出现预设的Portal服务器地址。检查BAS设备上设置的DNS服务器是否有效,部分BAS设备需要单独放行DNS服务器地址,或者放行DNS服务器专用的53端口,问题严重可与BAS厂商确认。
打开白屏,点击地址栏有预设的Portal服务器地址。请用户复制地址栏的URL地址进行进一步分析。但是打不开页面。问题常见于BAS设备未将Portal服务器加入认证白名单。未允许用户认证前能够访问,BAS设备添加白名单解决。

  1. Portal认证手机无法自动弹出认证页面

这个问题是很多甲方爱纠结的地方,对于苹果设备,认证过一次,第二次一般不会自动弹出页面,忽略网络即可。
这里还需要聊下自动弹出认证页面的原理,当前很多终端厂商在用户链接WIFI后会去访问厂商自身的一个服务器地址,如果服务器地址返回一个正确的状态码就点亮WIFI图标。访问服务器的这个动作触发了Portal的http请求,就直接弹出了认证页面。
所以遇到这类问题的时候可以抓包终端访问的服务器地址,在认证前访问资源白名单给拦截掉。
DNS解析出错也会导致不能自动弹出页面。
C.日志提示发送challenge请求无响应
这一步问题导致的原因是用户弹出认证页面后,用户输入认证信息点提交,发送给Portal服务器,Portal服务器将信息发送给BARS设备的UDP2000端口后,没有得到对应的回应返回的错误码。
导致此类问题常见的原因是Portal协议(V1和V2)不匹配,对接的Portal密钥不匹配导致的。解决方案是切换portal协议类型。然后再查看认证的日志信息。
防火墙阻断或者过滤功能也会导致BARS无法返回信息给Portal服务器。换句话说就是认证平台发送给BAS设备的2000端口数据不可达
D.Portal认证发送认证请求无响应
出现此类问题是BARS将用户的认证信息提交给Radius服务器没有得到回应,报文直接被丢弃。
最常见的错误是BARS中设置的Radius服务器地址错误,对接密钥错误。仔细检查更正即可。
没有设置指定的认证域domain,此类常见于华为h3c等命令行配置的BARS。正确指定认证域即可。
部分设别会指定与Radius服务器通信的源IP,指定错误可能造成无法通信出现此类错误。无法处理可要求BAS设备开启DEBUG RADIUS查看具体错误。
E.发送认证请求被拒绝
此类错误是BARS提交的用户认证信息给Radius服务器的UDP1812端口数据被拒绝,但是没有返回具体的错误码。
检查Radius服务器填写的Radius客户端地址和密钥是否正确,输出Radius日志可以查找到具体问题。无法处理可要求BAS设备开启DEBUG RADIUS查看具体错误。
F.Portal认证发送认证请求失败
这个错误是Portal服务器将认证信息发给BARS服务器的UDP2000端口后,BARS服务器没有下一步操作了。
这个问题出现的也是比较诡异,一般是用户已经成功在BARS上线了(认证成功),才不会产生下一步操作,检测该终端在BARS上的状态。
G.Portal认证认证超时
认证页面出现的提示,前面的请求无响应都会在页面提示超时,Radius部分认证失败会提示认证失败。

  1. Portal认证认证失败

这里是用户信息校验失败,用户已经在线,用户名密码错误等会导致此类错误,具体错误查看日志中的reply-message后面的错误
4.故障排查流程及注意事项
已经有过认证成功案例的设备对接,出现故障的排查流程及注意事项。即使以数据证明部分地方是不可能出问题的,也需要逐条检查,问题往往出现在不肯能的地方
A. 网络环境的排查
认证过程中使用的端口包含1812,1813,3799,2000,50100和WWW端口。所以整个认证流程中务必确保端口能够使用。发送的消息不被截胡。
逐条排查认证过程中AC的端口是否冲突,上端防火墙或者审计设备是否有防止攻击的规则,包含以上端口的攻击防范都需要例外处理。端口映射的源端口和目的端口是否配置错误等
B. Portal流程排查
排查Portal发送的报文是否有回包,回包的错误提示信息(根据返回的错误信息变更对接协议及版本)。或者是否回包(回包被Portal丢弃,密钥不对。没回包,Portal没能成功将数据发送给BAS的指定端口,设备过滤,或者没在Ac允许的范围内,被AC丢弃)。
C.Radius流程排查
华为设备有test-aaa功能,快速简单进行Radius报文排查。在日志过程中显示已经SUCCESS。但是用户无法上线。Radius发送给BAS设备的参数BAS设备无法执行,拒绝用户上线,Radius设备发送给BAS设备的报文,BAS设备没有接受到(查看发送给BAS的端口是多少,tcpdump抓包或者查看日志),确认BAS的该端口是否被审计或者加防火墙等。

  1. 总结
    对接也就BAS设备和Portal设备的一个内部沟通过程,沟通过程中确保信息的安全性和完整性,双方协调了一个共享密钥,使用的语言版本(协议),沟通过程中均使用密钥。
    协议的匹配十分重要,如果不匹配的最终结果就是(举例。AC用汉语+密钥传输给Portal,Portal用密钥+英语去解析数据,解析出来的数据匹配不上)Portal就直接拒绝。
    双方确定了消息传递机制,如Portal过程中,发给AC的消息要发送给Ac的UDP2000端口,如果端口不可达,或者这个端口被其他设备过滤了数据,就导致AC收不到认证过程中的关键信息,整个沟通就是失败的。
    在Radius过程中,按照惯例AC传递用户的认证信息给Radius服务器的1812端口,Radius服务器将结果信息回送给这条认证信息的源端口,若源端口是固定的,则需要映射。若源端口随机,则路由转发最终回到AC。

标签:none

添加新评论


评论:只有地板了

  1. 管理猿 管理猿

    DEBUG发现BAS设备已经给Portal服务器发包,但是Portal服务器提示认证请求无响应。
    检测BAS端配置的nasip,basip,source-ip等。配置一个在BARS的ARP表中不存在的地址,会导致报文路由出错。最终发送不出去。
    修改以上IP地址为BARS设备上存在的IP地址。

    回复