设置：
VM1 --- 桥 -- VM2
VM1 和 2 位于同一子网中。网桥有 2 个接口添加到 brctl 网桥。当我使用 uptables -A FORWARD -s (VM1 ip) -j DENY 阻止 VM2 ip 时，它不起作用。我知道数据包永远不会进入网络层，但是这说“当 IP 数据包位于桥代码中时，将遍历所有 iptables 链”。甚至 MAC 过滤在 iptables 上也不起作用。 ebtables 工作正常。怎么了？
答案1
Linux 的桥接过滤器框架具有可用的机制，其中第 2 层桥接代码可以对iptables（以及arptables或ip6tables）进行上行调用，并过滤从第 2 层（桥接帧）到第 3 层（iptables带有数据包）的传输，然后返回第 2 层。这远远超出了使用BROUTING链的范围，链只给出了停留在第 2 层或继续在第 3 层的逻辑选择（通过将帧dnat/发送broute到本地）。
例如，这种分层违规允许利用该conntrack设施并在第 2 层提供可用的状态防火墙。
当人们没有预料到会发生这种情况并且出现难以调试的问题时，或者在（大多数时候）不需要时阻碍性能时，它也会造成麻烦。所以从内核 3.18 开始，br_netfilter 代码从网桥代码中分离出来并模块化并且不再自动加载。
现在要通过 iptables 使用此功能，一不得不modprobe br_netfilter并将 sysconf 参数net.bridge.bridge-nf-call-iptables设置为1（相当于echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables）。现在这将允许OP链接的所有奇妙的复杂性：基于 Linux 的桥上的 ebtables/iptables 交互。注意，当 iptables 使用physdevebtables) 匹配，如果同时使用和时不小心，这可能会巧妙地改变整个防火墙的行为iptables。
注意：nftables(以及iptables-nft) 也会受到影响。当前状态被认为有点混乱（因为分层违规的额外复杂性），并且进行了一些重组以直接连线支持桥接路径，不再使用br_netfilter：自内核 5.3 Linux 提供内核模块nf_conntrack_bridge允许nftables直接在桥接层处理连接跟踪，而无需到达ip（也不ip6和内网） 家庭：桥接器的连接跟踪支持。