DHCP协议分析
协议流程
直接DHCP
DHCP允许系统管理员在服务器上集中定义设备配置,当这些设备启动时,可以请求这些配置参数。
当客户端发送广播DISCOVER包时,DHCP 进程开始,本质上是说“外面有任何 DHCP 服务器吗?” 这就是我正在寻找的信息。” 然后 DHCP 服务器回复一个包含所有信息的OFFER报文。 客户机用一个REQUEST包进行响应,这个包的名称似乎很奇怪——实际上,客户机只是通过确认的方式,发送它刚刚从服务器返回的信息。 然后,服务器发送最后的ACKNOWLEDGEMENT数据包,同样带有相同的信息,再次确认它。
这是通常称为DORA序列(发现、提供、请求、确认),通常是这样描述的:

因为这些都是 UDP 数据包,请记住 UDP 协议中没有任何会话信息,那么是什么将这四个数据包绑定到一个“会话”中呢? 因此,最初的 Discover 报文有一个事务 ID,在随后的三个报文中匹配- Wireshark 跟踪如下所示:

实际上,客户端直到第四个包才有一个地址,所以 Discover 和 Request 包是从 IP 为0.0.0.0的客户端的 MAC 地址到255.255.255.255的广播地址(即到整个局域网)。
中继DHCP
在许多公司网络中,服务器在它们自己的子网中——分离服务器和工作站是相当普遍的做法。 这种情况下 DHCP 顺序如何工作? DORA 序列的前三个数据包被发送到广播地址,因此它们只能到达同一 VLAN 上的其他主机。
我们通过在客户端子网中的主机上放置一个 DHCP“转发器”或“中继”进程来完成这项工作。 该进程接收本地广播,然后将其以单播形式转发给 DHCP 服务器。 当服务器应答时(以单播方式向转发器主机),转发器将包“转换”为客户机所期望的广播应答。 几乎总是,这个转发器功能是在客户端子网上的路由器或交换机 IP 地址上完成的——换句话说,接口最终将成为客户端的默认网关。 这个函数在技术上不需要在那个接口上,但它是一个我们知道会在那里的接口,而且这个函数几乎总是可供我们使用。 另外,如果我们将其作为一种不成文的惯例,当我们以后需要更改它时,它将更容易找到该命令! 在 Cisco 路由器或交换机上,这个命令看起来像这样: 1
interface VLAN <x> ip helper-address 10.10.10.10
这里,10.10.10.10是我们 DHCP 服务器的 IP 地址。
在操作中,这改变了我们在大多数家庭网络上拥有的简单的广播操作:
这如何修改我们的 DORA 序列? 简单的回答是,它实际上不会修改任何数据包的 DHCP 内容。 它所做的是修改数据包中的上层“IP 地址”字段-路由器和服务器之间修改的数据包有“真实的”源和目的 IP 地址。 但是,客户端看到的包内容保持不变。 如果你深入研究 DHCP 报文,你会发现不管是否有中继,DHCP 客户端的 MAC 地址和 DHCP 服务器的 IP 地址实际上包含在 7 层 DHCP 协议的数据字段中。
现在我们开始为基本配置 DHCP 服务器工作站操作,但在我们到达之前,我们要考虑我们需要的专用设备,如 iphone,无线访问点(WAP), 或者甚至是预执行环境(PXE)设备,可以从 DHCP 信息加载其整个操作系统。
仿真
组网

路由设置
1 | <Huawei>sys |

抓包

dhcp discover






























.png)
.png)



.png)





