tcpdumpによるパケット解析入門｜障害調査の実践手順
※本記事にはプロモーション（広告）を含みます。
Linuxサーバーでネットワーク障害の原因を特定するなら、まずtcpdumpで通信の生ログを取得することから始めてください。アプリケーションログだけでは「接続できない」「遅い」という現象の原因がアプリ側かネットワーク側か切り分けられない場面が多く、パケットキャプチャを見ることで初めてTCPの再送やSYNの未応答が確認できます。本稿ではtcpdumpの基本操作から、障害調査で実際に使うフィルタの組み立て方、キャプチャ結果の読み解き方までを、現場の調査手順に沿って解説します。
tcpdumpの基本と準備
インストールと権限確認
主要なLinuxディストリビューションではtcpdumpがパッケージリポジトリに用意されています。Debian系ではapt install tcpdump、RHEL系ではdnf install tcpdumpで導入できます。パケットキャプチャはネットワークインターフェースを生モードで扱うため、root権限またはCAP_NET_RAWケーパビリティが必要です。sudoを付けずに実行すると「permission denied」で止まるので、初回はsudo tcpdumpから試すと確実です。CAP_NET_RAWを一般ユーザーに付与すればroot権限なしでの実行も可能ですが、権限を広げる分だけ管理対象が増える点は意識しておいてください。
基本構文とオプション
基本構文はtcpdump [オプション] [フィルタ式]です。よく使うオプションを以下にまとめます。
- -i eth0：キャプチャするインターフェースを指定（-i anyで全インターフェース）
- -nn：IPアドレスとポート番号を名前解決せず数値のまま表示
- -c 100：指定件数のパケットを取得したら自動終了
- -w capture.pcap：取得結果をファイルに保存
- -r capture.pcap：保存済みファイルを読み込んで再表示
- -v／-vv：詳細度を上げて表示情報を増やす
調査対象が複数のインターフェースにまたがる場合、最初に-i anyで全体を眺め、怪しい通信が特定のインターフェースに集中していないか確認する進め方が効率的です。
出力の読み解き方
tcpdump -nn -i eth0 port 80のように実行すると、1行ごとに「タイムスタンプ IP アドレス:ポート > IP アドレス:ポート フラグ シーケンス番号 長さ」の形式でパケットが流れます。矢印の向きが送信元と宛先を表し、flags [S]はSYN、[S.]はSYN+ACK、[.]はACKのみ、[P.]はPUSH+ACK、[F.]はFIN+ACKを意味します。3ウェイハンドシェイクが[S]→[S.]→[.]の順に並んでいれば接続確立は正常です。ここで応答が返らずSYNだけが繰り返される場合、ファイアウォールでの遮断やサーバー側プロセスの停止が疑われます。
障害調査に効くフィルタ術
IPとポートの絞り込み
本番環境では1秒間に数千パケットが流れることも珍しくなく、フィルタなしでは目的の通信を見つけられません。host 192.168.1.10で特定ホストとの通信に絞り、port 443やport 3306のようにポートを指定すればHTTPS通信やMySQL接続だけを抽出できます。srcとdstを組み合わせるとsrc host 10.0.0.5 and dst port 22のように、送信元・宛先を個別に条件づけられます。andやor、notを使った複合条件も有効です。
プロトコル別の指定方法
tcp、udp、icmpといったプロトコル名をそのままフィルタに使えます。DNS障害の切り分けにはudp port 53、pingの疎通確認にはicmpを指定します。VLANタグ付きの通信を扱う環境ではvlanキーワードを併用しないとパケットが表示されないことがあるため、キャプチャ結果が0件のときはVLANの有無も疑ってみてください。
異常トラフィックの検出
tcp[tcpflags] & tcp-rst != 0のようなビット演算フィルタを使うと、RSTパケットだけを抽出できます。RSTが特定のクライアント群からだけ大量に発生している場合、アプリケーションのタイムアウト設定やロードバランサー側の接続制限が原因になっているケースが目立ちます。以下は代表的な異常検知フィルタの例です。
| 調べたい状態 | フィルタ式 | 読み取れる兆候 |
|---|---|---|
| SYNだけが大量発生 | tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0 | ポートスキャンまたは接続先の応答なし |
| RST頻発 | tcp[tcpflags] & tcp-rst != 0 | 強制切断・ファイアウォール遮断 |
| 再送の疑い | tcp and tcp[8:4] == tcp[8:4]（Wiresharkで再確認） | 回線劣化・輻輳・MTU不整合 |
| 断片化パケット | ip[6:2] & 0x1fff != 0 | MTUサイズの不一致 |
パケットの読み方のコツ
TCPフラグの意味
TCPのフラグはRFC 793で定義された制御ビットで、SYN（接続開始）、ACK（受信確認）、FIN（正常終了）、RST（強制切断）、PSH（即時転送要求）の組み合わせで通信の状態を示します。正常なやり取りではSYN→SYN,ACK→ACKで接続が確立し、最後はFIN,ACK→ACK→FIN,ACK→ACKの4回でクローズします。この流れが途中で止まっている箇所を見つければ、障害が発生した瞬間を特定できます。
再送とタイムアウト
tcpdumpの出力だけでは、あるパケットが「再送」であるかどうかの自動判定は行われません。同一のシーケンス番号を持つパケットが短時間に複数回現れていれば再送と推測できますが、目視での確認には限界があります。再送の疑いがある通信を見つけたら、-wオプションでファイルに保存し、Wiresharkで開いて[TCP Retransmission]タグの有無を確認する進め方が確実です。
pcap保存と外部解析
現場でのその場調査にはtcpdumpのCLI表示で十分ですが、時系列でのグラフ化やストリーム単位の追跡にはGUIツールが向いています。用途に応じて使い分けると調査時間を短縮できます。
| ツール | 形態 | 得意なこと | 権限要件 |
|---|---|---|---|
| tcpdump | CLI | リモートサーバーでの即時キャプチャ | root／CAP_NET_RAW |
| Wireshark | GUI | パケットの詳細解析・ストリーム追跡 | キャプチャ時はroot相当 |
| tshark | CLI | Wiresharkの解析エンジンをスクリプトで利用 | root／CAP_NET_RAW |
| ss | CLI | ソケット単位の接続状態確認 | 一般ユーザーで実行可 |
tcpdumpでキャプチャしたpcapファイルはWiresharkやtsharkでそのまま開けます。サーバーにGUI環境がない場合は、-wで保存したファイルをscpでローカルに転送し、手元のWiresharkで解析する流れが一般的です。
現場で使う調査シナリオ
接続断トラブルの切り分け
クライアントから「アプリに繋がらない」と報告を受けたら、まずtcpdump -nn -i eth0 host <クライアントIP>で該当ホストとの通信を絞り込みます。SYNパケットがサーバーに到達しているのにSYN,ACKが返っていなければ、アプリケーションプロセスの停止やlistenポートの設定ミスが疑われます。逆にSYNパケット自体が届いていなければ、途中経路のファイアウォールやセキュリティグループの設定を確認する番です。
レイテンシ増加の特定
応答が遅いという相談では、リクエストパケットと応答パケットのタイムスタンプ差を見ます。-ttttオプションを付けると年月日を含む詳細な時刻表示になり、秒単位でどこに時間がかかっているか追いやすくなります。DBサーバーへのクエリ送信から応答までの間隔が数百ミリ秒単位で開いている場合、アプリケーション層よりもDB側の処理遅延を疑う根拠になります。
DNS名前解決の遅延
外部APIへのアクセスが断続的に遅くなる障害では、tcpdump -nn -i eth0 udp port 53でDNSクエリと応答を確認します。クエリを送ってから応答までの間隔が開いていたり、同一クエリが複数回送信されていたりする場合、名前解決サーバーの応答遅延やタイムアウトによる再送が起きています。DNSキャッシュの設定やリゾルバの向き先を見直す判断材料になります。
運用時の注意点と限界
ログ容量とローテーション
本番環境でフィルタなしのキャプチャを長時間続けると、ディスク容量を急速に消費します。-w とあわせて-C（ファイルサイズ上限）や-W（世代数）を指定し、古いファイルから自動的に上書きされるよう設定しておくと安全です。障害調査は数分から数十分の短時間で区切り、目的のフィルタを絞ってから実行する運用が現実的です。
個人情報と法的配慮
パケットキャプチャにはリクエストボディやCookie、場合によっては認証情報が含まれます。社内ネットワークであっても、通信の内容を取得する調査は事前に運用ルールや法務部門の確認を得たうえで実施してください。取得したpcapファイルは調査目的が終わり次第削除し、不要に保管しない運用が望ましいです。
権限管理とroot実行
tcpdumpの実行にroot権限を使う場合、対象サーバーへのアクセス権限そのものを厳格に管理しておく必要があります。CAP_NET_RAWを付与した専用ユーザーで運用すれば、sudo権限を持たせずにキャプチャ作業だけを許可できます。オプションの仕様やビット演算フィルタの記法はバージョンによって差異があるため、正確な仕様はman tcpdumpまたは公式サイト（tcpdump.org）のドキュメントで確認してください。セキュリティに関わる設定変更は自己責任で実施し、変更前に必ず検証環境で動作を確かめてください。
よくある質問
Q. tcpdumpとWiresharkはどちらを使うべきですか
A. リモートサーバー上でのその場調査はtcpdump、取得後の詳細分析やストリーム追跡にはWiresharkが向いています。tcpdumpで-w保存したファイルをWiresharkで開く組み合わせが効率的です。
Q. permission deniedと表示されて実行できません
A. パケットキャプチャにはroot権限またはCAP_NET_RAWケーパビリティが必要です。sudo tcpdumpのようにroot権限を付けて実行するか、setcapコマンドで一般ユーザーに権限を付与してください。
Q. 特定のポートだけをキャプチャするには
A. tcpdump -i eth0 port 443のようにportキーワードで指定します。srcやdstと組み合わせれば送信元・宛先ごとに条件を分けられます。
Q. キャプチャファイルが大きくなりすぎます
A. -wと-C（1ファイルの上限サイズ）、-W（保持する世代数）を組み合わせると、古いファイルが自動的に上書きされ、ディスク枯渇を防げます。フィルタで対象を絞ることも容量削減に有効です。
Q. tcpdumpだけでTCPの再送を確定できますか
A. tcpdumpのCLI表示だけでは再送の自動判定はできません。同一シーケンス番号の重複が見られたら、pcapファイルをWiresharkで開き[TCP Retransmission]の表示で確認してください。
Q. 本番環境でtcpdumpを動かしても安全ですか
A. フィルタなしの長時間キャプチャはCPUとディスクに負荷をかけます。調査対象のホストやポートを絞り、-cで取得件数を制限してから実行すると影響を抑えられます。
関連記事
まとめ
tcpdumpによる障害調査は、まずhostやportでフィルタを絞り込み、SYN・ACK・RST・FINといったTCPフラグの流れを追うところから始まります。接続断ならSYN,ACKの有無、レイテンシならタイムスタンプの間隔、DNS遅延ならudp port 53のクエリ・応答間隔というように、症状ごとに見るべきポイントは異なります。CLIでの即時確認とWiresharkでの詳細解析を使い分ければ、アプリケーションログだけでは見えなかった通信レベルの原因にたどり着けます。オプションの詳細はバージョンごとに異なる場合があるため、実施前にman tcpdumpや公式ドキュメントで最新の仕様を確認したうえで、検証環境から試してみてください。
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら
