クイックスタート：5分で学ぶ Conntrack テーブルの確認と管理
Linux が NAT ゲートウェイ、ロードバランサー、あるいは iptables/nftables ファイアウォールとして動作する際、カーネルは内部ですべてのネットワークセッションを追跡・記録しています。conntrack-tools を導入すれば、/proc 直下の難解な raw ファイルを解析することなく、これらの接続データへ直接介入できます。
Debian/Ubuntu でのパッケージインストール：
sudo apt update && sudo apt install -y conntrack
RHEL、Rocky Linux、CentOS Stream の場合：
sudo dnf install -y conntrack-tools
現在カーネルが追跡している総接続数を素早く確認：
sudo conntrack -C
ESTABLISHED 状態にある TCP 接続を上位10件取得：
sudo conntrack -L -p tcp --status ESTABLISHED | head -n 10
内部データベースサーバー（例: IP 10.0.0.50）宛てのセッションを抽出：
sudo conntrack -L -d 10.0.0.50
トラフィックフラッド攻撃元の IP からの接続を今すぐ一括切断したい場合は、-D フラグを使用します（大規模な攻撃の早期検知には DDoS検知ソリューション などの併用も有効です）：
sudo conntrack -D -s 203.0.113.88
仕組みと本質：Conntrack とは何で、どのように動くのか？
サーバーを、毎日何千人もの来訪者を迎えるオフィスタワーのエントランスに例えてみましょう。見知らぬ来客が現れると、警備員は身分証明書を確認し、受付台帳に記入してからエレベーターを通します。その人物が数分後に戻ってきた場合、警備員は台帳をチラリと見るだけで済みます。「登録済みですね、どうぞお通りください」。最初から審査をやり直す必要はありません。
Conntrack（Connection Tracking：接続追跡）は、まさに Linux カーネルにおけるこの「受付台帳」です。Netfilter フレームワークの根幹をなすサブシステムであり、ファイアウォールがパケットの所属セッションを判別できるのは、この仕組みのおかげです。これにより、次のような定番ルールが成立します：
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
通過する各パケットに対し、カーネルは5つのタプル（5-tuple: Source IP、Destination IP、Source Port、Destination Port、Protocol）を抽出します。このデータはハッシュ化され、RAM 上のハッシュテーブルへ直接格納されます。
把握しておくべき4つの接続ステータス
- NEW: データフローを開始する最初のパケット（代表例: TCP SYN パケット）。
- ESTABLISHED: 3ウェイハンドシェイク（3-way handshake）が完了し、双方向通信が確立されたセッション。
- RELATED: 既存のセッションに関連して派生した接続（例: FTP パッシブモードのデータ転送チャネルや ICMP unreachable エラーパケット）。
- UNTRACKED: 追跡から除外されたパケット。リソース節約のため、通常
rawテーブル経由で指定されます。
Conntrack ログの読み解き方
conntrack -L を実行すると、以下のような形式で出力されます：
tcp 6 431999 ESTABLISHED src=192.168.1.15 dst=1.1.1.1 sport=54212 dport=443 src=1.1.1.1 dst=192.168.1.15 sport=443 dport=54212 [ASSURED] mark=0 use=1
各項目の意味：
tcp 6: プロトコル名（TCP）と標準プロトコル番号（TCP は 6、UDP は 17）。431999: カウントダウンされる TTL（秒単位）。この時間内に新規パケットを受信しない場合、エントリは破棄されます。ESTABLISHED: 現在の TCP セッション状態。- 前後の
src/dst/sport/dportペア: 前半は送信方向（original）、後半は予期される応答方向（reply）のフロー。 [ASSURED]: カーネルが双方向のトラフィックを確認済みであり、単方向接続ではないことを示します。
実践トラブルシューティング：Conntrack テーブル枯渇時の対応
非常に不可解な症状に直面することがあります。CPU 使用率はわずか 30%、RAM にも十分な空きがあり、帯域幅も 1Gbps ポートの半分未満にもかかわらず、ピーク時に API タイムアウトが多発する現象です。ゲートウェイへの ping を試すと、断続的に 15〜20% のパケットロスが発生します（なお、本番導入前に ネットワーク障害をシミュレーション して耐性を検証しておくことも重要です）。
スイッチや物理ケーブルに異常は見当たりません。しかし、dmesg -T を実行すると、真の原因が姿を現します：
nf_conntrack: table full, dropping packet
当時、そのサーバーは 80 以上のマイクロサービスを抱える Kubernetes クラスタの NAT を担っていました。毎秒数万件の短命な HTTP リクエストが生成・終了を繰り返していたのです。結果として、Conntrack テーブルはデフォルト上限の 65,536 エントリに到達。メモリの枯渇を防ぐため、カーネルは新規パケットを自動的にドロップしていました。
現在の許容上限値の確認
カーネルが許可している最大エントリ数を確認：
sysctl net.netfilter.nf_conntrack_max
ハッシュテーブルのバケット数（hashsize）を確認：
cat /sys/module/nf_conntrack/parameters/hashsize
安全な拡張基準と RAM 計算式
nf_conntrack_max と hashsize の推奨比率は 4:1 または 8:1 です。64ビットシステムにおいて、1エントリあたり消費されるメモリは約 320 バイトです。
テーブルを 1,048,576 エントリ（100万接続）まで引き上げた場合でも、消費メモリは約 335 MB にすぎません。32GB や 64GB の RAM を搭載する現代のサーバーにおいては、極めてわずかなコストです。
稼働中システム（ランタイム）への即時適用：
sudo sysctl -w net.netfilter.nf_conntrack_max=1048576
echo 262144 | sudo tee /sys/module/nf_conntrack/parameters/hashsize
再起動後も設定を永続化するため、/etc/sysctl.d/99-conntrack.conf に追記します：
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_established = 21600
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
同時に、hashsize の値を /etc/modprobe.d/conntrack.conf に固定します：
options nf_conntrack hashsize=262144
作成した sysctl 設定を即時リロード：
sudo sysctl --system
高負荷サーバー向けの実践プラクティス
- TCP ESTABLISHED のタイムアウトを短縮する: Linux のデフォルト設定では、このセッションを 432,000 秒（丸5日間）保持し続けます。クライアントが FIN/RST を送信せずに突然切断された場合、そのエントリはテーブル内に約1週間居座り続けます。一般的な Web サーバーでは、6時間（21,600秒）または2時間程度まで引き下げることを推奨します。
- 大容量トラフィックに NOTRACK を適用する: HAProxy、Nginx リバースプロキシ、パブリック DNS などを運用している場合、すべてのパケットの状態を追跡する必要はありません。
rawテーブルで conntrack をバイパスすることで、大量の CPU・RAM リソースを解放できます：
sudo iptables -t raw -A PREROUTING -p tcp -m multiport --dports 80,443 -j NOTRACK
sudo iptables -t raw -A PREROUTING -p udp --dport 53 -j NOTRACK
- デバッグ時のリアルタイムイベント監視: 次のコマンドを使用すると、接続の生成・破棄イベントをリアルタイムに直接トレースできます：
sudo conntrack -E -e NEW,DESTROY
- 障害発生前のアラート設定: Grafana 等で
node_nf_conntrack_entries / node_nf_conntrack_entries_limitの使用率メトリクスを監視します。使用率が 75〜80% に達した段階でアラートを発出するよう閾値を設定しておくことで、夜間にテーブルが飽和してパケットドロップが始まる前に、インフラチームが余裕を持って対処できます。より詳細なパケット挙動を端末上で調査したい場合は、Termshark でパケット解析 を行うのも効果的です。
