iptables（アイピーテーブルズ）は、Linuxカーネルが提供するパケットフィルタリングフレームワークnetfilterを操作するユーザー空間ツールで、1998年にRusty Russell（ラスティ・ラッセル）らによって設計されました。送信元・宛先IPアドレス、ポート番号、プロトコル、接続状態などに基づいてパケットの通過・破棄・転送・書き換えを制御し、ファイアウォール、NAT、ロードバランサー、トラフィック分類など幅広い用途を担います。後継のnftablesが2014年から登場していますが、既存資産の多さや解説の豊富さから、今なお多くの環境で現役運用されています。
この記事の目次
- iptablesを構成する4つの基本テーブル
- iptables運用の基本コマンドフロー
- iptablesを扱う際の重要な留意点
- iptablesと後継nftablesの比較
- まとめ
iptablesを構成する4つの基本テーブル
iptablesではテーブル、チェイン、ルールという3階層の概念で構成されます。最も基本となるのがfilterテーブルで、INPUT・FORWARD・OUTPUTという3つの組み込みチェインを持ち、それぞれローカル宛て・転送・ローカル発のパケットに対する通過可否を判定します。-j ACCEPT／DROP／REJECT などのターゲットでパケットの最終運命を決定し、これがファイアウォール機能の中核となります。
natテーブルはNetwork Address Translation、つまりアドレス変換を司り、PREROUTING・POSTROUTING・OUTPUTチェインで構成されます。インターネット共有ルーター（MASQUERADE）、ポートフォワーディング（DNAT）、送信元アドレス書き換え（SNAT）等を実現します。mangleテーブルはTOS／TTL／MARKなどパケットヘッダの書き換えに使われ、QoSや高度なルーティング判定の補助に役立ちます。さらにraw・securityといった補助的テーブルもあり、目的に応じて使い分けます。
iptables運用の基本コマンドフロー
iptablesを運用する第一歩は、現在のルール状態を把握することです。iptables -L -n -v --line-numbers は filter テーブルのチェインとルールを行番号付きで表示し、各ルールがマッチしたパケット数とバイト数も併せて確認できます。NATの確認は iptables -t nat -L -n -v、mangle 確認は -t mangle と、テーブルごとに -t オプションで切り替えます。
ルール追加には、末尾追加の -A と先頭挿入の -I、特定位置への挿入 -I CHAIN N があります。例えば iptables -A INPUT -p tcp --dport 22 -j ACCEPT で SSH を許可、iptables -A INPUT -j DROP でデフォルト拒否、という構成は基本パターンです。設定はメモリ上に保持されるだけなので、永続化には iptables-save > /etc/iptables/rules.v4 のように書き出し、systemd の iptables-restore.service や netfilter-persistent パッケージで再起動時に自動復元する仕組みを整えます。誤って自身のSSH経路を切らないよう、適用前に at コマンドで5分後にルールクリアを予約しておくなどの安全策が運用上の鉄則です。
iptablesを扱う際の重要な留意点
iptablesでまず注意すべきは、ルールは上から順に評価され、最初にマッチしたものが採用される点です。許可ルールより前にDROPルールがあれば許可は無効化されるため、特に -I で先頭挿入する際は他ルールとの順序関係を常に意識する必要があります。デフォルトポリシー（-P INPUT DROP等）を「拒否」に設定する場合は、SSHや管理経路の許可ルールを忘れずに先に追加してから適用しないと、リモート切断という致命的事故を招きます。
現代的な運用ではconntrackによるステートフルフィルタリングが必須で、-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT を先頭付近に置くことで応答パケットを一括許可できます。これにより個別の戻りパケット用ルールが不要になり、ルールがすっきり保てます。設定の永続化には iptables-save／iptables-restore と netfilter-persistent または firewalld のフロントエンドを使い分けます。IPv6には別バイナリの ip6tables を使用する必要があり、IPv4とIPv6を両方守るには両側で同等のルールを整備する設計が必要です。
iptablesと後継nftablesの比較
iptablesは長年の運用実績で枯れた信頼性を持つ一方、テーブルごとにバイナリが分かれ（iptables／ip6tables／arptables／ebtables）、IPv4とIPv6で別々のルールを保守する必要がある、ルール追加の都度カーネルへ全置換が走るなど、設計上の古さも目立ってきました。エコシステムの肥大化により、新規機能の追加や保守も難しくなっています。
後継のnftables（2014年〜）は、これらの問題を統一構文で整理し、nftという単一コマンドでIPv4・IPv6・ARP・bridgeを横断的に扱えるようにしました。pf風の宣言的記述、セットとマップによる効率的なマッチング、ルールのインクリメンタル更新による性能向上など、現代ネットワーク要件に適した設計となっています。RHEL 8・Debian 11以降ではnftablesがデフォルトで、iptablesコマンドは内部的にnftablesへ翻訳される互換レイヤとして提供されています。既存スクリプトを動かしつつ、新規はnftables直書きへ移行するのが現代の合理的選択です。
まとめ
iptablesは、Linuxネットワーク制御の伝統的な顔として、四半世紀近くにわたりサーバー運用を支えてきた重要ツールです。テーブル・チェイン・ルールという階層構造、conntrackによる状態追跡、永続化と適用順序のベストプラクティスを押さえれば、現場のファイアウォール構築には今でも十分対応できます。とはいえ後継のnftablesへの移行は確実に進んでおり、新規構築では原則nftablesを採用し、iptablesは既存資産の保守と読み解きのために理解する、という位置づけが現代的な姿勢と言えるでしょう。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント