Conntrack：ステートフルファイアウォールの内部

パケット単位ではなく「フロー単位」で判定する

素朴なファイアウォールは1パケットずつヘッダを見て許可・拒否を決めます。だが TCP は双方向です。クライアントの発信を許可すると、サーバーからの戻りパケットも通さねばならない。これをパケット単位の静的ルールで書くと「外向きの新規接続は許可、内向きは戻りだけ許可」を手作業で対称に記述する羽目になり、ポート範囲ごとに穴を開けることになって破綻します。

ステートフルファイアウォール はこの問題を、判定の単位を フロー（コネクション） に引き上げて解決します。一度通した発信を「接続」として記憶し、その接続に属する戻りパケットを自動で許可する。Linux では netfilter の 接続追跡（connection tracking, conntrack） サブシステムがこの記憶を担います。フロー単位という発想の前提として、TCP/UDP の双方向性は /network/tcp-udp/ を参照してください。

conntrack は何を覚えているのか

conntrack はカーネル内に コネクション追跡テーブル を持ち、観測したフローを1エントリとして登録します。フローの同一性は概ね次の5要素（5タプル）で決まります。

• プロトコル（TCP/UDP/ICMP など）
• 送信元IP・送信元ポート
• 宛先IP・宛先ポート

各エントリは「往路（original）」と「復路（reply）」の2方向タプルを持ちます。復路タプルは往路を反転させたもので、これにより戻りパケットが来たとき「どのフローの戻りか」を逆引きできます。最初のパケットが入ると netfilter のフックでエントリが仮登録され、フロー終了やタイムアウトで除去されます。

状態：NEW / ESTABLISHED / RELATED / INVALID

ルールが参照する ctstate（接続状態）は4種類です。これは TCP のハンドシェイク状態とは別の、netfilter から見たフローの分類である点に注意してください。

実務のファイアウォールはこの分類を使い、たった2行で「発信は許可、戻りは自動許可」を実現します。

# 確立済み・関連フローの戻りパケットは無条件で通す（戻り用に穴を開けない）
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# 不整合パケットは捨てる
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
# 以降、NEW の着信だけをサービスごとに個別許可すればよい
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT

TCP の状態はもっと細かく追う

TCP については conntrack はさらに内部状態（SYN_SENT, SYN_RECV, ESTABLISHED, FIN_WAIT, TIME_WAIT など）を独立に持ち、フラグの整合性を検査します。例えばハンドシェイク前に届いた裸の ACK は INVALID 扱いになります。これにより、確立シーケンスを踏まない注入パケットを弾けます。conntrack の TCP 状態は TCP プロトコル本来の状態機械を模した別実装であり、両者を混同しないことが重要です。本来の状態遷移は /network/tcp-state-machine/ を参照してください。

状態ごとにタイムアウトが設定され、確立済み TCP は既定で非常に長い（数日規模）一方、UDP は応答が無いと短時間（数十秒〜数分）で消えます。UDP は本来コネクションレスですが、conntrack は往復タプルの観測でフローを擬似的に張り、戻りを通します。

NAT との連携

NAT は conntrack の上に構築されます。アドレス・ポート変換は フローの最初のパケット に対してだけ決定され、その変換内容が conntrack エントリに刻まれます。以後のパケットは状態照合でエントリに合致し、記録済みの変換が往復で一貫適用されます。

内側 192.168.0.10:51000 ──► (NAT) ──► 203.0.113.1:40001 ──► 宛先サーバー
   往路: src=192.168.0.10:51000 dst=server:443  を
   復路: dst=203.0.113.1:40001         に書き換えて記録
   戻り: src=server:443 dst=203.0.113.1:40001 を
         エントリ逆引きで dst=192.168.0.10:51000 へ復元

つまり PAT/マスカレードで「ポートで端末を見分ける」あの対応表の正体が、conntrack エントリそのものです。NAT の外形的な振る舞いとポートフォワーディングは /network/nat/ に、対称NATで直結が破綻する理由は /network/nat-traversal-hole-punching/ にまとめています。

テーブル枯渇：本番で最も刺さる罠

conntrack テーブルにはエントリ数の上限（nf_conntrack_max）があります。エントリはハッシュテーブルで管理され、上限に達すると 新規フローのパケットがドロップ され、ログに nf_conntrack: table full, dropping packet が出ます。既存接続は生きているのに新規接続だけが落ちるため、「一部のユーザーだけ繋がらない」という再現性の低い障害として現れます。

枯渇しやすいのは次のような状況です。

• 短命接続を大量に張る構成（ロードバランサ配下、リバースプロキシ、ベンチマーク）
• UDP フラッドや SYN フラッド。確立しないフローでもエントリは消費される
• タイムアウトが長く、消えないエントリが積み上がる（特に既定の長い TCP ESTABLISHED）

# 現在のエントリ数と上限を確認
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

# 状態の偏りを集計（どの状態のフローが溜まっているか）
conntrack -L 2>/dev/null | awk '{print $1, $4}' | sort | uniq -c | sort -rn | head

# 上限とハッシュバケットを引き上げる（メモリと引き換え）
sysctl -w net.netfilter.nf_conntrack_max=1048576
echo 262144 > /sys/module/nf_conntrack/parameters/hashsize

まとめ

ステートフルファイアウォールの核心は、判定単位をパケットからフローへ引き上げ、その状態を conntrack という表に外出しした点にあります。NEW で発信を覚え、ESTABLISHED/RELATED で戻りと関連フローを自動許可し、INVALID で不整合を弾く。NAT はこの表に変換を相乗りさせて往復の一貫性を担保します。そして表である以上、エントリ数という有限資源を持ち、それが枯渇すると新規接続だけが静かに落ちる――この性質を理解しているかどうかが、ステートフルな経路の障害切り分けを分けます。