• 戻る
  • 監視・パケット解析編
  • 電文を確認する方法（パケット・キャプチャ）

• OSSソフトウェアLANアナライザであるWiresharkの操作方法を説明する。
• 元ネタが古く、wireshark-setup-0.99.7.exeを使用している（操作方法は大きく変わっていないと思う）。

移行メモ（画像参照の誤り）: 「インストール」節の図が、元ページでは
画像参照の指定が ClassificationOfLanAnalyzer.png になっており、
直前の図（LANアナライザの区分）と同じファイル名を指していた。
添付には InstallationOptionOfWireshark.png が存在し、キャプションとも
一致するため、そちらを参照するよう修正した。

移行メモ（表のセル結合）: 「区分ごとの特徴」の表は、元ページで
PukiWiki の横方向セル結合（|>|）と縦方向セル結合（|~|）を
使っていた。GitHub Markdown はセル結合に対応しないため、
横結合は空セル、縦結合は「〃」で表現し直している。

補足（本ページの前提バージョン）: 概要にあるとおり、本ページは
Wireshark 0.99.7（2008 年）＋ GTK2 UI を前提とした説明である。
現在の Wireshark は Qt ベースの UI に変更されており、
メニュー構成やダイアログ名が異なる。主な対応は次のとおり。

本ページ（GTK2）	現在（Qt）
［Capture Interfaces］ダイアログ	［キャプチャ］→［オプション］
［Capture Option］ダイアログ	同上（1 つに統合）
［Statistics］メニュー	［統計］メニュー（項目はほぼ同じ）
Follow TCP Stream	［追跡］→［TCP ストリーム］
WinPcap	Npcap（WinPcap は開発終了）

画面は変わっているが、「どの統計・どのフィルタで何を見るか」という
本ページの中身は現在もそのまま通用する。

LANアナライザには、以下の区分がある。

これらのLANアナライザには、それぞれ以下のような区分がある。

• LANアナライザの区分毎の特徴 | # | 区分 | | 特徴 | | --- | --- | --- | --- | | 1 | ハードウェア
  LANアナライザ | 長所 | 持ち運びが容易。下位レイヤのトラブルシュートに優れるため、ケーブル品質の調査、エラーフレームの測定が可能。 | | 〃 | 〃 | 短所 | ソフトウェアLANアナライザと比べ、統計・レポート出力、しきい値の設定と警告の出力、パケットの分析などの機能が劣る。 | | 〃 | 〃 | 価格 | 一般的に高価である。 | | 2 | 商用ソフトウェア
  LANアナライザ | 長所 | 統計・レポート出力、しきい値の設定と警告の出力などの機能が優れている。 | | 〃 | 〃 | 短所 | NICドライバでキャプチャ可能である必要があるので、下位レイヤのトラブルシュートが難しい。 | | 〃 | 〃 | 価格 | 一般的に高価である。 | | 3 | OSSソフトウェアLANアナライザ | 長所 | プロトコル毎のパケットの分析機能に関しては、商用アナライザを凌ぐ（バージョンアップの頻度の多さも強み）。 | | 〃 | 〃 | 短所 | NICドライバでキャプチャ可能である必要があるので、下位レイヤのトラブルシュートが難しい。 | | 〃 | 〃 | 価格 | 無償で利用可能。 |

• Wiresharkは、OSSソフトウェアLANアナライザ。
  下位レイヤの、ケーブル品質の調査、エラーフレームの測定などの用途には利用できない。

以下からWindows版のWiresharkのインストーラをダウンロード

• Wireshark: Download
  http://www.wireshark.org/download.html

• デフォルト設定でインストールする。

• 基本的にデフォルトのインストールで問題ない。

• 以下、インストール オプションの注意点のみ抜粋して説明する。

  • (a) のインストール オプションは、

    • Wiresharkのインターフェイスのオプションで、
      前バーションのEtherealのインターフェイスで利用したい場合は、
      「Wireshark（legacy GTK1 user interface）」を選択する。
    • ココでは「Wireshark（GTK2 user interface）」前提で説明を進める。

  • (b) のインストール オプションは、

    • WinPcapをインストールするかどうかのオプションである。
    • Wiresharkのパケット キャプチャに必須のソフトウェアである。
    • 既にインストールされている場合を除いて必ずインストールする。

  • (c) のインストール オプションは、

    • Administrator権限を持たないユーザでもパケット キャプチャができるように、システム起動時にNICドライバをロードする設定である。
    • Wiresharkはプロミスキャスモードのパケット キャプチャが可能であり、セキュリティ上好ましくないので、
      プロミスキャスモードを必要としない場合は、基本的にこのオプションは有効にすべきでないと考える。

インストールが完了したら、Wiresharkを起動する。

キャプチャは、メニューの[Capture] → [Interface]で表示される以下の[Capture Interfaces]ダイアログで、
監視対象のインターフェイス（NIC）の[Start]ボタンを押して開始させる。

• キャプチャ オプションを設定したい場合は、[Option]ボタンをして、[Capture Option]ダイアログを表示する。
• [Capture Option]ダイアログでは、キャプチャ オプションを確認・変更する。

• 初めに、(1)を選択し、
• 重要な設定として以下の(3)/(6)/(7)の辺りを設定・確認する。
• その他の設定は、必要に応じて設定・確認する。
• 設定が完了したら、[Start]ボタンを押してトラフィックの監視を開始できる。

• 初めに、(1)を選択し、監視対象のインターフェイス（NIC）を選択する。

• 監視に使用するメモリ量を設定する。
• ファイル保存しない場合や、ファイル保存する場合にファイルI/Oによる
  性能低下を防ぐためのバッファリング処理に必要なメモリ量を設定する。

• プロミスキャス モードのオン・オフを設定する。
• プロミスキャス モードで監視する場合、このチェック ボックスをオンにする。

• キャプチャするパケットのデータ サイズを設定する。
• 設定がオフの場合、全てのデータをキャプチャする。
• オンにしてサイズを設定した場合、指定サイズより後ろのデータは切り捨てられる。

• キャプチャするデータをフィルタする設定をする。
• Wiresharkでは、これをキャプチャ フィルタと呼ぶ。
• フィルタ設定については、後述のキャプチャ フィルタ設定の項で説明する。

• リアルタイムにパケット リストを更新するかどうかを設定する。
• リアルタイムにトラフィックを参照したい場合は、[Update list of packets in real time]チェック ボックスをオンにする。
• また、パケット リストの自動スクロールの設定は、[Automatic scrolling in live capture]チェック ボックスで設定する。
• また、[Hide capture info dialog] チェック ボックスがオフの場合、
  [Capture Info]ダイアログが表示され、簡単な統計情報を確認できる。

• キャプチャしたデータのファイル保存に関する設定をする。
• ファイル名、ローリング方法、保持するファイルの最大数などを設定する。

• 名前解決に関する設定をする。
• この設定を有効にすると監視処理の性能が悪化することがあるので、
  名前解決は、キャプチャ後に実行することを推奨する。
  • [Enable MAC name resolution]は、MAC → メーカの名前に名前解決する。
  • [Enable network name resolution]は、IP → マシン名・FQDN名に名前解決する。
  • [Enable transport name resolution]は、ポート番号 → サービス名に名前解決する。

• パケット キャプチャの停止方法を設定する。
• キャプチャしたパケット数、データ量、時間などで設定できる。
• ファイル保存をする場合、データ量による停止は無効になる。

[Capture Option]ダイアログの[Capture Filter]テキスト ボックスにキャプチャ フィルタ用のフィルタ式を入力する。
（このキャプチャ フィルタ用のフィルタ式は、後述のディスプレイ フィルタ用のフィルタ式とは異なるので注意する）

[Capture Option]ダイアログの[Capture Filter]ボタンを押せば、
[Capture Filter]ダイアログ ボックスが表示され、フィルタの例からフィルタ式を選択できる。

• [Filter]リスト ボックスからフィルタの例を選択し[OK]ボタンを押すと、
  [Capture Filter]テキスト ボックスに対応するフィルタ式が設定される。
• また、[New]ボタンを押して新しいフィルタの例を作成することもできる。

キャプチャ フィルタには、幾つかのフィルタ式、演算子が用意されている。

詳細は、下記のサイトを参照のこと。

• The Wireshark Wiki > CaptureFilters
  http://wiki.wireshark.org/CaptureFilters
• Wireshark USER's Guide > 4.8. Filtering while capturing
  http://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html

• メニューの[Capture]を選択し[Interface]をクリックする。

• すると、[Capture Interface]ダイアログにインターフェイス（NIC）一覧が表示されるので、
  トラフィックを監視するNICの[Option]ボタンを押して、前述の設定をした後に、
  [Hide capture info dialog] チェック ボックスのチェックを外し、[Start]ボタンを押す。

• これにより、以下の[Capture form （インターフェイス名）]ダイアログが表示され、全体の統計情報を確認しながらトラフィックを監視できる。

• このダイアログの、 [Stop]ボタンが押されるか、停止設定値に達するまで、トラフィックの監視が継続される。

• 以下の図は、NIC監視中の[Capture form （インターフェイス名）]ダイアログである。

• [Capture form （インターフェイス名）]ダイアログから、
  • 一般的なネットワークでは、殆どのトラフィックはTCP/IP（ファイル共有・HTTP）であり、
  • 次いでUDP（DHCPのブロードキャスト、DNSクエリ）などのプロトコルであることが確認できる。
  • その他のプロトコルとしては、ARP（イーサネットで内のIP → MACのアドレス解決）を確認できる程度である。

• 現在のWindowsネットワークでは、NetBIOS （NBT）が使用されているので、
  この画面ではNetBIOS（NetBEUI）プロトコルのパケットは確認できない。
• 稀に、プリンタ サーバなどが発するNetBIOS（NetBEUI）のパケットが確認できる程度である。
• NetBIOS （NBT）が使用されていることは、キャプチャ後、次節で説明する画面から確認できる。

例えば、

• NetBIOSの名前解決であるNetBIOSネーム サービス（NBNB）
• ブラウジング機能などが使用するNetBIOSデータグラム サービス（NBDS）
• ファイル共有（SMB）などが使用するNetBIOSセッション サービス（NBSS）

を確認できる。

キャプチャを終了すると以下のような画面が表示される。ここには、主要な表示部位を示す。
※ メニュー バーの[View]で対応する表示部位 のチェックを外すと表示を消すことができる。

以下、それぞれの表示部位に表示される表示項目について説明する。

[メニュー バー]は、Wiresharkの各機能を呼び出す際に使用する。使用方法は後述する。

[ツール バー]には、良く使う機能がボタンとして用意されている。以下、良く使う機能のボタンをピックアップして説明する。

• 
  

  • ファイルの、オープン、セーブ、クローズ、リロードが可能。
  • オープン・セーブの際は、対象パケットの入・出力範囲の選択も可能。

• 
  

  • パケット印刷ダイアログを表示し、データのプリンタ出力や
  • テキストファイル出力ができる。出力範囲・出力部位の選択も可能。

• 
  

  • パケット検索ダイアログを表示し、条件に合ったパケットに移動する。
  • 検索条件には、フィルタ式、１６進値、文字列値などが指定できる。

• 
  

直前・直後に参照したパケットに移動する。

表示されたダイアログにパケット ナンバーを指定することで、指定したパケットに移動する。

最初・最後のパケットに移動する。

• [フィルタ ツール バー]は、キャプチャしたパケットをフィルタするときに使用する。
• Wiresharkでは、これをディスプレイ フィルタと呼ぶ
• ディスプレイ フィルタは、ディスプレイ フィルタの入力テキスト ボックスに、フィルタ式を入力する。

• 以下、[フィルタ ツール バー]のボタンについて説明する。 | # | ボタン | 説明 | | --- | --- | --- | | 1 | [Filter]ボタン | [Display Filter]ダイアログで、フィルタの例から選択できる。 | | 2 | [▼]ドロップダウン リスト | 過去のフィルタ式を選択できる。 | | 3 | [Expression]ボタン | [Filter Expression]ダイアログで、フィルタ式を参照できる。 | | 4 | [Clear]ボタン | フィルタ式をクリアする。 | | 5 | [Apply]ボタン | フィルタ式を適用する。 |

[Display Filter]ダイアログについては、「フィルタの例から選択する」で説明する。

[Filter Expression]ダイアログについては、「高度なフィルタ式の作成方法」で説明する。

• [パケット一覧部]には、キャプチャしたパケットの概要がレコード一覧として表示される。

• 1行に付き1パケット（フレーム）が表示され、簡単な説明が表示される。

• 以下、レコードのカラムについて説明する。

• 上記のレコードは、ファイル共有（SMB）機能で、

  • ファイルを送信する「Write AndX Request」コマンドと、
  • 送信ファイルのデータ部が分割されたTCPパケットである 。
  • [TCP segment of a reassembled PDU]という情報は、
    • TCPでストリームに書き込んだデータのサイズが大き過ぎるため、
      IPレイヤで複数のIPパケットに分割されたことを意味する。
    • この情報は、後述するWiresharkにより生成された追加情報
      であり、パケットのデータ中には含まれない。

• これらの分割されたパケットは、ファイル共有（SMB）によるものであるが、

  • SMBのコマンド情報が含まれないのでプロトコル パーサが反応せず、表示上は純粋なTCPのパケットとして表示される 。
  • SMBの「Write AndX Request」コマンドのパケットには、データ長=61440バイトと表示されているので、
    「Write AndX Request」コマンドによる通信データは、イーサネット上でのIPパケットのデータ部の最大サイズである
    1460バイト毎に分割されて送信される（この場合、61440 ÷ 1460 ＝ 43個のIPパケットに分割される）。

• [パケット詳細部]には、[パケット一覧部]で選択したパケットの詳細情報が表示される。
• プロトコル パーサによって解釈された情報がレイヤ毎に表示される。
• レイヤ : フレーム → イーサネット フレーム → IPパケット → 上位プロトコルの情報

• [パケット詳細部]の情報を選択した状態で右クリック、
  [Copy] → [Description]を選択することで、[パケット詳細部]の情報をコピーできる。
  このコピーした情報を検索（Find）機能で使用できる。

• また、[パケット詳細部]には以下の追加情報が出力される
  （これらの情報はパケットのデータ中には含まれないので注意する）。

  • TCPパケットの前後の関係をWiresharkが判断して自動生成性した追加情報（Generated fields）、
  • 他のパケットへのリンク（Link）

• 例えば、パケット詳細部の[SEQ/ACK Analysis]フィールドには、

  • シーケンス番号・ACK番号からTCPの通信シーケンスを分析するための追加情報・リンクが付与される。
  • 以下の図に示す[This is an ACK to the segment in frame: xx]という追加情報・リンクは、
    このパケットがリンク先のパケットに対するACKであることを示す。

• [パケット一覧部]の簡易情報に表示されていた[TCP segment of a reassembled PDU]という情報も、この追加情報である。
• [パケット詳細部]を確認すると、下記情報が表示されていることを確認できる。
  • [Reassembled PDU in frame: xxxx]という追加情報
  • IPレイヤで分割されたパケットを束ねるリンク

• Wiresharkは、

  • ノードが同一TCPコネクション上で初めのパケットの送信（・受信）を開始してから、

  • TCP のPushフラグ 付きのパケットを送信（・受信）するまでの、

    • Pushフラグ（TCPフラグ）は、TCPの受信バッファのデータをアプリケーションに送るように、送信側が受信側に対して指示するためのフラグである。
    • その他のTCPフラグについては、「TCPセグメント詳細情報（TCPフラグ）から異常を確認する」で説明する。

  • 一連のパケット に、[TCP segment of a reassembled PDU]追加情報・リンクを付与しているものと思われる。

    • これは、TCPストリームへの１回の書き込み（読み込み）に相当する。
    • TCPストリームについては「TCPストリームで上位プロトコルを確認する」を参照のこと。

• 以下は、Pushフラグ付きのSMBの「Write AndX Request」コマンドのパケットである。
  「Write AndX Request」コマンドのパケットを確認すると、分割されたIPパケットへのリンクを確認できる。

• また、トランスポート層のプロトコル（TCP, UDP）より上位のプロトコルである
  DNS 、HTTPなどのプロトコルでも、それぞれのプロトコル パーサによって追加情報・リンクが付与される。
  • 例えば、DNSクエリ（パケット）を参照すると、このDNSクエリに対するレスポンス（パケット）へのリンクを確認できる。

• また、以前のバージョンでは、パケット データ部から読み取るしかなかったHTTPのエンティティ ボディの情報が、
  Version0.99.7のプロトコル パーサからパケット詳細部の[Line - Based text data]フィールドに
  テキストとして出力されるようになった（ただしASCII以外の文字は正しく表示されない）。

• [パケット データ部]では、[パケット一覧部]で選択したパケットの情報が表示される。

• 以下は、HTTPリクエスト（GETメソッド）のパケットで左からアドレス、16進ダンプ、ASCIIが表示される。

• ただし、ASCII 以外の文字コード（Shift JIS、UTF-8）のエンコーディングに対応していないので使い難い。

画面の最下部の[ステータス バー]には、

• 現在のプログラムの状態、
• パケット
  • 取得したパケット(Packets)
    • 現在、開いているファイル中のPacketの数
  • 表示中のパケット(Displayed)
    • フィルタなどをかけた場合、表示されているPacketの数
  • マークされたパケット(Marked)
    • マーク したPacketの数
    • [パケット一覧部]でパケットを選択した状態で、メニューの[Edit]にある[Mark Packet]を選択することでパケットのマークが可能。
    • その他にも、[Mark All Packet]、[UnMark All Packet]、[Find Next Mark]、[Find Previous Mark]などの操作が可能。

などの情報が表示される。

• Wiresharkでは基本的に、キャプチャしたパケットにフィルタを設定して分析をする。Wiresharkでは、これをディスプレイ フィルタと呼ぶ。

• 最も簡単な方法は、[フィルタ ツール バー]にプロトコル名を小文字で入力し[Enter]キー（若しくは[Apply]ボタン）を押してフィルタをかける方法である。

• 以下、「smb」と入力して[Enter]キーを押しディスプレイ フィルタを適用した所である。

以下、フィルタ式の作成方法を示す。

[フィルタ ツール バー]の脇にある[Filter]ボタンを押せば、[Display Filter]ダイアログ ボックスが表示され、フィルタの例からフィルタ式を選択できる。

• [Filter]リスト ボックスからフィルタの例を選択し[OK]ボタンを押すと、
  [フィルタ ツール バー]に対応するフィルタ式が設定される。
• [Apply]ボタンを押すと、現在のフィルタ式を適用する。
• また、[New]ボタンを押して新しいフィルタの例を作成することもできる。

以下の基本的な点を押さえていれば、手入力でフィルタ式を作成できる。

• 基本的なフィルタ（アドレス、ポート、プロトコルを試用したフィルタ）

  • MACアドレス：「eth.addr==xx-xx-xx-xx-xx-xx」と記入する。
  • IPアドレス ：「ip.addr==xxx.xxx.xxx.xxx」と記入する。
  • ポート番号 ：「tcp.port==xx」、「udp.port==xx」と記入する。
  • プロトコル ：プロトコル名を小文字で記入する。

• 演算子

  • 上記の例では、「＝」演算子のみを使用しているが、他にも演算子を組み合わせて利用することで、更に複雑なフィルタ式を作成できる。.
  • 以下、演算子の表を示す（演算子には、C言語風の演算子、Perl風の演算子がある）。
  • ディスプレイ フィルタの演算子 | # | 区分 | 意味 | C言語風 | Perl風 | | --- | --- | --- | --- | --- | | 1 | | | | 比較演算子 | | 1-1 | | 等しい | == | eq | | 1-2 | | 等しくない | != | ne | | 1-3 | | より大きい | > | gt | | 1-4 | | より小さい | < | lt | | 1-5 | | 以上 | >= | ge | | 1-6 | | 以下 | <= | le | | 2 | | | | 論理演算子 | | 2-1 | | 論理和 | ｜｜ | or | | 2-2 | | 論理積 | && | and | | 2-3 | | 排他的論理和 | ＾＾ | xor | | 2-4 | | 否定 | ! | not |

• 等しくない

  • eth.addr、ip.addr、tcp.port、udp.portのフィルタ式を「!=」と組み合わせて使用すると正しく動かない。
  • この場合、「==」で評価した式をカッコ「（）」で囲み、その全体を「!」で否定するようにする。

• これ以上に、高度なフィルタ式を作成する必要がある場合は、
  • [フィルタ ツール バー]の脇か、
  • [Display Filter]ダイアログ ボックス中にある

[Expression]ボタンを押して表示される、[Filter Expression]ダイアログを利用する。

• ここでは、フィルタ式に使用できる
  • フィールド・演算子・値を、
  • 選択・入力する

ことでフィルタ式を作成できる。

• 以下は、HTTPのURLのホスト名でフィルタをかける式の作成例である。

1. [Field name]リスト ボックスから「http -> http.host」を選択し、
2. [Relation]リスト ボックスから任意の演算子を選択し、
3. [Value]テキスト ボックスでホスト名を入力する。

• [パケット詳細部]でフィルタに関するデータを選択し、
  • メニューから、[Analyze] ⇒ [Apply as Filters] ⇒ 「フィルタの方法」を選択、
  • もしくは、右クリックして表示されたメニューから[Apply as Filters] ⇒ 「フィルタの方法」を選択

することでフィルタ式を作成することができる。

• 以下は、追加情報に[This frame is a (suspected) fast retransmission]が出力されているパケットのみを表示するため、
  • [パケット詳細部]で[This frame is a (suspected) fast retransmission]を右クリック、
  • 表示されたメニューから[Apply as Filters] ⇒ [Selected]を選択して

フィルタをかけた所である。

• [フィルタ ツール バー]にフィルタ式

  tcp.analysis.fast_retransmission
  

が入力され、パケットがフィルタされたことを確認できる。

マクロな問題の検出についての具体例とWiresharkの操作方法について説明する。

• パケットをキャプチャし、メニューから[Statics] ⇒ [Summary]を選択すると、
  以下のような[Summary]ダイアログが表示され、

• 通信の概要を把握できる。

  • 単位時間辺りの平均転送データ量
  • 単位時間辺りの平均パケット数
  • 平均パケット サイズ

• これらの情報が確認できれば、ネットワークのパフォーマンスが低下した原因が、

  • 帯域幅の不足であるか、
  • スイッチング能力の不足であるか、

推測できる。

• パケットをキャプチャし、メニューから[Statics] ⇒ [Protocol Hierarchy]を選択すると、
  [Protocol Hierarchy Statics]ダイアログが表示され、通信の概要を把握できる。

• 例えば「UDPはTCPに勝つ」という構図がある。
  • HTTPやTelnetなどのTCP通信と、IP電話やテレビ会議などのUDP通信のトラフィックが同時に大量に発生した場合、
    UDPの方が軽量でトラフィックの影響を受け難いため、見かけ上HTTPやTelnetなどのTCP通信が圧迫される。
  • 必要に応じてルータやL3スイッチに実装されるQoS（ネットワークにおけるサービス品質）の
    優先順位・帯域制御などの機能（サービス品質制御機能）を利用する。
  • また、管理者の知らないところで利用禁止されているP2Pソフトが利用されていることなどを、
    プロトコル別一覧から検知することもできる（ただし、対応するプロトコル パーサが実装されている場合に限る）。

• パケットをキャプチャし、メニューから[Statics] ⇒ [IO Graphs]を選択すると[IO Graphs]ダイアログが表示され、時間軸を考慮した通信の概要を把握できる。

• [IO Graphs]ダイアログでは、次のようなグラフを表示できる。

  • [Graphs]グループのコントロールでは、フィルタ式を使用したグラフの生成とフィルタの適用が可能であり、
    [X Axis]・[Y Axis]グループでは、X・Y軸の単位・スケールの変更が可能である。
  • X軸（グラフの横軸）は時間を表す。Y軸（縦軸）はデータ量を表し、単位はパケット数、データ量（バイト）から選択できる。

• 以下の図は、

  • HTTPプロトコルによるWebアクセス、SMBプロトコルによるファイル転送をした際の、
  • IPプロトコル、HTTPプロトコル、SMBプロトコルのパケット数を

グラフにしたものである。

• SMBの1つ目の山は、ファイル サーバの共有フォルダをエクスプロールしている際の通信状態を示している。
  • この場合は、1つのSMBコマンドが1つのIPパケットに収まっているため、
    IP（黒折れ線グラフ）とSMB（赤棒グラフ）がほぼ等しいパケット数を示している。
  • しかし、ファイル転送の際の通信状態を示しているSMBの2つ目の山は、
    • 2つのSMBコマンドが複数のIPパケットに分割されるため、\
    • IP（黒折れ線グラフ）とSMB（赤棒グラフ）に大きな開きが

見られる。

• また、このツールはグラフ毎にスケールが変更できないため、若干使い難い。
  • 例えば、前述のグラフではHTTPのパケット数が少なくSMBのパケット数とスケールが合っていないため、HTTPプロトコルのグラフをハッキリ確認できない。
  • この場合、スケールを変更することでHTTPプロトコルのグラフを確認できる。
    下記は、[Y Axis]グループの[Scale]コンボ ボックスを「AUTO」→「500」に変更した所である。
  • これにより、HTTPプロトコルのグラフが際立ち詳細を確認できるようになるが、全体を一望できなくなってしまう。

• パケットをキャプチャし、メニューから[Statics] ⇒
  • [Endpoints]を選択すると[Endpoints]ダイアログが表示され、ノード毎の通信の概要をプロトコル毎に把握できる。
  • [Endpoint List] ⇒ [任意のプロトコル]を選択した場合は、特定のプロトコルのみのタブ無し[Endpoints]ダイアログが表示され、通信の概要を把握できる。

※ Txは送信、Rxは受信を表す。

• [Endpoints]ダイアログの[IPv4]タブでは、
  • CPUに負荷をかけるブロードキャストなどのトラフィック
  • 特定のサーバへの負荷集中
  • ノートPCの不正な持ち込み
  • PCが放つ異常なトラフィック（不正なP2Pソフトの使用、ウィルス感染の可能性など）

などの問題を検知できる。

• また、［TCP］・［UDP］タブではポートの情報も確認できる。

• パケットをキャプチャし、メニューから[Statics] ⇒ [Conversations]を選択すると
  [Conversations]ダイアログが表示され、2つのノードの、会話毎の通信の概要をプロトコル毎に把握できる。

※　Txは送信、Rxは受信を表す。

• [Conversations]ダイアログの[IPv4]タブでは、
  前述の[Endpoints]ダイアログの「ノード毎の通信の一覧・統計」より、
  さらに細かく「2つのノードの、会話毎の通信の一覧・統計」という形で分析できる。

• また、［TCP］・［UDP］タブではポートの情報も確認できる。

ミクロな問題の検出についての具体例とWiresharkの操作方法について説明する。

• 第2層以下の問題としては、
  • 第1層の物理的な問題と、
  • 第2層のイーサネット（主にNICの設定や、MACアドレスのアドレス解決関連）

の問題が考えられる。

• これらの問題はパケット キャプチャ ツールを使用して、
  • NICドライバまでフレーム・パケットが届いているか。
  • NICの設定やARPによるアドレス解決は正しいか。

などを確認することで問題を切り分ける。

• 例えば重複したIPアドレスが設定されているノードを下記の方法で特定できる。
  • システムの起動時・IPアドレス変更時などに自ノードのIPアドレスに対するARPのアドレス解決要求をブロードキャストする。
  • これをGratuitous ARPと呼ぶ。Gratuitous ARPに対するレスポンスがあった場合は他ノードとIPアドレスが重複していることになる。
  • 以下に、Gratuitous ARPにより重複したIPアドレスを検出した際のパケット キャプチャ結果を示す。

• 以下、Gratuitous ARPのシーケンスを説明する。
  • No13：自ノードのIPアドレスを持つGratuitous ARPがブロードキャストされる。
  • No14：同一のIPアドレスを持つ他ノードはGratuitous ARPにユニキャストで応答する。
  • No15：

この他ノードは、最初のGratuitous ARPのブロードキャストで書き換わった
ARPテーブルを元に戻すため、再びGratuitous ARPをブロードキャストする。

• 同一のIPアドレスを持つノードは、上記のMACアドレスから確認できる。

• 第3層の問題としては、主に
  • ルーティング関連の設定（IPアドレス、サブネット マスク、ルーティング テーブル）、
  • IPパケットのフラグメントに関する設定

のミスが考えられる。

• ルーティング テーブルを持つノードのNICをパケット キャプチャすることで問題を切り分ける。

※ 簡単な問題であれば、ping、tracert などのコマンドでも解決できる。

• フラグメント化
  • 通常のイーサネットでは、MTU（IPパケットの最大サイズ）は1500バイトになる。---これ以上のサイズのIPパケットはフラグメント化される。

物理（インターフェイス）規格毎の最大MTUサイズ | # | 規格 | 規格の説明 | 最大MTUサイズ | | --- | --- | --- | --- | | 1 | Ethernet | CSMA/CD方式のLAN規格 | 1,500バイト | | 2 | FDDI | トークンリング方式のLAN規格（利用は終焉しつつある） | 4,352バイト | | 3 | ATM | 広域ATMネットワーク、速度保証を謳ったキャリアサービス | 9,180バイト | | 4 | X.25 | 公衆回線網用 | 1,600バイト | | 5 | フレームリレー | 光ファイバなど | 1,600バイト |

• フラグメント化に関するビットには以下のビットがあり、フラグメント オフセット値には、分割されたパケットが全体のどの位置にあるかが指定される。
• これらの情報はIPヘッダに書きこまれているので、[パケット詳細部]でIPパケットの情報を確認する。

IPパケットのフラグメント化に関するビット | # | フラグ | 意味 | | --- | --- | --- | | 1 | Reserved bit | 予約されているビット（現状は利用されていない）。 | | 2 | Don’t fragment（DFビット） | フラグメント化を禁止するビットで、このビットがオンの時には、IPパケットは分割されなくなる。 | | 3 | More fragment（MFビット） | Don’t fragmentビットがオフの時に、後続に分割されたビットが続くかどうかを示す。 |

• サービス品質制御

  • サービス品質制御は、ルータやL3スイッチに実装されるQos（ネットワークにおけるサービス品質）の優先順位・帯域制御などの機能で実現される 。
  • L2スイッチもVLANで利用できる、タグを使用したサービス品質制御の機能を備えている。
  • ルータがパケットの優先度を決める方法には次の2つがある。
    • 送信元や送信先のIPアドレス、使用プロトコル、ポート番号で決める。
    • IPパケットの優先度を明示的にIPパケット内のフィールド（TOS・DSCP）で指定する。
  • TOSフィールド・DSCPフィールドは、パケット詳細部で確認できる。
    このフィールドの値の意味や、サービス品質制御に関する詳細は、専門書を参考のこと。

• プロトコル番号

  • プロトコル フィールドのプロトコル番号は、対象のIPパケットが何の上位プロトコル（トランスポート層）をカプセル化しているかを示す。
  • イーサネット上では、殆どのパケットが6番（TCP）、17番（UDP）を示す。
  • プロトコル番号は、IANAにより規定されている。
  • プロトコル番号に関する詳細は下記のWebページを参照のこと。
    iana.org > Assigned Internet Protocol Numbers
    http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml

• VPN間で通信できなくなる問題

  • 現象
    • VPN間でSMB通信をすると通信できなくなった。
    • ファイル サーバのNICをパケット キャプチャしたところ、一定サイズ以上のIPパケットが破棄されていた。
    • VPNルータのNICをパケット キャプチャしたところ、VPNルータAの内側のNIC ⇒ 外側のNICでIPパケットの破棄が起きていることが確認できた。

• 分析

  • そこで、VPNルータA の設定を確認した所、MTUサイズがイーサネット側とVPN側で異なっていることが判明した。
  • イーサネットではMTUサイズ：1500バイト、VPNではMTUサイズ：1280バイトとなっていた。
  • 通常は、DFビットが立っておりMTUサイズが異なることで通信ができなくなる場合は、
    ルータはICMPメッセージ（type3 code4 Next-Hop xxxx byte）を送信元に送信して、
    クライアントPCがこれより小さいMTUサイズで通信をリトライするように要求する。 | # | 表示 | 説明 | | --- | --- | --- | | 1 | Type3 | Destination Unreachable（到達不能） | | 2 | Code4 | Fragmentation Needed and Don't Fragment was Set | | 3 | xxxx byte | 現在のMTU値より小さい値でリトライを要求する。 |

• 結果

  • しかし、ルータのF/W機能でICMPメッセージを破棄する設定になっていると
    送信元にこのICMPメッセージが届かなくなり、通信できなくなる。
    この現象を[Path MTU Discovery Black Hole]と言う。
  • VPNルータAの設定を確認した所、ICMPメッセージをルータが破棄する設定になっており、本現象も[Path MTU Discovery Black Hole]に該当していることが判明した 。
  • このようなことがあるため、pingコマンドはDFフラグを立て、大きなサイズのデータで試す方が効果的である。

• サブネットマスクの設定ミス

  • 現象

    • ルータへの負荷が突然高くなった。
    • クライアントPCのNICをパケットキャプチャした所、
      ARPパケットから同一サブネットのIPアドレスへの通信が、
      デフォルト ゲートウェイ（ルータ）に送信されていることが確認できた。

  • 分析

    • そこで、クライアントの設定を確認した所、DHCPから配信されているサブネットマスクが
      1ビット余分に（255.255.255.0 → 255.255.255.128）設定されていることが確認できた。
    • サブネットマスク | # | 設定値 | 10進数表記 | 2進数表記 | | --- | --- | --- | --- | | 1 | サブネットマスク（正） | 255.255.255.0 | 11111111.11111111.11111111.00000000 | | 2 | サブネットマスク（誤） | 255.255.255.128 | 11111111.11111111.11111111.10000000 | | 3 | クライアントIP | xxx.xxx.xxx.56 | 00001010.11010011.00100001.00111000 | | 4 | サーバIP | xxx.xxx.xxx.134 | 00001010.11010011.00100001.10000110 |

  • 結果
    これにより上記表の項番４の、サーバのIPアドレスがクライアントPCからは違うサブネットのIPアドレスに見えてしまい、
    クライアントPCはサーバに対してパケットを送信する際、デフォルト ゲートウェイにパケットを送信していることが判明した。

• pingコマンドは通るが、実際には通信できないなどの問題が発生した場合、

  • 初めにnetstatコマンドを使用して
    リスニング ポート、プログラム、F/Wのパケット フィルタリング、
    その他TCP関連のパラメタ設定ミスがないかを確認する。
  • これでも問題が解決しない場合は、TCPのパケット内のデータを確認して問題を検出する。

• また、TCPではコネクション、ウィンドウ・フロー制御で問題が発生することがあり、
  これらに問題がある場合は、通信のオーバヘッドが大きくなり遅延が発生することが多い。
  このため、TCPの場合はこの点を重点的に分析する。

• TCPのプロトコル スタックの実装はベンダ、装置、OSなどにより様々で、未だに進化を続けている。
  このため、この進化に取り残された装置・OSなどがネットワーク上に混在していることがある。

  • 例えば、任意の装置・OSでRFC1323に記述されているウィンドウ スケール オプションを必ず使用できるかと言うと、そうとは限らない。
  • TCPのプロトコル スタックでは、このような実装の非互換により障害が起こることも考えられるため、
    今後の技術動向や新しくリリースされた装置・OSの実装にも注意を払う必要がある。

以下、TCPにおける問題の分析方法を説明する。

• シーケンス番号・ACK番号
  • シーケンス番号・ACK番号を確認することで、TCPの通信シーケンスを分析できる。
    シーケンス番号は、送信データのバイト数増加し、ACK番号は受信データのバイト数増加する
    （シーケンス番号・ACK番号は、送信側・受信側で別々に管理される）。
  • TCPの通信シーケンスを分析する場合は、メニューから[Statics] ⇒ [Flow Graph]を選択し、
    [Flow Graph]ダイアログで[TCP flow]オプション ボタンをチェックして、[OK]ボタンを押す。

• すると、TCPの通信シーケンスを分析する[Graph Analysis]ダイアログが表示される。
  ここから、TCPの通信シーケンスの詳細を分析できる。

• ただし、この分析方法では分析対象データが膨大になるので、大量のキャプチャ データから問題を抽出する場合は、
  TCPフラグ、TCPオプション、Wiresharkの追加情報などを使用してデータを検索・フィルタする方が、効率が良い。

• TCPセグメント詳細情報（TCPフラグ）から異常を確認する

  • TCPセグメント詳細情報にあるTCPフラグを確認する。
    TCPフラグを下記の表に示す。TCPフラグはビットマスクが可能になっている。

TCPのフラグ | # | 区分 | フラグ | 意味 | フラグの位置 | 16進表記 | | --- | --- | --- | --- | --- | --- | | 1 | | | | | 一般的なパケット | | 1-1 | | SYN | TCPコネクション接続時にセットされる。 | 00000000000010 | 0x02 | | 1-2 | | FIN | TCPコネクション切断時にセットされる。 | 00000000000001 | 0x01 | | 1-3 | | ACK | 肯定応答。接続開始時～終了時まですべてのパケットはACKフラグがオンになる。 | 00000000010000 | 0x10 | | 1-4 | | PSH | バッファ内容をアプリに渡す。 | 00000000001000 | 0x08 | | 2 | | | | | 特殊なパケット | | 2-1 | | RST | 問題発生時、緊急に接続を切断する。 | 00000000000100 | 0x04 | | 2-2 | | URG | 緊急に処理するパケットを示す。 | 00000000100000 | 0x20 | | 2-3 | | ECE | CEパケット の受信を送信側に通知する。 | 00000001000000 | 0x40 | | 2-4 | | CWR | 輻輳ウィンドウの縮小を相手に通知する。輻輳情報通知機能（ECN）で使用される。
輻輳ウィンドウとは、広告ウィンドウに対して、送信側が輻輳を起こさずに送信可能と推測したウィンドウ。 | 00000010000000 | 0x80 |

• TCPフラグのECE、CWRを分析する場合、IPヘッダのECTビット、CEビットも確認する。

  • ECTビット:Transport層プロトコルがECNに対応していることを示す。
  • CEビット:CEパケットにより、輻輳が起きていることを示す。ルータにより設定される。

• TCPフラグは[パケット詳細部]から確認でき、Wiresharkのフィルタ機能を使用して、
  コネクションの接続・切断、コネクションの拒否や輻輳 など問題となっているパケットを特定できる。

• 輻輳の発生を回避する技術や、輻輳状態から速やかに回復させる技術のことを輻輳制御と呼び、
  輻輳の状態が悪化し、通信効率が非常に低くなる状態を輻輳崩壊と呼ぶ。

  • 特にTCPでは輻輳によりパケット遅延が発生した場合、
    再送処理を自動で実行するため更に輻輳が悪化し輻輳崩壊へ至ることがある。
  • このためTCPでは様々な輻輳回避アルゴリズムが考えられている。
    その核となっているのが、「スロースタート」と「輻輳回避」という二つの輻輳制御である。
    ● スロースタート : 通信開始時は通信速度を遅くして、その後、回線速度に合わせて徐々に通信速度を速める。
    ● 輻輳回避 : ネットワークが混雑している時は速度を落す。

• TCPフラグのフィルタ式を入力する場合、[Filter Expression]ダイアログを使用する。

  • TCPフラグの[Field name]として、以下のものを利用できる。

TCPのフラグ（フィルタ式） | # | フラグ | フィルタ式（文字） | フィルタ式（ビット） | 備考 | | --- | --- | --- | --- | --- | | 1 | SYN | tcp.flags.syn == 1 | tcp.flags == 0x02 | 接続切断の検出に利用可能 | | 2 | FIN | tcp.flags.fin == 1 | tcp.flags == 0x01 | 〃 | | 3 | ACK | tcp.flags.ack == 1 | tcp.flags == 0x10 | － | | 4 | PSH | tcp.flags.push == 1 | tcp.flags == 0x08 | － | | 5 | RST | tcp.flags.reset == 1 | tcp.flags == 0x04 | 問題の検出に利用可能 | | 6 | URG | tcp.flags.urg == 1 | tcp.flags == 0x20 | 緊急データの検出に利用可能 | | 7 | ECE | tcp.flags.ecn == 1 | tcp.flags == 0x40 | 輻輳の検出に利用可能 | | 8 | CWR | tcp.flags.cwr == 1 | tcp.flags == 0x80 | 〃 |

- [SYN/ACK]、[PSH/ACK]などを含まない、[ACK]のみを抽出する場合は、フィルタ式（ビット）のビットマスクを使用する。

• 以下は、RSTフラグが立っているパケットをフィルタした所である。

• Wiresharkが自動生成するパケット ステータスから異常を確認する

  • Wiresharkは、以下の問題を分析して、TCPのパケットに追加情報を設定する。

    • TCPのコネクション
    • ウィンドウ・フロー制御
      ● ウィンドウ サイズの状態
      ● パケット遅延
      ● ロストしたパケット
      ● 再送要求のパケット
      ● 再送されたパケット\

  • このTCPの追加情報を下記の表に示す。
    これを元にWiresharkのフィルタ機能を使用して、問題となっているパケットを特定できる。

    • TCPの追加情報 | # | 区分 | TCPの追加情報 | 説明 | | --- | --- | --- | --- | | 1 | | | ウィンドウサイズの異常 | | 1-1 | | TCP Window Full | ウィンドウサイズを0にするパケットに付与される。
      ※ この後、項番2の[TCP Zero Window]が返される。 | | 1-2 | | TCP Zero Window | ウィンドウサイズが0になったことを示すメッセージのパケットに付与される。
      このパケットを受信した場合、送信を一旦停止する。
      ※ この後、項番5の[TCP Window Update]が返される。 | | 1-3 | | TCP Zero Window Violation | ウィンドウサイズが0で送信されたパケットに付与される。 | | 1-4 | | TCP Zero Window Probe | [TCP Zero Window]の受信後に送信される。
      ウィンドウ プローブ（探査）パケットに付与される。 | | 1-5 | | TCP Zero Window Probe Ack | [TCP Zero Window Probe]に対する応答。 | | 1-6 | | TCP Window Update | ウィンドウサイズが拡張されたことを示すメッセージのパケットに付与される。
      このパケットを受信した場合、送信が再開される。 | | 2 | | | パケットの消失と再送 | | 2-1 | | TCP Previous segment lost | シーケンス番号が不正である（期待する番号より大きい）パケットに付与される
      （パケットが失われたと判断する）。 | | 2-2 | | TCP Dup ACK | 同じACK番号が入った再送要求のACKパケットに付与される
      （パケットが失われた際の再送要求を意味する）。 | | 2-3 | | TCP Restansmission | 再送要求で再送されたパケットに付与される。
      送信の際にTCP 再送タイマを開始（通常は3秒に初期化）、
      タイマの有効期限が切れる前に送信データに対するACK応答が受信されない場合、データを再送信する。 | | 2-4 | | TCP Fast Restansmission | 再送要求で高速再送 されたパケットに付与される。
      TCP Dup ACKが3回到着した場合、パケットをロスしたと判断し、すぐにそのロスト パケットを再送する。 | | 3 | | | キープアライブ | | 3-1 | | TCP Keep - Alive | 直前のパケットと同じシーケンス番号であるパケットに付与される（TCPキープアライブ パケット）。 | | 3-2 | | TCP Keep - Alive ACK | TCPキープアライブ パケットへのレスポンス | | 4 | | | その他 | | 4-1 | | TCP Out – Of - Order | シーケンス番号が不正である（期待する番号より小さい）パケットに付与される（不明なステータス）。 | | 4-2 | | TCP ACKed lost segment | ACKに対するパケットが見つからない場合に、そのACKパケットに付与される（不明なステータス）。 |

  • TCP追加情報のフィルタ式を入力する場合、[Filter Expression]ダイアログを使用する。

    • TCP追加情報の[Field name]として、以下のものを利用できる。

TCPの追加情報（フィルタ式） | # | 追加情報 | フィルタ式 | | --- | --- | --- | | 1 | TCP Window Full | tcp.analysis.window_full | | 2 | TCP Zero Window | tcp.analysis.zero_window | | 3 | TCP Zero Window Violation | tcp.analysis.zero_window | | 4 | TCP Zero Window Probe | tcp.analysis.zero_window_probe | | 5 | TCP Zero Window Probe Ack | tcp.analysis.zero_window_probe_ack | | 6 | TCP Window Update | tcp.analysis.window_update | | 7 | TCP Previous segment lost | tcp.analysis.lost_ segment | | 8 | TCP Dup ACK | tcp.analysis.duplicate_ack | | 9 | TCP Restansmission | tcp.analysis.restansmission | | 10 | TCP Fast Restansmission | tcp.analysis.fast_restansmission |

- 以下は、[TCP Dup ACK]のパケットをフィルタした所である。

• TCPストリームで上位プロトコルを確認する

  • TCPストリームを確認する場合は、パケット一覧部で１つのTCP/IP通信のレコードを選択した状態で、
    メニューの[Analyze] ⇒ [Follow TCP Stream]を選択する。

  • すると、TCPコネクションのオープンからクローズまでの１つのTCPストリームが、
    フィルタ式によりフィルタされTCPストリームのデータを確認できる。

  • これにより、上位プロトコルのクライアント - サーバ間のやり取りを分析できる。
    TCPストリームはTCPの上位プロトコルのやり取りを分析する際に有用である。

  • TCPストリームでは、送信データと受信データが赤色・青色で分類されている。

    • TCPストリームはIPレイヤでパケットがどのように分割されたかなどの情報は表さない。
    • また、通常のプロトコルではありえないが、仮に双方のノードが同時に
      TCPストリームに書き込みを行った場合でも、上り・下りのストリームを別々に分析できる
      （TCPが通信の順番を制御するため、上り・下りのデータがパケット単位で混合することはない）。
    • TCPストリームには、このような特徴があるため、セション層以上のプロトコルを分析するのに重宝する。

  • 例えば、パケット一覧部でHTTPプロトコルのパケットを選択した状態で、[Analyze] ⇒ [Follow TCP Stream]を選択すれば、
    1コネクションで処理されたHTTPのリクエストとレスポンスのペアを確認できる。

    • これに対し、HTTP1.1プロトコルのHTTP Keep-Aliveが有効になっているパケットを選択した状態で、
      [Analyze] ⇒ [Follow TCP Stream]を選択すれば、1コネクションで処理された複数のリクエストとレスポンスを確認できる。
    • HTTP1.1のHTTP Keep-Aliveでは、性能向上のため、1回のTCPコネクションで、複数回のリクエスト ～ レスポンスを処理するように設計されている。
    • このため、TCPストリーム中に複数の1回のリクエスト ～ レスポンスを確認できる。

  • また、SMBプロトコル（ここではファイル共有サービス）のキャプチャ レコードを選択した状態で、
    [Follow TCP Stream]を選択すれば、SMBプロトコルのTCPストリームのデータを確認できる。

    • 同様に、送信データと受信データが赤色・青色で分類されている。
      しかし、SMBプロトコルのコマンドはHTTPなどと異なり複雑で、テキストでの分析は困難である。

    • SMBなどのテキストで分析し難いプロトコルの詳細は、SMBのプロトコル パーサ が
      出力するパケット詳細部の情報を元に、1パケット毎、SMBコマンドを分析する。

• エラー・警告・注意パケットの抽出

  • メニューの[Analyze] ⇒ [Expert Info]を選択することで[Expert Infos]ダイアログに、
    TCPのコネクション、ウィンドウ・フロー制御（ウィンドウ サイズの状態、パケット遅延、ロストしたパケット、再送要求のパケット、再送されたパケット）
    などのエラー・警告・注意パケットの情報を抽出できる。

[Expert Infos]ダイアログにおけるパケットの分類 | | 分類 | 分類 | 説明 | | --- | --- | --- | --- | | 1 | Error | エラー | フィールドと実際のパケットの長さが違う.etc、エラーを示す。 | | 2 | Warn | 警告 | ＴＣＰのパケット欠落、高速再送の発生.etcを警告する。 | | 3 | Note | 注意 | 再送要求、再送の発生、ウィンドウサイズの問題.etcを注意する。 | | 4 | Chat | 会話 | HTTPのリクエスト レスポンス、TCPのコネクションの接続・切断, etc.を示す。 |

• また、メニューの[Analyze] ⇒ [Expert Info Composite]を選択することで、[Expert Info Composite]ダイアログに、
  統計情報も含めたトラブルシューティングに役立つエラー・警告、コネクションの情報を抜き出して表示できる
  （[Details]タブには、[Expert Infos]ダイアログの内容が表示される）。

• コネクションの接続・切断回数を確認する

  • パケット遅延が大きい環境などでは、HTTP Keep-Aliveが無効に設定されている場合、
    TCPコネクションの接続・切断回数が多くなり、オーバヘッドが大きくなっている場合がある。

    • その他、SSLの利用時にHTTP Keep-Aliveが無効の場合、
      SSLコネクション確立のオーバヘッドが大きくなっている場合がある。

  • TCPコネクションの接続を示す3ウェイ ハンドシェイク部分を抜き出すには、

    • 以下のフィルタ式を適用するか、

      [SYNパケット]  or  [SYN / ACKパケット]  or  [ACKパケット（シーケンス番号1）]
      ------------------------------------------------------------------------
      tcp.flags == 0x02 || tcp.flags == 0x12 || ( tcp.flags == 0x10 && tcp.seq == 1 )
      └───────┘　└───────┘　　└─────────────────┘
            SYN                SYN/ACK                  ACKかつシーケンス番号が1
      

※ [SYN/ACK]、[PSH/ACK]などを含まない、[ACK]のみを抽出する場合は、フィルタ式（ビット）のビットマスクを使用する。

- [Expert Info Composite]ダイアログの[Chats]・[Details]タブを分析する。

• 予期せぬ接続の切断、輻輳などを確認する

  • 予期せぬ接続の切断を確認する場合は、RSTパケットを抜き出すため、以下のフィルタ式を適用する。

    tcp.flags.reset == 1
    

  • 例えば、リスニング ポートが重複していた場合など、コネクション確立後、直ちにRSTパケットにより接続が切断されることがある。

• pingコマンドは通るが、通信できないなどの問題が発生した場合など、

  • 初めにnetstatコマンドを使用して
    リスニング ポート、プログラム、F/Wのパケット フィルタリング
    などのパラメタ設定ミスがないかを確認する。
  • これでも問題が解決しない場合は、UDPのパケット内のデータを確認して問題を検出する。

• UDPの問題は、コネクション、ウィンドウ・フロー制御など、複雑な制御に起因することは無い
  （これは必要であればアプリケーション側で実装される）。

  • このため、UDPプロトコルのデータ（UDPヘッダ）自体に情報は殆ど無く、大部分がデータである。
  • 従って、UDPパケットの解析は、パケット キャプチャ ツールを使用してクライアント － サーバ間のデータをダンプして比較するだけになる。
    単純に思えるが、個々のパケット単位での照合は難しいので注意が必要になる（パケットの順番がずれることもある）。

• そのプロトコルのTCPストリームを確認し、
• プロトコルの動作・仕様、クライアント・サーバ プログラムの問題などを確認する。

• トラブルシュート事例（HTTP, FTP） | # | プロトコル | 現象 | | | 原因と、その特定方法 | | --- | --- | --- | --- | --- | --- | | 1 | | | | | HTTP | | 1-1 | | | | | HTTPの画面表示の遅延が大きい | | 〃 | 〃 | 〃 | | 原因 | HTTPキープアライブが無効になっていたため、SSLの使用や遅延の大きいネットワークでHTMLから複数のリンク ファイルをダウンロードする際に、接続確立のオーバヘッドが大きくなった。 | | 〃 | 〃 | 〃 | | 特定方法 | HTTPクライアントのNICをパケット キャプチャし、[Follow TCP Stream]ダイアログ、[Expert Info Composite]ダイアログを分析したところ、TCPコネクションの接続・切断が多発していることを確認した。 | | 1-2 | | | | | Webアプリケーション サーバでエラーが発生する | | 〃 | 〃 | 〃 | | 原因 | IEのキャッシュ制御の仕様がファジー（不明確）で、度々エラーが発生していた。 | | 〃 | 〃 | 〃 | | 特定方法 | HTTPクライアントのNICをパケット キャプチャし、[Follow TCP Stream]ダイアログでHTTPリクエスト・レスポンスを確認し、WWWブラウザのキャッシュ制御の仕様を分析した。キャッシュ制御の分析は「Fiddler（HTTP デバッグ プロキシ）」を使用しても良い。 | | 2 | | | | | FTP | | 2-1 | | | | | FTPサーバからダウンロードできない（アクティブモード） | | 〃 | 〃 | 〃 | | 原因 | アクティブモードのFTPでは、FTPサーバからFTPクライアントのファイル データ受信専用の、不特定の非特権ポートにアクティブ　オープンに行く。このクライアント側F/Wのポートを空けていなかった。 | | 〃 | 〃 | 〃 | | 特定方法 | FTPサーバのNICをパケット キャプチャし、クライアント側F/Wでフィルタリングされるポートに対してTCPのパケットが飛んでいることを確認した。 | | 2-2 | | | | | FTPサーバからダウンロードできない（パッシブモード） | | 〃 | 〃 | 〃 | | 原因 | パッシブモードのFTPでは、FTPクライアントからFTPサーバのファイル データ受信専用の、不特定の非特権ポートにアクティブ　オープンに行く。このサーバ側F/Wのポートを空けていなかった。 | | 〃 | 〃 | 〃 | | 特定方法 | FTPクライアントのNICをパケット キャプチャし、サーバ側F/Wでフィルタリングされるポートに対してTCPのパケットが飛んでいることを確認した。 | | 2-3 | | | | | FTPでファイルが見つからないエラー | | 〃 | 〃 | 〃 | | 原因 | FTPサーバが本来、相対パスでファイル一覧を返すところを、絶対パスで返すと言うFTPサーバ プログラム上のエラー。 | | 〃 | 〃 | 〃 | | 特定方法 | FTPクライアントのNICをパケット キャプチャし、FTPサーバのレスポンスから本来の相対パスのファイル一覧ではなく、絶対パスのファイル一覧が返っていることを確認した。 |

• トラブルシュート事例（SMB, その他） | # | プロトコル | 現象 | | | 原因と、その特定方法 | | --- | --- | --- | --- | --- | --- | | 3 | | | | | SMB | | 3-1 | | | | | Excelファイルのオープンが遅い | | 〃 | 〃 | 〃 | | 原因 | ネットワークにパケット遅延があり、更にExcelから発行されるSMBコマンドが多いことでオーバヘッドが大きくなった。 | | 〃 | 〃 | 〃 | | 特定方法 | ネットワーク経由のファイル オープン時、Excelによる排他制御などのSMBコマンドの実行が多発していることを確認した。 | | 3-2 | | | | | 特定のアプリケーションで、SMB経由の保存ができない(NAS) | | 〃 | 〃 | 〃 | | 原因 | UNIX・FAT優先モードになっており、NTFS用のアクセス・マスクのリクエストが処理できない。 | | 〃 | 〃 | 〃 | | 特定方法 | ファイル サーバのNICをパケット キャプチャし、正常ケース・異状系ケースのパケット詳細部の差異を見つけて、NASの開発元（サポート）に連絡、NASの設定に問題があることを確認した。 | | 3-3 | | | | | SMBで認証できない（WindowsCE + NAS） | | 〃 | 〃 | 〃 | | 原因 | クライアント・サーバ プログラムの作り込みの不一致。 | | 〃 | 〃 | 〃 | | 特定方法 | ファイル サーバのNICをパケット キャプチャし、正常ケース・異状系ケースのパケット詳細部の差異を見つけて、NASの開発元（サポート）に連絡、NAS側のプログラムに問題があることを確認した。
  WindowsでないSMB/CIFSサーバは、問題が起こることが多いので注意が必要。 | | 4 | | | | | その他 | | 4-1 | | | | | 認証でエラー | | 〃 | 〃 | 〃 | | 原因 | パスワードの入力・設定ミス | | 〃 | 〃 | 〃 | | 特定方法 | クライアントのNICをパケット キャプチャし、パケット詳細部（SMB）や、[Follow TCP Stream]ダイアログ（HTTP, POP3）を確認して、パスワードを確認する。 | | 4-2 | | | | | FTPサーバのレスポンス遅延 | | 〃 | 〃 | 〃 | | 原因 | FTPサーバがログ出力のためDNSを逆引き（IPアドレス⇒FQDN名）をしているが、DNSに当該レコードが無かったためレスポンスが大幅に遅延していた。 | | 〃 | 〃 | 〃 | | 特定方法 | FTPサーバのNICをパケット キャプチャし、リクエスト ～ レスポンスの間にDNS逆引きのDNSクエリが実行されていることを確認した。 |

• 以下は、HTTPとPOP3の認証エラーのトラブルシュート時のパケット キャプチャ例である。

• Wiresharkは、OSI参照モデルで言う所の第4・5層のキャプチャをする。

• 従って、キャプチャした情報は、フレームやパケット単位で見ることになる。

• HTTPのリクエスト・レスポンス(OSI参照モデルで言う所の第6層以上)
  のコンテンツについては、[Follow TCP Stream]で確認することができる。

• 参考

  • TCPストリームで上位プロトコルを確認する
  • Wiresharkで特定の通信セッションだけを抽出して表示する － ＠IT
    http://www.atmarkit.co.jp/fwin2k/win2ktips/1048wsharkstream/wsharkstream.html
  • [Follow TCP Stream]の結果、リクエスト・レスポンスの見た目が、
    HTTP 100-continue などによりキレイに繋がらないことがあります。
    • HTTP 100-continue - ..たれろぐ..
      http://d.hatena.ne.jp/naga_sawa/20101114/1289709797
    • また、全角文字が「・」で表示され確認できません。

下記を参照下さい。

• ネットワーク入門サイト - Wiresharkの使い方
  http://beginners-network.com/wireshark.html
• Wiresharkで特定のプロトコルだけを表示させる － ＠IT
  http://www.atmarkit.co.jp/fwin2k/win2ktips/1050wsfiltproto/wsfiltproto.html
• Wiresharkで特定の相手との通信だけを表示させる － ＠IT
  http://www.atmarkit.co.jp/fwin2k/win2ktips/1065wsfiltaddr/wsfiltaddr.html
• Wiresharkで特定の通信セッションだけを抽出して表示する － ＠IT
  http://www.atmarkit.co.jp/fwin2k/win2ktips/1048wsharkstream/wsharkstream.html

• さくらのナレッジ
  • （前編）―基本的な使い方とパケット解析
    https://knowledge.sakura.ad.jp/6286/
  • （後編）―コマンドラインベースでのパケットキャプチャ
    https://knowledge.sakura.ad.jp/6311/

• WinPcapは、パケット キャプチャに関する機能を提供するソフトウェア
• 以下のモジュールから構成される。
  • システム非依存型の「wpcap.dll」
  • ローレベル ライブラリ「Packet.dll」
  • カーネル モードのNDIS中間ドライバ「npf.sys」
• Wiresharkでは、WinPcapを使用してパケット キャプチャを行っている。

tsharkというCUI版も存在する様です。

Tags: インフラストラクチャ, 通信技術, 障害対応, 性能, デバッグ, ツール類