☰

マルチキャストICMPv6が返され、conntrackステータスが無効です。

tag-icon • tag-icon ipv6 netfilter multicast nftables ip-conntrack
マルチキャストICMPv6が返され、conntrackステータスが無効です。

私はIPv6のマルチキャスト機能を研究しています。

$ ping ff02::2%wlp3s0

これにより、通常、ローカルネットワークセグメントのすべてのルータがエコー応答（ウィキペディア-IPv6）。私の場合はホームルーターです。

しかし、もともとnftablesルールがエコー応答をブロックしていることがわかりました。

生の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唯一の違いは、前と後の1回であることを自分で知ることができますip6 nexthdr ipv6-icmp accept。

したがって、ペアに対するエコー応答ping ff02::2%wlp3s0はct state invalid。

私の質問

エコー応答のct状態は私のエコー要求の直接的な結果であるため、「接続済み」または「設定済み」にする必要はありませんか？

そうでない場合、ping 2001:470:20::2どちらの場合も「通常の」ユニキャストping（）が機能するのはなぜですか？

関連情報