tcpdump で本番ネットワーク障害をトリアージする｜キャプチャ設計・フィルタ戦略・情報保護対応

本番でtcpdumpを使う前に整理すべきこと

ネットワーク障害のトリアージで最初に手が伸びるツールの一つがtcpdumpです。しかし本番環境では「とりあえずキャプチャする」は通用しません。キャプチャ対象・フィルタ条件・保存先・破棄タイミングを事前に決めておかないと、かえって問題が複雑になります。

本記事では「障害が起きた、今すぐパケットを見たい」という状況を想定し、キャプチャ設計の考え方からBPFフィルタの組み方、取得後の検証手順、個人情報・認証情報の扱い、そして2026年時点の現行ディストリビューション環境での差分まで、一連の流れを解説します。

トリアージとパケットキャプチャの関係

トリアージの目的は「問題の切り分け」です。アプリケーション層の問題なのかネットワーク層の問題なのかを早期に判断するために、tcpdumpは有効な一次情報源になります。ただし、全トラフィックをダンプするのは本番ではリスクが高く、I/Oや保存容量を圧迫することもあります。最小限の情報で最大の判断材料を得るフィルタ設計が重要です。

キャプチャ設計：インターフェース・時間・ファイルサイズの三角形

キャプチャを始める前に、以下の三点を決めておきます。

• 対象インターフェース：ip link show や ip a で確認し、障害が疑われる通信経路に絞ります。ボンディング・VLAN・コンテナのvethなど、環境によって複数候補が出る場合は-Dオプションで列挙できます。
• キャプチャ時間・ローテーション：-G 60 -W 5で「60秒ごとにローテーション、最大5ファイル保持」という設定にすると、ディスクを食いつぶさずに直近5分を保持できます。
• スナップショット長（snaplen）：デフォルトは262144バイトですが、ヘッダ情報だけで判断できるケースでは-s 96程度に絞るとI/O負荷を下げられます。ペイロードを見たい場合はフルサイズのままにします。

想定例として、Webフロントエンドからバックエンド（ポート8080）への疎通不良を調査する場合のコマンド構成は次のようになります。

# ローテーションあり・フィルタ付きキャプチャ（想定例）
tcpdump -i eth0 -s 0 -G 60 -W 10 -w /var/tmp/cap_%Y%m%d%H%M%S.pcap \
  'host 192.0.2.10 and tcp port 8080'

-w に strftime 形式のタイムスタンプを埋め込むことで、ローテーション後のファイルを時系列で識別できます。保存先は /var/tmp よりも専用のキャプチャ用ディレクトリを設けるのが望ましく、後述の情報保護対応とセットで管理します。

BPFフィルタ戦略：障害類型ごとの組み方

tcpdumpのフィルタはBPF（Berkeley Packet Filter）構文で記述します。障害の類型に合わせて適切なフィルタを事前に用意しておくと、現場での判断が速くなります。

接続確立の失敗を見る

TCPの3ウェイハンドシェイク失敗（SYN に対して RST が返る、ACK が来ない）を検出したい場合は、TCPフラグを使ったフィルタが有効です。

# RST パケットだけを抽出（想定例）
tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'

# SYN のみ（接続試行を確認）
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'

特定ホスト間の往復を確認する

「AからBへの通信は届いているか」を見たい場合は host A and host B で双方向を同時にキャプチャできます。片側だけに絞る場合は src host / dst host を使います。

# A→B の方向だけ（想定例）
tcpdump -i eth0 'src host 192.0.2.10 and dst host 192.0.2.20'

DNSの応答遅延や失敗を見る

名前解決の問題が疑われる場合は、UDPポート53を対象にキャプチャします。-vオプションを付けるとTTLやIDなど詳細情報が表示されます。

# DNS クエリ・応答（想定例）
tcpdump -i eth0 -v 'udp port 53'

一般的なつまずきとして、コンテナ環境でホストのインターフェースを指定してもコンテナ内の通信が見えない、というケースがあります。コンテナ側のvethやdocker0ブリッジを指定する必要があります。ip link show でvethの対応関係を確認してからインターフェースを選びます。

取得後の検証：その場で読むか、Wiresharkに渡すか

pcapファイルを取得した後の読み方は、状況に応じて使い分けます。

ターミナル上での即時確認

取得済みのpcapをtcpdump自身で読み直すには -r を使います。フィルタを後から絞り込めるので、まず広めに取ってから絞る運用も有効です。

# 保存済みファイルを読み直す（想定例）
tcpdump -r /var/tmp/cap_20261008120000.pcap 'tcp port 8080 and tcp[tcpflags] & tcp-rst != 0'

-n（名前解決しない）と -tt（UNIX タイムスタンプ表示）を組み合わせると、スクリプトで後処理しやすくなります。

Wiresharkへの転送

詳細な解析が必要な場合はpcapファイルを手元の端末に転送してWiresharkで開きます。ただし、後述の情報保護対応が前提です。本番サーバから外部にpcapを移す行為は、社内ルールやコンプライアンス要件の確認が必要なケースがあります。

情報保護対応：本番キャプチャが抱えるリスクと対処

本番ネットワークのパケットには、認証トークン・セッションID・個人情報が含まれる可能性があります。2026年時点では、多くの組織でGDPRや個人情報保護法に基づくデータ取り扱い規定が整備されており、pcapファイルもその対象になり得ます。

• 保存先の権限管理：キャプチャファイルを置くディレクトリは、調査担当者のみ読めるよう権限を絞ります（例：chmod 700 /var/tmp/pcap_work/）。
• 保持期間の設定：調査終了後は速やかに削除します。-Wオプションによる自動ローテーションは一定の枚数を上限にできますが、調査完了後の明示的な削除手順をチームで決めておきます。
• 転送経路の暗号化：pcapを手元に持ってくる場合はSCPやrsync over SSHを使います。平文のFTPやHTTPは避けます。
• TLS/暗号化通信への対応：HTTPSなど暗号化された通信はtcpdumpだけではペイロードを読めません。トリアージの目的がTCPレベルの接続確認であれば問題ありませんが、アプリケーション層のデータが必要な場合はサーバサイドのSSL復号ログ（例：NSS_KEYLOG_FILE）を別途組み合わせます。この場合の取り扱いには、さらに慎重な情報管理が求められます。

2026年現行環境での差分と注意点

tcpdump自体は枯れたツールですが、現行の本番環境には以下のような差分があります。

コンテナ・Kubernetes環境

Kubernetesクラスタではノードのホストネットワーク上にvethが動的に作成されます。kubectl exec でPodに入ってtcpdumpを実行する手法もありますが、Podのコンテナイメージにtcpdumpが入っていないケースも多く、一般的にはデバッグ用のephemeral containerを使うか、ノード側のvethを特定してホストから取得します。

ephemeral containerを使う場合は kubectl debug コマンドで任意のデバッグイメージをアタッチできます（Kubernetes 1.23以降で安定版）。ただし本番クラスタでのephemeral container使用はRBACで制御している組織も多いため、事前に権限を確認します。

eBPFベースのオブザーバビリティとの使い分け

2026年時点では、CiliumやPixieなどeBPFベースのネットワーク可視化ツールが普及しています。これらはtcpdumpより高レベルな情報（サービス間のフロー、レイテンシ、HTTPステータスなど）を常時収集しており、障害発生後でも過去のメトリクスを参照できます。tcpdumpはこれらが収集していないレベルの詳細（特定のTCPフラグ、細かいシーケンス番号）を確認する場面で補完的に使う位置づけになりつつあります。

systemdとtcpdumpの組み合わせ

定期的なキャプチャや障害時の自動起動をsystemdのtransient unitとして管理する手法があります。systemd-run --unit=tcpdump-triage で起動すると、systemctl stop tcpdump-triage でクリーンに停止でき、ジャーナルにも記録が残ります。ただしこれは恒常的なキャプチャには向かず、あくまでインシデント対応時の一時的な使い方に限定するのが適切です。

libpcap・tcpdumpのバージョン確認

Debian 12（Bookworm）・Ubuntu 24.04 LTS・RHEL 9系では、tcpdump 4.99.x と libpcap 1.10.x が標準パッケージとして提供されています。古い環境からの移行時は tcpdump --version でバージョンを確認し、BPFオフロードやキャプチャフィルタの挙動差異を意識します。特にNICのオフロード機能（TSO/GSOなど）が有効な場合、ホスト側でキャプチャすると実際にワイヤ上を流れるパケットサイズと異なる場合がある点は、よくあるつまずきの一つです。