Open-Box｜科学之家 kexuezj.com
Open-Box · 科学之家
liandu2024Open-Box 核心作者
GitHub·2026.09.21 10:03:29（UTC+8）

Open-Box：ESXi 下虚拟终端需允许 MAC 更改与伪传输

liandu2024 说明模拟终端用 veth+netns；ESXi 端口组需允许 MAC 更改与伪传输，混杂模式非必需。Open-Box 不改 bridge-nf-call-iptables；该值为 1 时桥内二层也会进 netfilter。

作者原文@liandu2024

分开说这两件事。

1. 虚拟终端在 ESXi 下建不起来

这个是 ESXi 的安全策略挡的,不是 bug。「规则」页的模拟终端测试会建一对 veth(obprobe0 挂进 br-lan,obprobe1 放进独立网络命名空间),给它一个自己的 MAC,然后在里面跑 udhcpc 去问主路由要地址 —— 相当于临时插了一台新终端。

ESXi 的 vSwitch / 端口组默认:

  • MAC 地址更改:拒绝
  • 伪传输(Forged transmits):拒绝

这两项任一为"拒绝",虚拟机发出来的、源 MAC 不等于网卡自身 MAC 的帧都会被 vSwitch 丢掉 —— obprobe0 的 DHCP 请求正好就是这种帧,所以必然 udhcpc: no lease。要跑这个测试,需要在对应端口组上把 MAC 地址更改 和 伪传输 改成"接受"(混杂模式不是必需的,我们不抓包)。

这只影响「规则」页的这一个测试功能,不影响正常分流和代理。

2. bridge-nf-call-iptables=1 时同网段间歇断网

Open-Box 不会动这个 sysctl(代码里没有任何地方设置它),所以这是固件默认或别的软件打开的。

它打开之后,桥内的二层转发流量也会走一遍 netfilter,于是同网段设备之间本不该进内核的流量也会被内核的重定向链看到 —— 旁路由 + 同网段的场景下这正是断网的来源。建议保持 0:

sysctl -w net.bridge.bridge-nf-call-iptables=0

如果因为别的组件必须打开它,可以在「终端分流」里把受影响的设备设成「不进内核」,那些设备的流量会在进内核前就被放行。

麻烦你按第 1 条放开端口组策略再试一次虚拟终端,第 2 条确认一下 sysctl 关掉后断网是否消失,结果贴出来我再跟进。