☰

nftables 忽略应该匹配的内容，nftables 日志显示无意义的帧，tcpdump 显示预期的帧

tag-icon • tag-icon linux linux-networking kvm-virtualization linux-kernel nftables
nftables 忽略应该匹配的内容，nftables 日志显示无意义的帧，tcpdump 显示预期的帧

编辑：找到解决方案。综合和验证后将发布。

在发现了 nftables 的一些令人费解的行为后，我希望能得到一些社区的见解。

在 QEMU-KVM 客户机中使用以下规则集时，链中的以太网帧arp-出主机-wan0nftables 应该接受的帧无法识别。据我所知，内部 nftables 日志记录显示这些帧毫无意义，而 VM 客户机 tcpdump 和 VM 主机 Wireshark 验证这些帧符合预期。

table arp filter {
    chain input {
        type filter hook input priority filter; policy drop;
        iifname "enp1s0" counter packets 5 bytes 140 jump arp-in-host-wan0
        log prefix "nft: arp->input dropped: " flags all limit rate 3/second
        counter packets 0 bytes 0
    }

    chain output {
        type filter hook output priority filter; policy drop;
        oifname "enp1s0" counter packets 5 bytes 210 jump arp-out-host-wan0
        log prefix "nft: arp->output dropped: " flags all limit rate 3/second
        counter packets 0 bytes 0
    }

    chain arp-in-host-wan0 {
        ether daddr 52:54:00:ee:10:e6 limit rate 3/second counter packets 5 bytes 140 accept
        ether daddr ff:ff:ff:ff:ff:ff limit rate 3/second counter packets 0 bytes 0 accept
        counter packets 0 bytes 0 return
    }

    chain arp-out-host-wan0 {
                
        ### Broken rule not matching frames that should match
        ether saddr 52:54:00:ee:10:e6 limit rate 3/second counter packets 0 bytes 0 accept
                
        ### Wildcard rule to log non-matching frames in chain
        log prefix "nft: arp->output ALLOWED: " flags all

        ### Wildcard rule to let non-matching traffic pass
        counter packets 5 bytes 210 accept

        counter packets 0 bytes 0 return
    }
}

QEMU-KVM 客户机（journalctl -k），由上述 nftables 通配符规则捕获的流量（看似无意义，请注意非标准的 EthrType、ARP HTYPE、ARP PTYPE、ARP OPCODE）： 在此处输入图片描述

QEMU-KVM 客户机（tcpdump arp -vlenx），相同的流量被正确识别： 在此处输入图片描述

QEMU-KVM主机（从相关桥接设备捕获的Wireshark），相同的流量被正确识别： 在此处输入图片描述

QEMU-KVM 客户信息： 在此处输入图片描述

我很想了解这里发生了什么。如果我可以提供任何其他信息，请告诉我 - 谢谢！

更新 1：使用 NFLOG（语法“日志组”）记录时会观察到相同的行为。

Frame 1: 76 bytes on wire (608 bits), 76 bytes captured (608 bits) on interface nflog:30, id 0
    Interface id: 0 (nflog:30)
        Interface name: nflog:30
    Encapsulation type: NFLOG (141)
    Arrival Time: Jun 28, 2022 09:18:44.633102000 CDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1656425924.633102000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 76 bytes (608 bits)
    Capture Length: 76 bytes (608 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: nflog:arp]
Linux Netfilter NFLOG
    Family: ARP (3)
    Version: 0
    Resource id: 30
    TLV Type: NFULA_PACKET_HDR (1), Length: 8
        Length: 8
        .000 0000 0000 0001 = Type: NFULA_PACKET_HDR (1)
        HW protocol: ARP (0x0806)
        Netfilter hook: Local in (1)
    TLV Type: NFULA_PREFIX (10), Length: 5
        Length: 5
        .000 0000 0000 1010 = Type: NFULA_PREFIX (10)
        Prefix: 
    TLV Type: NFULA_IFINDEX_OUTDEV (5), Length: 8
        Length: 8
        .000 0000 0000 0101 = Type: NFULA_IFINDEX_OUTDEV (5)
        IFINDEX_OUTDEV: 2
    TLV Type: NFULA_PAYLOAD (9), Length: 46
        Length: 46
        .000 0000 0000 1001 = Type: NFULA_PAYLOAD (9)
Address Resolution Protocol
    Hardware type: Unknown (21076)
    Protocol type: Unknown (0x0064)
    Hardware size: 98
    Protocol size: 108
    Opcode: Unknown (21076)
[Malformed Packet: ARP/RARP]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

答案1

可能的原因是，在路由 arp 数据包之前，会遍历 arp 家族表（不确定这样说是否正确，但关键是 arp 数据包的源地址以太网帧尚未设置）。

匹配以太网源地址ARP 数据包，你应该匹配arp saddr ether而不是ether saddr进行匹配。（对于入站流量，您可能甚至想检查以太网帧头和 ARP 数据包头中的地址。

相关内容