一 认证流程描述
　　i. Wifidog 运行之后建立一系列的防火墙规则，主要规则起到如下作用：

　　　　1.阻断所有内网到外网的访问。

　　　　2.开通内网到外网的 dns 访问。

　　　　3.开通内网到认证服务器以及域名白名单的访问。

　　　　4.对内网到外网 80 端口的访问转向到 wifidog 自己的 http 服务（2060 端口）。

　　ii. 手机、pc 连接上来后，app 或者系统（安卓、ios 会自己连接到各自的服务器上来验证网络的连通性）会发起对外网的访问请求，dns 请求会被放过，然后对应的 80 端口的访问会被指向 2060 的 http 服务，其他的请求都会被拦截。
　　iii. Wifidog 的 http 接到 web 请求后，基本上都会被指向 404 页面，404 页面会给客户端一个重定向返回（302），要求客户端重定向访问认证服务器的 login 页面，附加参数 gw_id、gw_address、gw_port、url。
　　iv. 手机、pc 客户端加载、显示认证服务器的 login 页面，用户根据页面内容做相关的认证操作（qq 登录、微博登录、用户名密码登录、手机短信登录等多种登录方式） ，原则只有一个认证不成功就仍然让用户停留在认证服务器继续认证操作，认证成功给客户端一个 302 重定向返回，根据 login 接口提交上来的参数 gw_address、gw_port 跳转套 wifidog web 服务的/wifidog/auth 页面上，附带 token 和 url 参数。
　　v. Wifidog 的 web 服务收到手机、pc 客户端的/wifidog/auth 请求后，会主动对认证服务器的 auth 接口发起一个验证请求， 附带参数 ip、 mac、 token、 stage=loginvi. 认证服务器的 auth 接口收到 wifidog 的请求， 要根据内部逻辑返回是否允许通过的应答 ：

　　　　Auth: 0 拒绝

　　　　Auth: 1 允许

　　vii. Wifidog 接收到验证结果后，如果拒绝访问，就会返回 302 给客户端，重定向到认证服务器的 gw_message 接口，附带 message=denied 参数，客户端的上网访问仍然会回到第二步骤；如果允许访问，则改动防火墙规则，开通改客户端的上网（至此客户端已经能够正常上网） ，然后返回 302 重点向给客户端，重定向到认证服务器的 portal 接口，附带参数 gw_id。

　　viii. 认证服务器的的 portal 接口根据业务流成显示广告业或者做其他的跳转ix. 整个认证流程完成。

二 ping 心跳流程描述
　　i. ping 接口 wifidog 检测认证服务器访问是否正常、并向认证服务器提交 wifidog的运行状态。
　　ii. 定时 ping 认证服务器。
　　iii. 提交的参数 gw_id、sys_uptime、sys_memfree、wifidog_uptime。

三 auth 心跳流程描述
　　i. 和 ping 一样的频率定期请求认证服务器，并且有多少已认证客户端就发多少请求。
　　ii. 用来向认证服务器提交客户端的状态以及执行认证服务的验证结果。
　　iii. 提交的参数有：ip、mac、token、incoming、outgoing 、stage=counters。
　　iv. 如果服务器返回拒绝，则 wifidog 改动防火墙规则，关闭该客户端的上网。

本文章由 http://www.wifidog.pro/2015/03/18/wifidog%E6%A0%87%E5%87%86%E6%B5%81%E7%A8%8B%E6%8F%8F%E8%BF%B0.html 整理编辑，转载请注明出处

wifidog是一个用于配合认证服务器实现无线网页认证功能的程序，常见的情景就是使用于公共场合的无线wifi接入点，首先移动设备会连接公共wifi接入点，之后会弹出网页要求输入用户名密码，认证过后才能够连入外网。其主页是http://dev.wifidog.org/

实现原理

　　其实wifidog原理很简单，主要是通过管控iptables，配合认证服务器进行客户端的放行操作。wifidog在启动后都会自动启动三个线程，分别为客户端检测线程、wdctrl交互线程、认证服务器心跳检测线程。每当新用户连接无线AP并浏览网页时，wifidog会获取新用户的此次操作，并返回一个重定向到认证服务器的http于用户，此后用户通过认证服务器认证后，再继续浏览网页时，wifidog会询问认证服务器此用户权限，若放行则修改iptables放行此用户IP。

主要流程如下

• 添加关键路径对应的回调函数
• 删除所有iptables路由表
• 建立新的iptables路由表
• 开启客户端检测线程（用于判断客户端是否在线，是否登出）
• 开启wdctrl交互线程
• 开启认证服务器心跳检测线程
• 循环等待客户端连接（使用socket绑定2060端口并监听，实际上在建立新的iptables路由表规则时会将网关的80端口重定向到2060端口）

回调函数
　　回调函数主要用于根据用户http报文执行不同的操作，其原理就是分析http报文请求中有没有关键路径，若有，则执行关键路径对应的回调函数，若没有，则返回一个重定向到认证服务器的包给用户。一次典型的流程为

• 用户连接无线AP，访问某网站（比如http://www.baidu.com）
• wifidog获取到此http报文，检查是否包含关键路径，没有则返回重定向包给用户，将其重定向到认证服务器
• 用户认证成功，认证服务器将用户重定向到无线AP网关，并包含关键路径"/wifidog/auth"和token
• wifidog接收到用户重定向后访问的报文，检测到关键路径"/wifidog/auth"，然后访问认证服务器进行token认证
• 认证成功，wifidog修改iptables放行此用户（根据mac和ip进行放行）

wifidog的iptables规则
　　这一部分我没有仔细认真看源码，但可以推论出wifidog是怎么修改iptables的规则的，了解iptables基本原理的同学都清楚iptables实际上有两条路进行数据包处理，一条路会通过应用程序，一条路不同过应用程序，直接到POSTOUTPUT，而我认为wifidog建立的规则是

• 只要是访问认证服务器的http请求都直接不通过wifidog发送出去
• 只要是通过认证的客户端wifidog都会修改iptables让其数据直接从FORWARD到POSTOUTPUT，而不经过wifidog
• 其他行为都必须进过wifidog处理

客户端检测线程
　　此线程每隔60s会遍历一次客户端列表，对每一个客户端列表统计流量，如果客户端在60s间隔内没有新产生的流量则不更新客户端的最新更新时间，当当前时间减去最新更新时间大于断线要求时间时，则会将此客户端从客户端列表删除，并修改iptables规则禁止其访问外部网络，然后发送此客户端登出包于认证服务器，认证服务器根据此登出包将此客户端做登出处理。如若没有超出断线要求时间，此线程还会发送客户端状态获取包于认证服务器，认证服务器返回此客户端在认证服务器上的信息，如若信息表示此客户端已在认证服务器上登出，wifidog则会执行此客户端下线操作。

wdctrl交互线程
　　其原理是使用unix socket进行进程间通信，具体实现在之后文章中体现

认证服务器心跳检测线程
　　原理也很简单，就是每隔60s将路由的一些系统信息发送给认证服务器，认证服务器接收到会返回一个回执

　　循环等待客户端连接
　　这里主要会接收到两种类型的客户端连接

未认证的客户端打开网页操作，wifidog会接收到此http请求，并返回一个重定向到认证服务器的包于客户端
经过认证服务器认证成功后，认证服务器自动将客户端重定向到无线AP的操作，wifidog接收到此类http请求后会检测关键路径"/tmp/wifidog"，并把http请求中携带的token与认证服务器进行认证，认证成功后则修改iptables放行客户端。

具体代码实现见之后章节

本文章由 http://www.wifidog.pro/2015/03/17/wifidog%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90-wifidog%E5%8E%9F%E7%90%86.html 整理编辑，转载请注明出处

概述

wifidog是搭建无线热点认证系统的解决方案之一，他比nocat更适合互联网营销思路。目前支持openwrt系统，他实现了路由器和认证服务器的数据交互，在路由器方是用C语言代码，通过wifidog程序和linux iptables防火墙实现接入用户的认证跳转和控制，在认证服务器方是通过php实现用户的认证流程和管理。
优点：有开源代码，可以很方便的搭建认证系统。
缺点：通过iptables方式实现，性能比较差，整体拉低了路由器的数据包处理速度，协议比较繁琐，对认证服务器的造成性能损耗比较大，在安全方面都是明文传输，有一定的安全隐患。

认证流程图:

网关心跳协议

Wifidog将ping协议作为心跳机制向认证服务器发送当前状态信息。实现认证服务器和每个节点的状态双向健康监测的机制。

请求信息：
http://auth_sever/ping/? gw_id=%s sys_load=%lu sys_memfree=%u sys_load=%.2f wifidog_uptime=%lu

回复格式：
Pong

例子：
GET/ping/? gw_id=001217DA42D2&sys_uptime=742725&sys_memfree=2604&sys_load=0.03&wifidog_uptime

用户状态心跳协议

请求格式：
http://auth_server/auth/? stage= ip= mac= token= incoming= outgoing=

注意：
ip,mac,token为用户的基本信息，incoming/outgoing为用户的连接计数信息。 stage=counter|login|logout，分别表示：已认证，新认证用户，超时需要删除的用户。

回复格式：
Auth:状态码(注意中间冒号和状态码之间有个空格)

状态码：
0-AUTH_DENIED-Userfirewallusersaredeletedandtheuserremoved. 1-AUTH_ALLOWED-Userwasvalid,addfirewallrulesifnotpresent

例子：
GET/auth/?stage=counters&ip=7.0.0.107&mac=00:40:05:5F:44:43&token=4f473ae3ddc5c1c2165f7a0973c57a98&incoming=6031353&outgoing=827770HTTP/1.0 User-Agent:cnrouterwifidog Host:auth.cnrouter.com

跳转协议

对于新连接用户，路由器将其产生的任意url请求通过302重定向到认证平台。
请求格式：
http://auth_server/login/? gw_id= gw_address= gw_port= mac= url=

例子：
GET/login/? gw_id=808100949391&gw_address=192.168.81.1&gw_port=80&mac=aa:bb:cc:dd:cc:ee&url=http://www.sina.com.cn/HTTP/1.0 User-Agent:cnrouterwifidog Host:auth.cnrouter.com

注册协议

请求格式：
http://gw_ip/wifidog/auth? token=

例子：
GET wifidog/auth?token=12312412124 User-Agent:iphone Host:路由器ip 注册请求成功，以307的方式跳转平台的portal/?gw_id=

本文章由 http://www.wifidog.pro/2015/03/17/wifidog%E8%AE%A4%E8%AF%81%E8%B7%AF%E7%94%B1%E6%8E%A5%E5%8F%A3%E6%96%87%E6%A1%A3.html整理编辑，转载请注明出处

Token，一般模式
目前连接令牌都是弱实体，直接保存在连接表格里。一些利害关系人喜欢向连接添加特性（限时，稳定性令牌等等）来支持不同的无线社区模式。为了不搬起石头砸自己的脚，我们需要一个数据模式来解决连接处理和重新使用的问题，不只是它退化的情况。
以下是进行此操作的第一部分草稿。

数据模式

• Token_templates
• Token_template_id
• Token_template_network(注：Server-wide令牌不予以支持，但代码会查找你同步的网络的令牌)
• Token_template_creation_date
• Token_max_incoming_bytes 如：允许覆盖带宽
• Token_max_outgoing_bytes 如：允许覆盖带宽
• Token_max_total_data 如：允许覆盖带宽
• Token_max_connection_duration： 如：允许限制单独连接的长度
• Token_max_usage_duration: 如：允许以小时计算出售访问（只有在使用时开始计算）
• Token_max_wall_clock_duration: 如：允许出售日执照，周执照或月执照（当令牌第一次使用时开始计算）
• Token_max_age: 如：允许在期满之前设置最长时限（当令牌被发布时开始计算）
• Token_is _reusable:当期满时创建的令牌还可以重新使用吗？（能常情况下是可以的）

Tokens_template_valid_nodes(遗憾的是，酒店向他们的客户出售24小时访问权，我们考虑到他们的网络也许包括不只一个节点。如果令牌不准进入表格，它就会在网络的任何位置被认为是有效的)

• Token_template_id
• Token_valid_at_node

Token_lots:

• Token_lot_id
• Tonken_lot_comment:关于lot的自由形态评论
• Token_lot_creation_date

Lot是被同时发布的令牌组，例如预付卡。
Token_status

• Token_status
• Tokens
• Token_id
• Token_template_id
• Token_status:
• Token_lot_id:参考token_lots
• Token_creation_date(与连接起始时间不同)
• Token_issuer:系统里的用户。为所创建令牌负责的用户（不必与使用者一致）
• Token_owner:可以使用此令牌的用户（如果为空那就可以是任何人）

当建立连接时，token_templates表格中的数值连同网络策略或节点策略一同被使用，目的是用来计算连接表格里的max_data_transfer和expiration_date。这个计算比较贵，但是一旦完成，所有服务器所需要做的validate max_data_transfer和expiration_data几乎都是免费的。

连接（已存在表格中新的或重新定义的字段）

• Connection_status(被删除了，现在应在token_status中查找)
• Token_id 现在参考token table
• Max_total_bytes(token_max_data_transfer—SUM（为此令牌的所有连接传送数据）)
• Max_incoming_bytes 同上
• Max_outgoing_bytes 同上
• Expiration_date(MIN(NOW+token_max_connection_duration,NOW+token_max_total_duration-SUM(为此令牌的所有连接传送数据），token_expiration_date))
• Logout_reason 解释是什么导至连接关闭

如何运作，构思

告诉我我是否错了，但这就是我具体如何看待令牌结构的。
有了这个新的令牌结构，令牌本身在连接进程和管理上发挥的作用远比现在要大。
目前，认证服务器将用户作为是连接的中心点。用户是一个实体，拥有用户名和密码，这代表了一个物理上的人。在无用户模式下这个概念是无效的。例如一个splash_only网络只有一个用户，SPLASH_ONLY_USER并且每个用户之间并没有多少差别，也不能从滥用控制机制获益等等。此外，为此，当目前用户是splash-only用户时，代码需要添加特例脚本。
Token2.0中，令牌将会扮演现在用户的角色：代表物理人来连接到网络，然而用户将仅仅是一个认证方案。
以下是服务器端在登录进程中是如何运作的

1. 可选的 显示登录页面
2. 可选的 用户输入他的认证信息（用户/执照，访问代码，NIP,当日密码）
3. 基于成功认证
   　　为令牌目的获取认证信息（例如splash-only节点的user_id,代替SPLAHS_ONLY_USER id的应该是MAC地址）
   　　用此用户/MAC来删除连接
   　　目前用户已拥有可再用的有效的令牌吗？
   　　　　是的，使用此令牌
   　　　　没有，此用户可以获得新令牌吗？
   　　　　　　是的，创新一个新令牌并使用
   　　　　　　不能，此用户无法连接，告诉他原因和应该如何操作（滥用违规控制，需要购买新令牌等等）
   　　为此令牌创建新连接
   　　根据网络策略为此连接计算数据
   　　将令牌返回网关

需要以下所有支持：

• 欢迎页面个性化的简单方法（登录界面：用户/执照，访问代码，路径选择等等）
• 增加网络/节点管理界面来管理它允许的连接/令牌类型。也许我们想要splash-only节点，用户名/密码和/或访问代码节点的混合网络，对吗？
• 改变会话对象（并引用它），这样才能引用现在被称为令牌的对象。
• 编写大量的代码来支持所有一切!（执行是自然而然的事）

本文章由 http://www.wifidog.pro/2015/03/16/wifidog%E8%AE%A4%E8%AF%81%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%BB%A4%E7%89%8C%E7%BB%93%E6%9E%84.html 整理编辑，转载请注明出处