☰

在 FreeRadius 中配置 dhcp 模块（3.0.2 - Centos 6.5）

tag-icon • tag-icon freeradius
在 FreeRadius 中配置 dhcp 模块（3.0.2 - Centos 6.5）

我正在使用 REST 模块授权 DHCP 请求。如果授权失败，我想发送显式 DHCP NAK，但是如果失败，DHCP 模块似乎会立即返回，并忽略 DHCP 请求而不做出任何响应。

这是我的 DHCP 模块配置 - 如果 rest.authorize 成功，则 if (ok) 控制块被命中，但如果 rest.authorize 失败，则 if (fail) 永远不会被命中。

  dhcp DHCP-Discover {
    rest.authorize

    if (fail) {
            update reply {
                    DHCP-Message-Type = DHCP-Nak
            }
    }

    if (ok) {
        update reply {
           DHCP-Message-Type = DHCP-Offer
        }

        update reply {
            DHCP-Domain-Name-Server = x.x.x.x
            DHCP-Domain-Name-Server = x.x.x.x
            DHCP-Subnet-Mask = 255.255.255.0
            DHCP-Router-Address = x.x.x.x
            DHCP-IP-Address-Lease-Time = 3600
            DHCP-DHCP-Server-Identifier = x.x.x.x
        }
        mac2ip
    }
 }

以下是收到 401 Unauthorized 后的输出。我想要在指定的（短）时间内对 DHCP 进行临时阻止。但是 FreeRADIUS 的行为是忽略对相同 DHCP 事务的重复请求，这意味着客户端上的 DHCP 被阻止，直到它开始新的事务。如果可以发送 DHCP NAK，DHCP 客户端将在每个 NAK（即 DHCP Discover）之后启动新的事务，这意味着 FreeRADIUS 将处理来自客户端的每个 DHCP Discover，并且阻止将在更接近所需阻止时间时被移除。

Tue Jun  3 03:00:57 2014 : Debug: (3) rest : Sending HTTP GET to 

"http://xxxxxx//api/v1/dhcp/80%3Aea%3A96%3A2a%3Ab6%3Aaa"
Tue Jun  3 03:00:57 2014 : Debug: (3) rest : Processing response header
Tue Jun  3 03:00:57 2014 : Debug: (3) rest :    Status : 401 (Unauthorized)
Tue Jun  3 03:00:57 2014 : Debug: (3) rest : Skipping attribute processing, no body data received
Tue Jun  3 03:00:57 2014 : Debug: rlm_rest (rest): Released connection (4)
Tue Jun  3 03:00:57 2014 : Debug: (3)   modsingle[authorize]: returned from rest (rlm_rest) for request 3
Tue Jun  3 03:00:57 2014 : Debug: (3)   [rest.authorize] = fail
Tue Jun  3 03:00:57 2014 : Debug: (3)  } # dhcp DHCP-Discover = fail
Tue Jun  3 03:00:57 2014 : Debug: (3) Finished request 3.
Tue Jun  3 03:00:57 2014 : Debug: Waking up in 0.2 seconds.
Tue Jun  3 03:00:58 2014 : Debug: Waking up in 4.6 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:00:59 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:00:59 2014 : Debug: Waking up in 2.9 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:02 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:02 2014 : Debug: Waking up in 0.4 seconds.
Tue Jun  3 03:01:02 2014 : Debug: (2) Cleaning up request packet ID 2064626397 with timestamp +56
Tue Jun  3 03:01:02 2014 : Debug: Waking up in 1999991.0 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:06 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:06 2014 : Debug: Waking up in 3999983.1 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:15 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:15 2014 : Debug: Waking up in 7999966.3 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:23 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:23 2014 : Debug: Waking up in 15999942.1 seconds.

对于下面的选项 #4 解决方案，尽管这在 DHCP NAK 方面有效，但 DHCP 模块会“记住”DHCP 事务的 REST 授权结果。只有当设备尝试进行新事务时，DHCP 模块才会再次进行 REST 授权调用：

Received DHCP-Discover of id 7b0fb322 from 172.19.0.9:67 to 172.19.0.12:67
Sending DHCP-NAK of id 7b0fb322 from 172.19.0.12:67 to 172.19.0.9:67
Wed Jun  4 00:31:32 2014 : Debug: Waking up in 3.5 seconds.
Received DHCP-Discover of id 7b0fb322 from 172.19.0.9:67 to 172.19.0.12:67
Sending DHCP-NAK of id 7b0fb322 from 172.19.0.12:67 to 172.19.0.9:67
Wed Jun  4 00:31:35 2014 : Debug: Waking up in 0.6 seconds.
Wed Jun  4 00:31:36 2014 : Debug: (4) Cleaning up request packet ID 2064626465 with timestamp +138
Wed Jun  4 00:31:36 2014 : Debug: Waking up in 1999991.0 seconds.
Received DHCP-Discover of id 7b0fb322 from 172.19.0.9:67 to 172.19.0.12:67
Sending DHCP-NAK of id 7b0fb322 from 172.19.0.12:67 to 172.19.0.9:67
Wed Jun  4 00:31:40 2014 : Debug: Waking up in 3999982.8 seconds.

答案1

rest.authorize {
    fail = 1
}
if (reject || fail) {
    update reply {
        DHCP-Message-Type = DHCP-NAK
    }
}

好的。所以你有四个选择：

  • 返回带有 JSON 内容类型和一组空括号 {} 的 401（可能有效）
  • 使用 v3.0.x HEAD 提交，我刚刚修改了行为以允许空主体。奇怪的是它实际上是在为空主体调用主体数据回调。我没想到这一点，这就是它出错的原因。这将出现在发布的版本 3.0.4 中。
  • 将下面的返回语句编辑RDEBUG2("Skipping....")为。src/modules/rlm_rest/rest.creturn 0
  • 编辑您的休息调用以匹配我上面添加的代码片段（因为将它放在这个项目符号列表之后会影响格式）。

相关内容