ファイアウォール on KnightLiブログ

nftables フレームワークを理解する：テーブル、チェーン、ルール、セット

Sat, 18 Apr 2026 10:31:12 +0800

nftables を学び始めると、ついコマンドの細部に入りがちです。ルールをどう追加するか、handle をどう削除するか、ポートマッチをどう書くか。もちろんコマンドは重要ですが、先にフレームワークの概念を整理しておくと、ルールの読解、問題調査、ルールセット設計がかなり楽になります。

nftables は、次のような階層構造として理解できます。

table はルール空間を分離する。
family はルールが扱うネットワークプロトコルを決める。
chain はルールがどの段階で実行されるかを決める。
rule は具体的なマッチ条件とアクションを持つ。
set、map、verdict map は重複ルールを減らし、ルールセットを保守しやすくする。

以下では、概念を階層ごとに整理します。

table：ルールの名前空間

table は nftables で最も外側にあるルールコンテナです。異なる table は互いに分離されるため、関連するルールを同じ table にまとめるのが一般的です。

たとえば、フィルタリングルール、NAT ルール、独自のテスト用ルールを分けて置けます。こうすると境界が明確になります。デバッグ時にはどのルール群を変更しているかが分かりやすく、クリーンアップ時にも無関係な内容を誤って削除しにくくなります。

table 自体はパケットを直接処理しません。実際にパケット処理に関わるのは、table の中にある chain と rule です。

family：ルールが対象にするプロトコル

table を作成するときは family を選びます。これは、その table 内のルールがどの種類のパケットに適用されるかを決めます。

代表的な family は次のように理解できます。

ip：IPv4 のみを処理する。
ip6：IPv6 のみを処理する。
inet：IPv4 と IPv6 の両方を処理する。
arp：ARP を処理する。
bridge：ブリッジ層のトラフィックを処理する。
netdev：ネットワークデバイス入口に近く、より早い段階でトラフィックを処理する用途に向く。

通常のファイアウォールルールでは、inet がよく使われます。IPv4 と IPv6 のルールを同じ table に置けるため、似た構造のルールを 2 セット維持する必要がなくなります。

chain：ルールが実行される場所

chain は rule のリストです。パケットがある hook に入ると、chain 内のルールを順番に通過します。

chain は大きく 2 種類に分けられます。

基本 chain：カーネルのネットワーク経路上の hook に接続され、パケット処理の流れから直接呼び出される。
通常 chain：hook には直接接続されず、他のルールから jump されて呼び出される。

基本 chain では、通常いくつかの重要な属性を指定します。

type：この chain の用途。たとえば filter、nat、route。
hook：接続する処理段階。たとえば prerouting、input、forward、output、postrouting。
priority：同じ hook に複数の chain があるとき、どれを先に実行するか。
policy：どのルールにもマッチしなかった場合のデフォルト動作。一般的には accept または drop。

chain を理解するうえで重要なのは、ルールは「どこに書いても同じように効く」わけではないという点です。同じルールでも、input、forward、output のどこに置くかで意味はまったく変わります。

rule：マッチ条件とアクション

rule は、nftables が実際に判断を行う場所です。通常は 2 つの部分で構成されます。

マッチ条件：送信元 IP、宛先 IP、プロトコル、ポート、インターフェイス、接続状態など。
アクション：accept、drop、reject、counter、jump、return など。

ルールは順番に評価されます。パケットが処理を終了させるアクションにマッチすると、その後ろのルールは実行されません。マッチしなければ、chain の終端またはデフォルトポリシーに到達するまで処理が続きます。

そのため、ルールの順序は重要です。より具体的なルールは、通常より広い条件のルールより前に置く必要があります。そうしないと、実行される機会がない場合があります。

set：値の集合をまとめる

多数の IP、ポート、インターフェイスをマッチしたい場合、ルールを大量に並べると保守しにくくなります。set は、同じ型の値をひとまとめに管理するための仕組みです。

たとえば、信頼する IP の集合、拒否したいポートの集合、帯域制限したいアドレスの集合を set に入れられます。ルール側では、ある値がその set に含まれるかどうかだけを判定すれば済みます。

set の利点は次のとおりです。

ルール数を減らせる。
可読性が上がる。
後から要素を追加・削除しやすい。

ルールの中に同じような条件が大量に出てくる場合は、set の利用を検討するタイミングです。

map：マッチした値を結果に変換する

map は「参照表」として理解できます。入力値に応じて結果を返します。

たとえば、ポートごとに異なる mark を返す、アドレスごとに異なる処理パラメータを返す、といった表現ができます。多くの if/else 風ルールを書くより、map のほうが集中管理しやすく、保守もしやすくなります。

set が気にするのは「集合に含まれるかどうか」です。一方で map が気にするのは「この値に対応する結果は何か」です。

verdict map：マッチした値をアクションに変換する

verdict map は map の重要な使い方の 1 つです。マッチした値を verdict、つまりルールのアクションに変換します。

たとえば、IP 範囲ごとに accept、drop、または別 chain への jump を対応させられます。これにより、多くの分岐判断を 1 つの構造に圧縮できます。

ルールセットが複雑になってきたとき、verdict map はとても便利です。重複ルールを減らし、長い条件分岐の列ではなく、表に近い形でポリシーを表現できます。

概念からルール設計を考える

nftables ルールを設計するときは、次の順序で考えると整理しやすくなります。

まずルールが属する family を決める。
次に、どの table に入れるかを決める。
適切な hook と chain を選ぶ。
具体的な rule を書く。
重複条件が多い場合は、set、map、verdict map を導入する。

この順序で書くと、ルールは保守しやすく、問題も切り分けやすくなります。

まとめ

nftables の概念は複雑ではありませんが、階層が重要です。

table はルールの境界を管理する。
family はプロトコル範囲を管理する。
chain は実行位置を管理する。
rule はマッチとアクションを管理する。
set、map、verdict map は複雑さを管理する。

まずこれらの概念を理解してから具体的なコマンドを見るほうが、コマンドを直接暗記するより安定します。特にルールセットが増えてきたあとでは、概念が明確だと、問題がプロトコル範囲、実行段階、ルール順序、またはマッチ条件そのもののどこにあるのかを判断しやすくなります。

参考

https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/concepts-in-the-nftables-framework

nftables クイック入門：テーブル、チェーン、ルールとよく使う操作

Sat, 18 Apr 2026 10:22:07 +0800

nftables は、Linux でよく使われるパケットフィルタリングとファイアウォールルール管理の仕組みです。端末の通信制御、トラフィック統計、ポートマッチ、簡単な帯域制限だけを行うなら、最初からルール体系全体を覚える必要はありません。まずは次の 3 つを押さえれば十分です。

table：ルールを入れるコンテナ。
chain：ルールが評価される場所。通常は特定の hook に接続します。
rule：実際のマッチ条件とアクション。

以下では、まずテスト環境で試しやすい最小構成の流れを整理します。

基本構成

先にいくつか変数を用意します。以降のコマンドで再利用します。

table=customtable
chain=custom_control
target=drop
ip=192.168.18.251
mac=00:00:01:02:03:04

IPv4 と IPv6 の両方を扱える inet table を作成します。

`1`	`nft add table inet $table`

次に、forward 段階に接続する chain を作成します。

`1`	`nft add chain inet $table $chain { type filter hook forward priority 0\; }`

ここで、type filter はフィルタリング用のルールであることを示し、hook forward は転送されるパケットを処理することを示します。

よく使うマッチ方法

送信元 IP でマッチします。通常はアップロード方向の制御として考えられます。

`1`	`nft add rule inet $table $chain ip saddr $ip $target`

宛先 IP でマッチします。通常はダウンロード方向の制御として考えられます。

`1`	`nft add rule inet $table $chain ip daddr $ip $target`

MAC アドレスでマッチする場合、ether saddr で上り方向を制御できます。

`1`	`nft add rule inet $table $chain ether saddr $mac $target`

ブリッジ、転送、アドレス変換を経由するネットワークでは、下りパケットを宛先 MAC で安定してフィルタできない場合があります。端末の通信制御を行うときは、まず ether saddr または IP ベースのルールから検証するのが安全です。

ポートでマッチする場合、TCP と UDP をまとめて対象にできます。

`1`	`nft add rule inet $table $chain { tcp, udp } dport 22 $target`

ポート範囲をマッチしたい場合は、比較式を使えます。

`1`	`nft add rule inet $table $chain tcp dport \>= 1024 $target`

単一端末の通信量を集計する

特定 IP の上りと下りの通信量を集計したいだけなら、counter return を使えます。マッチしたらカウンターを記録して戻るため、後続に他の統計ルールがある場合でも余計なマッチ処理を減らせます。

1
2

nft add rule inet $table $chain ip saddr $ip counter return
nft add rule inet $table $chain ip daddr $ip counter return

統計結果を確認します。

`1`	`nft list chain inet $table $chain`

各ルールの handle を確認したい場合は、-a を付けます。

`1`	`nft -a list chain inet $table $chain`

handle は重要です。nftables で単一ルールを削除するときは、通常この値で対象を指定します。

簡単な帯域制限

帯域制限には limit rate over を使えます。たとえば、MAC アドレスごとに指定速度を超えた通信を制限します。

rate=10
unit=mbytes

nft add rule inet $table $chain ether saddr $mac limit rate over $rate $unit/second drop

ここでの mbytes、kbytes は、日常的な M、K の単位として理解できます。手動で 8 倍換算する必要はありません。実際に使うときは、まず緩めの値でテストし、マッチ方向と効果を確認してから調整するのが安全です。

ルールの削除と整理

まず handle 付きでルールを表示します。

`1`	`nft -a list chain inet $table $chain`

次に handle を指定してルールを削除します。

`1`	`nft delete rule inet $table $chain handle <handle>`

chain を空にします。

`1`	`nft flush chain inet $table $chain`

chain を削除します。

`1`	`nft delete chain inet $table $chain`

table 全体を削除します。

`1`	`nft delete table inet $table`

日常的なデバッグでは、自分で作成した table だけを整理するのがおすすめです。システムや他のサービスが自動生成した table を直接変更しないほうが、ルールを書き間違えた場合でも戻しやすくなります。

使い方のポイント

nftables を使うときは、まず独立した table と chain を自分で作成すると扱いやすくなります。利点は次の 2 つです。

システム既存のルールと混ざりにくい。
デバッグ、flush、削除を安全に行いやすい。

ルールを書いたあとは、必ず nft list chain で実際のマッチ状況を確認します。特に MAC、インターフェイス、ポート、帯域制限のルールは、デバイス、ブリッジ構成、システムバージョンによって挙動が変わることがあります。複雑なルールを一度に書くより、まず小さい範囲で試すほうが安全です。

参考

https://www.right.com.cn/forum/thread-8369750-1-1.html