iptables不能拦截ARP响应，因其属数据链路层协议，不经过IP协议栈和netfilter链；必须用ebtables在桥接路径上匹配vnet0→eth0的ARP reply帧，并设默认策略DROP防绕过。
为什么不能用 iptables 拦虚拟机发的 ARP 响应
因为 iptables 根本看不到这些包——ARP 是二层协议，不经过 IP 协议栈，网桥转发时直接走 br_forward 路径，iptables 的 INPUT/FORWARD 链完全不触发。你在 iptables -A FORWARD -p arp -j DROP 里写的规则压根不会匹配，内核甚至会报错 unknown protocol arp。
必须用 ebtables 的 FORWARD 链匹配出方向 ARP 帧
ebtables 工作在桥接路径上，能真实捕获从虚拟机口（如 vnet0）发出、经网桥 br0 转发到物理口（如 eth0）的以太网帧。关键是要锁定“虚拟机主动发的 ARP 响应”，而不是请求：
-
-p arp匹配所有 ARP 帧（必须） -
--arp-opcode reply只抓响应（opcode=2），排除请求干扰 -
-o eth0表示“要发往物理网络”，这是非信任出口的典型特征 -
-i vnet0明确来源是虚拟机接口（防止规则误伤其他桥口）
完整命令示例：
ebtables -A FORWARD -i vnet0 -o eth0 -p arp --arp-opcode reply -j DROP
这条规则会丢弃所有从 vnet0 发出、目标为 eth0 的 ARP 响应帧，有效阻止虚拟机冒充网关或服务器回复 ARP。
容易漏掉的两个关键点：默认策略和规则顺序
默认 ebtables 的 FORWARD 链策略是 ACCEPT，意味着没被显式匹配的帧全放行。如果你只加了上面那条 DROP 规则但没设默认策略，攻击者只要换 opcode 或改目的口就能绕过。
- 务必在最后加一条兜底：
ebtables -P FORWARD DROP - 但要注意：这条必须放在所有
ACCEPT规则之后，否则合法流量（如 DHCP、正常 ARP 请求）会被提前拦截 - 检查顺序用：
ebtables -L FORWARD --Lc，看计数器是否递增
另外，ebtables 不支持像 iptables 那样的连接状态跟踪（--state ESTABLISHED），所有判断只能基于帧头字段，所以 --arp-opcode 和接口方向是唯一可靠依据。
验证是否生效：别只信 ping，要看实际帧
ping 成功不代表 ARP 安全——虚拟机可能已缓存了网关 MAC，后续通信走的是已建立的二层连接。真正要确认，得抓桥上的原始帧：
- 在宿主机上运行：
tcpdump -i br0 -nn -e arp - 触发虚拟机发 ARP 响应（比如它刚获取到 IP 后广播一次，或你手动
arping -U） - 观察输出里是否还有来自
vnet0MAC、opcode 2、dst 是网关 IP 的帧
如果规则生效，这类帧将彻底消失；若仍可见，大概率是接口名写错（比如用了 virbr0 而不是实际桥名）、或者内核没开启 CONFIG_BRIDGE_NETFILTER（需检查 zcat /proc/config.gz | grep BRIDGE_NETFILTER）。
