前言:这个服务器的搭建只是为了了解wifidog与认证服务器的具体交互过程,在搭建商用认证服时,需要有所改进。
关于wifidog认证的流程,下面几篇博客介绍的很不错:
一.了解认证交互的数据
搭建wifidog authpuppy服务器,通过抓包,了解了认证过程数据的交互,以下是我搭建wifidog authpuppy参考的贴文
为了下面的解释说明更清楚,在上面的博客中截了下图:
关于1、2、3步是在路由器和客户端之间完成的,这里就不介绍了,
下面是第4、5、6、7步数据包分析:(客户端抓包:172.16.16.68)
第4步,截取的数据包如下,是一个get请求,附带的信息有网关ip,wifidog的监听端口2060,wifidog的gw_id,客户端mac,客户端请求的url;
第5步,认证服务器给客户端回复的信息是一个认证页面,
在这个认证页面中,是一个post提交的表格;
第6步,用户提交账号和密码,服务器收到post消息,检查用户的信息是否合理,合理则将至重定向到网关,也就是第7步;
第7步,authpuppy认证服认证通过,回复客户端一个重定向地址,包含token信息;
第8步,是客户端与路由器的交互,主要是比较token信息,第11步(黑色),路由器回复给客户端一个重定向到认证服,客户端收到重定向,进入第11步(红色);
第11步(红色),是客户端对认证服的一个get请求,认证服重定向一个url,本人重定向的url是:http://tooki.leptonnet.com/login.html。
综上,认证服需要提供,login和portal接口
下面是在服务器上的抓包,与上面抓包不是同一时间,下面的包是路由器与认证服的交互信息,因此服务器上需要有auth和ping的接口,关于字段的说明:
1.get
auth的stage字段,有至少3种状态,在stage为logout时,回复auth: 0即可,在其它状态回复auth: 1;
2.get ping,回复Pong即可;
下面是认证失败,认证服没有处理好将第6步重定向到了路由器,但此后路由器在对认证服发auth时,认证服由于没有对应的token记录,回复auth: 0,使得路由器在第11步(黑色)的时候重定向了下面的Get请求,因此,认证服需要一个gw_message.php的应答接口
二.认证服的实现
综合上面所有包的信息:认证服上需要有以下5个接口:
用户登录接口: 1.login;
登录认证成功重定向的接口: 2.portal;
路由器认证用户是否存在: 3.auth;
路由器检测认证服是否存在: 4.ping;
路由器发现用户不合理: 5.gw_message.php;
以下是实现的代码:
https://gitee.com/cocos_yang/wifidogRenZhengFuWuQi.git
注:
需要自己搭建mysql数据库,建两个表,userInfo(此表中只有两个字段username和password)和tokenMac(此表也只有两个字段mac和token);截图如下
下面是认证界面登录界面和认证成功后重定向的界面:
图一:认证界面
图二:认证成功后,重定向的界面
三.路由器中wifidog.conf的配置信息:
GatewayID yangyang
GatewayInterface br-lan
GatewayAddress 172.16.8.1
HtmlMessageFile /etc/wifidog-msg.html
AuthServer {
Hostname 1XX.XXX.2XX.1XX
SSLAvailable no
HTTPPort 80
Path /wifidog/
}
CheckInterval 60
ClientTimeout 5
FirewallRuleSet validating-users {
FirewallRule allow to 0.0.0.0/0
}
FirewallRuleSet known-users {
FirewallRule allow to 0.0.0.0/0
}
FirewallRuleSet unknown-users {
FirewallRule allow udp port 53
FirewallRule allow tcp port 53
FirewallRule allow udp port 67
FirewallRule allow tcp port 67
}
FirewallRuleSet locked-users {
FirewallRule block to 0.0.0.0/0
}
注:在wifidog中不要删掉关于firewall的配置,删除了会导致认证通过后无法上网。