Windowsのパケットキャプチャ実務 ── pktmon・netsh trace・Wiresharkの使い分け

「業務アプリのサーバー通信が月に数回失敗する。アプリのログには“タイムアウト”としか出ていない。サーバー側のログにも該当時刻のエラーはない。再現条件は不明」── 不具合調査のご相談で、この形は本当によく出会います。

アプリのログには、アプリが「書こうと決めたこと」しか残りません。タイムアウトという結果は分かっても、接続要求(SYN)に応答がなかったのか、接続は確立したのにサーバーが途中で黙ったのか、RSTで強制的に切られたのか、そもそもパケットが宛先に届いていたのかは、ログの一段下 ── 実際に線を流れたパケットにしか残っていません。ファイルやレジストリへのアクセスを一段下から見るのがProcess Monitorだとすれば、通信の一段下を見る手段がパケットキャプチャです。

ここで手が止まる典型が「顧客のサーバーにWiresharkをインストールできない」という制約です。変更管理やセキュリティポリシーの承認が下りず、調査のためのソフト追加が現実的でない現場は珍しくありません。しかしWindowsには、pktmonとnetsh traceという2つのパケットキャプチャ手段が標準で載っています。採取はOS標準ツールで行い、採れたファイルを手元のPCに持ち帰ってWiresharkで読む ── この分担にすれば、インストール不可の現場でもパケットは見られます。

この記事では、中小企業の情シス担当者とWindowsアプリ開発者を対象に、pktmon・netsh trace・Wiresharkの使い分けと、それぞれの実務手順を整理します。ループバック通信の罠、クライアント側とサーバー側どちらで採るかの判断、TLSで中身が見えない問題への向き合い方、アプリログとの突き合わせまで、2026年8月時点の一次情報にもとづいて解説します。

1. まず結論

• 「採るのは標準ツール、読むのはWireshark」が現場の基本形です。顧客サーバーにソフトを入れられなくても、pktmonとnetsh traceはWindows標準で使えます。採取したログはpcapng形式に変換し、手元のWiresharkで解析します。¹²
• pktmonはWindows 10 / Windows Server 2019以降に標準搭載のパケットキャプチャツールです。フィルタ登録→開始→停止→変換の4手順で使え、ネットワークスタックのどのコンポーネントでパケットが破棄されたか(ドロップ理由)まで分かるのが独自の強みです。³⁴
• netsh traceはより古くからある標準ツールで、「シナリオ」としてETWプロバイダー群を束ねて採取できます。パケットに加えてWindowsコンポーネント内部のイベントも残り、persistent=yesで再起動をまたぐ採取もできます。⁵⁶
• どちらの出力もETL形式で、そのままではWiresharkで開けません。pktmonはpktmon etl2pcapで、netsh traceはMicrosoft製のオープンソースツールetl2pcapngでpcapngへ変換します。¹²
• Microsoft自身も「まずpktmon、足りなければnetsh trace、プロトコル解析はWireshark」という流れを案内しています。この記事の使い分けは、その公式の推奨と同じ並びです。⁷
• pktmonの既定では各パケットの先頭128バイトしか記録されません。Wiresharkで中身まで読むつもりなら、開始時に--pkt-size 0(全体を記録)を指定するのを忘れないでください。⁸
• localhost宛の通信は、普通のキャプチャには映りません。NICを通らないためです。WiresharkならNpcapのループバックアダプタ、標準ツールならpktmonのスタック内採取を使います。⁹
• TLSで中身が見えなくても、分かることは多い。接続確立、TLSハンドシェイクの成否、RST、どちらが黙ったかは暗号化されていても見えます。SSLKEYLOGFILEによる復号は開発環境限定の手段です。¹⁰
• キャプチャには通信内容そのものが入ります。認証情報や個人情報を含み得る前提で、必要最小限の採取と、社外に渡す前の絞り込みを手順に組み込んでください。

2. キャプチャの3つの道具と使い分け

最初に、3つの道具の役割を1枚の表にします。

役割分担を一言でいえば、pktmonとnetsh traceは「採る」道具、Wiresharkは「読む」道具です。Wiresharkにも採取機能はありますが、インストールできない環境では使えません。逆に、標準ツールのETLをテキスト変換して読むこともできますが、表示フィルタもTCP解析もない環境で目視するのは苦行です。「現場で標準ツールで採り、pcapngに変換して、手元のWiresharkで読む」が、制約のある現場での最短ルートです。

Microsoftのパケットロス調査ガイドも同じ構図で、まずpktmonで採取と原因の切り分けを行い、それで足りなければnetsh trace start scenario=InternetClientなどのコンポーネントレベルのトレースへ進み、プロトコルの振る舞いはWiresharkで解析する、という順序を示しています。⁷

なお、パケットに何が写っているかを読む前提として、Ethernet・IP・TCP・アプリケーションデータという層の重なりをイメージできていると理解が速くなります。層の解剖は「OSI参照モデルをはっきりイメージする」で図解しています。

3. pktmon実務 ── フィルタ→開始→停止→変換

pktmonの基本の流れは4手順です。管理者権限のターミナルで実行します。

:: 1. 先にフィルタを登録して対象を絞る(対象サーバー192.168.10.20のTCP 8443)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. 採取開始。パケット全体を記録し、1GBのリングバッファで上書き
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. 事象を再現させる。待つ間はカウンターで流量と破棄を確認できる
pktmon counters --drop-reason

:: 4. 停止して、Wireshark用にpcapngへ変換
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. 登録したフィルタを片付ける(フィルタは明示的に消すまで残る)。
::    注意: filter remove は名前を指定できず、登録済みフィルタを「すべて」削除する。
::    別の調査のフィルタが残っている環境では、先に pktmon filter list で確認する
pktmon filter remove

押さえておきたいポイントを挙げます。

• フィルタは採取開始前に登録します。Microsoftのドキュメントも、全トラフィックの採取はノイズが多すぎるとして、開始前のフィルタ適用を強く推奨しています。フィルタはIPアドレス、ポート、MACアドレス、プロトコル、VLAN IDなどで指定でき、最大32個まで登録できます。複数のフィルタは「いずれかに合致したら記録」というOR条件です。³
• pktmonのフィルタは送信元と宛先を区別しません。-i 192.168.10.20は「このアドレスが送信元または宛先のパケット」を意味します。方向の絞り込みは、変換後にWiresharkの表示フィルタで行います。³
• 既定のパケットサイズは128バイトです。ヘッダーの解析だけならこれで足りますが、アプリケーションデータまで読むなら--pkt-size 0で全体を記録します。⁸
• ログは既定でcircular(リングバッファ)モード、既定サイズは512MBです。--file-sizeで上限を変えられるほか、--log-mode real-timeにすると画面にリアルタイム表示され、ログファイルは作られません。まずリアルタイム表示で「狙った通信が見えていること」を確かめてから、本番の採取を仕掛けると空振りを防げます。⁸

3.1. pktmonならではの強み ── どこで捨てられたかが分かる

Wiresharkと違うpktmonの独自価値は、NICの1地点ではなく、ネットワークスタック内の複数の地点でパケットを捕捉し、破棄(ドロップ)された場所と理由を報告できることです。パケットがどのコンポーネントまで到達し、どこで消えたかが分かるため、「MTU不一致」「VLANフィルタ」のようなドロップ理由から、総当たりせずに原因へ到達できます。⁴

• pktmon listで、監視対象になるネットワークコンポーネント(NIC、プロトコルスタック、フィルタドライバーなど)の一覧とIDを確認できます。
• pktmon counters --drop-reasonで、コンポーネントごとの通過/破棄カウンターと直近のドロップ理由を一覧できます。ログを解析する前の一次切り分けとして便利です。¹¹
• pktmon etl2txtでテキスト変換すると、破棄されたパケットにはdropとdropReason(破棄理由)が付いて出力されます。³

「アプリに届く前にOSのどこかで捨てられているのでは」という疑いは、Wiresharkを眺めるだけでは決着しません。たとえば受信規則の不備でファイアウォールに落とされているケース(「Windowsファイアウォールと業務アプリ」)の切り分けで、この機能は効きます。

一点だけ注意があります。pktmonは同じパケットをスタック内の複数地点で記録するため、そのままpcapngに変換すると同じパケットが重複して見えることがあります。pcapng形式には「どのコンポーネントで捕捉したか」の情報が引き継がれないためで、Wiresharkで読む目的ならpktmon etl2pcapの--component-idで地点を絞って変換する(またはドロップだけを--drop-onlyで別ファイルにする)のが定石です。¹

4. netsh trace実務 ── シナリオとETL、再起動をまたぐ採取

netsh traceは、pktmonより古くからWindowsに載っているトレース採取の仕組みです。特徴は「シナリオ」という単位で、その問題に関係するETWプロバイダー一式をまとめて有効化できることです。⁶

:: 使えるシナリオの一覧と、シナリオに含まれるプロバイダーの確認
netsh trace show scenarios
netsh trace show scenario netconnection

:: 採取開始。パケットキャプチャ込み、1GBの循環バッファ
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: 事象を再現させてから停止(マージ処理に少し時間がかかる)
netsh trace stop

• capture=yesを付けるとパケットキャプチャが有効になり、ipv4.address=192.168.10.20のようなキャプチャフィルタで対象を絞れます。フィルタの一覧はnetsh trace show capturefilterHelpで確認できます。⁶
• 停止するとETLファイルに加えて.cabファイルが生成されます。.cabにはアダプタ構成やOSビルドなどシステム情報が含まれ、環境情報の収集を兼ねられます。⁶
• トレースセッションは同時に1つしか実行できません。別の採取を始める前に、走りっぱなしのセッションがないかnetsh trace show statusで確認します。⁶
• persistent=yesを付けると、再起動をまたいでセッションが維持されます。「再起動直後の一瞬だけ通信が失敗する」「起動時のサービス接続が失敗する」といった、手動では開始が間に合わない事象の採取はnetsh traceの独壇場です。⁵

4.1. ETLをWiresharkで読める形にする ── etl2pcapng

netsh traceのETLは、そのままではWiresharkで開けません。MicrosoftがGitHubで公開しているオープンソースツールetl2pcapngを使うと、netsh trace start capture=yesで採取したETL内のパケットをpcapngへ変換できます。²

etl2pcapng.exe C:\temp\nettrace.etl C:\temp\nettrace.pcapng

etl2pcapngは変換の際、パケットに関与したプロセスIDをパケットコメントとして書き出します。「どのプロセスの通信か」をWireshark上で確認できるので、同じサーバーに複数のアプリが通信している環境の切り分けで役立ちます。²

なお、ETWイベント側(シナリオプロバイダーが記録したWindows内部のイベント)はpcapngには変換されません。イベントまで読みたい場合はnetsh trace convert input=C:\temp\nettrace.etlでテキスト等に変換するか、Windows Performance Analyzerなどで開きます。⁵⁷

5. Wiresharkでの読み方入門 ── 表示フィルタとTCP解析

採ったpcapngを開いたら、まず表示フィルタでノイズを削ります。よく使うものを表にします。¹²¹³

tcp.analysis.*は、WiresharkがTCPのシーケンス番号を追跡して自動判定してくれる解析フラグです。再送、重複ACK、順序入れ替わり、ZeroWindowなどが機械的に拾えるため、最初にtcp.analysis.flagsを打って「問題っぽい箇所」を一覧するのが読み始めの定石です。¹³

タイムアウト調査では、次の形を順に探します。

1. 3ウェイハンドシェイクは成立したか。SYN→SYN/ACK→ACKの3発が揃っているか。SYNを繰り返しているのに応答がなければ、相手に届いていないか、途中で黙って破棄されています(ファイアウォールの典型パターン)。
2. RSTはどちらから飛んだか。SYNに対して即RSTなら宛先ポートで誰も待ち受けていない状態、確立後のRSTならどちらかが接続を強制切断した状態です。RSTの送信元IPが「どちらが切ったか」の直接証拠になります。
3. 再送が続いていないか。同じセグメントの再送が繰り返されているのは、送信側に確認応答(ACK)が返ってきていないサインです。行きのデータが失われたのか、帰りのACKが失われたのかは、片側のキャプチャだけでは確定できません(だからこそ次章の「両側で採る」が効きます)。再送とタイムアウトの深掘りは「TCP再送で産業用カメラ通信が止まる原因と切り分け」で詳しく扱っています。
4. ZeroWindowが出ていないか。受信側アプリがソケットからデータを読み出しておらず、受信バッファが満杯になっているサインです。ネットワークではなく受信側アプリの設計(「TCPでSendした単位ごとにReceiveできるという誤解」)を疑う根拠になります。

パケットを1つずつ読む前に、統計機能で全体を俯瞰するのも有効です。[統計]→[対話(Conversations)]は「どのIPペア・ポートペアが、いつからいつまで、どれだけ話したか」の一覧で、目的の通信を特定してからその会話だけをフィルタできます。[統計]→[入出力グラフ(I/O Graph)]は時間軸の流量グラフで、「この時刻から片方向だけ無音になった」のような形が一目で分かります。対象のTCP会話を右クリックして[追跡]→[TCPストリーム]を選べば、その接続のやり取りだけを平文で通し読みできます。

6. ループバック通信の罠 ── localhost宛はNICを通らない

同じPC内のアプリ同士の通信 ── たとえば業務アプリからlocalhost:8080の中間サービスへの接続 ── を調べようとして、「Wiresharkに何も出ない」で詰まるのは定番の罠です。

原因ははっきりしています。localhost(127.0.0.1)宛の通信は物理NICを通らず、OS内部のループバック経路で折り返されるためです。物理アダプタを対象にした通常のキャプチャには、最初から現れません。⁹

対処は2通りです。

• Wiresharkで採る場合: Npcapが提供する「Adapter for loopback traffic capture」をキャプチャ対象に選びます。Windows版Wireshark(3.0以降)のインストーラーにはNpcapが同梱されているので、Wiresharkが入っている環境なら追加作業なしで使えます。⁹
• 標準ツールで採る場合: pktmonはNICの外側ではなくネットワークスタック内部の複数地点で採取するため⁴、ループバック通信の観測にも使えます。確実を期すなら、本番の再現待ちを仕掛ける前にpktmon start -c -m real-timeのリアルタイム表示で、目的のループバック通信が実際に見えることをその環境で確かめてください。

あわせて2つの取り違えに注意します。

• 「localhost」はIPv6の::1に解決されることがあります。アプリはIPv6の::1に接続しているのに、調べる側が127.0.0.1(IPv4)だけを見ていて「通信がない」と誤断するパターンです。表示フィルタはip.addr == 127.0.0.1 || ipv6.addr == ::1のように両方張るか、アプリの接続先設定をアドレスで明示します。⁹
• 自分自身の実IP宛の通信も、線には出ません。同じPCの192.168.10.5から192.168.10.5宛に接続する場合、宛先が実IPでもOS内部で折り返されます。「実IPを指定しているからNICを通るはず」とは限らない、と覚えておいてください。

7. どこで採るか ── 片側か、両側か、時刻同期

キャプチャの価値は「どこで採ったか」で決まります。判断の目安は次のとおりです。

片側のキャプチャで分かるのは「自分の位置から見えた事実」だけです。クライアント側で再送が続いていても、送ったパケットが経路で消えたのか、サーバーに届いたのに応答が消えたのかは区別できません。両側で採って突き合わせると、「クライアントは送った・サーバーには届いていない」のように、どちらが黙ったかが確定します。責任分界(アプリか、OSか、ネットワーク機器か、相手先か)を確定させたい局面では、最初から両側採取を段取りする価値があります。

7.1. 突き合わせの前提は時刻同期

両側のキャプチャを突き合わせるには、両マシンの時計が揃っている必要があります。採取を始める前に、時刻のずれを確認・記録しておきます。

:: 時刻同期の状態(同期先・最終同期時刻)を確認
w32tm /query /status

:: 相手サーバーとの時刻差を実測する(5サンプル)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchartは自分と相手コンピューターの時刻オフセットを表示するコマンドで、突き合わせ時に「サーバー側の時刻は+0.8秒ずれていた」と補正する根拠になります。¹⁴ ずれが大きい環境では、先に時刻同期を直してから採取するのが結局近道です。

7.2. 「いつ起きるか分からない」にはリングバッファ

再現条件が不明な事象は、リングバッファで採りっぱなしにして、発生したら止めるのが基本です。

• pktmon: 既定がcircularモードです。--file-sizeで上限(MB)を指定し、古いパケットから上書きされます。⁸
• netsh trace: maxSize=1024 filemode=circularのように指定します。⁵
• Wireshark: [キャプチャ]→[オプション]→[出力]で「複数ファイル+リングバッファ」を構成できます。ファイルサイズや時間で切り替えながら最新N個だけを保持するため、ディスク使用量に上限を設けたまま長時間回せます。¹⁵

いずれの場合も、事象が起きたら「発生時刻をメモしてから」採取を止める運用を、現場の担当者と共有しておいてください。リングバッファは待てば待つほど過去が消えるので、発生から停止までの手順が長いと肝心の区間が上書きされます。

8. TLSで中身が見えない問題 ── 見えなくても分かること

いまどきの業務通信の多くはTLS(HTTPS)です。「暗号化されているならキャプチャしても無駄では」と思われがちですが、タイムアウト調査で知りたいことの大半は、暗号化されたままでも分かります。

• TCP接続が確立したか(3ウェイハンドシェイク)
• TLSハンドシェイクがどこまで進んだか ── ClientHelloに対してServerHelloが返ったか、ハンドシェイク中にRSTやアラートで切れたか
• ClientHelloに載る接続先ホスト名(SNI)や、ネゴシエートされたTLSバージョン
• 確立後、どちらが送信を止めたか。無応答の位置、再送、RST、正常なクローズ(FIN)か

つまり「つながらない」「途中で切れる」「応答が返らない」の切り分けに、中身の復号はほとんど要りません。暗号化で失われるのは“何を話したか”であって、“誰がいつ黙ったか”は残るからです。

それでも中身が必要な場合、WiresharkにはSSLKEYLOGFILE環境変数で書き出したセッション鍵を使ってTLSを復号する仕組みがあります。ただし対応するのはFirefox・Chrome・Chromium系EdgeのブラウザやOpenSSL系のライブラリなど一部の実装で、Windows標準のSChannel(WinHTTPやWinINETを使うアプリ)はこの仕組みに対応していません。¹⁰ セッション鍵がファイルに書き出される=そのファイルを手にした者が通信をすべて復号できる、という性質上、本番環境で使う手段ではなく、開発環境での再現・デバッグ用と位置づけるべきです。

なお、社内プロキシ経由の通信では、キャプチャに写る宛先がプロキシサーバーになり、CONNECTトンネルの中をTLSが流れる形になります。そもそもアプリがどのプロキシへ向かうのかという手前の問題は、同日公開の姉妹記事「社内プロキシとWindowsアプリ ── WinINET・WinHTTP・.NETのプロキシ解決を整理する」で整理しています。

9. アプリログとの突き合わせ ── 時刻を同じ軸に並べる

キャプチャ単体で結論が出ることは、実はあまりありません。実務の決め手は、アプリログの1行とパケットの1往復を、同じ時間軸の上に並べることです。

手順としては次の形になります。

1. アプリログから事象の時刻を特定します(例: 10:23:41にタイムアウト例外)。タイムアウト値が30秒なら、開始は10:23:11ごろのはずです。
2. Wiresharkの時刻表示を[表示]→[時刻表示形式]→[日時]に切り替え、該当区間を表示フィルタで絞ります(frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00"のように時刻でも絞れます)。
3. その区間で、5章の順序(ハンドシェイク→RST→再送→ZeroWindow)を確認します。「ログのタイムアウト時刻の30秒前にSYNを送り、以後SYNの再送のみ」まで突き合わせられれば、ログの“タイムアウト”が「この採取点には応答が一切返ってきていない」という観測事実に置き換わります(SYNが相手に届いていないのか、応答のSYN/ACKが帰り道で失われたのかは、この採取点だけでは確定できません。確定させたい場合はサーバー側の採取と突き合わせます)。
4. キャプチャの時刻とログの時刻のずれ(7.1節で測った時刻差、ログのタイムゾーン表記)を必ず補正します。突き合わせの誤差が数秒あると、別の通信を犯人にしてしまいます。

調査結果を第三者(ベンダー、回線事業者、顧客のネットワーク担当)へ渡すときは、フィルタでノイズを削ってから渡すのが礼儀であり、安全策でもあります。Wiresharkで対象の会話だけを表示フィルタで絞り、[ファイル]→[指定パケットのエクスポート]で「表示されているパケットのみ」を保存すれば、必要な範囲だけの小さなpcapngを作れます。

最後に、取り扱いの注意です。キャプチャファイルには通信内容そのものが入ります。平文プロトコルの認証情報、HTTPのCookieやAPIキー、メールや帳票の中身、個人情報が含まれ得ます。次の3点を採取手順とセットで決めておいてください。

• 必要最小限の採取: 採取前フィルタ(3章・4章)で対象を絞り、期間も最小にする。「とりあえず全部」を顧客環境でやらない
• 渡す前の絞り込み: 対象の会話だけをエクスポートし、無関係な第三者の通信を含めない。機密部分が残る場合はマスキングや別手段を宛先と合意する
• 保管と削除: 採取ファイルの保管場所・期限・削除を決め、調査完了後に消す

10. まとめ

• アプリログの「タイムアウト」の一段下には、実際に線を流れたパケットという事実があります。SYNに応答がないのか、RSTで切られたのか、再送が続いたのか、ZeroWindowなのかで、次に調べる場所が変わります。
• Wiresharkを入れられない現場でも、Windows標準のpktmonとnetsh traceで採取できます。採るのは標準ツール、読むのは手元のWireshark、という分担が基本形です。
• pktmonはフィルタ登録→pktmon start --capture→pktmon stop→pktmon etl2pcapの4手順。既定では128バイトで切り詰められるため、中身まで読むなら--pkt-size 0を忘れずに。ドロップ箇所と理由が分かるのはpktmonだけの強みです。
• netsh traceはシナリオでETWプロバイダーを束ねて採れ、persistent=yesで再起動をまたげます。ETLはetl2pcapngでpcapngへ変換して読みます。
• Wiresharkではtcp.analysis.flagsから読み始め、ハンドシェイク・RST・再送・ZeroWindowの順で形を探します。ConversationsとI/O Graphで俯瞰してから絞ると速い。
• localhost宛はNICを通らないため普通には採れません。Npcapのループバックアダプタか、pktmonのスタック内採取を使います。
• 両側で採って突き合わせれば「どちらが黙ったか」が確定します。その前提は時刻同期(w32tm)です。再現条件不明の事象はリングバッファで待ち構えます。
• TLSでも通信の骨格は見えます。復号(SSLKEYLOGFILE)は開発環境限定の手段と位置づけ、キャプチャファイル自体も機密として最小採取・絞り込み・削除まで運用に組み込んでください。

パケットキャプチャは「ネットワーク専門家の道具」と思われがちですが、実際にはアプリのログと突き合わせて初めて意味が出る、アプリ側の調査道具です。次に“タイムアウト”の一言で調査が止まったら、その一段下を見にいってください。

関連記事

• TCP再送で産業用カメラ通信が止まる原因と切り分け
• TCPでSendした単位ごとにReceiveできるという誤解 ── バイトストリームとして扱うための受信設計
• OSI参照モデルをはっきりイメージする ── HTTPリクエスト1個を7層に解剖する
• Process Monitor(ProcMon)実践ガイド ── 「設定が読まれない」「ACCESS DENIED」を10分で特定する
• Windowsファイアウォールと業務アプリ ── 受信規則はインストーラーで登録する
• 社内プロキシとWindowsアプリ ── WinINET・WinHTTP・.NETのプロキシ解決を整理する

関連する相談領域

合同会社小村ソフトでは、「業務アプリの通信が時々失敗するが原因が分からない」「顧客環境でだけ起きる接続エラーを切り分けたい」といった通信起点の不具合調査を扱っています。パケットキャプチャの採取設計(どこで・何を・どれだけ採るか)から、Wiresharkでの解析、アプリログとの突き合わせ、アプリ側の修正までを一続きで対応します。

• Windowsアプリ開発
• 不具合調査・原因解析
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Wiresharkをインストールできない顧客サーバーで、パケットキャプチャを採るにはどうすればいいですか？

Windows標準のpktmonまたはnetsh traceを使えば、ソフトの追加インストールなしで採取できます。pktmonなら管理者権限のターミナルでフィルタを登録し、pktmon start --captureで採取を開始、pktmon stopで停止します。採れたETLファイルはpktmon etl2pcapでpcapng形式に変換できるので、解析は自社に持ち帰った手元のWiresharkで行えます。「採るのは標準ツール、読むのはWireshark」という分担が、インストール制約のある現場での基本形です。

pktmonとnetsh traceはどちらを使うべきですか？

pktmonが使えるOS(Windows 10 / Windows Server 2019以降)なら、まずpktmonをおすすめします。コマンドが単純で、ネットワークスタックのどのコンポーネントでパケットが破棄されたか(ドロップ理由)まで確認でき、pcapng変換も単体で完結するからです。netsh traceが有利なのは、pktmonが載っていない古いOSで採る場合、シナリオという形でWindowsコンポーネントのETWイベントもまとめて採りたい場合、persistent=yesで再起動をまたいで採取したい場合です。Microsoftのトラブルシューティング資料も、まずpktmon、足りなければnetsh traceという順序を案内しています。

localhost(127.0.0.1)宛の通信がWiresharkに表示されないのはなぜですか？

localhost宛の通信は物理NICを通らず、OS内部のループバック経路で折り返されるためです。物理アダプタを対象にした通常のキャプチャには最初から現れません。WiresharkではNpcapが提供する「Adapter for loopback traffic capture」を選ぶとループバック通信を採取できます。pktmonはネットワークスタック内部で採取するため、ループバック通信の観測にも使えます。また「localhost」がIPv6の::1に解決されて、127.0.0.1のつもりで見ていた画面に何も出ない、という取り違えもよくあるので、アドレスを明示して確認してください。

HTTPS(TLS)の通信は、パケットキャプチャで中身が見えますか？

アプリケーションデータの中身は暗号化されていて見えません。ただし、TCP接続の確立と切断、TLSハンドシェイクの成否、RSTによる切断、どちらが応答を止めたかといった「通信の骨格」は暗号化されていても分かるため、タイムアウト調査の大半はTLSのままで進められます。中身まで必要な場合はSSLKEYLOGFILEによる復号という手段がありますが、対応するのはFirefoxやChrome系など一部のTLS実装で、Windows標準のSChannelは非対応です。秘密鍵情報を書き出す仕組みなので、使うとしても開発環境限定と考えてください。

採取したキャプチャファイルを、社外のサポート窓口に送っても大丈夫ですか？

そのまま送るのは危険です。キャプチャには通信内容そのものが入っており、平文プロトコルの認証情報、Cookie、APIキー、個人情報が含まれ得ます。まず採取の段階でフィルタと期間を絞って必要最小限にし、渡す前にWiresharkの表示フィルタで対象通信だけを抽出してエクスポートしてください。それでも残る内容は宛先と相談のうえ、機密部分の扱い(マスキング、別手段での提供)を決めてから渡すべきです。採取ファイルの保管期限と削除も、あらかじめ決めておくことをおすすめします。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。