nftables：特定のフックに対してさまざまな種類のチェーンが評価されますか？

長い話を短く

トラフィックを受信して​​それをNATするネットワークネームスペースを試してみると、チェーンで指定された優先順位に関係なく、フィルタチェーンの優先順位は重要ではないことがわかりますtype nat hook prerouting。 NATは常に正しいパス前のフック優先順位で終わります。 - 別名100 NF_IP_PRI_NAT_DSTNATチェーン自体間の優先順位が維持されます。

.hookパケットの通過中に実際に実行されるアクションの定義の項目を見てみましたが、チェーン登録時に異なる動作を導入するNATフックに対してのみ定義された.ops_register/項目を無視しました。.ops_unregister

カーネル6.5.xの使用とnftables1.0.9、いくつかのリンクを提供https://elixir.bootlin.com/現在、最新のLTSカーネルを使用しており、パッチバージョンはありません：6.1（6.1.xではありません）。

結論として：

• NATは特別なフック優先順位で動作し、次のような他のフックタイプとも機能します。フィルターまたは路線：NATチェーンは他のチェーンとは異なって登録されます。指定された優先順位は、同じ場所に接続されている異なるNATチェーン間で引き続き適用されます。

• 路線次の一般的な優先順位に従ってください。フィルター（特別な登録は必要ありません。）

• NF_IP_PRI_NAT_DST他の場所（または他のさまざまなNAT関連の正確な値）で正確な優先順位を使用しないでください。nftablesNetfilterのNATフックは決定的ではなく定義されない場合があります（たとえば、生成順序によって変更されたり、動作がカーネルバージョンによって変更される可能性があります）。たとえば、DNATの前に-101以下を使用し、DNATの後に-99以上を使用しますが、未定義の動作を防ぐために-100を使用しないでください。

• 他の特別施設の優先順位にも同じ注意事項が適用されます。そこ、またはNF_IP_PRI_CONNTRACK_DEFRAG等NF_IP_PRI_CONNTRACK（そしてiptables対話時の優先順位iptablesルールに従い、決定的な結果が必要です）。

---

実験

家族のような場合は控えておきますinet。十分なルールセットとテストケースを使用すると、同じように機能することを確認できます。

ルールセットの例（loadを使用nft -f ...）：

table t         # for idempotence
delete table t  # for idempotence

table t {
    chain pf1 {
        type filter hook prerouting priority -250; policy accept;

    udp dport 5555 meta nftrace set 1 counter
    }

    chain pf2 {
        type filter hook prerouting priority -101; policy accept;

    udp dport 5555 counter accept
    udp dport 6666 counter accept
    }

    chain pf3 {
        type filter hook prerouting priority -99; policy accept;

    udp dport 5555 counter accept
    udp dport 6666 counter accept
    }

    chain pn1 {
        type nat hook prerouting priority -160; policy accept;

        counter
    }

    chain pn2 {
        type nat hook prerouting priority 180; policy accept;

        udp dport 5555 counter dnat to :6666
    }

    chain pn3 {
        type nat hook prerouting priority -190; policy accept;

        counter
    }

    chain pn4 {
        type nat hook prerouting priority 190; policy accept;

        udp dport 5555 counter dnat to :7777
        udp dport 6666 counter dnat to :7777
    }

}

このルールセットは、受信したUDPポート5555をpn2。このテストに使用したUDPポート6666（接続できないICMPターゲットポートによってストリームが削除されない）に受信アプリケーションがあり（対話的に）pn1pn3pn4pn4socat UDP4-LISTEN:6666,fork EXEC:date離れてクライアントの使用socat UDP4:192.0.2.2:5555 -。

pn2優先順位が180のNATチェーンがDNATを実行すると考えることができます。後ろに優先順位が-99のフィルタチェーンpf3。ただし、type nat他の種類ではこれは発生しません。 NATは特別です。次のように使用してくださいnft monitor trace。

# nft monitor trace
trace id 4ab9ba62 ip t pf1 packet: iif "lan0" ether saddr 8e:3e:82:1a:dc:87 ether daddr fa:2f:7e:2d:f1:03 ip saddr 192.0.2.1 ip daddr 192.0.2.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 49393 ip length 30 udp sport 58201 udp dport 5555 udp length 10 @th,64,16 0x610a
trace id 4ab9ba62 ip t pf1 rule udp dport 5555 meta nftrace set 1 counter packets 0 bytes 0 (verdict continue)
trace id 4ab9ba62 ip t pf1 verdict continue
trace id 4ab9ba62 ip t pf1 policy accept
trace id 4ab9ba62 ip t pf2 packet: iif "lan0" ether saddr 8e:3e:82:1a:dc:87 ether daddr fa:2f:7e:2d:f1:03 ip saddr 192.0.2.1 ip daddr 192.0.2.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 49393 ip length 30 udp sport 58201 udp dport 5555 udp length 10 @th,64,16 0x610a
trace id 4ab9ba62 ip t pf2 rule udp dport 5555 counter packets 0 bytes 0 accept (verdict accept)
trace id 4ab9ba62 ip t pn3 packet: iif "lan0" ether saddr 8e:3e:82:1a:dc:87 ether daddr fa:2f:7e:2d:f1:03 ip saddr 192.0.2.1 ip daddr 192.0.2.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 49393 ip length 30 udp sport 58201 udp dport 5555 udp length 10 @th,64,16 0x610a
trace id 4ab9ba62 ip t pn3 rule counter packets 0 bytes 0 (verdict continue)
trace id 4ab9ba62 ip t pn3 verdict continue
trace id 4ab9ba62 ip t pn3 policy accept
trace id 4ab9ba62 ip t pn1 packet: iif "lan0" ether saddr 8e:3e:82:1a:dc:87 ether daddr fa:2f:7e:2d:f1:03 ip saddr 192.0.2.1 ip daddr 192.0.2.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 49393 ip length 30 udp sport 58201 udp dport 5555 udp length 10 @th,64,16 0x610a
trace id 4ab9ba62 ip t pn1 rule counter packets 0 bytes 0 (verdict continue)
trace id 4ab9ba62 ip t pn1 verdict continue
trace id 4ab9ba62 ip t pn1 policy accept
trace id 4ab9ba62 ip t pn2 packet: iif "lan0" ether saddr 8e:3e:82:1a:dc:87 ether daddr fa:2f:7e:2d:f1:03 ip saddr 192.0.2.1 ip daddr 192.0.2.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 49393 ip length 30 udp sport 58201 udp dport 5555 udp length 10 @th,64,16 0x610a
trace id 4ab9ba62 ip t pn2 rule udp dport 5555 counter packets 0 bytes 0 dnat to :6666 (verdict accept)
trace id 4ab9ba62 ip t pf3 packet: iif "lan0" ether saddr 8e:3e:82:1a:dc:87 ether daddr fa:2f:7e:2d:f1:03 ip saddr 192.0.2.1 ip daddr 192.0.2.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 49393 ip length 30 udp sport 58201 udp dport 6666 udp length 10 @th,64,16 0x610a
trace id 4ab9ba62 ip t pf3 rule udp dport 6666 counter packets 0 bytes 0 accept (verdict accept)

trace id 46ad0497 ip t pf1 packet: iif "lan0" ether saddr 8e:3e:82:1a:dc:87 ether daddr fa:2f:7e:2d:f1:03 ip saddr 192.0.2.1 ip daddr 192.0.2.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 49394 ip length 30 udp sport 58201 udp dport 5555 udp length 10 @th,64,16 0x620a
trace id 46ad0497 ip t pf1 rule udp dport 5555 meta nftrace set 1 counter packets 0 bytes 0 (verdict continue)
trace id 46ad0497 ip t pf1 verdict continue
trace id 46ad0497 ip t pf1 policy accept
trace id 46ad0497 ip t pf2 packet: iif "lan0" ether saddr 8e:3e:82:1a:dc:87 ether daddr fa:2f:7e:2d:f1:03 ip saddr 192.0.2.1 ip daddr 192.0.2.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 49394 ip length 30 udp sport 58201 udp dport 5555 udp length 10 @th,64,16 0x620a
trace id 46ad0497 ip t pf2 rule udp dport 5555 counter packets 0 bytes 0 accept (verdict accept)
trace id 46ad0497 ip t pf3 packet: iif "lan0" ether saddr 8e:3e:82:1a:dc:87 ether daddr fa:2f:7e:2d:f1:03 ip saddr 192.0.2.1 ip daddr 192.0.2.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 49394 ip length 30 udp sport 58201 udp dport 6666 udp length 10 @th,64,16 0x620a
trace id 46ad0497 ip t pf3 rule udp dport 6666 counter packets 0 bytes 0 accept (verdict accept)
^C

すべての事前ルーティングされたNATフックがpf2、pf3Wa間、つまり優先順位-101と-99の間で発生し、優先順位-100、つまり優先順位で発生することがわかります。NF_IP_PRI_NAT_DSTNetfilterの自己構造で使用static const struct nf_hook_ops nf_nat_ipv4_ops[]。チェーンにはip t pf35555の代わりにポート6666が表示されます。

NATステートメントが適用されている場合、Netfilterは（同じフックで）次のルールをスキップするため、pn4上記の例ではここをまったく通過する機会はありません（同じフローの2つのパケットのみが最初にポート5555に到着します）。表示される：この動作は、type filter次のフックの位置を続けてナビゲートすることとも異なります（たとえば、それ以降のナビゲーションpf3中などpf2）。

通常のように、ストリームの次のパケットはNATチェーンをトリガしなくなりました。新しいストリーム（conntrackステータスNEW）を生成するパケットだけがNATチェーンに送信されるため、次のパケットはチェーンを通過するようには見えなくなりますpnX。事前にルーティングされた4つのNATチェーン間で優先順位が尊重されます。優先順位はpn3（-190）、pn1（-160）、pn2（180）です（これは（190）ですが、pn4機会はありません）。

注：同じ実行でパケット/バイトカウンタが増加していないように見えるという事実は、バグや欠けているnft monitor trace機能のように見えます（確認すると増加していましたnft list ruleset）。

type natフックを使う他の基本機能とは異なる登録機能nftablesフックしたがって、さまざまな方法で処理できます。

.ops_register = nf_nat_ipv4_register_fn,
.ops_unregister = nf_nat_ipv4_unregister_fn,

NAT（Netfilterで管理）によって処理されフックされます。NF_INET_PRE_ROUTING（まだNetfilterから提供）nftables）この作業が最初に行われますNF_IP_PRI_NAT_DST。

これではないタイプフィルタ（いいえ路線）その後、一般を使用しますnftables代わりに方法指定されたもの。