この記事は、 「ネットワーク中級編|構築・検証・障害切り分けを身につける」 の第32回です。
前回は検証環境の作り方を学びました。今回は、実際の通信をパケット単位で確認するための Wiresharkの基本操作を身につけます。
Wiresharkの基本操作|パケットキャプチャー・表示フィルター・見方を図解
Wiresharkを使うと、端末から実際に送受信されたパケットを確認できます。 この記事では、インターフェースの選び方、キャプチャーの開始・停止、3つの画面の見方、 表示フィルター、保存方法、パケットが見えないときの確認点まで順番に解説します。
設定やログだけでは、通信がどこまで届いているのか判断できないことがあります。 そのようなとき、パケットキャプチャーを確認すると、 端末が本当に送信したのか、相手から応答が返ったのか、どのプロトコルで止まったのか を事実として確認できます。
ただし、Wiresharkは「起動すれば原因を自動判定してくれるツール」ではありません。 正しい場所で取得し、必要な通信を絞り込み、通信の流れと照らし合わせて読むことが重要です。
この記事を読み終えるとできること
- Wiresharkの役割と利用場面を説明できる
- 通信中のインターフェースを選んでキャプチャーできる
- パケット一覧・詳細・バイト列の役割を区別できる
- ARP・ICMP・DNS・TCPなどを表示フィルターで絞り込める
- 表示フィルターとキャプチャーフィルターの違いを説明できる
- パケットが見えない場合の確認点を整理できる
Wiresharkとは何か
Wiresharkは、ネットワークインターフェースを通過するパケットを取得し、 プロトコルごとに分解して確認できるネットワークプロトコルアナライザーです。
端末が送信した通信は、Ethernet、IP、TCP、UDP、DNSなど、複数のヘッダーを持つパケットとして流れます。 Wiresharkは、取得したデータを単なる16進数ではなく、各プロトコルの項目へ分解して表示します。
Wiresharkで通信を確認するイメージ
Wiresharkが役立つ代表的な場面
通信の学習
ARP要求、ICMP Echo、TCPの3ウェイハンドシェイク、DNS問い合わせなどを、 実際のパケットで確認できます。
障害切り分け
要求は送信されているか、応答は返っているか、再送が発生しているかを確認し、 原因候補を絞り込みます。
通信要件の確認
アプリケーションが実際に使用する宛先IPアドレス、プロトコル、ポート番号を確認できます。
性能調査
応答時間、TCP再送、重複ACK、ウィンドウサイズなどを確認し、遅延やロスの兆候を探します。
Wiresharkの価値は「通信の事実を確認できること」です。
設定上は正しく見えても、実際に送受信されたパケットが想定どおりとは限りません。 パケットを確認すると、推測ではなく観測結果を根拠に切り分けられます。
利用前に知っておくべき注意点
許可された環境だけでキャプチャーする
パケットには、IPアドレス、ホスト名、URL、利用サービス、認証に関する情報などが含まれる場合があります。 業務環境で取得するときは、組織の規程、作業申請、取得範囲、保管方法、共有先を確認してください。
自分に管理権限がないネットワークや第三者の通信を、無断で取得してはいけません。
学習では、自分のPC、自宅ネットワーク、または明示的に許可された検証環境を使用してください。
Wiresharkでネットワーク全体が見えるわけではない
通常のPCで取得できるのは、基本的にそのPCのインターフェースから見える通信です。 スイッチ配下の別端末同士のユニキャスト通信は、PCへ転送されないため、そのままでは確認できません。
| 取得場所 | 主に確認できる通信 | 用途 |
|---|---|---|
| 利用者PC | そのPCが送受信する通信 | 端末起点の障害調査 |
| サーバー | そのサーバーが送受信する通信 | 要求到達・応答送信の確認 |
| スイッチのミラーポート | 指定ポートやVLANを複製した通信 | 経路上の通信確認 |
| ファイアウォールやルーターのキャプチャー | 機器を通過する対象通信 | 境界での到達・変換・破棄確認 |
障害調査では「Wiresharkを使うこと」よりも、 通信経路のどこで取得すれば判断できるかを先に考えることが重要です。
Wiresharkのインストールと起動
Windowsの場合
公式サイトからWindows用インストーラーを入手して実行します。 Windowsでライブキャプチャーを行うには、パケット取得用ドライバーの Npcapが必要です。公式インストーラーにはNpcapの導入項目が含まれています。
- 公式配布ページからインストーラーを入手する 組織管理端末では、ソフトウェア導入ルールや承認済みバージョンを確認します。
- インストーラーを実行する 学習目的であれば、通常は既定のコンポーネントで進められます。
- Npcapをインストールする Npcapがない場合、保存済みファイルは開けても、Windows上でライブキャプチャーできません。
- Wiresharkを起動する 起動画面にネットワークインターフェースの一覧が表示されることを確認します。
macOS・Linuxの場合
公式パッケージまたはOSのパッケージ管理機能を使用します。 Linuxでは、一般ユーザーがキャプチャーできるようにするための権限設定が必要になる場合があります。 安易にWireshark全体を常時管理者権限で実行するのではなく、組織やOSの推奨手順に従ってください。
画面構成やメニュー名は、OSやWiresharkのバージョンによって多少異なります。 本記事では、共通する基本操作を中心に説明します。
Wiresharkの基本操作を全体で理解する
最初に、キャプチャーから解析までの流れを覚えます。 いきなり大量のパケットを読むのではなく、 目的を決めて、短時間だけ取得し、条件で絞ることが基本です。
基本操作の6ステップ
長時間取り続けるより、事象を再現する直前から短時間取得する方が読みやすくなります。
「取得開始 → 問題を再現 → 取得停止」の順番を意識してください。
キャプチャーするインターフェースの選び方
Wiresharkの起動画面には、Ethernet、Wi-Fi、VPN、仮想アダプター、ループバックなど、 複数のインターフェースが表示される場合があります。 選ぶべきなのは、調査対象の通信が実際に通るインターフェースです。
有線LANを利用中
Ethernet、イーサネットなどの名前を選びます。
無線LANを利用中
Wi-Fi、Wirelessなどの名前を選びます。
VPN経由を調査
VPNアダプターまたは物理NICのどちらで見えるかを確認します。
選択の判断方法
-
OSで現在の接続状態を確認する
Windowsならネットワーク設定や
ipconfig、Linuxならip addressなどで、使用中のNICを確認します。 - Wiresharkの波形を見る 通信中のインターフェースは、起動画面の小さなグラフが動きます。
- IPアドレスを照合する Capture Optionsでインターフェースのアドレスを確認し、OS側のIPアドレスと照合します。
-
短時間テストする
迷う場合は数秒だけ取得して
icmpやdnsで絞り、目的の通信が見えるか確認します。
仮想化ソフト、Docker、WSL、VPNクライアントを導入しているPCでは、多数の仮想アダプターが表示されます。 名前だけで決めず、IPアドレスと実際の通信経路を確認してください。
Wiresharkのメイン画面を理解する
キャプチャーを開始すると、画面は主に3つの領域に分かれます。 まずは、それぞれの役割を区別できれば十分です。
0000 00 11 22 33 44 55 66 77 88 99 aa bb 08 00 …
上段:Packet List
現在のキャプチャーファイルに含まれるパケットが一覧表示されます。 代表的な列は次のとおりです。
| 列 | 意味 | 確認例 |
|---|---|---|
| No. | キャプチャー内のパケット番号 | 調査結果で「No.125」と記録する |
| Time | パケットを取得した時刻または経過時間 | 要求から応答までの時間を確認する |
| Source | 送信元アドレス | どの端末が送信したか確認する |
| Destination | 宛先アドレス | 想定したサーバーへ向いているか確認する |
| Protocol | Wiresharkが判別した主なプロトコル | ARP、DNS、TCP、TLSなど |
| Length | パケットの長さ | 極端に小さい・大きいパケットを確認する |
| Info | 要求、応答、フラグなどの概要 | Echo request、SYN、Standard queryなど |
中段:Packet Details
選択した1パケットを階層構造で確認します。 たとえばTCP通信では、次のように表示されます。
各行を展開すると、MACアドレス、IPアドレス、ポート番号、TCPフラグ、シーケンス番号などを確認できます。 障害調査では、上段だけで判断せず、必要に応じて中段でフィールド値を確認します。
下段:Packet Bytes
パケットの生データを16進数と文字列で表示します。 最初からバイト列を手作業で読む必要はありませんが、中段で選択したフィールドが実際のどのバイトに対応するか確認できます。
パケットをキャプチャーする基本手順
ここでは、自分のPCからデフォルトゲートウェイへpingを実行し、ICMPパケットを取得する流れを例にします。
-
デフォルトゲートウェイを確認する
Windowsでは
ipconfigを実行し、現在利用中のNICに表示されるデフォルトゲートウェイを確認します。 - Wiresharkで使用中のインターフェースを選ぶ EthernetまたはWi-Fiなど、pingが通る経路のNICを選択します。
- キャプチャーを開始する 青いサメのヒレのボタン、または対象インターフェースをダブルクリックして開始します。
- コマンドプロンプトからpingを実行する 数回だけ送信し、事象を再現します。
- キャプチャーを停止する 赤い停止ボタンを押し、取得範囲を固定します。
- 表示フィルターへicmpと入力する ICMPパケットだけを表示し、Echo requestとEcho replyが対になっているか確認します。
正常なら、Echo requestとEcho replyが同じ回数だけ確認できます。
requestだけ見えてreplyがない場合は、要求は送信されたものの、応答が返っていないことを示します。 ただし、原因が相手側とは限らず、途中経路、フィルタリング、戻り経路なども候補です。
1つのパケットを読む方法
パケットを読むときは、細かいフィールドを上からすべて確認する必要はありません。 調査目的に合わせて、次の順番で確認します。
- 何のプロトコルか Packet ListのProtocol列とInfo列を見て、ARP、ICMP、DNS、TCP、TLSなどを判断します。
- 誰から誰へ送られたか SourceとDestinationを確認します。必要に応じてEthernet層のMACアドレスとIP層のIPアドレスを分けて見ます。
- 要求か応答か DNS QueryとResponse、ICMP Echo requestとreply、TCP SYNとSYN/ACKなどを対で確認します。
- 時系列が正常か 要求後に応答があるか、同じパケットが再送されていないか、応答まで何秒かかっているかを確認します。
- 詳細フィールドを確認する IP、ポート、フラグ、エラーコードなど、仮説の判断に必要な項目だけを中段で展開します。
パケット解析の基本は「要求と応答を対で見る」
1パケットだけで結論を出さず、前後のパケットを含めて通信の流れを確認してください。
表示フィルターの基本
キャプチャーには、OSのバックグラウンド通信、ブロードキャスト、名前解決など、多数のパケットが含まれます。 表示フィルターを使うと、取得済みパケットの中から必要なものだけを画面に表示できます。
取得済みのパケットは残したまま、条件に一致するパケットだけを画面へ表示する機能です。
まず覚える表示フィルター
| フィルター | 表示する通信 | 主な用途 |
|---|---|---|
arp | ARPパケット | IPアドレスからMACアドレスを確認する流れ |
icmp | IPv4のICMP | ping、到達不能、TTL超過 |
icmpv6 | IPv6のICMPv6 | IPv6の疎通、近隣探索 |
dns | DNSとして解析されたパケット | 問い合わせ名、応答、エラー確認 |
tcp | TCPを含むパケット | 接続確立、データ転送、切断 |
udp | UDPを含むパケット | DNS、NTP、音声通信など |
tls | TLSとして解析されたパケット | 暗号化通信の接続状態 |
ip.addr == 192.0.2.10 | 指定IPが送信元または宛先 | 1台の端末に関係する通信 |
ip.src == 192.0.2.10 | 指定IPが送信元 | 端末から送信した通信 |
ip.dst == 192.0.2.53 | 指定IPが宛先 | 特定サーバーへ向かう通信 |
tcp.port == 443 | 送信元または宛先TCPポート443 | HTTPS関連のTCP通信 |
udp.port == 53 | 送信元または宛先UDPポート53 | UDPを使うDNS通信 |
eth.addr == 00:11:22:33:44:55 | 指定MACアドレスに関係する通信 | 同一LAN内の端末確認 |
frame.number == 100 | 指定パケット番号 | 報告されたパケットへ移動 |
表中の192.0.2.0/24は説明用アドレスです。
演習時は、自分のPCや調査対象のIPアドレスへ置き換えてください。
複数条件を組み合わせる
| 記号 | 意味 | 例 |
|---|---|---|
&& | 両方の条件を満たす | ip.addr == 192.0.2.10 && tcp.port == 443 |
|| | どちらかの条件を満たす | arp || icmp |
! | 条件を否定する | !arp |
( ) | 条件をまとめる | ip.addr == 192.0.2.10 && (dns || tls) |
障害調査で使う表示フィルター
表示フィルターで何も表示されなくても、元のパケットが消えたわけではありません。
フィルター欄を空にして適用すれば、取得済みパケットを再びすべて表示できます。
キャプチャーフィルターとの違い
Wiresharkには、表示フィルターとは別にキャプチャーフィルターがあります。 名前は似ていますが、適用するタイミングと構文が異なります。
| 比較項目 | 表示フィルター | キャプチャーフィルター |
|---|---|---|
| 適用タイミング | 取得後・表示中 | 取得時 |
| 動作 | 表示だけを絞る | 取得するパケット自体を絞る |
| 一致しないパケット | ファイル内に残る | 原則として保存されない |
| 構文例 | tcp.port == 443 | tcp port 443 |
| 初心者の使い方 | 積極的に使用 | 大量取得時に慎重に使用 |
代表的なキャプチャーフィルター
| フィルター | 取得対象 |
|---|---|
host 192.0.2.10 | 指定ホストが送信元または宛先の通信 |
src host 192.0.2.10 | 指定ホストが送信元の通信 |
dst host 192.0.2.53 | 指定ホストが宛先の通信 |
tcp port 443 | TCPポート443の通信 |
udp port 53 | UDPポート53の通信 |
net 192.0.2.0/24 | 指定ネットワークに関係する通信 |
host 192.0.2.10 and tcp port 443 | 指定ホストのTCP/443通信 |
キャプチャーフィルターで除外したパケットは、あとから表示フィルターを変更しても確認できません。
初めて調査する事象では、まず短時間だけ広めに取得し、表示フィルターで絞る方法が安全です。
通信のまとまりを追跡する
TCP通信では、同じ接続に属するパケットが多数並びます。 Wiresharkのストリーム追跡機能を使うと、選択した通信に関係するパケットをまとめて確認できます。
Follow TCP Streamの基本操作
- 確認したいTCPパケットを選択する 対象のクライアントとサーバー、ポート番号を確認します。
- 右クリックする コンテキストメニューからFollowを選択します。
- TCP Streamを選ぶ 同じTCP接続に属するデータをまとめて表示します。
- 元の画面でストリーム番号を確認する 自動的に
tcp.stream == 数字が適用されます。
UDPにもFollow UDP Streamなどの機能があります。DNSのように要求と応答が短い通信では、通常のパケット一覧でも十分確認できます。
暗号化通信の注意
HTTPSなどのTLS通信では、IPアドレス、ポート番号、TCPの状態、TLSハンドシェイクなどは確認できますが、 アプリケーションデータの内容は通常暗号化されています。
パケットが見えることと、中身の平文が読めることは同じではありません。 暗号化されている通信では、確認できる範囲を理解して調査します。
キャプチャーファイルを保存する
調査結果をあとから確認したり、別の担当者へ共有したりする場合は、キャプチャーファイルを保存します。
Wiresharkでは、標準的に.pcapng形式を利用できます。
- キャプチャーを停止する 取得中のまま閉じないようにします。
- File → Save Asを選ぶ 調査日時や対象が分かるファイル名を付けます。
- 保存範囲を確認する 表示中のパケットだけを書き出す操作と、取得全体を保存する操作を混同しないようにします。
- 調査メモを別途残す 取得場所、時刻、端末IP、再現操作、適用フィルターを記録します。
ファイル名の例
一緒に残すべき情報
| 項目 | 記録例 |
|---|---|
| 取得日時 | 2026年8月1日 10:30〜10:31 |
| 取得場所 | 利用者PCのWi-Fiインターフェース |
| 対象端末 | PC-A / 192.0.2.10 |
| 再現操作 | 社内ポータルへアクセス |
| 事象 | 名前解決がタイムアウト |
| 使用フィルター | dns && ip.addr == 192.0.2.10 |
| 確認結果 | DNS Queryは4回送信、Responseなし |
キャプチャーファイルには機密情報が含まれる可能性があります。 メール添付や外部サービスへのアップロードを安易に行わず、組織の情報管理ルールに従ってください。
パケットが見えないときの確認点
「Wiresharkを起動したが、目的の通信が見えない」という場合は、次の順番で確認します。
1.NICが違う
Wi-Fi通信をEthernetで取得していないか、VPNや仮想アダプターを選んでいないか確認します。
2.取得開始前に通信した
キャプチャー開始後に事象を再現します。名前解決結果や接続がキャッシュされている場合もあります。
3.表示フィルターが残っている
前回のフィルターで対象外になっていないか確認し、一度フィルター欄を空にします。
4.権限やドライバーの問題
WindowsではNpcap、Linuxではキャプチャー権限を確認します。インターフェース一覧自体が出ない場合もあります。
5.取得場所が違う
別端末同士の通信は、自分のPCでは見えない場合があります。ミラーポートや機器側キャプチャーを検討します。
6.別プロトコルを使っている
DNSがUDP/53とは限らず、TCP、暗号化DNS、プロキシ経由など、想定と異なる通信方式の場合があります。
チェックの順番
目的のパケットが見えない場合
チェックサムエラーが大量に見える場合
送信側PCでキャプチャーすると、NICのチェックサムオフロードによって、Wireshark上ではチェックサム未完成の状態に見える場合があります。 そのため、赤や黒の表示があるだけで、実ネットワーク上のパケット破損と即断してはいけません。
Wiresharkの色分けやExpert Informationは重要な手がかりですが、 それだけで原因を確定せず、取得場所と通信の流れを確認することが必要です。
実践演習:pingとDNS通信をキャプチャーする
自分のPCで、ICMPとDNSの2種類を取得します。 自宅または許可された検証環境で実施してください。
演習1.pingを確認する
- 使用中のインターフェースでキャプチャーを開始する
- デフォルトゲートウェイへpingを4回送信する
- キャプチャーを停止する
- 表示フィルターへ
icmpを入力する - Echo requestとEcho replyの数を確認する
- 1つのrequestを選び、送信元IP、宛先IP、Typeを確認する
送信元IP:
宛先IP:
Echo requestの数:
Echo replyの数:
判断:
確認ポイントを見る
- 正常なら、基本的にrequestとreplyが同数になります。
- IPv4のEcho requestはICMP Type 8、Echo replyはType 0です。
- requestだけの場合は、応答が返っていない、または取得場所で応答が見えていない可能性があります。
演習2.DNS問い合わせを確認する
- 新しくキャプチャーを開始する
- Windowsでは
nslookup example.comを実行する - キャプチャーを停止する
- 表示フィルターへ
dnsを入力する - QueryとResponseを探す
- Query Name、DNSサーバーのIP、応答コード、返されたアドレスを確認する
問い合わせ先DNSサーバー:
Query Name:
Responseの有無:
応答コード:
回答として返った情報:
確認ポイントを見る
- QueryはPCからDNSサーバーへ送信されます。
- ResponseはDNSサーバーからPCへ返ります。
- 問い合わせ名が想定と違う場合、アプリケーション設定や検索サフィックスも確認候補です。
- QueryだけでResponseがない場合、DNSサーバーまでの経路、ファイアウォール、サーバー状態などを切り分けます。
演習3.調査結果を文章で報告する
演習2の結果を、次の形式でまとめてください。
取得場所:
実施操作:
確認した表示フィルター:
観測結果:
判断:
次に確認する項目:
正常時の報告例を見る
端末のWi-FiインターフェースでDNS通信を取得しました。
dnsで絞り込んだ結果、端末からDNSサーバーへexample.comのQueryが送信され、
約20ミリ秒後にNoErrorのResponseが返っていることを確認しました。
この取得時点では、端末からDNSサーバーまでの到達性と名前解決応答は正常と判断します。
実務での調査手順
実務では、すべてのパケットを眺めるのではなく、申告内容から仮説を立てて取得します。 たとえば「Webサイトが開かない」という事象なら、次のように分解します。
| 確認段階 | パケットで見る内容 | 代表フィルター |
|---|---|---|
| 名前解決 | DNS QueryとResponse、応答コード | dns |
| 同一LANの宛先解決 | ARP要求と応答 | arp |
| TCP接続 | SYN、SYN/ACK、ACK、RST、再送 | tcp |
| TLS接続 | Client Hello、Server Hello、Alert | tls |
| 応答時間 | 要求から応答までの時間差 | 対象IP+プロトコル |
パケット解析は、OSI参照モデルの下から機械的に全部見る作業ではありません。
申告内容、構成図、接続先、使用プロトコルから確認ポイントを決め、 必要なパケットを要求・応答の流れで読みます。
Wiresharkでよくある勘違い
勘違い1:赤や黒のパケットは必ず障害
色は表示ルールによる強調です。TCP再送やRSTなどの手がかりにはなりますが、事象との関係を確認せず原因と断定できません。
勘違い2:自分のPCで全端末の通信を見られる
スイッチ環境では、他端末同士のユニキャスト通信は通常見えません。取得場所を設計する必要があります。
勘違い3:表示フィルターで消えたパケットは削除された
表示対象から外れただけです。フィルターを解除すると、取得済みパケットを再表示できます。
勘違い4:HTTPSなら何も分からない
内容は暗号化されますが、IP、ポート、TCP接続、TLSハンドシェイク、通信量、タイミングなどは確認できます。
勘違い5:パケットがないので相手が悪い
NICの選択、取得開始時刻、取得場所、フィルター、権限が誤っている可能性もあります。
勘違い6:大量に取るほど調査しやすい
不要な通信が増えるほど解析が難しくなります。再現前後を短く取得し、条件を記録する方が実務的です。
理解度チェック
次の5問に答えてください。解答を見る前に、自分の言葉で理由も考えてみましょう。
問題1.Wiresharkの表示フィルターについて正しい説明はどれですか。
- 条件に一致しないパケットをキャプチャー時に破棄する
- 取得済みパケットのうち、条件に一致するものだけを表示する
- ファイアウォールの通信許可設定を変更する
- 通信を暗号化する
解答を見る
表示フィルターは、取得済みデータを残したまま画面表示だけを絞ります。
問題2.IPアドレス192.0.2.10が送信元または宛先のパケットを表示するフィルターはどれですか。
host 192.0.2.10ip.addr == 192.0.2.10tcp port 192.0.2.10ip == 192.0.2.10
解答を見る
ip.addrは、送信元または宛先のIPv4アドレスに一致するパケットを表示します。Aはキャプチャーフィルターの書き方です。
問題3.pingの要求パケットは見えるが応答パケットが見えない場合、どのように判断するべきですか。
解答を見る
要求が取得地点から送信されたことは確認できますが、応答が返っていない理由はまだ確定できません。相手の状態、途中経路、フィルタリング、戻り経路、取得場所などを追加確認します。
問題4.別のPC同士のユニキャスト通信を、自分のPC上のWiresharkで確認できない主な理由は何ですか。
解答を見る
スイッチは通常、宛先MACアドレスに対応するポートへだけユニキャストフレームを転送するためです。必要に応じてミラーポートや経路上の機器で取得します。
問題5.キャプチャーフィルターを使うときに注意すべきことは何ですか。
解答を見る
条件に一致しないパケットは取得されないため、あとから必要になっても確認できない点です。初回調査では短時間を広めに取得し、表示フィルターで絞る方法が安全です。
自分の言葉で説明する課題
後輩から「Wiresharkを起動したら、ネットワーク障害の原因が分かりますか」と質問されました。 1分程度で説明してください。
説明例を見る
Wiresharkは、端末や取得地点で実際に送受信されたパケットを確認するツールです。 要求が送信されたか、応答が返ったか、DNSやTCPのどの段階で止まったかを判断する手がかりになります。 ただし、原因を自動で確定するわけではありません。通信経路のどこで取得するかを決め、 IPアドレスやプロトコルで絞り、要求と応答を時系列で確認する必要があります。
まとめ
- Wiresharkは、取得地点から見えるパケットをプロトコルごとに分解して確認するツール
- 利用前に、取得権限、対象範囲、機密情報の扱いを確認する
- 最初に調査目的を決め、正しいインターフェースを選び、短時間だけ取得する
- 画面は、Packet List、Packet Details、Packet Bytesの役割を分けて読む
- 表示フィルターは取得済みパケットの表示を絞り、元データは残る
- キャプチャーフィルターは取得時に絞るため、除外したパケットをあとから確認できない
- パケット解析では、送信元・宛先・要求・応答・時間・再送を流れで確認する
- 目的の通信が見えない場合は、NIC、開始時刻、フィルター、権限、取得場所を確認する
Wiresharkを使いこなす第一歩は、多くのフィルターを暗記することではありません。 「どの通信を、どこで取得し、何を確認するのか」を説明できるようになることです。

コメント