分类 wifidog认证 下的文章

wifidog 代码简单分析(2)

上一节提到httpdAddC404Content 及它的回调函数,还有相应的流程,只是讲解功能,并不是指注册了回调函数就可以执行回调函数了,而是要等客户端触发回调函数才执行。下面接着讲解其他部分。

fw_destroy(), 清掉和wifidog 有关的iptables 规则,这里不细说。

fw_init(), 添加wifidog 相关的iptables 链及规则,这里的规则主要是wifidog.conf 里设置的firewall rule set, global/validating-users/known-users/unknown-users/locked-users,这里unknown-users 默认的四条关于53/67 port 的allow 规则需要打开。除了.conf里的,还有认证服务器也会被加入白名单,以使得客户端能够正常和认证服务器交互。

接下来,wifidog 会创建几个线程,注意,wifidog 是多线程运行不是fork 子进程:
1,超时检查线程:函数thread_client_timeout_check;
2,ping协议线程:函数thread_ping;
3,和wdctl 交互的线程,wdctl 是控制wifidog 结束,重启的程序,这里不细说;
4,httpd处理线程,函数thread_httpd,这个线程是在一个while 死循环里接受http 连接然后处理连接的线程,可以读取http 请求的具体内容,主要调用了两个函数httpdReadRequest/httpdProcessRequest,读取和处理http 请求。

我们主要来讲解下超时检查和ping 协议线程.
1) 函数thread_client_timeout_check 调用了fw_sync_with_authserver,其他部分代码是线程锁,我们只需要关注fw_sync_with_authserver 函数。
fw_sync_with_authserver 函数功能:网关每隔config.checkinterval 时间检查,把所有客户端链表的信息发送给认证服务器进行流量更新,并且计算每一个客户端距离上次认证成功之后所经过的时间,如果距离上次认证成功经过的时间超过config.checkinterval * config.clienttimeout,即认为已经超时,网关会发送此客户端的logout 通知认证服务器,并将此客户端的iptables 白名单移除,客户端需要重新认证。
2) 函数thread_ping 调用ping 函数。
ping()函数功能:网关定时发送Ping 协议包通知认证服务器证明自己是活的,发包的时间间隔也是config.checkinterval, ping协议格式:http://auth_server/ping/?gw_id=xxx&sys_uptime=xxx&sys_memfree&sys_load=xxx&wifidog_uptime=xxx,这些都是网关的参数,和客户端没有的关系。

本文章由 http://www.wifidog.pro/2014/12/09/wifidog%E4%BB%A3%E7%A0%81%E5%88%86%E6%9E%90-1.html 整理编辑,转载请注明出处

wifidog 代码简单分析(1)

本文针对wifidog-20090925版本解释下wifidog的代码功能。
源码包括wifidog网关协议src 文件夹以及自带的libhttpd 库libhttpd 文件夹(libhttpd库用来创建wifidog 的http 服务,后面会提到这个库具体做什么),wifidog的配置文件wifidog.conf,这里主要分析src 文件夹里的源码。

按照看源码的习惯,在gateway.c main 里的开始,按流程分析。
config_get_config()函数,是一个获取全局变量config的函数,全局变量config 是关于网关全部配置的结构体,config 的成员变量都在wifidog.conf 文件里,这个变量时贯穿全部流程的一个全局变量,要看懂主要的变量的作用。如下所说config 都是指这个全局变量config。

config_init()函数,设置config 成员的默认初始值,有些设置成NULL,详细的看conf.c 的config_init函数,对照config 的结构体定义。

parse_commandline()函数,通过命令行获取config 结构体的某些成员值,如wifidog -c /etc/wifidog.conf, 通过-c 设置configfile 的值。

config_read(),读取configfile, 设置config 的成员值。这里要注意,config_read会覆盖parse_commandline 设置的config 成员值,parse_commandline会覆盖config_init设置的config 成员值。

config_validate(),检查config 的auth_server 和 gw_interface 值是否为空,因为这两个变量值最为重要。

client_list_init(), 这个函数涉及到另一个全局变量firstclient, 这个结构体主要保存客户端的信息,如ip, mac, token, incoming, outgoing等,客户端信息被存储到一个链表里,firstclient是链表头。

init_signals(),处理一些信号,如quit 信号,会清理一些iptables 规则,杀掉ping 协议线程和counter 协议线程,前者是网关不断发ping 包给认证服务器证明自己是活的,后者是网关向认证服务器更新客户端信息。

main_loop(),wifidog 流程开始。
首先检查config 的 gw_address 和 gw_id 有没有值,如果没有值,通过get_iface_ip 和get_iface_mac 来获取,这里gw_id 设置成网关gw_interface 的mac 地址,gw_address 是网关 gw_interface 的IP,一般gw_interface 是br0, 在wifidog.conf 里设置。

接着在网关 gw_interface 的IP 和 gw_port 上用libhttpd 库运行一个http server,并创建对于文件'wifidog'、''、'about'、'auth'、'status'的访问回调函数:http_callback_wifidog、http_callback_wifidog、http_callback_about、http_callback_auth以及http_callback_status,这里所谓的访问回调函数可以理解成当客户端访问auth 文件时会执行http_callback_auth函数,其他函数同理。

这里还有一个libhttpd的函数,httpdAddC404Content,这个函数是用来处理客户端第一次http 访问外网时执行回调函数,回调函数就是这个函数的第二个参数http_callback_404。

对于上面四个访问回调函数,我们下面会提到http_callback_auth,其余三个不重要,这里就不细说了。在此之前,我们先来看一下流程用到的第一个函数http_callback_404。

这里需要有个场景:我们连上了一个路由器(等同于这里的网关),这个路由器有wifigdog,并且绑定到了无线的interface 上,然后我们第一次上网,输入url: www.baidu.com。

在http_callback_404函数里,会把上述场景中的url 请求通过lihttpd 记录下来,然后判断认证服务器是否可达,接着就会把客户端的浏览器重定向到认证服务器: http://auth_server/login/?gw_id=xxx&gw_address=xxx&gw_port=xxx&url=www.baidu.com
接着网关就是等待认证服务器重定向客户端浏览器http://gatewayip:gatewayport/wifidog/auth?token=xxx, 这个token是认证服务器生成的,用来标识唯一客户端。浏览器重新访问网关,网关调用auth 的回调函数:http_callback_auth,这个函数就是拿着客户端浏览器发送的token 去认证服务器上核对token 的过程。

http_callback_auth(),该函数首先会检查http 报文里有没有token,然后通过arp_get 拿该报文发送者的ip 对应的MAC 地址,然后到之前提到的客户端链表里搜此ip 和mac 对应的客户端,如果搜不到,说明是新的客户端接入,那么就需要把它追加到链表里;如果这个客户端是logout请求(http报文请求里有logout),那么网关会发一个关于此客户端下线的通知到认证服务器;如果不是logout请求,那么不管是不是新的客户端,都需要再次认证一下,这时交由函数authenticate_client 处理。

authenticate_client(),因为我们之前已经把这个客户端追加到链表里了,所以首先去客户端链表里找,如果找得到这个客户端,那么就继续进行。网关将此客户端的mac、ip、token发送个login 请求到认证服务器[auth_server_request(&auth_response, REQUEST_TYPE_LOGIN, r->clientAddr, mac, token, 0, 0);],验证此token 和之前认证服务器给客户端的token 是否一致,如果一致会返回一个auth code=auth_allowed 给网关,通知网关对此客户端放通,网关收到后会将此客户端加入上网白名单(设置iptables 规则允许上网,客户端不再看到访问www.baidu.com 弹出非百度窗口),然后将客户端重定向到http://auth_server/portal/?gw_id=xxx, 到此网关协议工作完成,但我们的源码解析还没有完成,下面回到http 几个回调函数地方,接着讲解。

本文章由 http://www.wifidog.pro/2014/12/09/wifidog%E4%BB%A3%E7%A0%81%E5%88%86%E6%9E%90.html 整理编辑,转载请注明出处

【Wifidog协议V1】

Wifidog网关协议V1

  1. 网关心跳(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: auth.ilesansfil.org

  1. 认证服务器认证协议

这个页面描述了当用户已经被认证并允许访问互联网时,为了认证用户和进程,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: auth.ilesansfil.org

  1. 网关重定向浏览器,wifidog的http流程

客户端浏览器在不同情况下会被重定向到其它页面:
初始化请求:
基于捕捉,客户端会被网关重定向到以下URL:
login/?gw_address=%s&gw_port=%d&gw_id=%s&url=%s
例如:https://auth.ilesansfil.org/login/?gw_id=0016B6DA9AE0&gw_address=7.0.0.1&gw_port=2060&url=www.baidu.com
初始化请求之后认证服务器重定向浏览器
客户端将被重定向到网关。 http://"gw_address:gw_port/wifidog/auth?token=xxx
URL示例:http://7.0.0.1:2060/wifidog/auth?token=4f473ae3ddc5c1c2165f7a0973c57a98
网关带着auth去认证服务器上认证token值是否正确
http://auth.ilesansfil.org/auth/?stage=login&ip=xxx&mac=xxx&token=4f473ae3ddc5c1c2165f7a0973c57a98&incoming=0&outgoing=0&gw_id=xxx
如果服务器回复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
路由器收到AUTH_ALLOWED重定向浏览器到http://auth.ilesansfil.org/portal/?gw_id=xxx, auth server确定成功返回成功页面,认证完成。

本文章由 http://www.wifidog.pro/2014/12/09/wifidog%E5%8D%8F%E8%AE%AE%E6%8E%A5%E5%8F%A3.html 整理编辑,转载请注明出处

wifidog 源码初分析(三)

上一篇分析了 接入设备 在接入路由器,并发起首次 HTTP/80 请求到路由器上时,wifidog 是如何将此 HTTP 请求重定向至 auth-server 的流程。

之后接入设备的浏览器接收到 wifidog 返回的 302 重定向请求后,会将页面重定向至 auth-server 的 /login 页面,并且在此 URL 中会携带一些路由器/网关 参数,以及接入设备的 MAC 地址和客户端访问的源URL(如示例中的 baidu.com)。

POST /login/?gw_address=192.168.1.1&gw_port=2060&gw_id=default&mac=44:94:fc:ef:28:40&url=http%3A//www.baidu.com/ HTTP/1.1

auth-server 收到请求后处理,并返回重定向到 wifidog 的响应(注:同时携带了为此接入设备的用户分配了 token),接入设备的浏览器重定向至路由器上 wifidog 的 http 服务(端口 2060) /wifidog/auth 上(且携带了认证服务器为此接入设备分配的 token),下面介绍下 wifidog 接收到 /wifidog/auth 的访问后的校验流程。
在 wifidog 启动 http 服务前,注册了一个针对访问路径 /wifidog/auth 的回调,如下:

httpdAddCContent(webserver, "/wifidog", "about", 0, NULL, http_callback_about);  
httpdAddCContent(webserver, "/wifidog", "status", 0, NULL, http_callback_status);  
// 注册了针对 /wifidog/auth 的访问回调 http_callback_auth
httpdAddCContent(webserver, "/wifidog", "auth", 0, NULL, http_callback_auth); 

这样对于 接入设备(or 客户端) 重定向过来的 /wifidog/auth 就进入了 http_callback_auth 函数中,如下:

http_callback_auth(httpd *webserver, request *r)  
{  
    t_client    *client;  
    httpVar * token;  
    char    *mac;  
    // 1, 获取条件参数中的 logout 值
    httpVar *logout = httpdGetVariableByName(r, "logout");  
    // 2, 获取条件参数中的 token 值
    if ((token = httpdGetVariableByName(r, "token"))) {  
        /* They supplied variable "token" */
        // 3, 可以看到, 这里要求必须能够通过 ARP 协议获取到 接入设备 的 MAC 地址
        if (!(mac = arp_get(r->clientAddr))) {  
        /* We could not get their MAC address */
            debug(LOG_ERR, "Failed to retrieve MAC address for ip %s", r->clientAddr);  
            send_http_page(r, "WiFiDog Error", "Failed to retrieve your MAC address");  
        } else {  
            /* We have their MAC address */
            LOCK_CLIENT_LIST();  
            // 4, 检查该客户端(接入设备)是否已经在 wifidog 维护的接入客户端列表中
            if ((client = client_list_find(r->clientAddr, mac)) == NULL) {  
                debug(LOG_DEBUG, "New client for %s", r->clientAddr);  
                client_list_append(r->clientAddr, mac, token->value);  
            } else if (logout) {  
                // 5, 退出处理
                t_authresponse  authresponse;  
                s_config *config = config_get_config();  
                unsigned long long incoming = client->counters.incoming;  
                unsigned long long outgoing = client->counters.outgoing;  
                char *ip = safe_strdup(client->ip);  
                char *urlFragment = NULL;  
                t_auth_serv *auth_server = get_auth_server();  
                fw_deny(client->ip, client->mac, client->fw_connection_state);  
                client_list_delete(client);  
                debug(LOG_DEBUG, "Got logout from %s", client->ip);  
                /* Advertise the logout if we have an auth server */
                if (config->auth_servers != NULL) {  
                    UNLOCK_CLIENT_LIST();  
                    auth_server_request(&authresponse, REQUEST_TYPE_LOGOUT, ip, mac, token->value,  
                                        incoming, outgoing);  
                    LOCK_CLIENT_LIST();  
                    /* Re-direct them to auth server */
                    debug(LOG_INFO, "Got manual logout from client ip %s, mac %s, token %s"
                    "- redirecting them to logout message", client->ip, client->mac, client->token);  
                    safe_asprintf(&urlFragment, "%smessage=%s",  
                        auth_server->authserv_msg_script_path_fragment,  
                        GATEWAY_MESSAGE_ACCOUNT_LOGGED_OUT  
                    );  
                    http_send_redirect_to_auth(r, urlFragment, "Redirect to logout message");  
                    free(urlFragment);  
                }  
                free(ip);  
            }  
            else {  
                // 6, 已经登录校验通过
                debug(LOG_DEBUG, "Client for %s is already in the client list", client->ip);  
            }  
            UNLOCK_CLIENT_LIST();  
            if (!logout) {  
                // 7, 到 auth server 上进一步校验 token
                authenticate_client(r);  
            }  
            free(mac);  
        }  
    } else {  
        /* They did not supply variable "token" */
        // 8, 未携带 token, 直接拒绝
        send_http_page(r, "WiFiDog error", "Invalid token");  
    }  
} 

在该函数中主要处理了 客户端退出,非法校验,以及 客户端校验等流程,下面分别描述注释中的各个步骤:
1,对于客户端退出,则会携带 logout 参数信息,并走到第 5 步(当然,如果连 token 参数都没有的话,会直接走到第 8 步,也就是拒绝);
2,按照正常的认证流程,会携带由认证服务器分配的 token 参数;
3,正如注释说明的,这里要求必须能够通过 ARP 协议获取到 接入设备 的 MAC 地址;(其实通过查看 arg_get 的实现,可以看到是直接解析 /proc/net/arp 文件 -- ARP cache -- 来获取对应客户端 IP 地址的 MAC 信息的),类似如下:
[asd@ubuntu ~]#more /proc/net/arp
IP address HW type Flags HW address Mask Device
192.168.1.203 0x1 0x2 18:03:73:d5:1b:a2 * eth0
192.168.1.1 0x1 0x2 00:21:27:63:c0:ce * eth0
4,在能够获取到该客户端的 MAC 地址后,根据客户端的 IP 和 MAC 地址检查该客户端是否已经在 wifidog 维护的接入设备(or客户端)列表中,如果不在,则追加到此列表中(关于此列表的数据结构在后面再详细描述);
5,如果该客户端已经存在,且本次访问是要求 logout 退出的,则进入此退出处理的流程,该流程主要包括几个步骤:关闭该客户端 ip/mac 的出口(outgoing)规则 --> 从客户端列表中删除该客户端记录 --> 通知认证服务器该客户端退出(且携带该客户端的token, 上下行流量等信息) --> 返回重定向至 认证服务器 的 #define DEFAULT_AUTHSERVMSGPATHFRAGMENT "gw_message.php?" 访问路径(携带一个已退出的 message);
6,如果该客户端已经登录校验过,且本次访问非 logout 退出,则直接跳转到第 7 步;
7,这一步就是 token 校验的过程,具体实现在 authenticate_client 函数中:

/** Authenticates a single client against the central server and returns when done
* Alters the firewall rules depending on what the auth server says
@param r httpd request struct
*/
void
authenticate_client(request *r)
{
    t_client    *client;
    t_authresponse  auth_response;
    char    *mac,
            *token;
    char *urlFragment = NULL;
    s_config    *config = NULL;
    t_auth_serv *auth_server = NULL;

    LOCK_CLIENT_LIST();

    client = client_list_find_by_ip(r->clientAddr);

    if (client == NULL) {
            debug(LOG_ERR, "Could not find client for %s", r->clientAddr);
            UNLOCK_CLIENT_LIST();
            return;
    }

    mac = safe_strdup(client->mac);
    token = safe_strdup(client->token);

    UNLOCK_CLIENT_LIST();

    /* 
     * At this point we've released the lock while we do an HTTP request since it could
     * take multiple seconds to do and the gateway would effectively be frozen if we
     * kept the lock.
     */
    auth_server_request(&auth_response, REQUEST_TYPE_LOGIN, r->clientAddr, mac, token, 0, 0);

    LOCK_CLIENT_LIST();

    /* can't trust the client to still exist after n seconds have passed */
    client = client_list_find(r->clientAddr, mac);

    if (client == NULL) {
            debug(LOG_ERR, "Could not find client node for %s (%s)", r->clientAddr, mac);
            UNLOCK_CLIENT_LIST();
            free(token);
            free(mac);
            return;
    }

    free(token);
    free(mac);

    /* Prepare some variables we'll need below */
    config = config_get_config();
    auth_server = get_auth_server();

    switch(auth_response.authcode) {

    case AUTH_ERROR:
            /* Error talking to central server */
            debug(LOG_ERR, "Got %d from central server authenticating token %s from %s at %s", auth_response, client->token, client->ip, client->mac);
            send_http_page(r, "Error!", "Error: We did not get a valid answer from the central server");
            break;

    case AUTH_DENIED:
            /* Central server said invalid token */
            debug(LOG_INFO, "Got DENIED from central server authenticating token %s from %s at %s - redirecting them to denied message", client->token, client->ip, client->mac);
            safe_asprintf(&urlFragment, "%smessage=%s",
                    auth_server->authserv_msg_script_path_fragment,
                    GATEWAY_MESSAGE_DENIED
    );
            http_send_redirect_to_auth(r, urlFragment, "Redirect to denied message");
            free(urlFragment);
            break;

    case AUTH_VALIDATION:
            /* They just got validated for X minutes to check their email */
            debug(LOG_INFO, "Got VALIDATION from central server authenticating token %s from %s at %s"
                        "- adding to firewall and redirecting them to activate message", client->token,
                            client->ip, client->mac);
            client->fw_connection_state = FW_MARK_PROBATION;
            fw_allow(client->ip, client->mac, FW_MARK_PROBATION);
            safe_asprintf(&urlFragment, "%smessage=%s",
                    auth_server->authserv_msg_script_path_fragment,
                    GATEWAY_MESSAGE_ACTIVATE_ACCOUNT
            );
            http_send_redirect_to_auth(r, urlFragment, "Redirect to activate message");
            free(urlFragment);
            break;

    case AUTH_ALLOWED:
            /* Logged in successfully as a regular account */
            debug(LOG_INFO, "Got ALLOWED from central server authenticating token %s from %s at %s - "
                        "adding to firewall and redirecting them to portal", client->token, client->ip, client->mac);
            client->fw_connection_state = FW_MARK_KNOWN;
            fw_allow(client->ip, client->mac, FW_MARK_KNOWN);
            served_this_session++;
            safe_asprintf(&urlFragment, "%sgw_id=%s",
                    auth_server->authserv_portal_script_path_fragment,
                    config->gw_id
            );
            http_send_redirect_to_auth(r, urlFragment, "Redirect to portal");
            free(urlFragment);
            break;

    case AUTH_VALIDATION_FAILED:
            /* Client had X minutes to validate account by email and didn't = too late */
            debug(LOG_INFO, "Got VALIDATION_FAILED from central server authenticating token %s from %s at %s "
                    "- redirecting them to failed_validation message", client->token, client->ip, client->mac);
            safe_asprintf(&urlFragment, "%smessage=%s",
                    auth_server->authserv_msg_script_path_fragment,
                    GATEWAY_MESSAGE_ACCOUNT_VALIDATION_FAILED
            );
            http_send_redirect_to_auth(r, urlFragment, "Redirect to failed validation message");
            free(urlFragment);
            break;

    default:
            debug(LOG_WARNING, "I don't know what the validation code %d means for token %s from %s at %s - sending error message", auth_response.authcode, client->token, client->ip, client->mac);
            send_http_page(r, "Internal Error", "We can not validate your request at this time");
            break;
    }

    UNLOCK_CLIENT_LIST();
    return;
}

这里主要是两大步骤:
1,通过调用 auth_server_request(&auth_response, REQUEST_TYPE_LOGIN, r->clientAddr, mac, token, 0, 0); 让 认证服务器 对该客户端的 token 进行校验;

2,根据认证服务器返回的 token 校验结果进行不同的处理(主要是对该客户端的防火墙过滤规则进行不同的设置),这里主要以 AUTH_ALLOWED 校验结果进行分析,这里主要是两个动作:

2.1,通过 fw_allow 函数调用对此客户端"放行";

2.2,返回重定向至认证服务器的 portal 路径访问的响应;

这里就简要分析一下 fw_allow 函数的实现,查看fw_allow的实现可以看到真正设置allow客户端通过防火墙的动作是在iptables_fw_access中实现的,如下:

/* Set if a specific client has access through the firewall */
int iptables_fw_access(fw_access_t type, const char *ip, const char *mac, int tag)
{
  int rc;

  fw_quiet = 0;

  switch(type) {
     case FW_ACCESS_ALLOW:
        iptables_do_command("-t mangle -A " TABLE_WIFIDOG_OUTGOING " -s %s -m mac --mac-source %s -j MARK --set-mark %d", ip, mac, tag);
        rc = iptables_do_command("-t mangle -A " TABLE_WIFIDOG_INCOMING " -d %s -j ACCEPT", ip);
        break;
     case FW_ACCESS_DENY:
        iptables_do_command("-t mangle -D " TABLE_WIFIDOG_OUTGOING " -s %s -m mac --mac-source %s -j MARK --set-mark %d", ip, mac, tag);
        rc = iptables_do_command("-t mangle -D " TABLE_WIFIDOG_INCOMING " -d %s -j ACCEPT", ip);
        break;
     default:
        rc = -1;
        break;
     }

     return rc;
}

同样的,我们这里主要分析一下ALLOW时的iptables的防火墙设置规则,对执行的两个iptables命令展开来就是下面两个步骤:

1) 在mangle表中追加WiFiDog_$ID$_Outgoing外出过滤链,该链的规则如下几条:

a) IP 地址为该客户端的IP地址;

b) MAC地址为该客户端的MAC地址;

c) 设置MARK为FW_MARK_KNOWN;

iptables –t mangle –AWiFiDog_$ID$_Outgoing -s 客户端IP地址 -m mac --mac-source 客户端MAC地址 -j MARK --set-markFW_MARK_KNOWN

2)在mangle表中追加一条[接受所有目的地址为此客户端IP地址的] WifiDog_$ID$_Incoming输入过滤链;

iptables -t mangle -AWiFiDog_$ID$_Incoming -d 客户端IP地址 -j ACCEPT

最后,Auth server重定向客户端浏览器到www.baidu.com

本文章由 http://www.wifidog.pro/2014/12/08/wifidog-%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90.html 整理编辑,转载请注明出处