在与 qemu 客人玩耍时，我发现了一些非常奇怪的东西。如果我将系统防火墙设置为拒绝所有到我的网关的流量 ( 10.0.2.2)，防火墙只会拒绝直接发往网关的流量。并非注定要10.0.2.2到达的流量似乎继续路由并流经网关，就好像规则根本不存在一样。
我从客人的角度理解它（10.0.2.15）：
Packet{dest==10.0.2.0/24} 10.0.2.15 -x-> 10.0.2.2 (Rejected)
Packet{dest!=10.0.2.0/24} 10.0.2.15 <--> 10.0.2.2 <-> !=10.0.2.0/24 (Okay)
这与我的预期完全相反。我认为我缺少一些东西，但我不知道是什么。
这是我的设置：
- 防火墙规则：
ufw reject out to 10.0.2.0/24 - 输出
ip route：default via 10.0.2.2 dev ens3 proto dhcp metric 100 10.0.2.0/24 dev ens3 proto kernel scope link src 10.0.2.15 metric 100 - 的输出的相关部分
iptables -S似乎是：-A ufw-user-output -d 10.0.2.0/24 -j REJECT --reject-with icmp-port-unreachable
这是有效的并且没有被阻止，因为网关使用不是网关地址的源和目标 IP 地址路由数据包。没有地址为 10.0.2.2 的IPv4数据包（参见后面的 ARP）用于成功地通过 IP 地址为 10.0.2.2/24 的网关路由。
因此，当 10.0.2.15 向 8.8.8.8 发送数据包时，该数据包的源地址为 10.0.2.15，目标地址为 8.8.8.8。此数据包没有目的地 10.0.2.2，因此在 10.0.2.0/24 内没有目的地：通过。
与通过网关的路由间接相关的有效负载中唯一具有 IPv4 地址 10.0.2.2 的数据包不是 IPv4 数据包。它们是虚拟机系统用来发现（并在其 ARP 表中缓存）网关接口的以太网 MAC 地址的ARP数据包。“外部”的 IPv4 流量：将路由与网关匹配，然后在链路层（以太网）发送到此 MAC 地址（而不是 IP 地址 10.0.2.2）。
ARP不被UFW后端的iptables过滤，所以不能被UFW拦截。例如，它可能与arptables一起使用，但有用的用例并不常见。
笔记
DHCP (IPv4)
如果 10.0.2.2 也是 VM 的 DHCP 服务器，这可能会或不会（取决于所使用的确切技术）在某些时候阻止 DHCP 通信正常工作或强制 VM 执行广播 DHCP DISCOVER 而不是单播DHCP 请求。如果租约可能在几小时后丢失，IP 地址和路由也会丢失，从而间接地通过路由器连接。
通常情况并非如此，因为通常 Linux 上的 DHCP 必须依赖 RAW 套接字（例如正确处理源地址 0.0.0.0），这会绕过所有iptables规则。
IPv6
由于 IPv6 的链路层解析协议不是 ARP 而是使用 ICMPv6，因此是 IPv6 的一部分并由ip6tables过滤，因此某些适用于 IPv4 的假设对 IPv6 无效。例如，不加选择地阻止 ICMPv6 通常会导致 IPv6 连接的快速丢失和通过SLAAC获取的可路由 IPv6 地址的删除，而不加选择地阻止 IPv4 的 ICMP 通常可以正常工作（除了可能的PMTUD 黑洞问题）。