分类 wifidog分析 下的文章

Wifidog分析wifidog认证网关协议v1

网关心跳(Ping协议)
Wifidog将ping协议做为心跳机制向认证服务器发送当前状态信息。这可以实现为认证服务器每个节点的状态生成中央日志。
Wifidog客户端在conf文件中进行设置,目的是通过http定期启动thread(ping_thread.c)向认证服务器发送状态信息。信息格式如下:

http://auth_sever/ping/?    
gw_id=%s
sys_uptime=%lu    
sys_memfree=%u    
sys_load=%.2f    
wifidog_uptime=%lu

通过系统调用wifidog客户端收集的数据

Headers
HTTP/1.0\r\n" 
"User-Agent: WiFiDog %s\r\n" 
"Host: %s\r\n" 
"\r\n",

一个标准的HTTP需求应该是:

GET /ping/?gw_id=001217DA42D2&sys_uptime=742725&sys_memfree=2604&sys_load=0.03&wifidog_uptime=3861 HTTP/1.0
User-Agent: WiFiDog 1.1.3_beta6
Host: wifidog.pro

认证服务器认证协议
这个页面描述了当用户已经被认证并允许访问互联网时,为了认证用户和进程,wifidog网关和认证服务器之间的信息传送。
Wifidog客户端将定期的启动一个thread来报告每个用户的连接状况。目前它被用来报告每个用户输入/输出计数器,以显示用户依然在现,并允许认证服务器将不再连接的用户断开。
以下是发给每个在线用户的信息

auth_server:/auth/index.php?
stage=
ip=
mac=
token=
incoming=
outgoing=

注意:stage=计数器/登录,取决于是否是新客户端
即使输入输出变量会在所有信息中出现,但他们只对处于counter阶段的信息有效。其它情况下输入输出经常设置为0。
在做回复时,认证服务器会以有效身份或新用户信息,或者认证服务器错误提示形式进行回复。
回复格式如下:
Auth:

新用户状态为:

0 - AUTH_DENIED - User firewall users are deleted and the user removed.
6 - AUTH_VALIDATION_FAILED - User email validation timeout has occured and user/firewall is deleted
1 - AUTH_ALLOWED - User was valid, add firewall rules if not present
5 - AUTH_VALIDATION - Permit user access to email to get validation email under default rules
-1 - AUTH_ERROR - An error occurred during the validation process

注意:认识服务器错误一般不会改变防火墙或用户状态

标准的URL为:

GET /auth/?stage=counters&ip=7.0.0.107&mac=00:40:05:5F:44:43&token=4f473ae3ddc5c1c2165f7a0973c57a98&incoming=6031353&outgoing=827770 HTTP/1.0
User-Agent: WiFiDog 1.1.3_beta6
Host: wifidog.pro

网关重定向浏览器
客户端浏览器在不同情况下会被重定向到其它页面:
初始化请求:
基于捕捉,客户端会被网关重定向到以下URL:

login/?gw_address=%s&gw_port=%d&gw_id=%s&url=%s 
例如:https://wifidog.pro/login/?gw_id=0016B6DA9AE0&gw_address=7.0.0.1&gw_port=2060

初始化请求之后
当请求被处理并且客户端已经被重定向到网关时
如果服务器回复AUTH_DENIED:注意你通常在标准认证服务器上看不到这样的提示。客户端将不会被重定向回网关。

gw_message.php?message=denied 

如果服务器回复AUTH_VALIDATION:

gw_message.php?message=activate 

如果服务器回复AUTH_ALLOWED:这是门户重定向:

portal/?gw_id=%s 

如果服务器回复AUTH_VALIDATION_FAILED:注意你将不会在标准认证服务器看到此回复。客户端将不会重定向回网关。

gw_message.php?message=failed_validation

认证服务器重定向浏览器
基于成功登录,客户端将被重定向到网关。 http://" . $gw_address . ":" . $gw_port . "/wifidog/auth?token=" . $token

URL示例:http://192.168.1.1:2060/wifidog/auth?token=4f473ae3ddc5c1c2165f7a0973c57a98

本文章由 http://www.wifidog.pro/2015/04/01/Wifidog%E5%88%86%E6%9E%90wifidog%E8%AE%A4%E8%AF%81.html 整理编辑,转载请注明出处

Wifidog流程wifidog网关协议 V2结构

线程

主程序

  • 启用“status”或者“autheserv”线程
  • 等待状态线程在初始化网络和拒绝客户端之前,成功的下载配置
  • 一旦被初始化,等待连接到它的节点
  • 用以前的方法处理流量(访问登录页面…获取标识,用认证服务器测试标识,提供防火墙规则)

状态线程

  • 连接认证服务器并且每五分钟(默认)发送一次状态
  • Wiifdog uptime
  • System uptime
  • System free memory
  • System load average
  • System network interface list(ifconfig –a).(需要选择wifidog将要使用的接口)

http客户端线程
  当一个新的连接被初始化时,启用此线程。如果有80个人连接到认证服务器,同时就会有80个线程被启用。最好是有个threads pool,但99%的情况都没用,并且会花费很多时间在代码和调试上。

命令行的选项

用所需的数值设置:--auth Authserver’s hostname –lan LAN interface

当wifidog初始化他的config,它应该看到一些选项,如“这是连接登录页面的URL”…

  • 全球化宽带设置
  • 登录页面URL
  • 门户页面URL
  • 计时器

协议的JOSN
如何创建JOSN:

struct json_object *status_object = json_object_new_object();

json_object_object_add(status_object, "wifidog_version", json_object_new_string(VERSION));

json_object_object_add(status_object, "protocol_version", json_object_new_double(2.0));

json_object_object_add(status_object, "node_id", json_object_new_string(node_id));

json_object_object_add(status_object, "fetch_config", json_object_new_boolean(1));
       
struct json_object *node_status_object = json_object_new_object();

json_object_object_add(node_status_object, "wifidog_uptime", json_object_new_int(25));

json_object_object_add(node_status_object, "sys_uptime", json_object_new_int(get_sys_uptime()));

json_object_object_add(node_status_object, "sys_loadavg", json_object_new_double(get_sys_loadavg()));

json_object_object_add(node_status_object, "sys_memfree", json_object_new_int(get_sys_memfree()));

char * json = json_object_to_json_string(status_object);

回复了JOSN字符串

解析:

struct json_object * json_object = json_tokener_parse(the_string);

struct json_object * value_json_object = json_object_object_get(json_object, "node_id");

printf("%s\n", json_object_get_string(value_json_object));

这将在树结构的第一级检索“node_id”。

测试所需防火墙规则的运行(Linux)
这些命令行需要测试试我们所需的所有模块:

iptables -A INPUT -m mac --mac-source 00:00:00:00:00:00 -j ACCEPT

iptables -D INPUT -m mac --mac-source 00:00:00:00:00:00 -j ACCEPT

iptables -t nat -A PREROUTING -p tcp --dport 9999 -j REDIRECT --to-ports 2060

iptables -t nat -D PREROUTING -p tcp --dport 9999 -j REDIRECT --to-ports 2060

如果运行,我们可以继续操作。我确信还有许多尝试,但这只是个开始。

防火墙规则(Linux)
我们曾使用MARKs来标记流量是已知,未知或是在验证。
现在流量就简单的是已知或未知,指定拒绝规则应该被发送为“拒绝acl规则”。
我们应该尝试停止使用MARKs,因为我们只有255个。
这是我的经验,不全面但还是发布一下:

iptables -t filter -N wd_lan2wan

iptables -t filter -N wd_lan2wan_fromauth 

iptables -t filter -N wd_lan2wan_clients

iptables -t filter -N wd_lan2wan_defaults

iptables -t filter -N wd_incoming_stats

iptables -t filter -I FORWARD 1 -i LAN_INTERFACE -o WAN_INTERFACE -j wd_lan2wan

iptables -t filter -I FORWARD 1 -j wd_incoming_stats

iptables -t filter -A wd_lan2wan -j wd_lan2wan_clients

iptables -t filter -A wd_lan2wan -j wd_lan2wan_defaults

iptables -t nat -N wd_redirect

iptables -t nat -I PREROUTING 1 -j wd_redirect

iptables -t filter -A wd_lan2wan -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

iptables -t filter -A wd_lan2wan_defaults -p tcp --dport 53 -j ACCEPT

iptables -t filter -A wd_lan2wan_defaults -p udp --dport 53 -j ACCEPT

iptables -t filter -A wd_lan2wan_defaults -d AUTHSERV_HOSTNAME -j ACCEPT

iptables -t filter -A wd_lan2wan_defaults -j REJECT

iptables -t filter -A wd_incoming_stats -d 192.168.1.10 -j RETURN

iptables -t filter -A wd_lan2wan_clients -s 192.168.1.10 --match mac --mac-source 01:02:03:04:05:06 -j ACCEPT

iptables -t nat -I wd_redirect 1 -s 192.168.1.10 --match mac --mac-source 01:02:03:04:05 -j ACCEPT

我只添加一个规则来允许客户端,但我们需要计算出这些数据。如果我们能够有两个规则,这样会比较规整,但如果想避免使用REDIRECT规则的话,我们将要在相同的热点来MARK流量。我们能够做到,但需要像以前一样能够获得“magic number”MARK才行。

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

Wifidog流程网关协议v2

线路协议
回复形式

在线路协议中有以下说明:

  • 紧凑表示(当浏览分散式网络时,宽带也不便宜)
  • 用户可读
  • 能够为C语言和PHP提供快速的解析器,并且比较理想的是能够多语言化
  • 适用于与配置文件分享解析器和格式
  • 适用于清晰的显示树结构(例如认证服务器列表)

请求格式

必须遵循请求格式:

  • 每个http请求都有多个操作(例如为多个用户更新统计数据)
  • 保持http传送,因为这能允许完整的NAT和透明代理阻力

以上的一些需求没有适用于RESTFull ROA。然而,保持现有格式事实上把我们限制在了tag-value对列表。理论上即使可以将action=whatever放在列表中间并在协议中申明以下每个参数都是那个action的参数,这将使大多数网络服务器与框架完全混淆。

  Acv:另一个可能性是从PHP进行URL-parsing的方式借用一个页面。将get请求设置到一个数组表示,这将允许公平的逻辑请求捆绑。也就是:

 /page?req[0][action]=Action1&req[0][Param1]=param&req[0][Param...]=param...&req[0][Paramn]=paramn&\


req[...][action]=Action...&req[...][Param1]=param&req[...][Param...]=param...&req[...][Paramn]=paramn&\


req[n][action]=Actionn&req[n][Param1]=param&req[n][Param...]=param...&req[n][Paramn]=paramn

  Acv:当比较容易进行解析的时候,这个格式会保持用户可读

功能性需求

  • 允许认证服务器发送一些主要的配置变更
  • 允许基于MAC认证的非连接关系
  • 允许per-connection防火墙政策
  • 允许per-connection宽带管理,不只限于设置数量
  • 允许全球宽带管理
  • 指定围墙花园
  • 指定最初连接用户列表

指令
NOOP
基本上只为网关心跳。可能会指定操作间很短的延迟,并且如果在实际操作之间延迟的话,就会发送NOOP。
AUTH_VERIFY
STATS_UPDATE

提议方案
  Philippe:

 I think we could have a Hash kind of structure like this:

 * protocol_version: 1 (start with this to identify protocol)

 * wifidog_version: ...

 * status:

   * uptime, etc.

 * connected_clients:

   * stats, etc.

  简单回复:

 {

    "protocol_version": 1,

    "config": {

        "login_url": "https://auth.server/login.php",

        "portal_url": "http://portal.server/",

        ... },

    "clients": [

        { "mac": "00aabbccdd22", "ip": "10.0.0.1", ... },

        { "mac": "00aabbccdd22", "ip": "10.0.0.1", ... },

        ... ]

}

网关和认证服务器通信
2.png

配置

  • 醒目页面,如果auth-server=down(URL)
  • 醒目页面,如果internet=down(内容)
  • 围墙花园(考虑一下DNS超时)
  • 静态MAC黑/白名单
  • 全球防火墙/QOS配置

本文章由 http://www.wifidog.pro/2015/03/31/wifidog%E6%B5%81%E7%A8%8Bwifidog%E5%8D%8F%E8%AE%AE.html 整理编辑,转载请注明出处

Wifidog认证稳定性测试方法及说明

下面是我所使用的测试方法,有其他更好测试方法的网友也可以共享出来。

测试方法:
通过软件发送多个连接请求来达到测试wifidog处理请求的能力,也就是其稳定性。
通过http_load软件发送网站连接请求,查看后台监控wifidog异常,逐渐增加 发送连接请求次数直到wifidog死掉或者重启。

测试环境:
将刷好的带wifidog认证的路由接入Internet和测试机(电脑或者手机)。使用电脑连接到路由后台,以调试模式运行wifidog,以便随时监控wifidog。

测试条件:
wifidog启动中并且测试机没有进行过认证。

预期结果:
wifidog死掉或者重启。

测试步骤:
测试工具链接:http://pan.baidu.com/s/1i36B8ED
将路由器接入外网,确认wifidog启动之后,在不认证的条件下,将http_load.zip压缩包解压到C盘根目录下。打开http_load文件夹,双击运行“wifidog稳定性测试.bat”批处理程序。等待程序运行完毕,打开文件夹下的result.txt即可查看到结果。
1.jpg

(右侧为修改后wifidog版本测试结果)
结果分析:

   30 fetches, 15 max parallel, 50527 bytes, in 0.140625 seconds
   1684.23 mean bytes/connection
   213.333 fetches/sec, 359303 bytes/sec
   msecs/connect: 1.04167 mean, 31.25 max, 0 min
   msecs/first-response: 46.3542 mean, 78.125 max, 15.625 min
   HTTP response codes:
   code 302 – 30


   1.30 fetches, 15 max parallel, 50527 bytes, in 0.140625 seconds
        说明在上面的测试中运行了30个请求,最大的并发进程数是15,总计传输的数据是50527bytes,运行的时间是0.140625秒
   2.1684.23 mean bytes/connection
        说明每一连接平均传输的数据量50527/30=1684.23
   3.213.333 fetches/sec, 359303 bytes/sec
        说明每秒的响应请求为213.333,每秒传递的数据为359303 bytes/sec
   4.msecs/connect: 1.04167 mean
        说明每连接的平均响应时间是1.04167 msecs,31.25 max, 0 min,最大的响应时间31.25msecs,最小的响应时间0 msecs;
   5.msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
   6、HTTP response codes: code 200 — 49 
        说明打开响应页面的类型,如果403的类型过多,那可能要注意是否系统遇到了瓶颈。

   特殊说明:
          测试结果中主要的指标是 fetches/sec、msecs/connect 这个选项,即服务器每秒能够响应的查询次数,用这个指标来衡量性能。

命令参数如下:
-parallel 简写-p :含义是并发的用户进程数。
-fetches 简写-f :含义是总计的访问次数。
-rate 简写-p :含义是每秒的访问频率。
-seconds简写-s :含义是总计的访问时间。

本文章由 http://www.wifidog.pro/2015/03/31/wifidog%E7%A8%B3%E5%AE%9A%E6%80%A7%E6%B5%8B%E8%AF%95.html 整理编辑,转载请注明出处