【初心者向け】Wiresharkによるパケット解析の基礎｜見方・使い方をやさしく解説

はじめに

サーバやネットワークを扱っていると、「Webサイトが表示されない」「通信が遅い」「なぜか接続できない」といった問題に遭遇することがあります。

こうした通信トラブルの原因を調べる手段のひとつがパケット解析です。本記事では、パケット解析ツールとして広く使われている Wireshark を使い、初心者向けに「何を見るのか」「どう使うのか」をやさしく解説します。

Wiresharkとは？

Wiresharkは、ネットワーク上を流れる通信データ（パケット）を視覚的に確認できるオープンソースのツールです。Wiresharkを使うことで、以下のような観点を確認することができます。

  • 通信元、通信先のIPアドレス
  • 通信に使用されているプロトコル（TCPやHTTPなど）
  • 通信が正常に始まり、正常に終わっているか
  • エラーや再送が発生していないか

Linuxでよく使われる tcpdump で取得した情報をそのまま解析するのは可読性が低いので、tcpdump で取得した情報をWiresharkで解析するという流れが一般的です。

下記サイトから解析する端末のOSに応じたインストーラをダウンロードして、インストールしてみてください。
Wireshark • Go Deep | Download

Wiresharkの使い方

それでは早速、Wiresharkの使い方をご紹介します。取得したpcapファイルを開いてください。
Linuxサーバにて、tcpdumpを使ってpcapファイルを作成する方法は、以下の記事に記載しているので、合わせて参考にしてください。
https://eeengineer.com/linux-tcpdump-howto-production/

Wiresharkの画面の見方

Wiresharkでpcapファイルを開くと以下のような画面が表示されます。
画面は「パケット一覧」、「詳細情報」、「生データ」の3つに分かれています。基本的には「パケット一覧」、「詳細情報」を解析して、トラブルの原因を特定していきます。

  • パケット一覧
    取得したパケットが時系列で一覧表示されるエリアです。まずはこの一覧を確認し、通信の流れに異常がないかを確認します。
    • 送信元（Source）
    • 宛先（Destination）
    • プロトコル（TCP / HTTP など）
    • 概要（Info）

※生データの解析が必要なケース

  • プロトコル解析
    例：RFC通りのバイト構造になっているか、ヘッダやフラグの位置が正しいか
  • アプリケーションデータの確認
    実際に送付されている文字列
  • 異常データ・文字化けの調査
    文字コードの問題、想定外の文字、バイナリデータの破損確認
  • セキュリティフォレンジック
    不正なペイロード有無、攻撃パターンとの一致確認

ディスプレイフィルタ

Wiresharkのディスプレイフィルタとは、取得済みのパケットの中から、表示したいパケットだけを絞り込んで表示させる機能です。トラブルに関係がありそうな通信に絞ることで、作業効率が大幅に向上します。

左上のボックスに検索条件を入力し、右上の矢印ボタンを押下すると、ディスプレイフィルタをかけることができます。

よく使う基本的なフィルタ機能を説明します。

プロトコルの指定

プロトコルを指定することで、TCP、UDP、HTTPなどに通信を絞って表示させることができます。以下はTCPに絞った結果となります。

# フィルタ条件
tcp

IPアドレス指定

プロトコルを指定することで、TCP、UDP、HTTPなどに通信を絞って表示させることができます。以下はIPアドレスが192.168.10.110のノード間との通信に絞った結果となります。

# フィルタ条件
ip.addr == 192.168.10.110

送信元IPアドレスを指定する場合は以下となります。

# フィルタ条件
ip.src == 192.168.10.110

宛先IPアドレスを指定する場合は以下となります。

# フィルタ条件
ip.dst == 192.168.10.110

ポート番号指定

ポート番号を指定することで、特定のポートに通信を絞って表示させることができます。以下はポート番号が443(HTTPS)の通信に絞った結果となります。

# フィルタ条件
tcp.port == 443

複数条件指定

複数条件を指定することが可能です。以下は通信対象のIPアドレスが192.168.10.110、かつポート番号が443(HTTPS)通信に絞った結果となります。

# フィルタ条件
ip.addr == 192.168.10.110 and tcp.port == 443

特定の通信セッションの抽出

特定の通信セッションを抽出して表示させることが可能です。以下の通り操作してください。
確認したい通信セッションに含まれるひとつのパケットを右クリック > follow > TCP stream

以下の通り、特定の通信セッションのみを抽出した結果を表示することができます。

一連のTLS通信の内容を確認する流れを以下に記載しているので、興味がある方はこちらも参照してみてください。
【図解】HTTPS通信の仕組みとTLS1.3の流れを解説！Wireshark(パケットキャプチャ)で徹底理解

トラブル事例

意図的に通信障害を発生させた際、Wiresharkでどのように見えるかを確認してみましょう。

3-way handshake 失敗ケース

クライアントからHTTPSのWebサイトにアクセスしようとしたが、3-way handshake に失敗してアクセスできないケースを発生させています。

それぞれのパケットについて説明します。

クライアントからWebサイトに対して接続を開始しており、[SYN]を送信してます。

Webサイトからクライアントに対して[SYN, ACK]が返ってきていますが、そのあとにクライアントからWebサイトに対して[ACK]が送信できていません。

その後、[TCP Retransmission]にて再送を試みていますが、依然として3-way handshakeができていない状況です。
本ケースにおいては、クライアント側が被疑箇所となりますので、クライアント側のFWのフィルタ設定であったり、クライアントのリソースの問題などを調査し、原因を特定していきましょう。

TLS handshake 失敗ケース

クライアントからHTTPSのWebサイトにアクセスしようとしたが、TLS handshake に失敗してアクセスできないケースを発生させています。

それぞれのパケットについて説明します。

3-way handshake は成功していることが確認できます。

下記のAlertが表示されています。
Alert (Level: Fatal, Description: Protocol Version)

本Alertは、TLSハンドシェイクを開始したが、サーバがサポートしていないTLSバージョンの通信を受け取ったため、サーバ側が通信を即拒否していることを意味しています。

※一般的に、TCP通信が成立しているにも関わらず TLS Alert が返却される場合、原因はファイアウォールではなく TLSバージョンや暗号スイートの不整合であることが多いです。

Alertを受けて、TCPレイヤの後処理が実行されて、最終的にRSTパケットが返るという流れになっています。

参考（意図的なトラブル発生方法）

参考までに、意図的にネットワークトラブルを発生させる方法をご紹介します。

3-way handshake 失敗事象の発生方法

接続元サーバにて、接続先サーバから返却されるACKを拒否するルールを設定しています。

[root@appserver-dev ~]# iptables -A INPUT -p tcp --sport 443 --tcp-flags ACK ACK -j DROP
[root@appserver-dev ~]#
[root@appserver-dev ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  anywhere             anywhere             tcp spt:https flags:ACK/ACK

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
[root@appserver-dev ~]#

<iptablesコマンドのオプション>
-p tcp：TCP通信のみ
–sport 443：送信元のポート
–tcp-flags ACK ACK：ACKフラグが立っているTCPパケット
-j DROP：送信先に何も返さずに破棄

tcpdump取得コマンドは以下となります。コマンド実行中に送信先サイトにアクセスしてみてください。ACKが拒否されてサイトにアクセスできないはずです。パケットキャプチャが取得できたら、CTRL + C でコマンド終了して、出力したpcapコマンドを回収しましょう。

[root@appserver-dev ~]# tcpdump -i enp0s3 -nn -s 0 -w handshake_fail.pcap
dropped privs to tcpdump
tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C25 packets captured
25 packets received by filter
0 packets dropped by kernel
[root@appserver-dev ~]#

TLS handshake 失敗事象の発生方法

接続先サーバのApacheにて、TLS1.1を拒否する設定を追加しています。

[root@quiz ~]# vi /etc/httpd/conf.d/ssl.conf
[root@quiz ~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf
#SSLProtocol all -SSLv3
SSLProtocol all -TLSv1.1
[root@quiz ~]# systemctl restart httpd
[root@quiz ~]#

Apacheの設定変更後、クライアントからTLSv1.1を指定して接続先サーバにアクセスしようとすると、下記の通り接続が拒否される挙動となります。

[root@appserver-dev ~]# curl --tlsv1.0 --tls-max 1.0 https://eeengineer.com
curl: (35) error:0A0000BF:SSL routines::no protocols available
[root@appserver-dev ~]#

まとめ

本記事では、Wireshark を使ったパケット解析の基本として、画面の見方やディスプレイフィルタの使い方、代表的なネットワークトラブルの見え方を解説しました。

パケット解析では、すべての内容を理解しようとする必要はありません。まずは、

  • TCPの3-way handshakeが成立しているか
  • 再送（Retransmission）やRSTが発生していないか
  • TCPは成立しているのにTLS Alertが出ていないか

といったポイントを確認するだけでも、原因の切り分けは十分可能です。

Wireshark は、通信トラブルが「どのレイヤで発生しているのか」を可視化できる強力なツールです。
まずは TCP と TLS の流れを追うことを意識しながら、実際のパケットを見て慣れていきましょう。

スポンサーリンク

コメント