liandu2024：Open-Box 虚拟终端在 ESXi 下需放行 MAC 更改与伪传输
liandu2024 在 Open-Box #207 中说明，模拟终端测试会以 veth 和独立网络命名空间模拟新终端；ESXi 端口组需要允许“MAC 地址更改”和“伪传输”，混杂模式并非必需。其同时表示 Open-Box 不会修改 bridge-nf-call-iptables；该值为 1 时，桥内二层流量也会进入 netfilter，在旁路由同网段场景被重定向链处理，建议保持为 0，或将受影响设备设为“不进内核”。
作者原文@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 关掉后断网是否消失,结果贴出来我再跟进。