Linuxでiptables / nftablesの基本と実践設定

Linuxのパケットフィルタ設定を理解するとき、今は「iptablesだけ覚えればよい」という状態ではなくなっている。nftables は、Linux の現代的なパケット分類・フィルタリングの仕組みとして位置付けられており、新しい構成では nftables を中心に考える方が自然になりやすい。一方で、iptables は今でも多くの環境や記事、ツール、運用手順で登場するため、両者の関係を理解しておく価値が高い。この記事では、まずパケットフィルタの考え方を整理し、その上で iptables の基本、nftables の基本、実践的な最小構成、永続化、SSHでの事故防止までを一気につなげて理解しやすい形にまとめる。

iptables と nftables の関係

iptables は Linux カーネル内の IPv4 / IPv6 パケットフィルタルールを設定・確認するための伝統的なユーザー空間ツールとして使われてきた。一方で nftables は、Linux のより新しいパケット分類フレームワークで、複数のネットワーク層や IPv4 / IPv6 などをより統一的に扱える。nftables の公式ドキュメントでは、新しいコードは legacy な xtables より nftables を使うことが推奨されている。つまり、今から新規で覚えるなら nftables を軸にしつつ、既存サーバーや古い手順の理解のために iptables も読める状態を目指すのが実務的になる。

最初に理解しておくべきこと

Linux のフィルタ設定では、単に「ポートを閉じる・開ける」だけでなく、どのタイミングでパケットを見るのか、どの方向の通信を対象にするのか、既存接続をどう扱うのかを意識した方が整理しやすい。特に重要なのは、入力方向、出力方向、転送方向の違いと、既存接続を許可する stateful な考え方になる。nftables の NAT 解説でも、状態を持つ NAT では nf_conntrack エンジンが使われることが説明されており、現代的なファイアウォール設定では「通信の状態」を意識するのが基本になりやすい。

iptables の基本的な考え方

iptables では、テーブルとチェインの組み合わせでルールを定義する。man page でも、複数のテーブルが存在し、それぞれに組み込みチェインやユーザー定義チェインを持てると説明されている。実務で最初に触ることが多いのは filter テーブルの INPUT、OUTPUT、FORWARD で、ざっくり言えば「受信」「送信」「転送」に対してルールを書く形になる。昔からのLinuxサーバー記事ではこの構成を前提にしているものが多いため、既存環境の理解ではまだ重要になる。

iptables の基本コマンド

iptables の最初の確認は、現在のルールを一覧で見ることから始めると安全。ルールをいきなり追加する前に、今どうなっているかを把握した方が事故が少ない。基本的な確認は次のようになる。

sudo iptables -L -n -v

保存形式に近い形で見たいなら次もよく使う。

sudo iptables-save

iptables-save はルールセット全体を出力するため、バックアップや比較にも向いている。man page でも、簡単に解析しやすい形式で標準出力へダンプすると説明されている。

iptables の最小構成例

最小限の考え方としては、「既存接続は許可」「SSH は許可」「それ以外は拒否または破棄」という組み方が基本になりやすい。たとえば次のような例は、学習用としてかなり分かりやすい。

sudo iptables -F
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

sudo iptables -A INPUT -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -p tcp –dport 22 -j ACCEPT

ここでは、すでに張られている通信や関連通信、ローカルループバック、SSH だけを許可している。実際の本番では HTTP / HTTPS や監視ポートなども追加するが、考え方の骨格としてはかなり重要になる。

iptables でよくある事故

iptables の初心者が最もやりやすい事故は、自分が今 SSH で入っている通信まで遮断してしまうこと。特にデフォルトポリシーを DROP にした直後に SSH 許可ルールを入れ忘れると、作業中の接続が切れて復旧が面倒になる。そうした事故を避ける手段として、iptables-apply は新しいルールを適用した後に確認を求め、応答できなければタイムアウト後に以前のルールへ戻す仕組みを持っている。リモートサーバーを触るときは、この考え方を知っておくとかなり安全になる。

iptables の保存と復元

iptables の設定は、実行しただけでは永続化の方法が環境依存になりやすい。そのため、保存と復元の考え方を知っておく必要がある。保存は iptables-save、復元は iptables-restore が基本になる。

sudo iptables-save > rules.v4
sudo iptables-restore < rules.v4

man page でも、iptables-restore は標準入力またはファイルからルールを復元すると説明されている。つまり、ルールをコードのようにファイル管理し、復元コマンドで一括反映する流れが扱いやすい。

nftables の基本的な考え方

nftables では、iptables のように INPUT や OUTPUT が最初から固定で用意されているわけではなく、テーブルを作り、その中にチェインを作り、さらに必要なフックへ明示的に結び付ける。nftables の公式 Wiki でも、iptables と違って事前定義チェインではなく、必要な base chain を自分で定義すると説明されている。これは最初は少し抽象的に見えるが、慣れると柔軟性が高く、構成を明示的に読みやすくしやすい。

nftables のテーブルとチェイン

nftables では、テーブルがトップレベルの入れ物になり、その中にチェイン、セット、マップ、stateful object などを持てる。公式Wikiでも、テーブルは ruleset のトップレベルコンテナであると説明されている。まずは filter 用のテーブルを作り、その中に input / output / forward 用の chain を作るところから始めると理解しやすい。

nftables の最小構成例

nftables で最小限のフィルタ構成を作るなら、次のような書き方が分かりやすい。

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
}

chain forward {
type filter hook forward priority 0;
policy drop;
}

chain output {
type filter hook output priority 0;
policy accept;
}
}

ここでは inet ファミリーを使っているため、IPv4 と IPv6 を統一して扱いやすい。nftables Wiki でも、iptables では IPv4 / IPv6 などで別ツールだったものが、nftables では family の概念でまとめられていると説明されている。

nft コマンドでの操作

nftables は nft コマンドで操作する。現在のルールセットを見るなら次が基本になる。

sudo nft list ruleset

ファイルへ書いた設定を読み込むなら次のようにする。

sudo nft -f /etc/nftables.conf

nftables Wiki の scripting 解説でも、nft はファイル形式でルールセットを扱え、変数や include も使えると説明されている。つまり、nftables は「一行ずつ手で足す」より、ファイルとして構成管理しやすい方向へ寄っている。

nftables での実践的な追加例

HTTP / HTTPS も許可したいなら、input chain に次のような行を足すだけでよい。

tcp dport { 80, 443 } accept

ICMP を適切に許可したい場面では、環境に応じて ping 許可も追加しやすい。

ip protocol icmp accept
ip6 nexthdr icmpv6 accept

nftables の matching packet headers 解説でも、TCP や UDP などのレイヤ4プロトコルに対して柔軟にマッチを記述できることが整理されている。

NAT の基本例

ルータやコンテナホストのように NAT が必要な場面では、nftables でも NAT チェインを定義できる。公式Wikiでも、stateful NAT は nf_conntrack を使う一般的な方法が推奨されている。たとえば masquerade の基本例は次のように書ける。

table ip nat {
chain postrouting {
type nat hook postrouting priority 100;
oifname “eth0” masquerade
}
}

これは、外向きインターフェースが eth0 のときに送信元アドレス変換を行う例になる。NAT はフィルタと違って hook や priority の意味も重要になるため、まずは最小例から理解する方が安全。

iptables から nftables への移行の考え方

既存環境ではまだ iptables ルールが残っていることが多いが、man page には xtables-nft 系のツールが、iptables などを nftables API 経由で扱うための移行支援として存在すると説明されている。つまり、完全に別世界というより、「iptables 文化を引き継ぎつつ内部では nftables 系へ寄せる」運用もあり得る。新規構成では nftables を素直に使い、既存運用では iptables コマンドが nft backend を使っているかも含めて確認するのが現実的になる。 :contentReference[oaicite:14]{index=14}

よくある実践パターン

Linux サーバーで最初に組む実践設定は、かなりの割合で次の考え方に落ち着きやすい。
・デフォルトで受信は拒否
・既存接続は許可
・ループバックは許可
・SSH は許可
・HTTP / HTTPS は必要なら許可
・不要な転送は拒否
この骨格は iptables でも nftables でもほぼ共通で、違うのは書き方と構造になる。最初から複雑なルールを書くより、この最小セットを安定して適用できるようになる方が重要。

設定前に必ずやるべきこと

ファイアウォール設定で最も危険なのは、自分の管理経路を断ってしまうこと。特に SSH 越しにサーバーを操作している場合は、今の接続元IP、許可したい管理ポート、コンソール復旧手段を先に確認した方がよい。また、現在のルールを保存して戻せるようにしておくと安全になる。

sudo iptables-save > backup.rules
sudo nft list ruleset > backup.nft

このように事前バックアップを取っておくと、失敗時の復旧がかなり楽になる。

まとめ

Linux で iptables / nftables を理解するときは、まず nftables が現代的な標準寄りであることを押さえつつ、iptables の文化や既存運用も読める状態を目指すのが現実的になる。実践では、最初に「既存接続を許可」「ループバックを許可」「SSH を許可」「必要な公開ポートだけ許可」「それ以外は拒否」という骨格を理解し、そのうえで保存・復元・永続化・事故防止を意識した方が安全。特にリモートサーバーでは、いきなり厳しいルールを適用するより、現在の通信を切らない段階的な適用を心がける方が失敗しにくい。