nftables（エヌエフテーブルズ）は、Linuxカーネルが提供する次世代のパケットフィルタリング・分類フレームワークで、長年使われてきたiptables／ip6tables／arptables／ebtablesを置き換えるべく2009年から開発されました。2014年にLinuxカーネル3.13でメインライン入りし、現在ではRHEL 8、Debian 11、Ubuntu 22.04などのディストリビューションで標準のファイアウォール基盤となっています。nftというシンプルな単一コマンドでIPv4・IPv6を統一的に扱い、宣言的かつ高性能なルール記述を実現し、セットやマップなど現代的な機能を多数提供しています。
この記事の目次
- nftablesの中心となる3つの設計概念
- nftables設定の基本フロー
- nftables導入時のチェックポイント
- iptablesからnftablesへの主な変化
- まとめ
nftablesの中心となる3つの設計概念
nftablesではtable、chain、ruleという3階層構造を共通に採用し、tableはアドレスファミリ（ip、ip6、inet、arp、bridge、netdev）と名前で識別されます。chainはtableの内部で定義され、種類（base chainとregular chain）と用途（filter／nat／route）を持ちます。base chainにはhook（input／forward／output／prerouting／postrouting）とpriority値が紐づき、netfilterパイプラインのどこで動作するかを宣言的に指定できます。
現代的な強みのひとつがsetとmapです。多数のIPアドレスやポート番号を効率良くマッチングしたい場合、iptablesでは数千行のルールが必要だった場面でも、nftablesではnamed setに集合を定義してsaddr @blocklist で一行マッチが可能になります。dynamic setやintervalキーワードを使えばCIDR範囲やレート制限も柔軟に扱えます。inetファミリのおかげでIPv4とIPv6を同一テーブル・同一ルールで扱えるため、保守工数も大きく削減されます。
nftables設定の基本フロー
nftablesでの設定は、宣言的なrulesetファイルを用意するアプローチが基本です。例えば table inet filter { chain input { type filter hook input priority 0; policy drop; ct state established,related accept; iif lo accept; tcp dport 22 accept; } } のように、テーブルからチェイン、ルールまでをネストした構文で記述できます。多くのディストリビューションでは /etc/nftables.conf をエントリポイントとし、include で複数ファイルに分割する運用も一般的です。
設定の反映は nft -f /etc/nftables.conf を実行するだけです。アトミックに置換される設計のため、ルール更新中にパケットが取りこぼされる心配は基本的にありません。現在の状態確認には nft list ruleset、特定テーブルのみ表示は nft list table inet filter といったコマンドを使います。永続化は nftables.service ユニットによる自動ロードが標準で、起動時に /etc/nftables.conf が読み込まれます。テンプレ化やAnsibleとの組み合わせも容易で、コードとしてのインフラ（IaC）と相性の良い設計となっています。
nftables導入時のチェックポイント
nftables導入時の最初の注意点は、レガシーのiptables互換レイヤ（iptables-nft）との共存です。RHEL 8・Debian 11以降では iptables コマンドが内部的に nftables を呼ぶ実装に変わっていますが、これと nft 直接記述を混在させると、tableの所有関係が複雑になり予期せぬ干渉が起こり得ます。新規環境ではどちらか一方に統一する判断を最初に固めるのが安全です。
設計面では、inetファミリを軸にIPv4とIPv6を一つのテーブルにまとめると保守がぐっと楽になります。namedセットはIPブラックリスト・ホワイトリスト・ポート集合に活用し、変更時はsetだけを更新できる構造にすると運用が大幅に効率化されます。アトミック置換はトランザクション的な強い保証ですが、巨大なrulesetを完全置換する際は瞬間的にメモリと処理を消費するため、規模が大きい場合は include による分割や add element によるset追加の活用を検討します。設定ファイルは機能単位でディレクトリ分割し、コメントとともにGitなどで版管理する習慣が望ましいでしょう。
iptablesからnftablesへの主な変化
iptables時代は、IPv4はiptables、IPv6はip6tables、ARPはarptables、L2はebtablesと、目的ごとに別バイナリを覚える必要があり、ルール構文も微妙に異なっていました。ルールを1行追加するたびにカーネルへ全置換が走る実装も、大規模ルール環境では性能面の悩みでした。集合マッチ用にipsetという別ツールを併用する必要があり、複雑化していたのも事実です。
nftablesは、これら全てを単一の枠組みに統合した点が革新的です。nftコマンドひとつでIPv4・IPv6・ARP・bridge・netdevを横断的に扱い、ルール更新はアトミックかつインクリメンタルに行われ、setとmapがipset相当の機能を内包します。構文も宣言的でJSONエクスポート／インポートに対応し、自動化や監査に向いています。学習コストはありますが、現代の運用要件にはるかにフィットする設計であり、新規構築では迷わずnftablesを採用すべきフェーズに入っています。古い手順書を読み解く時のためにiptables知識を維持しつつ、本番設計はnftables主体に切り替えるのが現実的な路線です。
まとめ
nftablesは、長年Linuxを守ってきたiptablesを正統に継ぐ新世代のパケット制御フレームワークです。統一された構文、アトミック更新、強力なsetとmap、IPv4／IPv6統合管理など、現代の運用要件に応える設計となっており、主要ディストリビューションがすでに標準採用しています。学習投資は必要ですが、その分だけ可読性と保守性の高いファイアウォール構成を実現できます。これからの新規Linux運用設計では、nftablesを軸に据える選択が間違いなく合理的です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント