ESXi 客户机 VPN：路由还是桥接，先定端口组

要么路由这些数据包，要么扩展以太网域：端口组的改动是这一选择的下游。从一个持有私有地址的应用看，两种做法的结果可能一模一样，但对 hypervisor 的要求完全不同。这就是为什么端口组总是先被放宽、设计问题后被回答，而且往往是在一次广播风暴之后。按顺序走完这些检查，在需求还含糊时就停下来，因为没有任何端口组设置能修好一个从未被选定的设计。

决定权属于服务所有者；hypervisor 配置应当执行这个决定，而不是在无意中替它做决定。

先弄清远端到底需要什么

列出远程客户端必须访问的服务及其使用的协议。如果只是若干已知网段上的 TCP 服务，路由就够了。如果确实需要 2 层邻接——依赖广播的发现、非 IP 协议、不接受网关的设备——路由无法伪造，应当尽早说明。对清单里的非 IP 条目要诚实，因为路由式设计往往正是在那里于一周后悄悄失效。

接着检查客户端地址池。路由式设计需要一段地址范围，并在远端配有明确的回程路由；桥接式设计则需要扩展后的以太网域自己承担地址分配与隔离。无论选哪种，都得有本 VM 之外的人点头。

两种设计各自对虚拟网络提出什么要求

两种设计的差别在于虚拟网络必须容忍什么，表格是最直观的呈现：

路由让广播域留在原地，并给出一个天然的位置来限制哪些服务穿过网关。桥接则移动了边界：客户端成为扩展以太网域的参与者，地址分配、隔离以及任何 2 层策略从此都落在它们身上。把选定的那一行写进变更记录。像“路由式 TUN，客户端地址池 10.90.0.0/24，核心上配回程路由”这样一句话，可以避免下一位工程师从端口组设置出发重新争论设计。

谁应当被允许看到谁的帧

在动端口组之前，先问平台所有者一个问题：这个设计是否要求本 VM 接收发往其他参与者的帧？如果答案是否，本节内容全部不适用，因为路由式 TUN 从不需要那种可见性。如果答案是是，那么 Broadcom 关于混杂模式的指南 才是真正值得读的材料：它说明了 VM 能看到 vSwitch 的多少内容，并建议把该策略限制在一个端口组内。

把它当作需求核对，而不是通行证。当桥接需求写成文字之后，只为一条专用连接打开该设置，其余地方一律保持关闭。从别的桥接示例里抄来的宽 VLAN 干道，正是没人记得删掉的那部分，而单 VLAN 设计就应当保持单 VLAN。

把哪个端口组改过、为什么改，记在写设计行的那同一个地方。正是这一配对让下一次审计成为可能。

让客户机侧的对象保持明确

在 Linux 内部，桥成员身份和地址归属是两个独立对象，把它们混为一谈就会造成那种令人困惑的“半能用”状态。地址要配在桥接口或路由式隧道上，而不是同一条路径的两端，成员端口则不要保留 IP 配置。

避免把同一个子网分别独立地放在路由式 TUN 和一张无关的以太网接口上。那种配置会产生 通往同一网段的两条路径、非对称回包，以及一个从不提及任何一条路径的 flapping 支持线程。如果客户机还托管容器或本地 hypervisor，要检查它们是否已经在向同一个上行链路桥接。一块网卡上两座桥是一种设计，而不是你希望在变更窗口里发现的意外。

用数据包路径确认，而不是 ping

验证真实路径，而不只是可达性。从客户端确认哪个源地址到达远端服务，再确认回包沿同一条路返回。在客户机上查看该具体流的转发计数，在端口组上确认没有开启超出所选设计需要的额外可见性。

最后，测试失效方向。停掉隧道或断开客户端，确认流量不会悄悄回落到一条你以为没在用的路由路径上，因为正是这种回落，让桥接式设计悄悄变成了一个不请自来的路由器。