DHCP：在 Wireshark 中配置服务器、中继和流量分析
大家好！我是大聪明-PLUS！
在任何网络中，设备都需要 IP 地址、网关和 DNS 服务器才能正确交换数据并访问互联网。虽然可以手动配置所有内容，但这既不方便又容易出错。DHCP （动态主机配置协议）应运而生。它的作用很简单：自动将所有必要的网络参数分配给客户端，包括 IP 地址、子网掩码、网关和 DNS 服务器。
本文将详细介绍 DHCP 协议，从 DORA（发现、提供、请求、确认）消息交换过程，到使用 Wireshark 进行网络流量分析，再到在 MikroTik 和 Ubuntu 服务器上配置 DHCP 服务器。我们还将探讨其他协议特性，例如 DHCP 中继，它允许为其他子网上的客户端提供服务。
服务器设置和流量分析
1. 拓扑结构
首先，我们在 GNS3 中搭建一个简单的网络。它包含三个客户端：Windows 10、Ubuntu 和一个轻量级的 VPC 模拟器。它们都连接到交换机 Switch-1，Switch-1 又连接到一台 MikroTik 路由器。目前，路由器仅作为 DHCP 服务器，为网络中的客户端分配 IP 地址。
192.168.10.0/24子网设计用于254 个工作主机。网络中的第一个地址（192.168.10.0）保留为网络标识符，最后一个地址（192.168.10.255）用于子网内的广播。因此，工作地址的范围为192.168.10.1到192.168.10.254。
2. 在 MikroTik 上设置 DHCP
接下来我们来设置 MikroTik。首次通过控制台启动 MikroTik 时，设备会要求输入用户名和密码。默认用户名是admin，密码为空（直接按 Enter 键）。但是，在初始设置过程中，系统会要求您设置一个新密码。密码不能为空。这是因为出于安全考虑，新密码不能与当前密码（即空密码）相同。因此，输入空密码会导致错误，您需要在后续登录时输入密码。
登录后，第一步是为客户端连接的接口（在本例中为 ether1）分配 IP 地址。该 IP 地址分配在192.168.10.0/24子网内，其中“ /24 ”表示子网掩码为255.255.255.0。子网掩码决定了哪些地址被视为本地网络的一部分，并确保设备之间能够正确交换数据。
下一步是创建 IP 地址池——一个地址范围，DHCP 服务器将从中自动为客户端分配 IP 地址。在本例中，地址池涵盖192.168.10.10到192.168.10.100。配置 DHCP 时，我们还会指定一个 DNS 服务器，例如8.8.8.8，以便客户端能够正确解析网络和互联网上的名称。地址池和 DNS 配置实现了地址分配的集中管理，避免了地址冲突，并确保所有设备正常运行。我们将租约时间设置为一天，这样会自动释放不再连接的设备的地址，并将其重新分配给新客户端。
使用地址池还可以简化网络组织：地址池之外的地址可以保留给服务器或打印机等静态设备，这样它们就不会由 DHCP 自动分配。因此，地址池、子网掩码和 DNS 服务器是 DHCP 配置的关键要素，可确保为所有客户端分配正确、唯一且易于管理的 IP 地址。
3. DORA 分析
Windows 10
Ubuntu
VPC模拟器
从 DHCP 服务器获取网络参数
DHCP 服务器安装并启用后，网络上的所有设备都会自动接收其设置。每个客户端都会收到一个 IP 地址（该地址在服务器定义的地址池中是唯一的）、一个子网掩码（用于识别哪些地址是本地地址）、一个网关（允许设备在未来访问其他网络）以及一个 DNS 服务器（用于正确解析域名）。此外，还会传输其他网络正常运行所需的参数，例如地址租约时间。
所有这些数据都通过 DHCP 协议传输，客户端获取 IP 地址的过程可以通过一系列DORA消息来追踪：发现 (Discover)、提供 (Offer)、请求 (Request) 和确认 (Acknowledgment)。首先，客户端发送地址请求（发现），服务器响应并提供一个空闲 IP 地址（提供），客户端确认地址选择（请求），最后服务器确认 IP 地址分配（确认）。借助这种机制，设备可以自动接收所有必要的参数，并准备好在网络上运行。
现在让我们继续深入探讨DORA流程本身，并以单个设备为例，详细检查每个阶段，以清楚地说明在每个步骤中客户端和服务器之间究竟发生了什么。
发现
DHCP 消息 - 发现
当设备连接到网络但尚未获取 IP 地址时，它会发送DHCP Discover 请求——这是DORA流程的第一步。简而言之，客户端会告知网络它是新加入的，并希望接收配置设置。接下来，我们来看看每一层实际发生了什么。
数据链路层（以太网 II）：在这一层，数据包会连同目标地址一起广播，ff:ff:ff:ff:ff:ff以便本地网络上的所有设备都能收到消息。这是必要的，因为客户端此时还不知道 DHCP 服务器的位置。数据包的源地址是客户端的 MAC 地址，即其网卡的唯一标识符。这使得网络上的任何 DHCP 服务器都能识别请求者并做出响应。
网络层（IP）：客户端尚未获取 IP 地址，因此源地址为 [IP 地址0.0.0.0]。此数据包的目的是255.255.255.255将 [IP 地址] 广播到本地网络上的所有设备。这种双重广播（在数据链路层和网络层）确保 Discover 数据包能够到达子网上的所有 DHCP 服务器，即使存在多个服务器。
传输层（UDP）：客户端通过端口68发送数据包，DHCP 服务器通过端口67接收该数据包。UDP 用于无连接传输，这简化并加快了传输过程。网络上的每个服务器都有机会处理请求并为客户端分配一个空闲的 IP 地址。
应用层（DHCP）：主要请求信息位于此处。消息类型为Discover，表示正在搜索 DHCP 服务器。事务 ID 对于此次尝试是唯一的，以便客户端可以将收到的响应与其发送的请求进行匹配。由于客户端没有地址，因此 IP 字段仍然为空。DHCP 选项包括：消息类型 = Discover、客户端标识符（客户端 MAC 地址）、主机名、供应商类标识符（例如，MSFT 5.0）以及包含所需设置列表（子网掩码、网关、DNS 和其他参数）的参数请求列表。Discover 消息会通知服务器新客户端的存在及其需求，从而允许开始提供地址和网络设置的过程。
因此，Discover只是客户端请求获取 IP 地址和其他设置。服务器此时不会分发任何信息；它只会接收有关哪些设备已连接以及该设备具体需要什么的信息。
提供
DHCP 消息 - 提供
当 DHCP 服务器收到客户端的 Discover 请求时，它会以DHCP Offer响应——这是DORA流程的第二步。服务器会向客户端提供一个特定的 IP 地址和所需的网络参数。该数据包以单播方式发送，以便被选中的客户端能够直接收到 Offer，同时其他服务器也能知道该地址已被占用。
数据链路层（以太网 II）：在这一层，数据包直接发送到客户端的 MAC 地址（0e:2a:b0:14:00:00）。源地址是服务器的 MAC 地址（0c:63:76:e4:00:00）。与 Discover 不同，这不是广播，而是单播，因此服务器可以直接告知客户端它提供的 IP 地址。
网络层（IP）：数据包的源地址是 DHCP 服务器的 IP 地址（192.168.10.1），目标地址是服务器分配给客户端的 IP 地址（192.168.10.100）。在这一层，服务器会向客户端提供一个地址，客户端确认选择后即可使用该地址。
传输层（UDP）：服务器使用端口67作为源端口，客户端使用端口68接收数据包。UDP 允许数据包快速传输而无需建立连接，但不保证数据包的送达。
应用层（DHCP）：消息类型为 Offer，事务 ID 与 Discover 匹配，以便客户端能够将响应与原始请求进行匹配。主字段“您的（客户端）IP 地址”包含提供的地址（192.168.10.100）。DHCP 选项包括服务器标识符（192.168.10.1）、IP 地址租约时间、子网掩码、路由器和域名。这些参数让客户端了解接受地址后将收到的网络设置。
DHCP Offer 是服务器向客户端发送的特定服务请求，其中包含 IP 地址和网络参数。此时，客户端可以接受该 Offer 并进入下一步——DHCP Request。
要求
DHCP 消息 - 请求
客户端收到服务器的 IP 地址分配请求后，会发送DHCP 请求——这是DORA流程的第三步。在这个数据包中，客户端确认其选择的 IP 地址，并通知网络它打算使用该地址。该数据包会被广播，以便选定的服务器知道其分配已被接受，其他 DHCP 服务器（如果有多个）也可以释放它们的分配。
数据链路层（以太网 II）：数据包会发送给网络上的所有设备（ff:ff:ff:ff:ff:ff），这样被选中的服务器就能收到确认信息，其他服务器也能明白它们的地址请求已被拒绝，这些地址可以返回地址池。源地址是客户端的 MAC 地址（0e:2a:b0:14:00:00），它是客户端网络接口的唯一标识符。
网络层（IP）：0.0.0.0由于客户端尚未收到最终的IP地址，因此数据包的源地址为空。目标地址是255.255.255.255 将数据包发送到本地网络上的所有设备。此广播确保数据包能够到达选定的服务器以及网络上的所有其他服务器（如有）。
传输层（UDP）：客户端使用端口68作为源端口，服务器监听端口67作为目标端口。
应用层（DHCP）：消息类型为请求，事务 ID 与发现和提供匹配，绑定整个DORA事务。由于地址租约尚未最终确定，因此 IP 字段仍为空。DHCP 选项包括：消息类型 = 请求，服务器标识符 = 192.168.10.1，请求的 IP = 192.168.10.100，客户端标识符 = 客户端 MAC 地址，主机名 = MSEDGEWIN10（Windows 10），供应商类别 = MSFT 5.0，以及包含子网掩码、网关、DNS 和其他最终ACK参数的参数请求列表。
DHCP 请求通知网络它已接受服务器的分配。客户端准备接收最终确认，之后 IP 地址和网络设置将生效，这在下一步——DHCP 确认中发生。
致谢
DHCP 消息 - 确认
客户端发送请求后，服务器会通过DHCP ACK确认最终的 IP 地址和网络设置——这是DORA流程的第四步，也是最后一步。该数据包正式为客户端分配 IP 地址和所有网络设置，之后设备即可在本地网络上完全运行。
数据链路层（以太网 II）：在这一层，数据包直接以单播方式发送到客户端的MAC 地址0e:2a:b0:14:00:00。源地址是 DHCP 服务器的 MAC 地址0c:63:76:e4:00:00。 单播用于将所选地址的确认信息准确地传递给特定设备，并避免不必要的广播。
网络层（IP）：数据包的源地址是 DHCP 服务器的 IP 地址（192.168.10.1），目标地址是客户端当前已正式分配的 IP 地址（192.168.10.100）。在这一层，数据包已直接寻址到已分配的 IP 地址，这与之前的步骤不同，之前的步骤中客户端的 IP 地址尚不清楚。
传输层（UDP）：服务器使用端口67作为源端口，客户端监听端口68。
应用层（DHCP）：消息类型为ACK，事务 ID 与之前的 Discover、Offer 和 Request 数据包相同，从而将整个DORA事务绑定在一起。“您的（客户端）IP 地址”字段包含分配的 IP 地址（192.168.10.100）。DHCP 选项包括以下参数：子网掩码（255.255.255.0）、路由器（192.168.10.1）、DNS 服务器（8.8.8.8）、IP 地址租约时间（1 天）、服务器标识符（192.168.10.1）以及列表末尾的选项 255。客户端将这些设置应用到其网络接口，然后即可在网络上完全正常工作，包括通过指定的网关访问外部资源以及使用 DNS 进行域名解析。
DHCP ACK 数据包完成 DORA 流程，正式为客户端分配 IP 地址和网络参数。收到此数据包后，设备即可在本地网络中运行，并具备连接到其他网络的能力。
MikroTik命令ip dhcp-server lease print显示 DHCP 服务器当前已分配给网络上设备的 IP 地址。在本例中，dhcp1 服务器为三台设备分配了地址：Windows、Ubuntu 和 VPCS。
表格显示，每个设备都从地址池中分配了一个唯一的 IP 地址，以及其 MAC 地址和主机名。“已绑定”状态表示租约已激活——这意味着设备当前正在使用此 IP 地址，并且可以在网络上完全运行。Windows 系统获得的 IP 地址为192.168.10.100，Ubuntu 系统获得的 IP 地址为192.168.10.99，VPCS 系统获得的IP 地址为192.168.10.98。
DHCP 服务器已成功完成任务：所有三台设备都自动获取了 IP 地址、子网掩码、网关和其他必要的网络参数。它们现在可以在本地网络内交换数据，将来还可以使用网关访问其他子网或互联网。
4. 分析其他 DHCP 消息
发布
Windows 10
DHCP 消息 - 释放
当该命令在 Windows 客户端计算机上执行时ipconfig /release，设备会通知 DHCP 服务器它不再需要已租用的 IP 地址。在本例中，客户端向服务器192.168.10.1发送DHCP Release 请求，释放地址192.168.10.100。这意味着服务器可以将此 IP 地址返回到空闲地址池中，以便其他设备可以使用。
执行该命令后，客户端的 IPv4 地址、网关和 DNS 服务器都会消失。在此状态下，设备无法与本地网络内外进行完整的数据交换。只有当客户端通过 DHCP 重新获取网络参数或手动设置网络参数后，功能才能恢复。
Release网络数据包通过单播方式直接发送到服务器。源地址为客户端的旧 IP 地址（192.168.10.100），目标地址为服务器的 IP 地址（192.168.10.1）。该数据包包含消息类型（Release）、客户端标识符（MAC 地址）和服务器标识符，以便 DHCP 服务器能够准确地确定需要终止哪个租约。
MikroTik 服务器收到此数据包后，会立即更新客户端的租约记录：地址返回到可用地址池中，租约状态从绑定变为释放（或从活动租约列表中删除该记录）。
DHCP 释放机制允许客户端在使用完 IP 地址后，将其优雅地归还给服务器。这样，该地址就不再被使用，服务器可以将其分配给其他设备。
纳克
DHCP 消息 - NAK
Windows 客户端使用`ipconfig /release`命令释放 IP 地址192.168.10.100后，服务器将该地址返回到空闲地址池。之后，DHCP 地址池被修改，现在只包含192.168.10.10到 192.168.10.99 之间的地址。当 Windows再次尝试获取 IP 地址192.168.10.100时，服务器返回了DHCP NAK消息。该消息告知客户端请求的地址无效，无法使用。/ip pool set dhcp_pool ranges=192.168.10.10-192.168.10.99
服务器会广播DHCP NAK消息，以确保客户端收到通知。消息中，服务器会指定无法使用的 IP 地址及其标识符，以便客户端确认这是服务器的正确响应。收到NAK后，客户端会立即停止使用旧的 IP 地址，并开始从头开始获取新地址：首先，它发送 Discover 消息，然后接收 Offer 消息，确认 Request 消息，最后接收包含新 IP 地址的 ACK 消息。在本例中，Windows 收到了地址192.168.10.97，该地址在当前地址池中。
服务器发送NAK 的原因有很多。最常见的是客户端请求的地址已不在地址池中或已被其他设备占用。此外，如果客户端尝试续租服务器不再识别的旧 IP 地址，或者客户端指定的续租服务器无效，也可能发生 NAK。
一般来说，DHCP NAK 是一种保护机制，可以防止 IP 地址冲突，并确保设备只使用当前地址池中的有效地址。
通知
设备通过 DHCP 获取 IP 地址和其他设置后，可能需要在不更改 IP 地址的情况下向 DHCP 服务器请求其他网络参数。这可以通过DHCP INFORM消息来实现。客户端向服务器发送此消息，以获取例如当前 DNS 服务器、域名或其他可在不影响其当前 IP 地址的情况下更改的网络选项。
INFORM消息从已分配给设备的 IP 地址发送，服务器则以包含所请求参数的常规DHCP ACK进行响应。如果网络上的 DNS 设置、网关或其他服务参数已更新，而客户端需要在不请求新 IP 地址的情况下获取这些参数，则此方法非常有用。
与 Discover、Request 或 Release 不同，INFORM 不执行 IP 地址分配，而仅用于信息检索。Windows 上的命令ipconfig /renew，Linux 上的命令。dhclient -1 -v -s 192.168.10.1>
衰退
当客户端检测到 DHCP 服务器提供的 IP 地址已被其他设备使用时，会发送 DHCP DECLINE消息。例如，客户端收到一个地址为192.168.10.98的Offer，但 ARP 检查发现该地址已被其他主机占用。在这种情况下，客户端无法安全使用该 IP 地址，因此会向服务器发送DECLINE消息以通知其地址冲突。
收到拒绝请求后，服务器会将该地址标记为不可用，并且在管理员或服务器解决冲突之前，不会再将其分配给其他客户端。因此，DHCP 拒绝机制可以防止网络上的 IP 地址冲突，并确保所有设备正常运行。
值得注意的是，使用DECLINE 参数时，即使客户端已经在使用其他 IP 地址，它也不会丢失当前正在使用的 IP 地址。这纯粹是一种保护机制，用于处理可能导致冲突的服务器请求。
示例用法：Windows 和 Linux在检查 Offer 时，如果通过 ARP 检测到网络上的 IP 匹配，则会自动发送DECLINE 。
5. 静态 IP 绑定
Ubuntu 客户端
Wireshark 分析
Mikrotik 桌子
DHCP 允许您使用设备的 MAC 地址为其分配特定的 IP 地址。这种机制称为静态租约 ，它确保选定的客户端始终获得相同的地址，而不受动态地址池的影响。
实际上，具体操作如下：MikroTik 管理员手动创建一个条目，指定 IP 地址、客户端 MAC 地址、DHCP 服务器名称以及一条便于参考的注释。在本例中，我们为 MAC 地址为 192.168.10.105 的0c:a2:21:ee:00:00Ubuntu 虚拟机分配了一个静态 IP 地址。配置命令如下：/ip dhcp-server lease add address=192.168.10.105 mac-address=0c:a2:21:ee:00:00 comment="Ubuntu fixed IP" server=dhcp1
应用此设置后，DHCP 服务器将不再把此 IP 地址分配给其他设备。如果具有指定 MAC 地址的客户端尝试使用地址池中的另一个地址，服务器将发送NAK（如屏幕截图所示），客户端将被强制请求新的配置。在我们的示例中，Ubuntu 最初被拒绝，但随后通过标准的DORA流程，被正确分配了地址192.168.10.105。
6. 在 Ubuntu 上设置 DHCP
我们将把 DHCP 服务器从 MikroTik 迁移到 Ubuntu Server。之前，MikroTik 分配的 IP 地址是192.168.10.1；现在它将由一台专用的 Ubuntu 服务器来承担这项任务。首先，我们将禁用 MikroTik 上的 DHCP 服务，这样客户端将不再从它那里获取 IP 地址。
/etc/default/isc-dhcp-server
首先，您需要确保软件包本身已安装。如果没有，请使用以下命令安装：sudo apt install isc-dhcp-server。安装完成后，您需要告诉服务器监听哪个网络接口来接收客户端请求。这需要在文件中完成/etc/default/isc-dhcp-server。打开该文件并编辑以下行：INTERFACESv4="ens3"。ens3是我的网络接口名称；您的网络接口名称可能不同。
/etc/dhcp/dhcpd.conf
接下来，我们进入主配置文件/etc/dhcp/dhcpd.conf。在那里，我们设置网络参数：已分配地址池、网关、DNS 服务器以及租约时间。这意味着服务器现在知道应该将哪些地址分配给哪些用户、通过哪个网关、分配哪个 DNS 服务器以及租约期限。
我们为服务器分配了静态 IP 地址192.168.10.2/24。Ubuntu服务器现在可以向客户端分配 IP 地址了。使用以下命令启动服务：sudo systemctl start isc-dhcp-server要检查状态：sudo systemctl status isc-dhcp-server.
Windows 10
Ubuntu 客户端
当客户端开始与新服务器通信时，会发生以下情况：Windows 尝试使用旧地址192.168.10.97，服务器接受该地址，因为它在新地址池中可用。然而，之前在 MikroTik 设备上拥有静态地址192.168.10.105的 Ubuntu 客户端无法再获取该地址，因为它不在新地址范围内。服务器忽略此请求，客户端重新发送 Discover 请求，收到 Offer 请求，发出 Request 请求，最终从地址池中获得新地址——192.168.10.12。
因此，检查租约表显示：Windows 保留了其旧地址，Ubuntu 获得了一个新地址，vpc 也从新的地址范围中获得了其 IP 地址。
7. 配置 DHCP 中继
我们的网络现在有两个子网：旧的192.168.10.0/24和新的172.16.10.0/24。DHCP服务器（Ubuntu Server，192.168.10.2）目前只知道第一个子网的地址池。这意味着如果来自新子网的客户端（PC2、PC3）发送 DHCP Discover 请求，服务器根本看不到这些请求——广播数据包无法通过路由器。
为了解决这个问题，我们使用 MikroTik 作为DHCP 中继并设置路由。
1）在MikroTik上设置路由
我们将 IP 地址172.16.10.1/24分配给 ether2 接口，该接口指向新的子网172.16.10.0/24。现在路由器知道发往该子网的数据包会经过 ether2 接口，从而可以正确地在网络之间路由流量。路由对于返回路径也至关重要：当 DHCP 服务器响应时，数据包应该返回到172.16.10.0/24。
2) 在 MikroTik 上设置 DHCP 中继
DHCP中继
DHCP 中继——它允许一个子网中的客户端访问另一个子网上的服务器，即使该服务器不在同一广播范围内。中继监听客户端网络接口上的 DHCP 数据包，并将它们作为常规单播数据包转发到服务器。
在 MikroTik 上，它看起来像这样：
/ip dhcp-relay add name=relay1 interface=ether2 dhcp-server=192.168.10.2 local-address=172.16.10.1 /ip dhcp-relay enable relay1
-
interface=ether2 - 新子网和需要拦截数据包的客户端所在的接口。
-
dhcp-server=192.168.10.2 - 请求将被转发到的服务器的 IP 地址。
-
local-address=172.16.10.1 - 客户端子网中的 MikroTik IP 地址，将作为客户端响应的来源。如果没有 local-address，服务器返回的 Offer/ACK 数据包可能无法到达客户端，因为客户端无法将其路由到不同的子网。
-
enable relay1 - 激活先前创建的名为 relay1 的中继。
VPC-2
由于服务器只知道192.168.10.0/24网络，Relay 会将Discover 消息传递给服务器，但服务器无法分配地址，客户端将无法获得 IP 地址。因此，在启动 Relay 之前，需要将新的子网添加到 DHCP 服务器配置（/etc/dhcp/dhcpd.conf）中。
VPC-2 和 VPC-3
DHCP 消息 - 提供
PC1 和 PC2 都已获取地址。我们分析客户端 PC2 的DHCP Offer。Ubuntu服务器本身想要从其位于第一子网的地址池中为客户端分配一个地址，但客户端位于第二子网172.16.10.0/24。数据包通过 MikroTik 到达客户端，MikroTik 充当DHCP 中继。路由器将自身的本地 IP 地址172.16.10.1替换为源地址 ，以便数据包能够正确到达客户端，因为客户端没有直接连接到服务器的路由。数据包的目标地址是 IP 地址172.16.10.10 ，这是服务器提供给客户端的地址。 “下一个服务器 IP 地址”字段仍然是192.168.10.2，表明实际的DHCP 服务器位于第一子网。这意味着数据包看起来像是来自 MikroTik，但实际上它是 Ubuntu 服务器发出的 Offer。该机制允许隔离子网中的客户端获取 IP 地址和网络参数。
3. 数据包如何通过中继（逐步分析）
-
步骤 1：客户端（PC2/PC3）发现位于172.16.10.0/24
子网上的客户端发送DHCP Discover广播（）。它会搜索任何 DHCP 服务器。但是，由于服务器位于不同的子网，数据包无法直接到达客户端。ff:ff:ff:ff:ff:ff -
步骤 2：MikroTik 设备上的 MikroTik
DHCP 中继拦截以太网 2 端口上的 Discover 数据包。中继读取该数据包，并将目标 IP 地址替换为新的目标 IP 地址——DHCP 服务器 IP 地址 (192.168.10.2)。现在，该数据包以单播方式从 MikroTik 设备发送到服务器。 -
步骤 3：服务器收到 Discover
数据包。Ubuntu DHCP 服务器收到该数据包。目前，服务器只知道 192.168.10.0/24 网段的地址池，因此无法为 172.16.10.0/24 网段分配地址。中继可以选择性地添加选项 82（代理信息），以便服务器知道客户端来自哪个子网以及要使用哪个地址池。 -
步骤 4：服务器发出 Offer。
服务器为客户端生成DHCP Offer 。如果172.16.10.0/24的地址池已被添加，则服务器从该地址池中选择一个空闲 IP 地址，并将数据包发送回Discover (MikroTik) 消息的源IP地址。 -
步骤 5：MikroTik 将 Offer 传递给客户端。
当数据包返回到 MikroTik 时，它会将源 IP 地址更改为客户端子网上的接口（172.16.10.1），以便客户端可以接受响应，并将Offer转发给客户端。 -
步骤 6：请求和确认。
客户端发送DHCP 请求，服务器发送 DHCP 确认——整个DORA过程完全通过中继完成。客户端会收到 IP 地址、网关和 DNS 名称，就好像服务器位于其子网中一样。
结果
在这个项目中，我们学习了DHCP协议并实际考察了它的运行机制。首先，我们研究了客户端如何通过DORA过程获取 IP 地址和其他网络参数，然后使用Wireshark分析数据包，确认每条消息的作用。我们在 MikroTik 上配置了 DHCP，之后将服务器迁移到 Ubuntu Server，以了解它在不同系统上的运行情况。我们还测试了 NAK 和 RELEASE 等消息，以了解客户端和服务器如何交换附加信息并解决冲突。之后，我们在 MikroTik 上添加了第二个子网并配置了DHCP 中继，使客户端能够从其他网络获取地址。
因此，DHCP极大地简化了网络管理，这一点显而易见。无需手动为每个客户端分配 IP 地址、网关和 DNS，一切都会自动完成。此外，诸如中继和静态地址分配等工具的可用性，使得该协议即使在复杂的网络拓扑中也便捷灵活。
