桥接的站点仍然需要本地互联网出口决定

VLAN 扩展测试得很干净：两端站点的主机互相可见，文件共享正常，打印机也有响应。然后小站点的人发现每次下载都在走另一个站点的互联网线路，工单以带宽投诉的形式进来。桥接只做了它被要求做的事。它在两栋楼之间搬运帧，而对于这些帧该走哪台路由器上网，它从来没有意见。

桥接搬运帧，不做决定

第 2 层扩展让两个地点看起来像同一个广播域，因此 ARP 请求、DHCP 广播和同子网流量都会穿过隧道。这就是它提供的全部服务。桥接中没有任何东西检查目标地址、把它与站点的上联链路比较，或把流量导向更近的出口。每个客户端仍然用自己被配置的地址和掩码，自行决定走本地还是走远程。

在这个共享子网上放两台路由器，两台都会成为看似合理的网关，无论其中一台是否离使用它的客户端更近。

客户端如何选择网关

RFC 1122 中描述的 IPv4 判断很简单。客户端所连子网内的目标用 ARP 直接到达，子网外的目标则发往配置的默认网关。这就是为什么站点之间同子网的流量可以不经任何路由器参与就穿过桥接，也是为什么互联网流量完全取决于客户端收到的网关地址。这两件事互相独立，而一个能用的文件共享只证明了前者。

如果小站点的客户端被配置成大站点的路由器，它的互联网帧先穿过隧道，再从那里出去。

修改 VPN 设备自身的默认路由，并不会移动那个客户端的网关，因为客户端根本没有把设备当路由器用。设备还需要一条到其远端对端设备的独立路由，才能让承载那些帧的隧道保持在线，而把这两件事混为一谈，正是桥接扩展把自己传输打挂的方式。

让 DHCP 表达预期的出口

DHCP 应答中的选项 3 会按优先顺序提供客户端子网上的路由器地址列表，客户端通常取第一个应答的。机制本身没问题；出问题的是归属。与其假定最近的 DHCP 服务器会发放最近的网关，不如记录每个站点上实际租约到底给了什么。

运行一个协调一致的分配器，或者运行两个为同一策略显式配置的分配器，并给这条策略一个负责人。在远端站点再加一个独立的分配器，并不会创造本地性，它只会给同一个广播域造出两个权威。

不要为了让两个站点的设置看起来一样，就把一个网关地址分配给两台各自独立运行的路由器。跨越桥接网段的共享虚拟地址，是一套有自身要求的第一跳冗余设计，而手搓版本会产生看起来像间歇性丢包的 ARP 冲突。如果应用其实并不需要共享的第 2 层网段，各自独立的可路由前缀配本地默认网关运维更简单，出事时也更好解释。

分别测试四件事

要四个观察，而不是一个。在每个站点取一份新的 DHCP 租约，记下它拿到的路由器和掩码。访问另一个站点上同子网的服务，确认路径走的是桥接而不是被路由的绕行。在每个站点从公网取点东西，确认是哪条上联把它带过去的。然后断开隧道，看看什么坏了，因为桥接失败时彻底失去连通性的站点，其实一直在依赖远端网关，只是没人注意。

这四个结果能告诉你，你手里是站点间桥接、本地出口，还是意外回程，收集它们只需要十分钟。

设计原则并不光鲜：桥接决定可达性，DHCP 决定网关，设备上的路由表决定隧道自己的路径。把这三件事分开讨论，因为试图一次修好三者的改动，通常会弄坏其中两件。