Wireshark でパケットを観る

学習目標

本講を終えると、以下を達成できるようになります。

• Wireshark / tshark / dumpcap / tcpdump の 役割の違い を述べられる
• キャプチャ用インタフェースを選び、取得フィルタ(BPF) で取り込み量を絞れる
• 表示フィルタ(Wireshark 独自構文)で、取り込んだ pcap から目的のパケットだけを抽出できる
• 1 つのパケットを Ethernet → IP → TCP → アプリ層 と層をたどって読める
• TCP の 3 ウェイハンドシェイク・再送・ウィンドウ更新 を Wireshark の表示で識別できる
• SSLKEYLOGFILE で ブラウザの TLS 通信を復号 し、HTTP/2 の中身を覗ける
• tshark で パケットからフィールドだけを抽出 し、CLI で自動処理できる
• 「SYN は出ているのに SYN/ACK が返らない」「再送が連発する」 など、典型的なトラブルの見え方 を判定できる

このレッスンの目次

位置づけ ─ Wireshark / tshark / dumpcap / tcpdump

役割分担を図で

図の見方:キャプチャは OS のパケットフックから生バイトを取る重い処理、解析はそれを TCP/HTTP/TLS など各層に分解する処理。GUI で全部やるのが Wireshark、サーバ上で tcpdump -w xxx.pcap して手元の Wireshark で開く運用も多い。

つながる知識: パケットキャプチャは OS から見ると ネットワークインタフェースのフックポイント に常駐する作業。Linux は AF_PACKET、macOS / BSD は BPF デバイス、Windows は Npcap(WinPcap の後継) が経路。この層は通常のユーザ権限では触れず、管理者権限 やキャプチャ専用グループ(Linux なら wireshark グループ)が必要。

導入とキャプチャ開始

OS 別インストール

最初のキャプチャ ─ 5 ステップ

1. Wireshark を起動 → 「キャプチャ → インタフェース」 で動いているインタフェースが上位に並ぶ(波形プレビュー付き)
2. 有線なら en0 / eth0、無線なら Wi-Fi を選んでダブルクリック → キャプチャ開始
3. ブラウザで http://example.com/ を開く(HTTPS でなく HTTP の方が観察しやすい)
4. Wireshark 上部の 赤い四角(停止) でキャプチャ停止
5. 表示フィルタ欄に http と入れて Enter → HTTP メッセージだけが残る

Wireshark の 3 ペイン構造

図の見方:Wireshark の操作の 9 割は 「① で気になる行を選ぶ → ② で層を展開して読む → ③ でバイト位置を確認」 の往復。パケットを「読む」 とは、② の階層展開を上から下へたどる作業のこと。

層をたどって読む ─ 1 つの HTTP リクエストの解剖

図の見方:外側のヘッダから内側へ、Frame(物理 + 取得情報) → Ethernet → IP → TCP → HTTP と入れ子になっている。Wireshark の詳細ペインは、これをそのまま展開可能なツリーで見せる。第11回(階層化とカプセル化) の図が 実バイトとして可視化 される瞬間。

各層で必ず見るフィールド

考えてみよう: 同じ Web ページを取得しても、HTTP/1.1 と HTTP/2、HTTP/3 でパケットの見え方は大きく違う。HTTP/1.1 は平文 ASCII でそのまま読めるが、HTTP/2 は バイナリフレーム で多重化、HTTP/3 は QUIC over UDP で TCP すら見えない。Wireshark は ALPN(Application-Layer Protocol Negotiation) を見て自動判別してくれる。次回 第33回 QUIC / HTTP/3 で、その差を再度見ます。

取得フィルタ vs 表示フィルタ ─ 似て非なる二つ

BPF と Wireshark 構文の対応表

ペイロード中身に基づく絞り込みは BPF では困難。BPF は ヘッダのバイト位置で素早く判定する低レベル機構なので、HTTP のテキスト中身や TLS のハンドシェイク種別のような 解析後でないと意味が分からない条件 は表示フィルタの仕事になります。

# TCP の再送だけ
tcp.analysis.retransmission

# 1500 バイト超の IP パケット(MTU超えの調査)
ip.len > 1500

# RST が立った TCP (異常切断)
tcp.flags.reset == 1

# DNS 応答で NXDOMAIN
dns.flags.rcode == 3

# HTTP/2 の SETTINGS フレーム
http2.type == 4

# 特定の TCP ストリーム全体(右クリック → Follow → TCP Stream で取得した番号)
tcp.stream eq 7

TCP を観る ─ 3 ウェイ・再送・ウィンドウ

3 ウェイハンドシェイクの見え方

図の見方:Info 列の [SYN] / [SYN, ACK] / [ACK] の 3 行が 3 ウェイ。直後にデータ送信(GET) が続く。Time 列を見れば、SYN→SYN/ACK 間の往復時間 ≒ RTT(ここでは約 18ms)。これだけで「サーバまでの距離感」 が分かる。

再送の見え方

Wireshark は TCP ストリームの状態を内部で追跡しており、同じ Seq の再送 や 失った Seq に対する Duplicate ACK を Info 列に [TCP Retransmission] や [TCP Dup ACK ...] と表示してくれます。表示フィルタで tcp.analysis.retransmission や tcp.analysis.duplicate_ack を入れれば、再送だけを抽出可能。

便利機能:Follow → TCP Stream

パケット一覧で気になる行を右クリック → Follow → TCP Stream。これだけで、その TCP セッションの送受信バイトをアプリ層の塊として整形表示してくれます。HTTP/1.1 の通信なら 「リクエストヘッダとレスポンスヘッダ・本文」 がそのまま 1 画面に 並びます。HTTPS だと暗号文が並ぶので意味不明 ─ 次節の TLS 復号と組み合わせると一気に有用になります。

TLS を復号する ─ SSLKEYLOGFILE を使う

セットアップ例(macOS / Linux)

# Chrome を SSLKEYLOGFILE つきで起動(macOS)
export SSLKEYLOGFILE="$HOME/sslkeys.log"
open -a "Google Chrome"

# curl の場合
curl --tlsv1.3 --keylog-file ~/sslkeys.log https://example.com/

# Linux で Firefox
SSLKEYLOGFILE=/tmp/sslkeys.log firefox &

sslkeys.log の中身は次のようなテキスト:

CLIENT_HANDSHAKE_TRAFFIC_SECRET 52d7e2bc... 4a91c0ab8f...
SERVER_HANDSHAKE_TRAFFIC_SECRET 52d7e2bc... 8d3f7e21a4...
CLIENT_TRAFFIC_SECRET_0          52d7e2bc... 1b22b7f0c9...
SERVER_TRAFFIC_SECRET_0          52d7e2bc... 6e0d8c4915...

Wireshark はこれらの secrets を使って TLS 1.3 のキーを再構成し、暗号文を復号して上の階層(HTTP/2) を表示できるようになります。

つながる知識: SSLKEYLOGFILE は RFC 文書ではなく業界事実上の標準(NSS Keylog format)。OpenSSL は SSL_CTX_set_keylog_callback() で出力できる。本機構があるからこそ、自社の HTTPS バックエンドとの通信不具合を Wireshark で追える。一方で 本番環境で常に有効化してはいけない(鍵が平文ファイルとして残る) ─ デバッグ時のみ、安全な手元環境で。

tshark で自動化 ─ CLI でフィールドだけ抜く

よく使うレシピ

# 1) ライブで HTTP リクエストの URI だけ表示
tshark -i en0 -Y 'http.request' -T fields -e ip.dst -e http.host -e http.request.uri

# 2) pcap から DNS クエリ名を集計
tshark -r capture.pcapng -Y 'dns.qry.name' \
       -T fields -e dns.qry.name | sort | uniq -c | sort -rn | head

# 3) TLS の SNI(Server Name Indication) 一覧
tshark -r capture.pcapng -Y 'tls.handshake.extensions_server_name' \
       -T fields -e tls.handshake.extensions_server_name | sort -u

# 4) TCP ストリームの統計(再送・損失・ACK重複)
tshark -r capture.pcapng -q -z conv,tcp

# 5) JSON 出力(jq などへ流す)
tshark -r capture.pcapng -Y 'http.request' -T json | jq '.[] | ._source.layers.http'

# 6) リングバッファでの長時間キャプチャ(100MB × 5 ファイルでローテート)
dumpcap -i en0 -b filesize:100000 -b files:5 -w rotating.pcap

覚えるべき主要オプション:-i インタフェース、-r 入力 pcap、-w 出力 pcap、-Y 表示フィルタ、-f 取得フィルタ、-T fields -e ... 指定フィールド抽出、-q -z 統計表示。

つながる知識: サーバ上で問題を再現するときは、SSH 越しに root で tcpdump して pcap を持ち帰る のが定石。tcpdump -i any -w /tmp/x.pcap host 10.0.0.5 and port 443 のような形で取り、scp で手元へ。tshark は GUI 不要なので CI / 自動テスト・回帰検査に組み込みやすい。

よくあるトラブルシュートのレシピ

つながる知識: ここで挙げた症状の多くは、過去のレッスンで原理を学んだもの ─ TCP(第18回)、IP/ICMP/MTU(第20回)、TLS(第25回)、DNS(第13・39回)、ファイアウォール(第27回)。Wireshark は「学んだことを目で確認する装置」。逆に、原理を知らないと表示が読めない。教科書とパケット観察は両輪で動かすのが効きます。

まとめと用語チェック

用語チェック

確認問題