パケットキャプチャ
パケットキャプチャとは
パケットキャプチャは、ネットワークを流れるパケットをそのまま記録して中身を解析する手法です。pingなどの [[ネットワーク診断コマンド]] が「健康診断」だとすれば、パケットキャプチャは「精密検査」— 実際に流れたデータそのものを見るため、推測ではなく事実で問題を特定できます。
- 「リクエストは本当に送られているか」「応答はどこまで返ってきているか」が確定できる
- 再送・遅延・切断など、アプリのログには出ないネットワーク層の挙動が見える
- プロトコルの学習教材としても最高 — [[TCP/IP]] の3ウェイハンドシェイクを目で見られる
定番ツール
| ツール | 特徴 |
|---|---|
| Wireshark | GUIの定番。プロトコルを自動解析して色分け表示。学習にも最適 |
| tcpdump | CLIの定番。サーバー上で手早く取得。結果をWiresharkで開くのが定石 |
サーバーで tcpdump を使ってキャプチャファイル(pcap形式)を保存し、手元のWiresharkでじっくり解析する、という組み合わせが実務の定番です。
# 例: ポート443宛の通信をファイルに保存する
tcpdump -i eth0 port 443 -w capture.pcap
フィルタが命
キャプチャはすべての通信が記録されるため、絞り込まないと膨大なノイズに埋もれます。
- 取得時のフィルタ —
port 443やhost 192.168.1.10のように対象を限定して録る - 表示フィルタ(Wireshark)—
httpやtcp.port == 443のように後から絞り込む
「対象の通信だけを最小限録る」のが上達の第一歩です。パケットの構造は [[OSI参照モデル]] のカプセル化(各層が上の層のデータに自分のヘッダを付けて包む動き)がそのまま入れ子で見えるので、層の知識が読解力に直結します。
注意点 — 暗号化と権限
- [[HTTPS・TLS]] で暗号化された通信は、キャプチャしても中身は読めません(宛先やタイミングなどのメタ情報は見える)。中身を見たい場合は開発環境で復号設定を使います
- パケットキャプチャは通信の傍受と紙一重の技術 — 自分が管理するネットワーク・許可された範囲でのみ行うこと。他人の通信を無断で傍受することは法律で禁じられています
初学者向けポイント
- まずは自分のPCでWiresharkを起動し、ブラウザでサイトを開いてDNS→TCP→TLSの流れを眺めてみるのが最高の入門
- 「アプリが悪いのかネットワークが悪いのか」で揉めたとき、キャプチャは客観的な証拠になる
- pcapファイルには機密情報が含まれうる — 共有時は取り扱いに注意する
関連技術とのつながり
- [[ネットワーク診断コマンド]] — コマンドで切り分け、足りなければキャプチャへ進む
- [[TCP/IP]] — ハンドシェイクや再送を実際に観察できる
- [[OSI参照モデル]] — パケットの構造は層の入れ子として表示される
- [[HTTPS・TLS]] — 暗号化された通信の中身は読めないことを理解しておく
Q: パケットキャプチャの説明として正しいのはどれ?
- [x] ネットワークを流れるパケットを記録し、中身を解析する手法
- [ ] パケットを高速に転送するルーターの機能
- [ ] 帯域を増やして通信を速くする技術
解説: 実際に流れたデータそのものを見るため、推測ではなく事実でネットワークの問題を特定できます。
Q: 本文で紹介された実務の定番の組み合わせはどれ?
- [ ] サーバーでWiresharkのGUIを直接起動する
- [x] サーバーでtcpdumpによりpcapを保存し、手元のWiresharkで解析する
- [ ] pingの結果をWiresharkで開く
解説: CLIのtcpdumpで取得し、GUIのWiresharkで解析するのが定石です。
Q: HTTPSで暗号化された通信をキャプチャした場合について正しいのはどれ?
- [ ] 暗号化されていても中身は常にそのまま読める
- [ ] 暗号化された通信はキャプチャ自体ができない
- [x] キャプチャはできるが中身は読めず、宛先などのメタ情報は見える
解説: TLSで暗号化された部分は復号設定なしには読めません。ただし通信の存在や宛先・タイミングは観察できます。