iptablesからnftablesへ段階的に移行する｜ルール変換と動作確認・切り戻しの流れ

なぜ今 nftables へ移行するのか

Linux カーネル 3.13（2014年）で導入された nftables は、長年の標準だった iptables を置き換えるパケットフィルタリングフレームワークです。Red Hat Enterprise Linux 9（2022年）では iptables がデフォルトから外れ、Debian 12（bookworm、2023年）でも nftables がデフォルトになりました。2026年時点では、主要なサーバーディストリビューションのほぼすべてが nftables を標準ファイアウォールとして採用しており、iptables は互換レイヤー経由での動作が主流になっています。

移行を先送りにしてきた現場でも、OS の LTS サポート期限が迫る、あるいは新規サーバーを構築する際に「iptables コマンドで設定したら nftables のルールと競合した」という問題に直面するケースが増えています。本記事では、既存の iptables ルールを nftables に段階的に移行するシナリオを、変換・適用・検証・切り戻しの順に解説します。

移行前の準備──現行ルールの棚卸しとバックアップ

移行作業に入る前に、現行の iptables ルールを完全に書き出しておくことが不可欠です。後から切り戻す際のベースラインになるため、ファイルとして保存しておきます。

# IPv4 ルールを保存
sudo iptables-save > /root/iptables-backup-$(date +%Y%m%d).rules

# IPv6 ルールも忘れずに
sudo ip6tables-save > /root/ip6tables-backup-$(date +%Y%m%d).rules

次に、現在の環境で nft コマンドが使用できるかを確認します。カーネル 4.1 以降であれば nftables は利用可能ですが、パッケージが未インストールの場合もあるため確認しておきましょう。

nft --version
# 例: nftables v1.0.9 (Old Doc Yak #3)

Debian/Ubuntu 系では update-alternatives --config iptables で、現在 iptables-legacy と iptables-nft のどちらが使われているかを確認できます。すでに iptables-nft が選択されている場合、iptables コマンド自体がバックエンドで nftables に書き込んでいるため、現行ルールの確認には nft list ruleset も併用します。

iptables-translate でルールを変換する

nftables プロジェクトは iptables-translate（単一ルール変換）と iptables-restore-translate（保存済みルールセット一括変換）という変換ツールを提供しています。手動での書き換えよりも確実であり、変換後のルールをベースに調整する流れが現場での定番になりつつあります。

単一ルールの変換例

# iptables のルール例
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# 変換後の nftables 構文を確認
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# 出力例: nft add rule ip filter INPUT tcp dport 22 counter accept

保存済みルールセットの一括変換

先ほど保存したバックアップファイルを使って、ルールセット全体を nftables 形式に変換します。

sudo iptables-restore-translate \
  -f /root/iptables-backup-$(date +%Y%m%d).rules \
  > /root/nftables-converted.nft

# IPv6 も変換して追記
sudo ip6tables-restore-translate \
  -f /root/ip6tables-backup-$(date +%Y%m%d).rules \
  >> /root/nftables-converted.nft

変換後のファイルは必ず内容を確認してください。変換ツールはすべてのモジュールに対応しているわけではなく、-m recent や -m hashlimit などのカスタムモジュールを使ったルールは手動での書き直しが必要になることがあります。また、テーブル定義（nft add table、nft add chain）が変換結果に含まれているかも確認し、不足があれば補完します。

nftables のルールを段階的に適用する

一度にすべてのルールを切り替えるのはリスクが高いため、段階的に適用することを推奨します。特にリモートアクセスが前提のサーバーでは、誤ったルールを適用すると SSH セッションが切断され、復旧に物理アクセスが必要になることもあります。

構文チェックと事前検証

本番環境に適用する前に、nft の -c（check）オプションで構文チェックだけを実行します。ルールは適用されず、エラーのみが出力されます。

# 構文チェックのみ（実際には適用されない）
sudo nft -c -f /root/nftables-converted.nft

構文エラーがなければ、可能であれば同じ構成のテスト環境やスナップショットから復元した VM で実際に適用して動作を確認します。

本番環境への適用

段階的移行の基本的な流れは、iptables のルールをフラッシュせずに nftables にも同じルールを適用して並走させ、問題がなければ iptables 側を段階的に空にしていく方法です。

# nftables にルールを読み込む
sudo nft -f /root/nftables-converted.nft

# 読み込まれたルールを確認
sudo nft list ruleset

なお、iptables-nft 互換レイヤーを使用している環境では、iptables コマンド自体が nftables のバックエンドに書き込んでいます。この場合、nft list ruleset の出力に iptables が管理するルールも表示されるため、意図せず重複が生じないよう、どちらのフロントエンドが書き込んでいるかを把握しておくことが重要です。

動作確認と切り戻しの手順

ルールの適用後は、実際のトラフィックで意図したとおりに動作しているかを確認します。nftables はカウンター機能を標準で持っているため、パケットが意図したルールにマッチしているかを直接確認できます。

カウンターによるトラフィック確認

# カウンター付きでルールセットを表示
sudo nft list ruleset

# 特定のテーブルのみ表示
sudo nft list table ip filter

SSH などの許可済みサービスへの接続を行い、対応するルールのパケットカウンターが増加していれば、ルールが正しく機能していることを確認できます。カウンターが増えないルールは、マッチしていないか、優先度の高い別のルールで先にジャンプしている可能性があります。

切り戻し手順

問題が発生した場合の切り戻しは、nftables のルールをフラッシュしてから iptables のバックアップを復元する手順です。

# nftables のルールをすべて削除
sudo nft flush ruleset

# iptables バックアップから復元（YYYYMMDDは実際の日付に置き換える）
sudo iptables-restore < /root/iptables-backup-YYYYMMDD.rules
sudo ip6tables-restore < /root/ip6tables-backup-YYYYMMDD.rules

# 復元後の確認
sudo iptables -L -n -v

切り戻し手順は事前にドキュメント化し、コンソールアクセスが可能なチームメンバーと共有しておくことが、リモートでの移行作業の鉄則です。また、nft flush ruleset はすべてのテーブル・チェーンのルールを一括削除するため、フラッシュ前に必ず現在のルール一覧を確認します。

2026年現行環境での注意点とディストリビューション差分

2026年時点での主要ディストリビューションの状況を整理しておきます。

• RHEL 9 / AlmaLinux 9 / Rocky Linux 9：nftables がデフォルト。firewalld のバックエンドも nftables。iptables コマンドは iptables-nft として提供されており、nftables に書き込む。
• Debian 12（bookworm）/ Ubuntu 22.04 以降：nftables がデフォルトで有効。iptables-legacy パッケージで旧バイナリを使用可能だが、非推奨扱い。
• Ubuntu 24.04（Noble）：ufw のバックエンドも nftables に移行済み。ufw 経由のルール編集と nft 直接操作の混在は避けるべき。

firewalld を使用している環境では、firewalld 自体が nftables を管理しているため、nft コマンドで直接ルールを操作すると次回の firewalld リロード時に上書きされます。firewalld を使いつつ nftables の機能を活用したい場合は、firewalld のリッチルールやカスタムゾーン、あるいは firewalld の direct rules 機能を経由してルールを定義するほうが安全です。

nftables の設定ファイルは /etc/nftables.conf（またはディストリビューション依存の /etc/nftables.d/ ディレクトリ）に保存し、systemctl enable nftables でサービスとして起動時に読み込まれるように設定します。iptables の iptables-persistent パッケージに頼るアプローチは、nftables への完全移行後は不要になります。

移行後の運用では、nft list ruleset をスクリプトに組み込んだ定期的なルール監査も効果的です。nftables はルールのセット操作やマップ、セット型の IP リストなど、iptables にはない機能を持つため、移行を機に既存ルールの整理と高度化を検討する現場も増えています。段階的な移行を経て安定稼働を確認したうえで、iptables 関連パッケージを整理するという流れが、リスクを最小化した現実的な進め方といえます。