為什麼儘管防火牆規則阻止了所有發往它的出站流量，但流量仍繼續流經我的網關？
在與 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 黑洞問題）。