☰

尽管防火墙规则阻止了发往该网关的所有出站流量，但为什么流量仍继续流经我的网关？

tag-icon • tag-icon routing firewall kvm qemu ufw
尽管防火墙规则阻止了发往该网关的所有出站流量，但为什么流量仍继续流经我的网关？

当我在 qemu guest 中闲逛时，我发现了一些非常奇怪的东西。如果我将系统防火墙设置为拒绝所有发往我的网关 ( 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

答案1

这是有效的并且不会被阻止，因为网关会路由源 IP 地址和目标 IP 地址的数据包不是网关的地址。不IPv4地址为 10.0.2.2 的数据包（请参阅后面关于 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 范围内没有目的地：pass。

唯一间接涉及通过网关路由的负载中具有 IPv4 地址 10.0.2.2 的数据包不是 IPv4 数据包。他们是ARPVM 系统用来发现（并在其 ARP 表中缓存）网关接口的以太网 MAC 地址的数据包。 “外部”的 IPv4 流量：将路由与网关进行匹配，然后在链路层（以太网）发送到此 MAC 地址（而不是 IP 地址 10.0.2.2）。

ARP 未被过滤iptables这是UFW的后端，所以不能被UFW屏蔽。它可能与arp表例如，但有用的用例并不常见。

笔记

  • 动态主机配置协议 (IPv4)

    如果 10.0.2.2 也是虚拟机的 DHCP 服务器，这可能会或不会（取决于所使用的具体技术）在以后的某个时刻阻止 DHCP 通信正常工作或强制虚拟机执行广播 DHCP DISCOVER 而不是单播DHCP 请求。如果租约可能在几个小时后丢失，那么 IP 地址也会丢失，从而路由，从而通过路由器间接连接。

    通常情况并非如此，因为通常 Linux 上的 DHCP 必须依赖于 RAW 套接字（例如正确处理源地址 0.0.0.0），这会绕过所有iptables规则。

  • IPv6

    由于IPv6的链路层解析协议不是ARP而是使用 ICMPv6，因此是 IPv6 的一部分并被过滤ip6表，一些对 IPv4 有效的假设对 IPv6 无效。例如，不加区别地阻止 ICMPv6 通常会导致 IPv6 连接快速丢失，并删除通过以下方式获取的可路由 IPv6 地址：SLAAC，同时不加区别地阻止 IPv4 的 ICMP 通常可以正常工作（除了可能的情况之外）PMTUD黑洞问题）。

相关内容