☰

多播 ICMPv6 返回，conntrack 状态无效

tag-icon • tag-icon ipv6 netfilter multicast nftables ip-conntrack
多播 ICMPv6 返回，conntrack 状态无效

我正在研究 IPv6 的组播功能。

$ ping ff02::2%wlp3s0

这通常会导致本地网段上的所有路由器发出回显应答（维基百科 - IPv6）。以我为例，我的家庭路由器。

然而，我发现我原来的 nftables 规则阻止了 echo-r​​eplies：

原始 nftables 规则阻止回显回复

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iifname "lo" accept
        ct state { established, related } accept
        ct state invalid drop
        ip protocol icmp accept
        ip6 nexthdr ipv6-icmp accept        
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

通过此设置，没有回复。

$ ping ff02::2%wlp3s0
PING ff02::2%wlp3s0(ff02::2%wlp3s0) 56 data bytes

修复了允许回显回复的 nftables 规则

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iifname "lo" accept
        ct state { established, related } accept
        ip protocol icmp accept
        ip6 nexthdr ipv6-icmp accept
        ct state invalid drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

通过这个设置，它起作用了：

$ ping ff02::2%wlp3s0
PING ff02::2%wlp3s0(ff02::2%wlp3s0) 56 data bytes
64 bytes from fe80::----:----:----:----%wlp3s0: icmp_seq=1 ttl=64 time=1.82 ms

CT状态无效是罪魁祸首

您可能自己发现，唯一的区别是一次ct state invalid drop在之前ip6 nexthdr ipv6-icmp accept和之后一次。

因此，对的回显答复ping ff02::2%wlp3s0似乎具有ct state invalid. （我什至用更具体的规则和日志记录来检查这一点以确保）

我的问题

难道回声应答的 ct 状态不应该是“相关的”或“已建立的”吗，因为它是我的回声请求的直接结果？

如果不是：为什么“正常”单播 ping ( ping 2001:470:20::2) 在这两种情况下都有效？

相关内容