nftables記録された動的に塗りつぶされたコレクションをサポートします。nftables wiki。 Wikiページの最初の例は次のとおりです。
table ip my_filter_table {
set my_ssh_meter {
type ipv4_addr
size 65535
flags dynamic
}
chain my_input_chain {
type filter hook input priority filter; policy accept;
tcp dport 22 ct state new add @my_ssh_meter { ip saddr limit rate 10/second } accept
}
}
nftables上記の構成を説明すると、次のようになります。
この例では、送信元IPアドレスあたり1秒あたり10の接続にトラフィック速度を制限するためにmy_ssh_meterというダイナセットを使用する新しいTCP SSH（ポート22）接続を一致させるルールを作成します。
このルールをどのように解釈または理解するのですか？つまり、Linux接続追跡サブシステムでTCP宛先ポート22（）への新しい接続（）を見つけると、データを含むソースIPアドレス（ip saddr）がlimit rate 10/second名前付きセットに追加されます。ところでこのセットは一度も使用されたことがないようですが？コレクションを埋めるときに何が起こりましたか？my_ssh_meterct state newtcp dport 22my_ssh_meteraccept
ベストアンサー1
何が起こったのか:
新しいSSH接続が到着すると、そのソースに関連付けられたメーターがセットに追加され（存在しない場合はセットであるため、各要素は一度だけ表示されます）、ブール結果のtrue / falseを提供するように評価されます。
true と評価された場合、ルールは続行でき、そうでない場合はルールは停止します。
注：接続されている楽器がない場合、要素の追加は常にtrueと評価されます。コレクションに追加することは最終的ではありません。
ここで：
trueと評価された場合（フラッディングされていない場合）、ルールは
accept現在の入力フック（例chain my_input_chain：）評価を終了します。false と評価されると、ルールは
accept最終ステートメントの前に終了します。- 次のルールに進むか、ルールがない場合
- 基本的なチェーン戦略を使用します。
accept
したがって、何が起こっても新しい接続パケットは常に許可されます。このルールセットは、ルールセットを埋める以外に目立つ効果はありません。
Wikiのルールセットの例は不完全です。同じ条件で、次のように（または）が来る必要がありますdrop（一部の規則の分解はもちろん可能です）。reject
% nft add rule ip my_filter_table my_input_chain tcp dport 22 ct state new drop
したがって、指標がオーバーフローすると、前のacceptルールの最後の部分は評価されず、次のルールから着信接続が削除されます。試行が行われるたびに、インジケータのトークンバケットで計算されます。したがって、継続的に早すぎると、新しい接続がまったくない可能性があります（デフォルトのトークンバケットバーストは5で、最初の接続はすぐにフラッディングされても常に成功します）。
ここで知っておくべき重要な点は、他の多くの声明と同様に置く氏名（特殊構文は@置く）両方とも変更を加えたアクションを実行し（コレクションに要素を追加します）、ブール結果（trueまたはfalse）を持ち、これは追加の評価ルールの残りの部分によって異なります。両方の役割が同時に使用されます。
テストするには、or10/secondに置き換えます。これで動作がより明確になります（5番目の接続以降：デフォルトでは）。10/minute10/hourlimitトークンバケットは5つのパケットバーストを許可します。 )