站点 VPN 需要两端使用相同的 VLAN ID 吗？

两个办公室使用相同的 VLAN 编号，看起来应该对站点间隧道有帮助，但它不会改变隧道承载的任何内容。VLAN ID 标记的是一座建筑内部的以太网广播域； 隧道在网关之间转发 IP 数据包。两个站点可以使用完全不同的 VLAN 编号，却仍能互相路由；两个站点也可以使用相同的 VLAN 编号，却仍然无法互通。决定可达性的变量是地址规划。

误区：两端使用相同的 VLAN ID

这种看法有其合理的出发点。在一座建筑内，同一 VLAN 的两个端口可以通信，不同 VLAN 的两个端口则不能，因此 VLAN 编号看起来像是赋予连通性的东西。而跨过路由型隧道，并不存在可供标签描述的共享以太网段，网关之间也从不交换 VLAN 标签。

隧道真正需要的，是两段互不重叠的地址范围，以及允许二者之间流量的策略。在任一办公室更改 VLAN，隧道照常工作，因为隧道配置中没有任何内容引用它。这就是终结争论的测试：重编 VLAN，地址保持不变，观察隧道是否仍在。

反向测试同样有说服力。给两个办公室相同的子网，无论 VLAN 编号多么一致，地址也不会因此变得无歧义。

隧道实际承载的是什么

IPsec 依据以地址、协议和端口表达的策略来保护 IP 数据包。 IPsec 架构 在 IP 层描述这些选择器，而 IP 层比交换机标签所描述的任何东西都高出好几层。数据包进入隧道时已经离开了 VLAN；标签已被本地交换机消耗掉。

基于策略和基于路由的设计，区别在于如何选择隧道，而不在于能承载什么。基于策略的对端匹配流量选择器，并把匹配的数据包送入隧道。基于路由的对端在隧道接口上路由流量，由路由表决定去向。两者仍然要协商保护范围，因此指向隧道的路由不会扩大对端已同意保护的范围。

这一区别解释了常见的半程失败：路由存在，数据包进入隧道，远端却将其丢弃，因为协商出的选择器从未包含该前缀。读取已安装的策略可以看出实际生效的范围。

ip xfrm policy
ip route show
swanctl --list-sas

真正会出问题的重叠

子网不同的两个办公室可以干净地通过隧道路由，它们的 VLAN 编号无关紧要。子网相同的两个办公室则不行，因为对某个地址的请求有两种可能含义，而路由表只能选一个。给其中一个站点重编地址是干净的解决办法，算上 DNS 和防火墙改动后，通常比替代方案更便宜。

当重编地址不可行时，刻意设计的地址转换可以给两侧呈现不同的地址视图。这意味着一对一映射、匹配的选择器、反映转换视图的 DNS 记录，以及能在改写后存活的回程路由。这是有实际运维成本的受支持设计，而不是更改 VLAN ID 能做到的事。

两端使用相同的 VLAN 编号，有时只是共享模板带来的巧合；把这种巧合当成隧道可用的原因，等到后来出问题时就会做出错误的改动。

每层只做一件事，并写下来

本地交换机决定哪些端口共享一个广播域，它的 VLAN 编号是本地账目，其他站点无需知道。网关认证对端并执行协商好的保护范围。路由表决定解密后的数据包下一步去向，访问策略决定该数据包是否本就应当放行。

把这些工作分开，才能让变更安全。在一个办公室重编 VLAN 只触及本地交换机、DHCP 范围，也许还有防火墙区域，不会触及隧道。更改前缀则触及隧道选择器、两侧路由和访问策略，不会触及交换机标签。

回程路由、私有 DNS 和应用身份要求又是独立的工作，没有一项可以通过照搬另一站点的 VLAN 编号获得。列出可达前缀和允许服务的设计文档能经受交换机更换；只列 VLAN 编号的文档则不能。

在假定标签能到达隧道之前，先用网桥工具确认本地情况。

bridge vlan show
ip -br addr
ip route get 10.62.0.20

当 layer-2 扩展才是真正需求时

有些设计确实需要站间以太网行为：依赖广播发现的旧应用、要求机器迁移时保留地址的搬迁，或内嵌 layer-2 假设的协议。这类情况需要承载帧的覆盖网络或桥接服务，此时 VLAN 成员关系、环路防护和故障处理都变成端到端的问题。

那是大得多的故障域，应当是刻意选择，而不是为了让文件共享能用而意外造成的结果。普通文件服务器、数据库或 Web 应用需要的是一条被授权的 IP 路径，底下没有拉伸的广播域，它会过得更舒服。

把 VPN 契约写成可达前缀加允许服务，只在本地运维需要的地方记录 VLAN 标签。这样每个办公室都能重编自己的交换，而不必把每次变更变成隧道重设计。