パケットキャプチャーを仕事で使えるレベルまで学ぶ方法

対象レベル：Level 1〜2
想定読了時間：25分
この記事で身につくこと：パケットを正しく取得し、障害原因の仮説を立て、調査結果を相手に説明するための学習手順

Wiresharkをインストールして、パケット一覧を眺めてみたものの、何を見ればよいのか分からない。

赤や黒に色付けされたパケットを見つけても、それが本当に障害原因なのか判断できない。

このような悩みを持つネットワークエンジニアは少なくありません。

重要なのは、次の流れを自力で実行できるようになることです。

1. 発生している事象を整理する
2. 適切な場所でパケットを取得する
3. 調査対象の通信だけに絞り込む
4. 通信を時系列で読む
5. 分かった事実と推測を分けて説明する

本記事では、Wiresharkの基本操作だけでなく、パケットキャプチャーを障害対応や顧客説明で使えるレベルまで引き上げる学習方法を解説します。

結論：仕事で使える人は「パケットの物語」を読んでいる

仕事でパケットキャプチャーを使える人は、大量のパケットを一枚ずつ眺めているわけではありません。

まず、次のような仮説を立てています。

クライアントからサーバーへTCP SYNは届いているのか。
SYN-ACKはどこまで戻っているのか。
TCP接続後、アプリケーションから応答が返るまでに何秒かかっているのか。

そのうえで、必要な通信だけを抽出し、時系列に沿って確認します。

つまり、パケット解析とは「怪しいパケットを探す作業」ではなく、通信開始から終了までの流れを追い、正常な動作から外れた場所を見つける作業です。

仕事で使えるレベルの目安は、次の5つです。

パケットキャプチャーを学んでも実務で使えない5つの理由

1. Wiresharkの操作から学び始めている

Wiresharkは通信を表示するためのツールです。

TCP/IPの動作を理解していない状態で操作方法だけ覚えても、表示された内容を判断できません。

例えば、TCPのSequence NumberとAcknowledgment Numberの関係が分からなければ、再送や欠損を正しく読み取ることは困難です。

先に学ぶべきなのは、Wiresharkのメニューではなく、通信が本来どのような順番で進むのかです。

2. パケットを取得する場所を考えていない

同じ通信でも、クライアント側、ファイアウォールの前後、サーバー側では見える内容が異なります。

クライアント側でSYNを確認できても、それだけではサーバーまで届いたとは断定できません。

途中にNAT、ロードバランサー、VPN装置、プロキシー、ファイアウォールがある場合は、送信元・宛先アドレスやポート番号が途中で変わることもあります。

3. 最初からすべての通信を見ようとしている

数万件、数十万件のパケットをそのまま読もうとすると、必要な通信を見失います。

最初に確認すべきなのは、次の情報です。

• 事象が発生した正確な時刻
• 問題が発生した端末のIPアドレス
• 接続先のIPアドレスまたはFQDN
• 使用しているプロトコルとポート番号
• 正常な端末や正常な時間帯との違い

4. Wiresharkの警告を原因だと決めつけている

WiresharkのExpert Informationは、通信上の異常や注目すべきイベントを見つけるための出発点です。

ただし、Wiresharkの公式ガイドでも、Expert Informationはあくまで調査のヒントであり、表示された項目が必ず問題を意味するわけではないと説明されています。

原文：

Expert information is only a hint
Expert information is the starting point for investigation, not the stopping point. Every network is different, and it’s up to you to verify that Wireshark’s expert information applies to your particular situation. The presence of expert information doesn’t necessarily indicate a problem and absence of expert information doesn’t necessarily mean everything is OK.

日本語訳：

専門家の情報はヒントに過ぎない
専門家の情報は調査の出発点であり、終着点ではありません。ネットワークはそれぞれ異なるため、Wiresharkの専門家情報がご自身の状況に当てはまるかどうかを確認するのは、ユーザー自身の責任です。専門家情報が存在するからといって必ずしも問題があるとは限らず、専門家情報がないからといって必ずしも問題がないとは限りません。

例えば、TCP Retransmissionが表示されたとしても、次の可能性があります。

• 実際にネットワーク上でパケットが失われた
• キャプチャー端末がパケットを取りこぼした
• 片方向の通信しか取得できていない
• 取得開始前の通信が不足している
• 同じパケットを複数箇所から重複して取得した

表示されたラベルだけで原因を断定してはいけません。

5. 分析結果を相手に説明できない

技術者本人が原因を理解していても、報告が次のようになってしまうことがあります。

WiresharkでRetransmissionが出ています。
ネットワークが怪しいと思います。

これでは、どこで何が起きているのか分かりません。

仕事では、少なくとも次のように説明する必要があります。

10時32分14秒から、クライアントがサーバー宛てにTCP SYNを3回送信していますが、SYN-ACKを受信していません。クライアント側では接続要求の送信を確認できましたが、サーバー側での到達状況は未確認です。
次に、ファイアウォールの破棄ログとサーバー側キャプチャーを確認します。

最初に学ぶべきTCP/IPの範囲

パケットキャプチャーを学ぶために、TCP/IPのすべてを暗記する必要はありません。

まずは次の範囲を優先します。

正常な通信を先に覚える

異常を見分けるためには、正常な通信を知っている必要があります。

TCPであれば、最初に次の流れを自分でキャプチャーしてください。

sequenceDiagram
    autonumber
    participant C as クライアント
    participant S as サーバー

    C->>S: SYN
    S-->>C: SYN / ACK
    C->>S: ACK

    Note over C,S: TCP接続確立

    C->>S: Application Data
    S-->>C: Application Data

    C->>S: FIN / ACK
    S-->>C: ACK
    S-->>C: FIN / ACK
    C->>S: ACK

    Note over C,S: TCP接続終了

TCPの現在の標準仕様はRFC 9293にまとめられており、接続確立や制御ビットなど、Wiresharkで確認するTCP動作の基礎になっています。

パケットを取得する場所を決める

パケット解析では、取得場所が非常に重要です。

取得場所によって見える事実が異なります。

flowchart LR
    C[クライアント<br/>10.10.10.25]
    F[ファイアウォール<br/>NAT・ACL・QoS]
    L[ロードバランサー<br/>VIP・SSL終端]
    S[サーバー<br/>172.16.20.10]

    C -->|通信| F
    F -->|通信| L
    L -->|通信| S

    CP1((取得地点A))
    CP2((取得地点B))
    CP3((取得地点C))
    CP4((取得地点D))

    CP1 -.-> C
    CP2 -.-> F
    CP3 -.-> L
    CP4 -.-> S

    A1[アプリケーションが<br/>通信を開始したか確認]
    A2[破棄・NAT・遅延の<br/>境界を確認]
    A3[VIP変換・SSL終端後の<br/>通信を確認]
    A4[サーバーへの到達と<br/>応答を確認]

    CP1 --- A1
    CP2 --- A2
    CP3 --- A3
    CP4 --- A4

例えば、クライアントからサーバーへの通信が失敗している場合、次の3地点で取得できると、障害区間を絞りやすくなります。

A：クライアント側

確認できること：

• アプリケーションが通信を開始しているか
• DNS問い合わせが発生しているか
• TCP SYNを送信しているか
• サーバーから応答を受信しているか
• クライアント自身がRSTを送信していないか

B：ネットワーク機器の前後

確認できること：

• ファイアウォールまでパケットが届いているか
• NATの前後でアドレスがどう変化しているか
• ファイアウォール通過後もパケットが存在するか
• QoSやVPN処理の前後で遅延が発生していないか

スイッチ上で取得する場合は、SPANやポートミラーリングを利用します。重要な障害調査では、ネットワークTAPを使用するケースもあります。

C：サーバー側

確認できること：

• サーバーまでリクエストが届いているか
• サーバーがSYN-ACKやRSTを返しているか
• アプリケーションが応答するまでに時間がかかっていないか
• サーバーがZero Windowを通知していないか

取得場所を決めるための質問

パケットを取り始める前に、次の質問に答えます。

どの地点まで通信が届いていることを証明したいのか。

「とりあえず端末でWiresharkを起動する」のではなく、調査したい境界を明確にすることが重要です。

現場で使えるパケット分析のステップ

flowchart TD
    A[事象を具体的に整理する] --> B[取得場所を決める]
    B --> C[正常時と異常時を取得する]
    C --> D[IPアドレス・ポート・<br/>時刻で絞る]
    D --> E[通信開始地点まで戻る]
    E --> F[セッション単位で<br/>時系列に読む]
    F --> G[パケット間の<br/>時間差を確認する]
    G --> H[再送・RST・<br/>ICMPなどを確認する]
    H --> I[正常時と異常時を比較する]
    I --> J[事実と推測を分ける]
    J --> K[追加調査を決める]
    K --> L[顧客・上司へ報告する]

STEP 1：事象を具体的な文章にする

「通信が遅い」だけでは、調査条件が不十分です。

次の形式で整理します。

2026年7月19日9時20分ごろ、クライアント10.10.10.25から業務システムapp.example.localへログインすると、認証画面の表示まで約15秒かかる。通常は2秒以内で表示される。

最低限、次の情報を記録します。

STEP 2：正常系と異常系を取得する

異常時のキャプチャーだけでは、どこが通常と違うのか判断しにくくなります。

できる限り、次の2つを用意します。

• 正常に通信できる端末または時間帯
• 問題が発生する端末または時間帯

比較する項目は次のとおりです。

• DNS応答時間
• TCP接続確立時間
• TLSハンドシェイク時間
• リクエスト送信から応答開始までの時間
• 再送回数
• TCP Windowの変化
• サーバーから返されるステータスコード

STEP 3：対象通信だけに絞る

パケットキャプチャーには、ARP、DNS、OSのバックグラウンド通信、監視通信など、多くの無関係な通信が含まれます。

最初は次の5つを使って絞り込みます。

送信元IPアドレス
宛先IPアドレス
送信元ポート
宛先ポート
プロトコル

この組み合わせは「5タプル」と呼ばれ、1つの通信を識別する基本情報になります。

STEP 4：通信開始から順番に読む

問題が起きたパケットだけを見るのではなく、通信の開始地点まで戻ります。

Webアクセスでは、HTTPだけを見るのではなく、
ARPやDNSから順番に確認します。

flowchart TD
    A[ユーザーがURLを入力] --> B[ARPによるMACアドレス解決]
    B --> C[DNSによる名前解決]
    C --> D[TCP 3-way handshake]
    D --> E[TLS handshake]
    E --> F[HTTPリクエスト送信]
    F --> G[サーバーでリクエスト処理]
    G --> H[HTTPレスポンス受信]
    H --> I[HTML・CSS・<br/>JavaScriptを解析]
    I --> J[追加リソースを取得]
    J --> K[Webページを表示]

    C -. 名前解決失敗 .-> X1[Webサーバーへ<br/>接続できない]
    D -. TCP接続失敗 .-> X2[タイムアウト<br/>または接続拒否]
    E -. TLS失敗 .-> X3[証明書・暗号方式エラー]
    G -. 処理遅延 .-> X4[ページ表示が遅い]

Webアクセスを通信相手ごとに分けると、次のような流れになります。

sequenceDiagram
    autonumber
    actor U as ユーザー
    participant C as クライアント
    participant D as DNSサーバー
    participant W as Webサーバー

    U->>C: URLを入力
    C->>D: DNS Query<br/>www.example.com
    D-->>C: DNS Response<br/>192.0.2.20

    C->>W: TCP SYN
    W-->>C: TCP SYN / ACK
    C->>W: TCP ACK

    Note over C,W: TCP接続確立

    C->>W: TLS ClientHello
    W-->>C: TLS ServerHello・証明書
    C->>W: TLS鍵交換・暗号化開始

    Note over C,W: TLSセッション確立

    C->>W: HTTP GET /
    W->>W: アプリケーション処理
    W-->>C: HTTP 200 OK・HTML

    C->>W: CSS・JavaScript・画像を要求
    W-->>C: 各リソースを返却

    C-->>U: Webページを表示

途中のプロトコルだけを見ると、本当の原因を見落とすことがあります。

例えば、HTTPS通信が始まっていない原因が、実際にはDNS応答の遅延だったというケースもあります。

STEP 5：時間差を見る

パケット解析では、内容だけでなく時間が重要です。

確認するのは、主に次の時間差です。

• DNS問い合わせから応答まで
• SYNからSYN-ACKまで
• ClientHelloからServerHelloまで
• リクエストから最初のレスポンスまで
• 再送が始まるまで
• ACKが返るまで

Wiresharkにはパケット間の時間差を表示する機能があります。frame.time_delta_displayedなどを列として追加すると、どの処理の間で待ち時間が発生しているか確認しやすくなります。

STEP 6：事実と推測を分ける

報告では、次の4項目を分けます。

Capture FilterとDisplay Filterの違い

Wiresharkには、目的の異なる2種類のフィルターがあります。

Capture Filter

パケットを取得する段階で、保存する通信を制限します。

host 192.0.2.10
tcp port 443
host 192.0.2.10 and tcp port 443
net 192.0.2.0/24

長時間取得や高トラフィック環境では、不要なパケットを保存しないために有効です。

ただし、Capture Filterで除外されたパケットは、後から確認できません。最初から条件を狭くしすぎると、DNSやICMPなど、原因特定に必要な通信を取り逃す可能性があります。

Display Filter

取得済みのパケットから、画面に表示する通信を絞り込みます。

ip.addr == 192.0.2.10
tcp.port == 443
dns
tcp.stream eq 5
tcp.analysis.retransmission

WiresharkとTSharkは共通の表示フィルターエンジンを使用しており、プロトコルやフィールドの存在確認、値の比較、フィールド同士の比較などが可能です。

TSharkでは、-fがCapture Filter、-YがDisplay Filterです。Capture Filterは取得時にパケットを破棄する仕組みであり、Display Filterとは構文も処理方法も異なります。

最初に覚えたい表示フィルター

IPアドレスで絞る

ip.addr == 192.0.2.10

送信元または宛先に指定したIPアドレスが含まれるパケットを表示します。

方向を限定する場合は、次のように指定します。

ip.src == 192.0.2.10
ip.dst == 192.0.2.20

TCPポートで絞る

tcp.port == 443
tcp.dstport == 443
tcp.srcport == 443

TCPの接続開始を確認する

tcp.flags.syn == 1

SYNだけに限定したい場合は、次のようにします。

tcp.flags.syn == 1 && tcp.flags.ack == 0

Boolean型のフィールドは、フィールド名を書くだけでは値がTrueであることを意味しない場合があります。SYNがセットされた通信だけを確認する場合は、公式ガイドでもtcp.flags.syn == 1のような比較が案内されています。

RSTを確認する

tcp.flags.reset == 1

再送を確認する

tcp.analysis.retransmission
tcp.analysis.fast_retransmission

Duplicate ACKを確認する

tcp.analysis.duplicate_ack

Zero Windowを確認する

tcp.analysis.zero_window

DNSエラーを確認する

dns.flags.rcode != 0

ICMPエラーを確認する

icmp
icmpv6

特定のTCPセッションだけを見る

tcp.stream eq 5

tcp.streamの番号は、対象パケットのTCP詳細から確認できます。

Follow TCP Streamで1つの通信を追う

対象のTCPパケットを右クリックし、次のメニューを選択します。

Follow
└ TCP Stream

Follow TCP Streamを使用すると、選択したTCPストリームに属するパケットだけを表示できます。

Wireshark公式ガイドによると、Follow機能はTCPだけでなく、UDP、TLS、HTTP、HTTP/2、QUIC、WebSocket、SIPなど複数のプロトコルに対応しています。

特に便利なのは、Follow TCP Streamを開いた直後に閉じ、生成されたフィルターだけを利用する方法です。

ただし、TLSで暗号化された通信は、暗号化後のアプリケーションデータをそのまま読むことはできません。

それでも、次の情報は確認できます。

• TCP接続の成否
• TLS ClientHelloとServerHello
• Server Name Indication
• 証明書交換
• TLS Alert
• パケットサイズ
• 応答時間
• 再送やRSTの有無

TCP 3-way handshakeを読めるようにする

WiresharkはTCPセッションの状態を追跡し、SEQ・ACKの関係から、再送やOut-of-Orderなどの解析情報を追加します。これらは、キャプチャーファイルを開いた際に、パケットの並び順を基に計算されます。

正常な接続

Client → Server：SYN
Server → Client：SYN, ACK
Client → Server：ACK

この3つが確認できれば、TCP接続は確立しています。

sequenceDiagram
    autonumber
    participant C as クライアント
    participant S as サーバー

    C->>S: SYN
    S-->>C: SYN / ACK
    C->>S: ACK

    Note over C,S: TCP接続確立

    C->>S: Application Data
    S-->>C: Application Data

    C->>S: FIN / ACK
    S-->>C: ACK
    S-->>C: FIN / ACK
    C->>S: ACK

    Note over C,S: TCP接続終了

ただし、TCP接続が確立したからといって、アプリケーションが正常とは限りません。

その後のTLSやHTTPも確認します。

SYNが繰り返し送信される

Client → Server：SYN
Client → Server：SYN Retransmission
Client → Server：SYN Retransmission

考えられる原因候補：

• 宛先IPアドレスまで到達していない
• 途中のファイアウォールが破棄している
• 戻り経路が存在しない
• サーバーが停止している
• サーバー側で応答が破棄されている

sequenceDiagram
    autonumber
    participant C as クライアント
    participant F as ファイアウォール・ネットワーク
    participant S as サーバー

    C->>F: SYN
    F--xS: 到達しない、または破棄
    Note right of C: SYN-ACKを受信できない

    C->>F: SYN 再送1回目
    F--xS: 到達しない、または破棄

    C->>F: SYN 再送2回目
    F--xS: 到達しない、または破棄

    Note over C,S: 接続タイムアウト

    rect rgb(255, 240, 240)
        Note over C,S: 原因候補<br/>・経路障害<br/>・ファイアウォールでの破棄<br/>・戻り経路の不備<br/>・サーバー停止
    end

クライアント側キャプチャーだけでは、どこで破棄されたかは分かりません。

サーバー側のキャプチャーやファイアウォールログと組み合わせて確認します。

SYNに対してRSTが返る

Client → Server：SYN
Server → Client：RST, ACK

考えられる原因候補：

• 対象ポートでサービスが待ち受けていない
• サーバーまたはネットワーク機器が明示的に接続を拒否した
• 接続先ポート番号を間違えている

sequenceDiagram
    autonumber
    participant C as クライアント
    participant S as サーバー

    C->>S: SYN
    S-->>C: RST / ACK

    Note over C,S: 接続拒否

    rect rgb(255, 245, 230)
        Note over C,S: 原因候補<br/>・サービスが待ち受けていない<br/>・接続先ポートが間違っている<br/>・サーバーが明示的に拒否している
    end

接続後にRSTが送信される

RSTを送信した機器と、その直前の通信内容を確認します。

ただし、パケット上の送信元IPアドレスだけで、必ずその端末がRSTを生成したとは限りません。

途中のファイアウォールやロードバランサーが、送信元を模倣してRSTを返す構成もあるため、複数地点での確認が必要です。

再送を見つけたときの確認方法

tcp.analysis.retransmissionが表示されたら、次の順番で確認します。

1. 再送された方向を確認する

クライアントからサーバー方向なのか、サーバーからクライアント方向なのかを確認します。

方向によって、問題が発生している可能性のある経路が変わります。

2. ACKが返っているか確認する

送信したデータに対するACKが返っているか確認します。

ACKがキャプチャー上に存在しない場合でも、実際にネットワーク上で失われたとは限りません。取得地点やキャプチャー漏れも考慮します。

3. 同じ時刻に複数通信で発生しているか確認する

特定の1セッションだけで発生しているのか、複数の通信で同時に発生しているのかを確認します。

複数通信で同時に発生していれば、共通する回線やネットワーク機器を疑う材料になります。

4. 正常時と比較する

再送が1件存在することだけでは、利用者への影響を判断できません。

正常時にも同程度の再送が発生していないか確認します。

遅延調査では「どの区間で待っているか」を見る

flowchart TD
    A[Webアクセスが遅い] --> B{DNS応答は速いか}

    B -- いいえ --> B1[DNS QueryとResponseの時間差を確認]
    B1 --> B2[DNSサーバー・名前解決経路を調査]

    B -- はい --> C{TCP接続は速いか}

    C -- いいえ --> C1[SYNからSYN-ACKまでの時間を確認]
    C1 --> C2[経路・FW・サーバー負荷を調査]

    C -- はい --> D{TLS接続は速いか}

    D -- いいえ --> D1[ClientHelloからServerHelloまでを確認]
    D1 --> D2[証明書・暗号方式・SSL終端装置を調査]

    D -- はい --> E{HTTP応答は速いか}

    E -- いいえ --> E1[リクエストから最初の応答までを確認]
    E1 --> E2[Web・AP・DBサーバーの処理時間を調査]

    E -- はい --> F{データ転送中に再送があるか}

    F -- はい --> F1[RetransmissionとDuplicate ACKを確認]
    F1 --> F2[回線品質・輻輳・インターフェースを調査]

    F -- いいえ --> G[クライアント側の描画・処理を調査]

通信が遅い場合、単に「パケット間隔が空いている場所」を探すだけでは不十分です。

次のように、待ち時間の責任を分けて考えます。

DNSの応答待ち
TCP接続の応答待ち
TLS接続の応答待ち
サーバー処理の応答待ち
クライアント処理の待ち時間
ネットワーク上の再送待ち

例えば、HTTPリクエストをサーバーが受信した後、15秒間パケットがなく、その後にHTTPレスポンスが返っている場合、ネットワーク転送よりもサーバー処理に時間がかかっている可能性があります。

一方、データ送信中に再送とDuplicate ACKが繰り返されている場合は、ネットワーク上の損失を疑う材料になります。

遅延調査の基本

全体の所要時間
  ↓
DNSにかかった時間
  ↓
TCP接続にかかった時間
  ↓
TLSにかかった時間
  ↓
アプリケーション応答までの時間
  ↓
データ転送にかかった時間

一つの「遅い」という事象を、複数の処理時間に分解することが重要です。

Expert Informationの正しい使い方

Wiresharkのメニューから、次を開きます。

Analyze
  └ Expert Information

Expert Informationでは、次のような項目を一覧化できます。

• TCP Retransmission
• TCP Out-of-Order
• Duplicate ACK
• RST
• DNSエラー
• HTTPエラー
• 不正なパケット形式
• チェックサム関連の警告

ただし、Expert Informationは答えではありません。

正しい使い方は、次の流れです。

Expert Informationで注目箇所を見つける
  ↓
該当パケットの前後を確認する
  ↓
同じTCP Stream全体を確認する
  ↓
正常系と比較する
  ↓
取得地点や機器ログと照合する

仕事用のWiresharkプロファイルを作る

Wiresharkでは、表示列、表示フィルター、Capture Filter、Coloring RulesなどをConfiguration Profileとして保存できます。

公式ガイドでは、プロファイルごとにPreferences、Capture Filters、Display Filters、Coloring Rules、Decode Asの設定などを管理できると説明されています。

例えば、次のプロファイルを作成します。

TCP障害調査プロファイル

表示列：

No.
Time
Source
Destination
Source Port
Destination Port
TCP Stream
TCP Length
TCP Window
Delta Time
Info

保存するフィルター：

tcp.flags.syn == 1
tcp.flags.reset == 1
tcp.analysis.retransmission
tcp.analysis.duplicate_ack
tcp.analysis.zero_window

DNS障害調査プロファイル

表示列：

Time
Source
Destination
DNS ID
Query Name
Response Code
Response Time
Info

保存するフィルター：

dns
dns.flags.response == 0
dns.flags.response == 1
dns.flags.rcode != 0

案件や調査目的ごとにプロファイルを分けることで、初動調査を速くできます。

TSharkを使って調査を自動化する

GUI操作に慣れたら、WiresharkのCLI版であるTSharkも学びます。

TSharkはライブ通信の取得と、保存済みキャプチャーファイルの解析に対応しています。標準の保存形式にはpcapngを使用できます。

通信を取得する

tshark -i 1 \
  -f "host 192.0.2.10 and tcp port 443" \
  -w incident.pcapng

再送パケットを抽出する

tshark -r incident.pcapng \
  -Y "tcp.analysis.retransmission"

必要なフィールドだけを表示する

tshark -r incident.pcapng \
  -Y "tcp.analysis.retransmission" \
  -T fields \
  -e frame.number \
  -e frame.time \
  -e ip.src \
  -e ip.dst \
  -e tcp.stream \
  -e tcp.seq \
  -e tcp.ack

DNSエラーをCSV形式で出力する

tshark -r incident.pcapng \
  -Y "dns.flags.rcode != 0" \
  -T fields \
  -E header=y \
  -E separator=, \
  -e frame.time \
  -e ip.src \
  -e ip.dst \
  -e dns.qry.name \
  -e dns.flags.rcode

TSharkを使えるようになると、複数のキャプチャーファイルから共通の異常を探したり、定型的な調査結果をCSVに出力したりできます。

自宅で作れる練習環境

パケットキャプチャーは、動画を見るだけでは身につきません。

自分で正常通信と異常通信を発生させ、違いを比較することが重要です。

最小構成は次のとおりです。

• Wiresharkを動かす解析端末
• Linux仮想マシン
• Webサーバー
• DNSサーバー
• curl、ping、iperf3などの通信生成ツール

VirtualBox、VMware、Hyper-V、Dockerなどを利用できます。

演習1：TCP接続の成功と拒否を比較する

1. Webサーバーを起動する
2. curlで正常にアクセスする
3. Webサーバーを停止する
4. 同じ宛先へアクセスする
5. 正常時と異常時のTCP接続を比較する

確認項目：

• SYNの送信回数
• SYN-ACKまたはRSTの有無
• 接続完了までの時間
• RSTを送信した方向

演習2：DNSエラーを確認する

存在する名前と存在しない名前を問い合わせます。

nslookup www.example.com
nslookup not-found-name.example

確認項目：

• Query Name
• Query Type
• Transaction ID
• Response Code
• 問い合わせから応答までの時間

演習3：遅延を発生させる

Linuxのtc netemを利用すると、検証環境で遅延やパケット損失を発生させられます。

sudo tc qdisc add dev eth0 root netem delay 200ms

解除：

sudo tc qdisc del dev eth0 root

確認項目：

• TCP接続時間の変化
• ACKが返るまでの時間
• アプリケーション応答時間
• 正常時とのグラフの違い

演習4：パケット損失を発生させる

sudo tc qdisc add dev eth0 root netem loss 5%

確認項目：

• Retransmission
• Fast Retransmission
• Duplicate ACK
• 通信速度の低下
• 再送がアプリケーションに与える影響

検証は、必ず自分が管理する閉じた環境で実施してください。

Wireshark公式Wikiには、HTTPやTCP Window Scalingなどを含むサンプルキャプチャーも公開されています。自分で再現することが難しいプロトコルの学習に利用できます。

8週間の学習ロードマップ

flowchart TD
    W1[1週目<br/>Ethernet・ARP・IP]
    W2[2週目<br/>TCPの基本]
    W3[3週目<br/>Wireshark操作]
    W4[4週目<br/>DNS・HTTP・TLS]
    W5[5週目<br/>TCP異常解析]
    W6[6週目<br/>複数地点の比較]
    W7[7週目<br/>TShark自動化]
    W8[8週目<br/>障害報告演習]

    W1 --> W2 --> W3 --> W4 --> W5 --> W6 --> W7 --> W8

1週目：Ethernet・ARP・IP

学習内容：

• Ethernetヘッダー
• MACアドレス
• ARP RequestとARP Reply
• IPv4ヘッダー
• TTL
• ICMP

成果物：

ping実行時のARPとICMPの流れを、パケット番号付きで説明する。

2週目：TCPの基本

学習内容：

• SYN、ACK、FIN、RST
• Sequence Number
• Acknowledgment Number
• Window Size
• TCP 3-way handshake

成果物：

TCP接続開始から終了までを図にし、それぞれのパケットの役割を説明する。

3週目：Wiresharkの基本操作

学習内容：

• Capture Filter
• Display Filter
• 列の追加
• Follow TCP Stream
• Expert Information
• Configuration Profile

成果物：

TCP調査用とDNS調査用のプロファイルを作成する。

4週目：DNS・HTTP・TLS

学習内容：

• DNS QueryとResponse
• DNS Response Code
• HTTPリクエストとレスポンス
• TLS ClientHelloとServerHello
• 暗号化通信で見える情報と見えない情報

成果物：

Webサイトへアクセスした際のDNS、TCP、TLSの順番を説明する。

5週目：TCP異常の読み方

学習内容：

• Retransmission
• Fast Retransmission
• Duplicate ACK
• Out-of-Order
• Zero Window
• RST

成果物：

再送を含むキャプチャーを分析し、原因候補と追加調査を記載する。

6週目：複数地点の比較

学習内容：

• クライアント側取得
• サーバー側取得
• SPAN・ポートミラーリング
• NAT前後の比較
• 時刻同期

成果物：

2地点のキャプチャーから、パケットが失われた可能性のある区間を説明する。

7週目：TSharkによる自動化

学習内容：

• pcapngファイルの読み込み
• Display Filterによる抽出
• Fields形式での出力
• CSV出力
• 複数ファイルの一括調査

成果物：

再送、RST、DNSエラーを抽出するコマンド集を作成する。

8週目：障害報告まで実施する

学習内容：

• 事象整理
• 仮説作成
• パケット取得
• 分析
• 顧客・上司への報告

成果物：

キャプチャーファイル、分析メモ、障害報告書を1セットで作成する。

パケット解析でよくある失敗

取得時刻を記録していない

利用者の操作時刻が分からなければ、対象通信を絞れません。

可能であれば秒単位で記録します。

キャプチャー端末の時刻がずれている

複数地点のキャプチャーを比較する場合は、時刻同期が重要です。

数秒ずれているだけでも、パケットの対応関係を判断しにくくなります。

Capture Filterを狭くしすぎる

TCP 443だけを取得すると、直前に発生したDNSエラーやICMPエラーを確認できないことがあります。

初回調査では必要な周辺通信を残し、取得後にDisplay Filterで絞る方法も検討します。

異常時のパケットしか取得していない

正常系との比較がなければ、異常に見える動作が実は通常動作だったという可能性を排除できません。

1地点のキャプチャーだけで原因を断定する

クライアント側で応答が見えないことは確認できても、途中で破棄されたのか、サーバーが応答していないのかは判断できません。

キャプチャーファイルだけを渡す

調査結果には、対象パケット番号、時刻、フィルター、確認した事実を添えます。

機密情報を考慮していない

パケットキャプチャーには、IPアドレス、ホスト名、URL、Cookie、認証情報、業務データなどが含まれる可能性があります。

取得前に承認を得て、保存場所、共有範囲、保管期間、削除方法を確認してください。

顧客・上司への説明方法

悪い報告例：

パケットロスが発生しています。
Wiresharkで再送が出ているのでネットワーク障害です。

改善した報告例：

9時20分15秒から9時20分22秒までの通信を確認しました。クライアントからサーバー方向に送信されたTCPデータの一部で再送が3回発生しています。同じ時間帯にDuplicate ACKも確認でき、クライアントからサーバー方向の通信で損失が発生した可能性があります。

ただし、今回のキャプチャーはクライアント側だけで取得しているため、実際の損失地点は確定していません。次に、サーバー側キャプチャーとファイアウォールのインターフェースカウンターを確認します。

報告テンプレート

■発生事象
2026年7月19日9時20分ごろ、業務システムへのログインに
通常2秒のところ約15秒かかった。

■取得条件
取得地点：クライアント端末
送信元：10.10.10.25
宛先：172.16.20.10
対象ポート：TCP 443
取得時間：9:20:10～9:20:40

■確認できた事実
・DNS応答は20ミリ秒以内
・TCP 3-way handshakeは完了
・HTTPリクエスト相当のデータ送信後、約12秒間応答なし
・応答待ちの間にTCP再送は発生していない
・12秒後にサーバー方向から応答を受信

■現時点の推測
ネットワーク転送よりも、サーバーまたはアプリケーション処理に
時間がかかっている可能性がある。

■未確認事項
サーバーがリクエストを受信した時刻と、
アプリケーション内部の処理時間は未確認。

■次の対応
サーバーログとアプリケーションログの時刻を照合する。

英語ドキュメントで覚えたい用語

海外ベンダーへの問い合わせ例

We captured packets on the client side during the issue.

The client sent three TCP SYN packets to 192.0.2.20 on port 443,
but no SYN-ACK was observed.

At this point, we have not confirmed whether the SYN packets
reached the server.

Could you please check the firewall logs and the packet capture
on the server side between 09:20:10 and 09:20:40 JST?

日本語訳：

事象発生中にクライアント側でパケットを取得しました。
クライアントは192.0.2.20のTCP 443番ポートへSYNを3回送信しましたが、SYN-ACKは確認できませんでした。
現時点では、SYNがサーバーまで到達したか確認できていません。
日本時間9時20分10秒から9時20分40秒までのファイアウォールログと、サーバー側のパケットキャプチャーを確認してください。

実務レベルに到達したかを確認するチェックリスト

次の項目にすべて答えられれば、パケットキャプチャーを実務で使うための基礎が身についています。

• 問題が発生した時刻、端末、接続先、操作を整理できる
• 調査目的に合った取得地点を選べる
• Capture FilterとDisplay Filterを使い分けられる
• 5タプルを使って対象通信を特定できる
• TCP 3-way handshakeを説明できる
• SYN再送とRSTの違いを説明できる
• DNS問い合わせと応答を対応付けられる
• TCP Stream単位で通信を追える
• パケット間の時間差を確認できる
• Expert Informationを原因確定ではなく調査の入口として使える
• 正常時と異常時を比較できる
• 複数地点のキャプチャーを比較できる
• 事実と推測を分けて報告できる
• キャプチャーファイルの機密性を考慮できる
• TSharkで定型的な抽出ができる

まとめ

パケットキャプチャーを仕事で使えるようになるためには、Wiresharkの機能を大量に暗記する必要はありません。

重要なのは、次の順番で学ぶことです。

TCP/IPの正常動作を理解する
        ↓
適切な地点でパケットを取得する
        ↓
対象通信をセッション単位で絞る
        ↓
通信開始から時系列で読む
        ↓
正常系と異常系を比較する
        ↓
事実・推測・未確認事項を分けて報告する

最初は、ping、DNS、HTTP、TCP接続など、自分で発生させた単純な通信から始めてください。

その後、接続拒否、名前解決失敗、遅延、パケット損失などを検証環境で再現します。

パケットキャプチャーは、ネットワークの内部で実際に起きたことを確認できる強力な証拠です。

一方で、1地点のキャプチャーだけですべてが分かるわけではありません。

パケット、機器ログ、サーバーログ、監視情報を組み合わせ、観測できた事実から障害区間を少しずつ絞り込むことが、現場で評価されるネットワークエンジニアへの第一歩です。