虚拟 pfSense TAP 网桥：帧可能阵亡的三个位置

你在 LAN 接口上禁用一条规则，帧依然消失，于是结论成了 pfSense 在无视自己的防火墙。通常发生的情况是，另一位所有者做了决定：网桥本身、成员接口，或者客户机之外的虚拟交换机。每个都有自己的控制和自己的日志。

在改动任何设置之前，下面这三道边界值得分开看，因为关掉一个并不能补偿另一个。

一个帧，三个策略所有者

来自 TAP 客户端的帧经隧道设备进入，穿过 pfSense 网桥，从某个 LAN 成员出去，然后在到达任何东西之前还要经过一台虚拟交换机。在客户机内部，过滤可能发生在网桥上，也可能发生在成员接口上；哪一处生效是配置选择，而不是固定属性。在客户机之外，虚拟机监控程序决定那块虚拟网卡是否可以发送源 MAC 并不属于它的帧。在上述任何一点被丢弃，从客户端看都是一样的。

调查之前先把预期路径写下来：隧道成员、网桥、LAN 成员、虚拟交换机、目的地。然后追问，这条路径上哪位所有者会看到这个帧。

是哪个 pfSense 控制在过滤

pfSense 为此记录了两个 sysctl，一个用于在网桥成员上过滤，一个用于在网桥本身上过滤，并且至少有一个必须保持开启。网桥层级的过滤作用于经由网桥成员到达的流量，所以它在方向上是入站，而不是对称的。要在真正执行过滤的那个接口上读规则，因为写在没有任何过滤角色的成员上的规则完全不起作用。 网桥过滤的文档讲清了归属。

没有 IP 地址的成员接口没有自己的地址或子网宏，所以对着那个宏写的规则，描述的可能是别的网段而不是你以为的 LAN。请使用刻意指定的网络对象，而不是图省事的宏。

分片不是帧

以太网帧承载 IP 包，而一个 IP 包可以是更大数据报的分片，所以这两个词不能互换。隧道内部有内层包，隧道外部有外层传输包，故障可能属于其中任何一个。一次小 ping 只走过那条协议栈上的一条路径，完全证明不了大流量传输。 在两个相邻边界上对比失败的那次交换，并在怪罪某条规则之前先读丢弃原因。

如果分片消失，答案是限定范围的修正或者对包大小的调查，而不是干脆把过滤整体关掉。

虚拟机监控程序有自己的准入决定

为其他机器桥接流量的客户机会发出源 MAC 地址不属于自己网卡的帧，很多虚拟交换机将其视为欺骗，除非端口组允许。允许这种发送，和允许网卡接收每一个帧，是两项彼此独立的控制；到处把两者都打开，远比问题所需的变化大。先弄清网桥必须接收哪些帧、必须发出哪些帧，然后只在拥有该职责的边界上授予这一行为。在改动一台远程管理的网桥之前，先保住控制台访问。

恢复连通性只是测试的一半；另一半是确认本该保持阻断的流仍然被阻断。

记录下是哪个所有者做了过滤、改了哪个控制，以及你验证了哪两条流。这份记录能让下一次事故不再从同一个猜测开始，即 pfSense 在无视自己。