从非 DHCP 客户端发送 DHCPINFORM 消息

发布于 2024-08-07 11:43:26 字数 77 浏览 3 评论 0原文

假设我在有 DHCP 服务器的子网中有静态 IP。如果我要发送 DHCPINFORM 消息发送到服务器,会发生什么?

阿米特

Suppose I have static ip in a subnet that has DHCP server. If i gonna send DHCPINFORM
message to the server, what will happen ?

amit

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

巴黎夜雨 2024-08-14 11:43:26

根据 DHCPINFORM 消息的 RFC-2131 tropic 4.3.5:

“DHCP 服务器通过直接向 DHCPINFORM 消息的‘ciaddr’字段中给出的地址发送 DHCPACK 消息来响应 DHCPINFORM 消息。服务器不得发送租约客户端的过期时间,并且不应该填写“yiaddr”服务器包括。
DHCPACK 消息中的其他参数如第 4.3.1 节中定义。 ”

1.
由于“DHCPAck”消息并不强制添加所有请求的网络配置参数,因此 DHCP 服务器可以自由地响应“DHCPInform”消息,无论是否有请求的参数响应(取决于实现),前提是客户端的静态 IP 设置已验证在 dhcp 服务器池下。

2.
此外,dhcp 客户端可以从许多 DHCP 服务器接收“DHCPAck”消息以响应其“DHCPInform”消息。客户端需要过滤从 DHCP 服务器接收到的所有“DHCPAck”消息以提取响应参数。

[示例:dhcp 客户端可能会搜索每个收到的“DHCPAck”消息以查找预定的供应商特定标记。如果“DHCPAck”消息包括预定的供应商特定标签,则 dhcp 客户端从该消息中提取响应参数。 ]

As per RFC-2131 tropic 4.3.5 for DHCPINFORM message:

"The DHCP server responds to a DHCPINFORM message by sending a DHCPACK message directly to the address given in the 'ciaddr' field of the DHCPINFORM message. The server MUST NOT send a lease expiration time to the client and SHOULD NOT fill in 'yiaddr'. The server includes
other parameters in the DHCPACK message as defined in section 4.3.1. "

1.
Since a "DHCPAck" message does not mandate to add all requested network configuration parameters, a DHCP server is free to respond to a "DHCPInform" message, with/without requested parameter responses (implementation dependent), provided the client's static ip settings are validated under dhcp server pools.

2.
Also, the dhcp-client may receive "DHCPAck" messages from many DHCP servers in response to its "DHCPInform" message. The client need to filters all of the "DHCPAck" messages received from DHCP servers to extract response parameters.

[ Example: The dhcp-client may searches each received "DHCPAck" message for a predetermined vendor-specific tag. If a "DHCPAck" message includes a predetermined vendor-specific tag, the dhcp-client extracts response parameters from this message. ]

自由如风 2024-08-14 11:43:26
问题:

如果我向服务器发送 DHCPINFORM 消息,会发生什么?

好问题:)答案不太清楚。 DHCP 服务器实现存在差异,并且 RFC有点不明确。此外,DHCPINFORM 消息(始终由客户端发起)已经经历了一些修订 - 或者如果您愿意的话,也可以进行一些修改,因此答案也可能取决于您的 DHCP 服务器软件的版本:

DHCPINFORM 最初是在 RFC2131,1997 年 3 月。RFC2131 已更新 4 次:3396436154946842。自 RFC 2131 发布以来,DHCPINFORM 本身随后已“澄清”了 7 次搜索将强调创建 DHCPINFORM 消息后所造成的一些混乱; 例如

最近,RFC 3203 创建了一条强制客户端(包括主机使用 DHCPINFORM 消息)进入 RENEW 状态。 RFC 6704 更新了 RFC 3203,其中包含有关使用 Nonce 身份验证安全协议。这些标准使你的问题的答案变得更加模糊。

由于 DHCP 服务器实现的差异,也许回答您的问题的最佳方法是使用 nmap (或类似的)来发现服务器发出的 ACK 消息的内容响应 DHCPINFORM。我选择 nmap 来说明这一点,因为 dhcp-discover 脚本是 nmap 脚本引擎 发送 DHCPINFORM 消息。以下是它在我的系统上的工作方式:

$ sudo nmap -sU -p 67 --script=dhcp-discover 192.168.1.1

Starting Nmap 7.70 ( https://nmap.org ) at 2022-05-30 18:37 CDT
Nmap scan report for myprivlan.com (192.168.1.1)
Host is up (0.0013s latency).

PORT   STATE SERVICE
67/udp open  dhcps
| dhcp-discover:
|   DHCP Message Type: DHCPACK
|   Server Identifier: 192.168.1.1
|   Subnet Mask: 255.255.255.0
|   Router: 192.168.1.1
|   Domain Name Server: 192.168.1.1
|_  Domain Name: myprivlan.com
MAC Address: 00:25:B0:E0:A9:F5 

Nmap done: 1 IP address (1 host up) scanned in 1.51 seconds

这样您就可以看到服务器的 ACK 消息中包含哪些信息。 AIUI,此信息可能只是 ACK 消息中完整信息集的子集 - dhcp-discover 脚本中定义的子集;您可以分析脚本代码来验证这一点。

作为进一步的实验,我对 DHCP 服务器的配置(OPNsense 防火墙)进行了一些更改,并重新运行相同的nmap命令。在每种情况下,我在服务器上所做的更改都准确地反映在 nmap 输出中。

因此,DHCPINFORM 似乎确实满足了最初的目标 - 使用静态 IP 配置更新客户端。但客户有责任定期请求此更新。

The question:

If I send a DHCPINFORM message to the server, what will happen ?

Good question :) The answer is not quite so clear. There are variances in DHCP server implementations, and the RFCs are a bit ambiguous. Additionally, the DHCPINFORM message (always initiated by the client) has gone through some revisions - or revelations if you prefer, and so the answer may also depend on the vintage of your DHCP server software:

DHCPINFORM was initially defined in RFC2131 in March, 1997. RFC2131 has been updated 4 times by: 3396, 4361, 5494, 6842. Since RFC 2131's publication, DHCPINFORM itself has subsequently been "clarified" 7 times through 2011. A search will highlight some of the confusion sown in the wake of the creation of the DHCPINFORM message; for example.

A bit more recently, RFC 3203 created a FORCERENEW message which forces the client (incl. hosts using the DHCPINFORM message) to the RENEW state. RFC 6704 updates RFC 3203 with details on use of the Nonce Authentication protocol for security. These standards have made the answer to your question still more ambiguous.

Due to variances in DHCP server implementations, perhaps the best way to answer your question is to use nmap (or similar) to discover the contents of the ACK message issued by your server in response to a DHCPINFORM. I chose nmap to illustrate this because of the dhcp-discover script that is part of the nmap scripting engine sends a DHCPINFORM message. Here's how it worked on my system:

$ sudo nmap -sU -p 67 --script=dhcp-discover 192.168.1.1

Starting Nmap 7.70 ( https://nmap.org ) at 2022-05-30 18:37 CDT
Nmap scan report for myprivlan.com (192.168.1.1)
Host is up (0.0013s latency).

PORT   STATE SERVICE
67/udp open  dhcps
| dhcp-discover:
|   DHCP Message Type: DHCPACK
|   Server Identifier: 192.168.1.1
|   Subnet Mask: 255.255.255.0
|   Router: 192.168.1.1
|   Domain Name Server: 192.168.1.1
|_  Domain Name: myprivlan.com
MAC Address: 00:25:B0:E0:A9:F5 

Nmap done: 1 IP address (1 host up) scanned in 1.51 seconds

And so you can see what information was included in the server's ACK message. AIUI, this information may only be a subset of the complete set of information in the ACK message - a subset defined in the dhcp-discover script; you may analyze the script code to verify that.

As a further experiment, I made some changes to my DHCP server's configuration (the OPNsense firewall), and re-ran the same nmap command. In each case, the change I made on the server was accurately reflected in the nmap output.

Consequently, it seems that DHCPINFORM does meet the original objective - to update clients with static ip configurations. But it is the client's responsibility to request this update periodically.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文