netfilter/nftables：Linux パケット処理パイプライン

ネットワークスタックに刺さった「フック点」

Linux のパケットフィルタリングは、独立したミドルウェアではなく ネットワークスタックの内部に埋め込まれたフック（hook） として実装されています。これが netfilter です。IP 層の処理経路には、あらかじめ決められた地点に「コールバックを差し込める穴」が5箇所あり、パケットがその地点を通過するたびに、登録された関数群（チェイン）が呼び出されます。

重要なのは、フック点が ルーティング判定（route lookup）を基準に配置されている ことです。パケットが「自分宛か、転送か」を決める判定の前後でフックが分かれるため、同じパケットでも通るフックが経路によって変わります。この配置を理解すれば、なぜ DNAT は PREROUTING で、SNAT は POSTROUTING でしか効かないのかが必然として腑に落ちます。

                ┌─────────────┐
  受信NIC ─►─ PREROUTING ─► [route?] ─┬─► INPUT ─► ローカルプロセス
                                      │              │
                                  （転送）           ▼（送信）
                                      ▼            OUTPUT
                                   FORWARD ──────────┤
                                      │              │
                                      └─► POSTROUTING ◄┘ ─► 送信NIC

5つのフック点と通過パターン

netfilter のフックは IPv4 では NF_INET_PRE_ROUTING 〜 NF_INET_POST_ROUTING の5つです。パケットの素性によって、この5つのうち決まった組み合わせだけを通ります。

通過パターンは3種です。受信してローカルで処理 するなら PREROUTING → INPUT、転送 なら PREROUTING → FORWARD → POSTROUTING、ローカルで生成して送出 するなら OUTPUT → POSTROUTING。転送パケットは INPUT も OUTPUT も通らない点が混乱しやすい急所です。FORWARD が効くのはホストがルータとして振る舞う（IP フォワーディング有効）ときだけです。

チェインの評価：優先度とテーブルの正体

各フック点には複数の チェイン を登録でき、チェインには 優先度（priority） という整数が付きます。パケットがフックを通過すると、そのフックに刺さったチェインが優先度の小さい順（負の数が先）に呼ばれます。iptables の「テーブル」（raw/mangle/nat/filter）の正体は、実はこの優先度の違いです。raw が最初（最も小さい優先度）、続いて conntrack によるフロー判定、mangle、nat、最後に filter という順に並んでいるだけで、テーブルは概念的なグループ分けにすぎません。

チェイン内では ルールが上から線形に評価 されます。各ルールはマッチ条件（プロトコル、IP、ポート、インタフェース、接続状態など）とターゲット（ACCEPT/DROP/JUMP など）の組です。条件に合致した最初の終端ターゲットで評価が打ち切られます。接続状態を見るステートフルな判定は conntrack サブシステムが担い、戻りパケットの自動許可などはここに依存します（詳細は Conntrack：ステートフルファイアウォールの内部）。

# iptables：filter テーブルの INPUT チェインを上から評価
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -P INPUT DROP   # どれにも合致しなければ既定ポリシーで落とす

iptables の構造的限界

iptables は長年の標準でしたが、設計上の制約を抱えていました。第一に テーブルとチェインが固定 で、ルール評価が純粋な線形走査である点。ルール数が N 本なら最悪 O(N) の比較が走り、数千ルール規模では評価コストが無視できません。第二に IPv4 と IPv6 が別実装（iptables と ip6tables）で、さらに ARP 用の arptables、ブリッジ用の ebtables と、プロトコルごとにツールもカーネルコードも分かれていました。

第三が ルール更新の非アトミック性 です。古い iptables は1ルールの追加ごとにテーブル全体をカーネルとやり取りし、大量ルールの一括更新では中間状態が見えたり競合したりしました。第四に、似た条件を多数並べるしかなく（例：100個の IP を許可するなら100ルール）、表現力が乏しいことです。

nftables：単一仮想マシンへの統合

nftables はこれらを根本から作り直しました。核心は、固定のテーブル/チェイン構造をやめ、カーネル内に 汎用のパケット処理仮想マシン（疑似ステートマシン） を置いたことです。ユーザー空間の nft がルールを バイトコードへコンパイル し、カーネルの VM がそれを実行します。これにより設計が次のように変わりました。

最大の実利は 集合（set）とマップ（map） です。iptables なら IP ごとにルールを並べるところを、nftables は集合に対する所属判定1回で済ませます。内部はハッシュや赤黒木で実装され、要素数によらず実質的に定数〜対数時間で引けます。さらに vmap（verdict map） を使えば「キー → 判定」を表として持ち、if-else の連鎖を表引き1回に畳めます。

table inet filter {
  set allowed_v4 { type ipv4_addr; elements = { 10.0.0.0/8, 192.0.2.5 } }

  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip saddr @allowed_v4 tcp dport { 22, 443 } accept   # 集合で一括マッチ
  }
}

XDP・TC との関係：処理段の住み分け

netfilter は強力ですが、パケットが IP スタックに入って conntrack を経た 後 で動きます。より手前で、あるいは別の目的で動く仕組みが XDP と TC です。三者は競合ではなく、パイプライン上の 処理段（ステージ）が異なる 補完関係です。

XDP（eXpress Data Path） は eBPF プログラムを NIC ドライバの受信直後（場合によってはハードウェアオフロード）で走らせ、skb（カーネルのパケット構造体）を生成する 前 に判定します。スタックのオーバーヘッドを丸ごと飛ばせるため、毎秒数千万パケットのドロップやリダイレクトを最小遅延でこなし、DDoS 緩和や L4 ロードバランサに使われます（L4ロードバランサの内部）。代償としてステートフルな判定や NAT は標準では持たず、必要なら自前で組みます。

TC（Traffic Control） は qdisc 層に位置し、本来はキューイングと帯域整形・分類を担当します。ここにも eBPF（tc-bpf）をフックでき、ingress/egress でパケットを加工・分類できます。XDP より後ろ（skb 生成後）ですが netfilter より柔軟な eBPF 加工が可能で、CNI などコンテナネットワークで多用されます。これら高負荷経路でのパケット受信そのものの仕組みは カーネルのパケット受信経路：NAPI と割り込み緩和 を参照してください。

まとめ

netfilter はネットワークスタックに5つのフック点を埋め込んだ仕組みで、フックは route lookup を基準に配置されるため、通過パターン（受信ローカル・転送・ローカル送出）と NAT の位置（DNAT は PREROUTING、SNAT は POSTROUTING）が構造的に決まります。チェインは優先度順に呼ばれ、iptables のテーブルはその優先度のグループ名にすぎず、ルールは線形走査されます。iptables の固定構造・線形走査・非アトミック更新・プロトコル別実装という限界を、nftables は単一の仮想マシン・集合/マップによる高速検索・トランザクション更新・inet family 統合で作り直しました。そして XDP（ドライバ最早段の超低遅延）と TC（qdisc 段の整形・分類）は netfilter より別の段で動く補完技術であり、どの段で何を決めるかを一貫して設計することが、Linux のパケット処理パイプラインを使いこなす鍵になります。