2015年2月

wifidog配置页面

openwrt上自带了wifidog 程序,界面如下:
1.png

1)wifidog守护进程:启用代表无线需要使用wifidog 来认证
2)网关ID:标识路由器的字段
3)External Interface/Internal Interface,内外网的Interface
4)端口:wifidog作为socket 服务端的监听端口
5)最大用户数:能连接的设备个数
6)检查间隔:隔多久检查一次客户端是否超时
7)客户端超时:客户端连接多久超时或者客户端多久不上网认为超时,会被下线重认证处理
8)信任的MAC列表:拥有这些MAC的设备不用做认证可以直接上网
9)鉴权服务器主机名:portal/auth/login的server 地址
10)鉴权服务器SSL启用:Auth server是否使用了HTTPS 连接
11)鉴权服务器HTTP端口:auth server http监听端口
12)鉴权服务器路径:auth server 的http 服务器根目录
13)HTTP Server authentication support:启用表示使用HTTP 服务认证
14)HTML Message file for wifidog:wifidog出错时会弹出的页面
15)防火墙规则设置:设置一些黑白名单

本文章由 http://www.wifidog.pro/2015/02/11/wifidog%E9%85%8D%E7%BD%AE-1.html 整理编辑,转载请注明出处

WifiDog 认证原理和流程

WifiDOG是一个热点系统,包含了认证服务器和客户端两部分组成,认证原理大体说下:
General Flow Description:
一般流程描述:
①The client does his initial request, as if he was already connected, (e.g.: http://www.6hl.cn)
客户端发出初始化请求,比如访问 www.6hl.cn 这个站点
②The Gateway's firewall rules mangle the request to redirect it to a local port on the Gateway. When that's the done, the Gateway provides an HTTP Redirect reply that contains the Gateway ID, Gateway FQDN and other informations
网关的防火墙规则将这个请求重定向到本地网关的端口上。当做完这个工作,网关提供一个HTTP重定向回复,包含了Gateway的ID,Gateway的FQDN以及其他的信息。
③The Client does his request to the Auth Server as specified by the Gateway, see Login Protocol
用户向认证服务器发出认证请求
http://auth_server/login?
gw_id=[GatewayID, default: "default"]
gw_address=[GatewayAddress, internal IP of router]
gw_port=[GatewayPort, port that wifidog Gateway is listening on]
url=[user requested url]

④The Gateway replies with a (potentially custom) splash (login) page
网关返回一个(可以是自定义的)splash(也称作“登录”)页面
⑤The Client provides his identification informations (username and password)
用户提供他的凭据信息,比如用户名和密码
⑥Upon succesful authentication, the client gets an HTTP Redirect to the Gateway's own web server with his authentication proof (a one-time token), http://GatewayIP:GatewayPort/wifidog/auth?token=[auth token]
成功认证的话,客户端将会被重定向到网关的自己的web页面上,并且带有一个 认证凭据(一个一次性的token),内容比如
http://GatewayIP:GatewayPort/wifidog/auth?token=[auth token]
⑦The Client then connects to the Gateway and thus gives it his token
用户就是用获取到的凭据访问网关
⑧The Gateway requests validation of the token from the Auth Server, see Client Protocol【见登录心跳】
网关去认证服务器询问token的有效性
⑨The Auth Server confirms the token
认证服务器确认token的有效性
①①The Gateway then sends a redirect to the Client to obtain the Success Page from the Auth Server, redirects to http://auth_server/portal/
网关发送重定向给客户端,以从认证服务器上获取 成功提示页面,重定向到 http://auth_server/portal/ 这个位置
①②The Auth Server notifies the Client that his request was successful
认证服务器通知客户请求成功,可以上网了

本文章由 http://www.wifidog.pro/2015/02/11/wifidog%E5%8E%9F%E7%90%86%E5%8F%8A%E6%B5%81%E7%A8%8B.html 整理编辑,转载请注明出处

如何构建类似CMCC的公共场合WIFI认证过程

我们去大多数机场或者一些公共场合的时候,会看到很多公共的WIFI热点需要进行手机号的短信认证登录,那么我们如何去构造这样一个系统呢?

这里介绍一种技术——wifidog,其提供了一套这样的解决方案,适用于openwrt和ddwrt,其包括了两个部分路由端需要安装的插件,以及一个提供的基于XMPP的web解决方案,我看了下觉得如果使用它提供的web解决方案的话,非常不方便,因为这样的技术一般只要弄清楚其通信的机制和协议就可以了,所以在文档中找到了其通信的协议,之后我会加以说明其相关的协议。

具体的原理是怎样?又是如何实现的。

首先我们需要一个可以进行命令行管理操作的路由器,比如刷过类似于openwrt或者ddwrt这种系统的路由器,这样的一个系统类似于一个小的Linux系统,如果我们可以进行命令行的控制,那么我们就可以安装一系列的软件了,这里我们通过给路由器安装wifidog,实现构建这样一个WIFI认证的系统。那么wifidog是如何实现整个过程的呢?

如何限制用户上网

简单来讲就是路由层会将所有的用户mac地址进行一个名单的控制,所以在未登录认证之前,然后wifidog可以配置一个登录授权的服务器地址,用户不在白名单列表里,就会被重定向到这个网址。

一般来讲,其实所有的网络访问应该都是不可以的,但是借助于iptables的管理,路由器可以设定一些ip以及相关协议(tcp, udp)的白名单,所以对于认证过程中可能设计到网页,包括中间需要网络请求提交的地址(例如新浪或者QQ等第三方的登录授权)都需要加入到访问网络地址的白名单里面。这样可以保证用户基本的网络访问权限的限制吗,但是同时又不影响网络的授权。

如何进行认证

当用户被重定向到了认证的网页之后,剩下的操作就在认证服务器端进行了,但需要保证的是,因为现在用户的基本网络访问权限是被限制住的,所以中间所有涉及到的网络请求地址都需要按照上面说的给加入到白名单里面,否则因为一些请求发送不出去,所以不能完成认证。

对于认证的过程,根据上述的描述,因为认证操作都在认证服务器端,所以可以保证认证过程是非常灵活。就比如说 我们常见的是短信验证码的认证,除此之外,我们可以用新浪微博登录,微信添加帐号,动态密码,豆瓣人人登录等等,因为一般第三方登录都是基于XOAuth或者OAuth2.0认证,所以一般都是无非有一个登录的地址,然后一个回调的地址,但是需要注意的是,第三方登录页面会有一些JS或者CSS资源之类的,这些资源可能不在同域下面,而一些图片显示,最重要登录验证提交都是在JS里面,所以也需要抓包分析一下地址,进行路由器的配置白名单。

如何实现用户认证之后打开网络权限以及用户控制

现在很多人可能有疑问是,认证操作是在服务器端进行的,那么认证通过后,认证服务器是如何告知路由器用户已经通过授权呢?

其实因为用户此时在内网,所以wifidog的解决方案是,在内网的一个ip地址开了一个端口(一般是2620),接受HTTP的请求,所以认证服务器认证成功之后需要给用户生成一个唯一的token标识,然后重定向到这个http请求地址并带上参数即可。

然后路由器这边接受到了请求之后,就会认为这个用户(实际判断是mac地址)可以进行网络访问,但是呢,实际上也不会这么直接开放用户网络权限,因为一般来说我们用CMCC的话是不是会看到用户已经上网的时长呢,所以这里wifidog也提供了一个用户的控制,具体是怎样的呢?

就是在用户认证成功之后,路由器不是得到了用户的token吗,然后token和mac以及ip可以构成唯一,所以路由器会周期性地把这三个值以及连接信息(其他参数)一起发给认证服务器,认证服务器通过返回值来判定该用户当前的状态,比如是可以继续网络访问呢,还是拒绝,还是验证失败,还是出错等等,来控制用户的访问权限。

例如实现三个小时剔除用户的话,就可以从用户认证通过开始计时,如果超过三小时,当路由器三小时后周期性发来验证信息的时候,可以返回拒绝,然后用户就会被踢下线。

整个逻辑也就是: 用户认证服务器通过后,会重定向到路由器的http认证地址,路由器获取用户的token,开始对其进行周期性的验证,由认证服务器对其进行鉴权。

路由器和认证服务器的心跳包保持在线

有的时候因为需要判断路由器这边的认证授权控制是否正常工作,所以路由器会一直对认证服务器进行心跳包的发送,可以让认证服务器监控到路由器是否正常工作。

以上就是借助wifidog的原理,对WIFI认证登录控制的整个限制的过程分析,这里主要是基于wifidog v1的协议和原理。 欢迎多多交流。

本文章由 http://www.wifidog.pro/2015/02/11/wifidog-cmcc.html 整理编辑,转载请注明出处

wlan网页登录认证原理

解答一:

它叫做 Captive portal,请自行wiki

算了,还是简单说一下吧
实现方法不止一种

方案一
DNS跳转,把客户端所有的dns请求都解析为认证服务器的ip,然后认证服务器上有404跳转
或者用dns url跳转,直接把dns解析为认证页面的地址

方案二
http跳转,对所有的http请求返回302或者301跳转,目标是认证页面。在网关上就可以实现

方案三
ip跳转,既把所有的ip包里的目标地址改为认证服务器,然后在认证服务器上做404跳转(因为用户有可能访问http://example.com/notexist这样在认证服务器上不存在的地址,所以需要404跳转),目标同样是认证页面,在网关上也可以实现。

解答二:

有个东西叫做bas(broadband access sever)做控制,ac一般透传vlan到bas,由bas控制用户。用户需要在bas通过aaa,否则是不能上网的,即使你有貌似合法的ip。

WLAN用户接入流程
流程描述:
1) 用户通过标准的DHCP协议,通过AC获取到规划的IP地址。
2) 用户打开IE,访问某个网站,发起HTTP请求。
3) AC截获用户的HTTP请求,由于用户没有认证过,就强制到Portal服务器。并在强制Portal URL中加入相关参数,具体请参见《中国移动WLAN业务PORTAL协议规范》。
4) Portal服务器向WLAN用户终端推送WEB认证页面。
5) 用户在认证页面上填入帐号、密码等信息,提交到Portal服务器。
6) Portal服务器接收到用户信息,向Radius发出用户信息查询请求。
7) Radius验证用户密码、查询用户信息,并向Portal返回查询结果及系统配置的单次连接最大时长(SessionTimeout)、手机用户及卡用户的套餐剩余时长信息(AvailableTime)。
8) 如查询成功,Portal服务器按照CHAP流程向AC请求Challenge。如果查询失败,Portal直接返回提示信息给用户,流程至此结束。
9) AC返回Challenge,包括Challenge ID和Challenge。
10) Portal将密码和Challenge ID及Challenge做MD5算法后的Challenge-Password,和帐号一起提交到AC,发起认证。
11) AC将Challenge ID、Challenge、Challenge-Password和帐号一起送到中央RADIUS用户认证服务器,由中央RADIUS用户认证服务器进行认证。
12) 中央RADIUS服务器根据用户信息判断用户是否合法(对于省内预付费卡用户,还需要判断用户接入地和归属地是否一致)。RADIUS对用户密码分别进行 静态密码和动态密码两次密码认证。如果其中一次成功,RADIUS向AC返回认证成功报文,并携带协议参数,以及用户的相关业务属性给用户授权。如果两次 都失败,RADIUS向AC返回认证失败报文。
13) AC返回认证结果给Portal服务器。(以及相关业务属性。)
14) Portal服务器根据认证结果,推送认证结果页面。如果成功,根据编码规则判断帐户的归属地,推送归属地定制的个性化页面,并将认证结果、系统配置的单 次连接最大时长、套餐剩余时长、自服务选项填入页面,和门户网站一起推送给客户,同时启动正计时提醒。如果失败,页面提示用户失败原因。
15) Portal服务器回应AC收到认证结果报文。如果认证失败,则流程到此结束。
16) 认证如果成功,AC发起计费开始请求给中央RADIUS用户认证服务器。
17) 中央RADIUS回应计费开始响应报文,并将响应信息返回给AC。用户上线完毕,开始上网。
18) 在用户上网过程中,为了保护用户计费信息,每隔一段时间AC就向中央RADIUS用户认证服务器报一个实时计费信息,包括当前用户上网总时长,以及用户总流量信息。
19) 中央RADIUS计费服务器回应实时计费确认报文给AC。
20) 当AC收到下线请求时,向RADIUS用户认证服务器发计费结束报文。
21) 中央RADIUS计费服务器回应AC的计费结束报文。

解答三:
wifidog
一. 用户上线

  1. 用户访问网络,通过iptables将未认证的用户dnat到wifidog进程,wifidog通过307报文将用户重定向到认证服务器

  2. 用户打开认证服务器登录页面,输入用户名密码,发送认证请求

  3. 认证成功的话服务器会发送302报文,携带token信息重定向到wifidog页面。认证失败的话会返回失败页面

  4. 用户携带token信息向wifidog发起认证请求,wifidog再向认证服务器发起请求,认证成功后授权,并将用户重定向到成功页面
    1.png

二. 保活和下线

  1. wifidog会定时向认证服务器发送保活消息

  2. 当用户主动请求下线后,wifidog此时并没有下线

  3. 当wifidog再次发起保活请求时,认证服务器会告诉它用户已下线,此时wifidog会将用户下线
    2.png

本文章由 http://www.wifidog.pro/2015/02/11/wifidog%E8%AE%A4%E8%AF%81-4.html 整理编辑,转载请注明出处