跨越 VPN 的 DHCP：桥接广播还是中继请求？

隧道另一侧的新笔记本拿不到地址，而同一台笔记本在总部却工作正常。常见的第一个猜测是隧道拦截了 DHCP。更多时候，广播根本没有通路：未配置的客户端发往 255.255.255.255，而普通 IP 路由器不会转发这个包。隧道只是做了路由式隧道本就该做的事。

两种设计可以改变这一点，而且它们并不等价。一种承载广播，另一种中继请求。

广播从不跨越路由器

没有地址的 DHCPv4 客户端从 0.0.0.0 发往受限广播地址，使用 UDP 端口 67 和 68。按设计，这个包只留在本地链路。转发它的路由器会把它所服务的每个网段都淹没。

因此，路由式的站点到站点隧道只是把中继接到服务器上。它不会扩展客户端的广播域，任何防火墙规则也做不到这一点。

刻意桥接的 VPN 可以在其支持的拓扑下承载以太网广播，于是 DHCP 能作为本地流量通过。这是真实可行的选项，但它属于 2 层的设计选择。你在扩大广播的同时，也扩大了故障域和访问边界。

桥接还会改变广播风暴、ARP 扫描或流氓 DHCP 服务器能触及的范围。如果你不会把远程办公室插到同一台交换机上，就不要仅为分发地址而桥接隧道。启用之前先测试这个影响半径。

这比提供一个地址是更大的决定，应当刻意做出。

通常的答案是客户端本地网络上的中继。它接收广播，将其转为单播请求，并把自己的地址写入网关地址字段。服务器再回复到该中继地址。

以一个远程办公室为例，中继位于办公室局域网，服务器则通过站点 VPN 访问。为该办公室配置作用域、中继与服务器标识，以及完整的返回路径。放行隧道内的 UDP 67 并不会告诉服务器该用哪个地址池。

会转发却始终收不到回复的中继，通常是返回路径问题。在修改作用域之前，先检查回到中继地址的路由。

DHCP 运行在 UDP/IP 之上。在以太网上，主机也可能用 ARP 检查候选地址是否已被占用。这种冲突检查是独立的链路本地操作，不是 DHCP 报文的传输方式。说 DHCP 本质上就是 ARP 是错的；说两者毫无关系又过于宽泛。

VPN 客户端也可以从 VPN 协议或服务器自身的地址池获取隧道地址，而不是来自 DHCP 广播。名字里含 DHCP 的选项可能描述的是下发的客户端设置，而不是被中继的 DHCP 报文。在假定涉及 DHCP 之前，先检查服务器的地址池。

记录接收网段、分配归属、作用域、是否存在中继，以及中断时的预期行为。然后用该模型测试一次新租约和一次续租。如果两个站点都能服务同一个无人管理的地址池，你就有一个冲突，正等着第一台漫游的笔记本。