摘要

  • RFC 5107 允许 DHCP 中继把一个 IPv4 地址交给服务器，再由服务器把该值写入 option 54。这个值把后续续租带回中继，不等于真实 DHCP 服务器的接口或身份。
  • 可审计的续租必须分别记录覆盖地址的选择、中继证据、服务器接收、租约决策、客户端应用与首个可用流量。地址相等只是一段转换回执。

事故记录看上去很整齐：客户端携带的 Server Identifier 与中继的 Server Identifier Override 都是同一个地址，服务器也继续处理了 DHCPREQUEST。可是没有任何记录说明续租从哪个接入口进入，当前 Circuit-ID 是否存在，Remote-ID 是否与最初分配一致。字段相等了，控制面事实却没有闭合。

普通 DHCPv4 在初次分配与续租之间存在一个路径断点。中继处理 DHCPDISCOVER 时，可以加入 Relay Agent Information，以及 Circuit-ID、Remote-ID、设备类别等子选项。租约生效后，RENEWING 状态的客户端通常直接把 DHCPREQUEST 发往 option 54 指定的地址。若拓扑允许，它会绕过中继，服务器便看不到新的接入证据。

RFC 5107 用一次明确的间接寻址修补这个断点。中继加入编号 11 的 Server Identifier Override 子选项，长度为四个字节，内容是一个 IPv4 地址。支持该机制的服务器必须把这个值写进相应回复的 option 54。客户端下次续租时先到这个地址，中继重新加入当前 Relay Agent Information，再把请求送到真实服务器。

因此，名为“服务器标识符”的地址可以不是服务器接口地址。它在这里是客户端返回路径的句柄。中继负责重建接入上下文，服务器负责租约状态与决策，option 54 只负责把客户端带到能连接两者的入口。

服务器还必须为该客户端记住覆盖地址，直到从中继收到下一条消息。这个要求产生了可丢失、可更新、可过期的辅助状态。事件应记录中继身份、学习时间、客户端或租约键、覆盖代次以及当时的子选项摘要。只保存“当前地址”无法回答它从何而来。

不支持 RFC 5107 的服务器会忽略子选项，仍把自己的合适接口地址放入 option 54。初次 DHCPACK 可能完全成功，兼容性问题要到续租才出现：客户端直达服务器，中继没有收到请求，服务器期待的接入证据也没有被重新附加。

所以“租约已发放”不能证明“保持中继可见性的续租路径已经建立”。混合服务器池尤其危险：有些实例回显覆盖地址，有些实例回显自身地址。若监控只看总体 ACK 成功率，这个分支会长期隐藏。

服务器处理 DHCPREQUEST 时通常会检查 option 54 是否属于自己的接口。存在覆盖子选项时，RFC 5107 改变了比较对象：服务器应比较 option 54 与子选项 11。两者相同，就可以继续处理，即使该地址不是本机接口。

这个比较只证明本次报文中的两个字段一致。它没有证明是谁插入了子选项、中继是否可信、客户端之前是否收到真实回复，也没有证明服务器拥有该地址。把 option54 == override 映射为“服务器认证成功”，等于把一致性检查扩大成身份断言。

中继仍应正常填写 giaddr。覆盖地址没有取代用于分配网络选择的中继地址，也没有取代 Circuit-ID、Remote-ID 或 Device Class。客户端返回目的地、中继跳点、接入端口和策略输入各有独立作用域。

如果一个中继配置了多个服务器，RFC 5107 建议它把所有 DHCP 消息——包括 RENEW DHCPREQUEST——转发给所有服务器。设计意图是避免中继维护一份影子租约表。它负责搬运当前证据，由各服务器把证据与自身租约状态比对。

多服务器转发需要逐目的地回执。中继收到续租，不代表每台服务器都收到；一台服务器给出 DHCPACK，也不代表其余目的地成功可达。非租约持有者保持沉默也不等于丢包。事件链必须标出每次发送、接收与最终决策者。

RFC 5010 的 Relay Agent Flags 子选项还能说明客户端原始报文是广播还是单播。RFC 5107 建议同时使用。服务器看到的是中继转换后的报文，不能从服务器侧传输方式反推出客户端最初怎样发送。

一旦使用覆盖地址，中继的可用性就进入租约连续性边界。客户端到不了覆盖地址，续租不会进入中继；中继到不了服务器，第一段成功而第二段失败。两种情况都可能让租约超时，而 option 54 本身始终格式正确。

正确的证据链至少包括：客户端报文到达中继、覆盖地址选择、giaddr、原始广播/单播标志、Relay Agent Information 摘要、服务器接收、覆盖状态落盘、回复中的 option 54、客户端收到回复、续租重新进入中继、逐服务器转发、租约决策、客户端配置应用与首个有效流量。

覆盖状态必须带代次。服务器重启后可能恢复租约，却没有恢复辅助覆盖地址；客户端仍保存旧 option 54。下一次请求看起来像“指向未知服务器”，实际故障却是持久租约与返回路径状态发生代次分裂。

迁移也可能产生相反情形。同一个 anycast 地址背后的中继集合发生变化，option 54 不变；或者真实服务器集合不变，中继地址却发生切换。地址稳定、实例身份和租约权限必须分别版本化。

安全边界并未因为字段相等而消失。Relay Agent Information 依赖中继与服务器之间的信任关系。恶意中继可以提供自己的地址，把后续续租吸引过来，再拒绝续租、修改 DHCPACK 选项，甚至向客户端呈现服务器没有批准的租期。

RFC 5107 明确指出，该子选项本身不提供额外安全收益。相关控制是 DHCP 认证、Relay Agent Information 认证，以及阻止不可信设备插入 option 82 的拓扑边界。安全日志还应说明认证了哪个主体、保护了哪些字段。

服务器认证中继不等于客户端认证服务器。客户端验证了某条 DHCP 消息，也不等于运营系统知道哪个中继选择了覆盖地址。一个 authenticated=true 布尔值会把不同主体与不同保护面压扁。

DHCPACK 之后仍有配置安装边界。收到地址、掩码、路由器与租期，不代表客户端已经应用；应用不代表首跳策略、上游路由、DNS 或应用服务正常。option 54 更不能替代这些下游回执。

管理者应关注各转换的成功率：覆盖地址写入、续租回到中继、证据重建、服务器决策、ACK 到达、配置安装、首包与服务探测。只报告“续租成功”会让故障归因停留在最粗层。

RFC 5107 的机制很小，却揭示了一个普遍错误：字段名称很容易被误当成现实对象。协议故意把“Server Identifier”变成中继提供的路径地址，运营系统就应保留这层间接关系，而不是虚构出服务器身份。

来源