Wiresharkの操作方法 のバックアップ(No.10)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• Wiresharkの操作方法 へ行く。
  • 1 (2017-05-04 (木) 22:58:16)
  • 2 (2017-05-04 (木) 23:06:10)
  • 3 (2017-05-07 (日) 21:39:38)
  • 4 (2017-05-08 (月) 15:28:24)
  • 5 (2017-05-09 (火) 16:49:43)
  • 6 (2017-05-10 (水) 12:05:22)
  • 7 (2017-05-10 (水) 15:33:34)
  • 8 (2017-05-10 (水) 15:36:24)
  • 9 (2017-10-29 (日) 18:07:43)
  • 10 (2017-11-28 (火) 09:22:20)
  • 11 (2018-01-16 (火) 16:21:49)

---

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

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

目次 †

概要 †

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

Wiresharkの特徴 †

区分 †

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 Interfaces]ダイアログ †

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

[Capture Option]ダイアログ †

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

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

設定項目 : (1) 監視対象のインターフェイス（NIC）を選択 †

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

設定項目 : (2) 監視に使用するメモリ量 †

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

設定項目 : (3) プロミスキャス モード †

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

設定項目 : (4) パケットのデータ サイズ †

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

設定項目 : (5) キャプチャ フィルタ †

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

設定項目 : (6) リアルタイム更新 †

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

設定項目 : (7) ファイル保存 †

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

設定項目 : (8) 名前解決 †

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

設定項目 : (9) 監視の停止方法 †

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

キャプチャ フィルタ †

[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 form （インターフェイス名）]ダイアログ †

• メニューの[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）

を確認できる。

キャプチャ結果の確認 †

GUIの確認 †

キャプチャを終了すると以下のような画面が表示される。ここには、主要な表示部位を示す。
※ メニュー バーの[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層以下の問題の検出 †

• 第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)の問題の検出 †

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

のミスが考えられる。

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

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

IPの問題点として確認できること †

• フラグメント化
  • 通常のイーサネットでは、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

IPのトラブルシュート事例 †

• 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はサーバに対してパケットを送信する際、デフォルト ゲートウェイにパケットを送信していることが判明した。

第4層(TCP)の問題の検出 †

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

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

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

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

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]ダイアログの内容が表示される）。
  

TCPのトラブルシュート事例 †

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

• パケット遅延が大きい環境などでは、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パケットにより接続が切断されることがある。
    

第4層(UDP)の問題の検出 †

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

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

7-5層(HTTP・FTP・SMTP・SMB)の問題の検出 †

セッション層以上のプロトコルの問題点として確認できること †

• そのプロトコルの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の認証エラーのトラブルシュート時のパケット キャプチャ例である。
  
  

HTTPのキャプチャ †

• 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の使い方 †

下記を参照下さい。

• ネットワーク入門サイト - 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

Wiresharkを使った通信監視 †

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

WinPcap? †

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

tshark †

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

---

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

     

Site admin: dotNetDevelopmentInfrastructure

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.183 sec.