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

目次

概要

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

Wiresharkの特徴

区分

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

LANアナライザの区分

区分ごとの特徴

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

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

インストール

ダウンロード

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

インストール

  • デフォルト設定でインストールする。
  • 基本的にデフォルトのインストールで問題ない。
  • 以下、インストール オプションの注意点のみ抜粋して説明する。
  • (a) のインストール オプションは、
    • Wiresharkのインターフェイスのオプションで、
      前バーションのEtherealのインターフェイスで利用したい場合は、
      「Wireshark(legacy GTK1 user interface)」を選択する。
    • ココでは「Wireshark(GTK2 user interface)」前提で説明を進める。
  • (b) のインストール オプションは、
    • WinPcapをインストールするかどうかのオプションである。
    • Wiresharkのパケット キャプチャに必須のソフトウェアである。
    • 既にインストールされている場合を除いて必ずインストールする。
  • (c) のインストール オプションは、
    • Administrator権限を持たないユーザでもパケット キャプチャができるように、システム起動時にNICドライバをロードする設定である。
    • Wiresharkはプロミスキャスモードのパケット キャプチャが可能であり、セキュリティ上好ましくないので、
      プロミスキャスモードを必要としない場合は、基本的にこのオプションは有効にすべきでないと考える。
Wiresharkのインストール オプション

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

キャプチャ準備

[Capture Interfaces]ダイアログ

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

[Capture Interfaces]ダイアログ

[Capture Option]ダイアログ

  • キャプチャ オプションを設定したい場合は、[Option]ボタンをして、[Capture 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]ダイアログ ボックスが表示され、フィルタの例からフィルタ式を選択できる。

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

フィルタ式・演算子

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

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

キャプチャ開始

[Capture form (インターフェイス名)]ダイアログ

  • メニューの[Capture]を選択し[Interface]をクリックする。
  • すると、[Capture Interface]ダイアログにインターフェイス(NIC)一覧が表示されるので、
    トラフィックを監視するNICの[Option]ボタンを押して、前述の設定をした後に、
    [Hide capture info dialog] チェック ボックスのチェックを外し、[Start]ボタンを押す。
  • これにより、以下の[Capture form (インターフェイス名)]ダイアログが表示され、全体の統計情報を確認しながらトラフィックを監視できる。
  • このダイアログの、 [Stop]ボタンが押されるか、停止設定値に達するまで、トラフィックの監視が継続される。
  • 以下の図は、NIC監視中の[Capture form (インターフェイス名)]ダイアログである。
[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の各機能を呼び出す際に使用する。使用方法は後述する。

ツール バー

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

  • メニュー1
    • ファイルの、オープン、セーブ、クローズ、リロードが可能。
    • オープン・セーブの際は、対象パケットの入・出力範囲の選択も可能。
  • メニュー2
    • パケット印刷ダイアログを表示し、データのプリンタ出力や
    • テキストファイル出力ができる。出力範囲・出力部位の選択も可能。
      パケット印刷ダイアログ
  • メニュー3
    • パケット検索ダイアログを表示し、条件に合ったパケットに移動する。
    • 検索条件には、フィルタ式、16進値、文字列値などが指定できる。
      パケット検索ダイアログ
  • メニュー4

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

  • メニュー5

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

  • メニュー6

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

フィルタ ツール バー

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

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

[Filter Expression]ダイアログ

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

パケット一覧部

  • [パケット一覧部]には、キャプチャしたパケットの概要がレコード一覧として表示される。
  • 1行に付き1パケット(フレーム)が表示され、簡単な説明が表示される。
パケット一覧部
  • 以下、レコードのカラムについて説明する。
#項目説明
1Noキャプチャしたパケット番号(パケット番号はフィルタを適用しても変わらない。)
2Timeキャプチャした時間表示
メニューの[Time Display Format…]から形式を変更可能。
・[Date and Time of Day]:日付 時刻
・[Time of Day]:時刻
・[Second Since Beginning of Day]:最初のパケットからの相対表示 → デフォルト
3Source送信元のMACアドレス、IPアドレス、ホスト名など
4Destination送信先のMACアドレス、IPアドレス、ホスト名など
5Protocol最上位層のプロトコル(プロトコル パーサで解釈できる場合)
プロトコル パーサ : キャプチャしたプロトコルを解釈するために必要なDLL
6Info各プロトコルの簡易情報
概要の把握には役に立つが、詳細はパケット詳細部で確認する。
  • 上記のレコードは、ファイル共有(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)機能で使用できる。
パケット詳細部の情報を利用した検索(Find)も可能
  • また、[パケット詳細部]には以下の追加情報が出力される
    (これらの情報はパケットのデータ中には含まれないので注意する)。
    • TCPパケットの前後の関係をWiresharkが判断して自動生成性した追加情報(Generated fields)、
    • 他のパケットへのリンク(Link)
  • 例えば、パケット詳細部の[SEQ/ACK Analysis]フィールドには、
    • シーケンス番号・ACK番号からTCPの通信シーケンスを分析するための追加情報・リンクが付与される。
    • 以下の図に示す[This is an ACK to the segment in frame: xx]という追加情報・リンクは、
      このパケットがリンク先のパケットに対するACKであることを示す。
パケット詳細部 - 追加情報とリンク(1)
  • [パケット一覧部]の簡易情報に表示されていた[TCP segment of a reassembled PDU]という情報も、この追加情報である。
  • [パケット詳細部]を確認すると、下記情報が表示されていることを確認できる。
    • [Reassembled PDU in frame: xxxx]という追加情報
    • IPレイヤで分割されたパケットを束ねるリンク
パケット詳細部 - 追加情報とリンク(2)
  • Wiresharkは、
    • ノードが同一TCPコネクション上で初めのパケットの送信(・受信)を開始してから、
    • TCP のPushフラグ 付きのパケットを送信(・受信)するまでの、
      • Pushフラグ(TCPフラグ)は、TCPの受信バッファのデータをアプリケーションに送るように、送信側が受信側に対して指示するためのフラグである。
      • その他のTCPフラグについては、「TCPセグメント詳細情報(TCPフラグ)から異常を確認する?」で説明する。
  • 一連のパケット に、[TCP segment of a reassembled PDU]追加情報・リンクを付与しているものと思われる。
  • 以下は、Pushフラグ付きのSMBの「Write AndX Request」コマンドのパケットである。
    「Write AndX Request」コマンドのパケットを確認すると、分割されたIPパケットへのリンクを確認できる。
パケット詳細部 - 追加情報とリンク(3)
  • また、トランスポート層のプロトコル(TCP、UDP)より上位のプロトコルである
    DNS 、HTTPなどのプロトコルでも、それぞれのプロトコル パーサによって追加情報・リンクが付与される。
    • 例えば、DNSクエリ(パケット)を参照すると、このDNSクエリに対するレスポンス(パケット)へのリンクを確認できる。
パケット詳細部 - 追加情報とリンク(DNS)
  • また、以前のバージョンでは、パケット データ部から読み取るしかなかったHTTPのエンティティ ボディの情報が、
    Version0.99.7のプロトコル パーサからパケット詳細部の[Line - Based text data]フィールドに
    テキストとして出力されるようになった(ただしASCII以外の文字は正しく表示されない)。
パケット詳細部 - 追加情報(HTTP)

パケット データ部

  • [パケット データ部]では、[パケット一覧部]で選択したパケットの情報が表示される。
  • 以下は、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]ボタンを押して新しいフィルタの例を作成することもできる。
[Display Filter]ダイアログ ボックス

フィルタ式を手入力する

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

  • 基本的なフィルタ(アドレス、ポート、プロトコルを試用したフィルタ)
    • 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]ダイアログを利用する。

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

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

[Filter Expression]ダイアログ ボックス
  • 以下は、HTTPのURLのホスト名でフィルタをかける式の作成例である。
    1. [Field name]リスト ボックスから「http -> http.host」を選択し、
    2. [Relation]リスト ボックスから任意の演算子を選択し、
    3. [Value]テキスト ボックスでホスト名を入力する。
HTTPのURL中に含まれるホスト名でフィルタをかけた結果(1)

パケット詳細部で選択中のデータを元にフィルタする

  • [パケット詳細部]でフィルタに関するデータを選択し、
    • メニューから、[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]を選択して

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

HTTPのURL中に含まれるホスト名でフィルタをかけた結果(2)
  • [フィルタ ツール バー]にフィルタ式
    tcp.analysis.fast_retransmission

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

マクロな問題検出についての具体例

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

帯域の不足、スイッチング能力、ワイヤ スピード

  • パケットをキャプチャし、メニューから[Statics] ⇒ [Summary]を選択すると、
    以下のような[Summary]ダイアログが表示され、
[Summary]ダイアログ
  • 通信の概要を把握できる。
    • 単位時間辺りの平均転送データ量
    • 単位時間辺りの平均パケット数
    • 平均パケット サイズ
  • これらの情報が確認できれば、ネットワークのパフォーマンスが低下した原因が、
    • 帯域幅の不足であるか、
    • スイッチング能力の不足であるか、

推測できる。

通信の一覧・統計

プロトコル階層毎の通信の一覧・統計

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

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

[IO Graphs]ダイアログ
  • 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プロトコルのグラフが際立ち詳細を確認できるようになるが、全体を一望できなくなってしまう。
[IO Graphs]ダイアログのスケールを変更し、HTTPのグラフを際立たせた所

ノード毎の通信の一覧・統計

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

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

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

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

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

2つのノードの、会話毎の通信の一覧・統計

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

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

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

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

第3層(IP)の問題の検出

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

のミスが考えられる。

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

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

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

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

      物理(インターフェイス)規格毎の最大MTUサイズ

      #規格規格の説明最大MTUサイズ
      1EthernetCSMA/CD方式のLAN規格1,500バイト
      2FDDIトークンリング方式のLAN規格(利用は終焉しつつある)4,352バイト
      3ATM広域ATMネットワーク、速度保証を謳ったキャリアサービス9,180バイト
      4X.25公衆回線網用1,600バイト
      5フレームリレー光ファイバなど1,600バイト
  • フラグメント化に関するビットには以下のビットがあり、フラグメント オフセット値には、分割されたパケットが全体のどの位置にあるかが指定される。
  • これらの情報はIPヘッダに書きこまれているので、[パケット詳細部]でIPパケットの情報を確認する。

    IPパケットのフラグメント化に関するビット

    #フラグ意味
    1Reserved bit予約されているビット(現状は利用されていない)。
    2Don’t fragment(DFビット)フラグメント化を禁止するビットで、このビットがオンの時には、IPパケットは分割されなくなる。
    3More 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間でSMB通信をすると通信できなくなる現象
  • 分析
    • そこで、VPNルータA の設定を確認した所、MTUサイズがイーサネット側とVPN側で異なっていることが判明した。
    • イーサネットではMTUサイズ:1500バイト、VPNではMTUサイズ:1280バイトとなっていた。
    • 通常は、DFビットが立っておりMTUサイズが異なることで通信ができなくなる場合は、
      ルータはICMPメッセージ(type3 code4 Next-Hop xxxx byte)を送信元に送信して、
      クライアントPCがこれより小さいMTUサイズで通信をリトライするように要求する。
      #表示説明
      1Type3Destination Unreachable(到達不能)
      2Code4Fragmentation Needed and Don't Fragment was Set
      3xxxx byte現在のMTU値より小さい値でリトライを要求する。
      SMBのIPパケットに付与されているDFビット
  • 結果
    • しかし、ルータの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.011111111.11111111.11111111.00000000
      2サブネットマスク(誤)255.255.255.12811111111.11111111.11111111.10000000
      3クライアントIPxxx.xxx.xxx.5600001010.11010011.00100001.00111000
      4サーバIPxxx.xxx.xxx.13400001010.11010011.00100001.10000110
  • 結果
    これにより上記表の項番4の、サーバの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]ボタンを押す。
[Flow Graph]ダイアログ
  • すると、TCPの通信シーケンスを分析する[Graph Analysis]ダイアログが表示される。
    ここから、TCPの通信シーケンスの詳細を分析できる。
[Graph Analysis]ダイアログ
  • ただし、この分析方法では分析対象データが膨大になるので、大量のキャプチャ データから問題を抽出する場合は、
    TCPフラグ、TCPオプション、Wiresharkの追加情報などを使用してデータを検索・フィルタする方が、効率が良い。
  • TCPセグメント詳細情報(TCPフラグ)から異常を確認する
    • TCPセグメント詳細情報にあるTCPフラグを確認する。
      TCPフラグを下記の表に示す。TCPフラグはビットマスクが可能になっている。

      TCPのフラグ

      #区分フラグ意味フラグの位置16進表記
      1一般的なパケット
      1-1SYNTCPコネクション接続時にセットされる。000000000000100x02
      1-2FINTCPコネクション切断時にセットされる。000000000000010x01
      1-3ACK肯定応答。接続開始時~終了時まですべてのパケットはACKフラグがオンになる。000000000100000x10
      1-4PSHバッファ内容をアプリに渡す。000000000010000x08
      2特殊なパケット
      2-1RST問題発生時、緊急に接続を切断する。000000000001000x04
      2-2URG緊急に処理するパケットを示す。000000001000000x20
      2-3ECECEパケット の受信を送信側に通知する。000000010000000x40
      2-4CWR輻輳ウィンドウの縮小を相手に通知する。輻輳情報通知機能(ECN)で使用される。
      輻輳ウィンドウとは、広告ウィンドウに対して、送信側が輻輳を起こさずに送信可能と推測したウィンドウ。
      000000100000000x80
  • TCPフラグのECE、CWRを分析する場合、IPヘッダのECTビット、CEビットも確認する。
    • ECTビット:Transport層プロトコルがECNに対応していることを示す。
    • CEビット:CEパケットにより、輻輳が起きていることを示す。ルータにより設定される。
      パケット詳細部(IPヘッダ)
  • TCPフラグは[パケット詳細部]から確認でき、Wiresharkのフィルタ機能を使用して、
    コネクションの接続・切断、コネクションの拒否や輻輳 など問題となっているパケットを特定できる。
    パケット詳細部(TCPフラグ)
  • 輻輳の発生を回避する技術や、輻輳状態から速やかに回復させる技術のことを輻輳制御と呼び、
    輻輳の状態が悪化し、通信効率が非常に低くなる状態を輻輳崩壊と呼ぶ。
    • 特にTCPでは輻輳によりパケット遅延が発生した場合、
      再送処理を自動で実行するため更に輻輳が悪化し輻輳崩壊へ至ることがある。
    • このためTCPでは様々な輻輳回避アルゴリズムが考えられている。
      その核となっているのが、「スロースタート」と「輻輳回避」という二つの輻輳制御である。
      ● スロースタート : 通信開始時は通信速度を遅くして、その後、回線速度に合わせて徐々に通信速度を速める。
      ● 輻輳回避 : ネットワークが混雑している時は速度を落す。
  • TCPフラグのフィルタ式を入力する場合、[Filter Expression]ダイアログを使用する。
    • TCPフラグの[Field name]として、以下のものを利用できる。

      TCPのフラグ(フィルタ式)

      #フラグフィルタ式(文字)フィルタ式(ビット)備考
      1SYNtcp.flags.syn == 1tcp.flags == 0x02接続切断の検出に利用可能
      2FINtcp.flags.fin == 1tcp.flags == 0x01
      3ACKtcp.flags.ack == 1tcp.flags == 0x10
      4PSHtcp.flags.push == 1tcp.flags == 0x08
      5RSTtcp.flags.reset == 1tcp.flags == 0x04問題の検出に利用可能
      6URGtcp.flags.urg == 1tcp.flags == 0x20緊急データの検出に利用可能
      7ECEtcp.flags.ecn == 1tcp.flags == 0x40輻輳の検出に利用可能
      8CWRtcp.flags.cwr == 1tcp.flags == 0x80
  • [SYN/ACK]、[PSH/ACK]などを含まない、[ACK]のみを抽出する場合は、フィルタ式(ビット)のビットマスクを使用する。
  • 以下は、RSTフラグが立っているパケットをフィルタした所である。
    パケット詳細部(RSTフラグが立っているパケットをフィルタ)
  • Wiresharkが自動生成するパケット ステータスから異常を確認する
  • Wiresharkは、以下の問題を分析して、TCPのパケットに追加情報を設定する。
    • TCPのコネクション
    • ウィンドウ・フロー制御
      ● ウィンドウ サイズの状態
      ● パケット遅延
      ● ロストしたパケット
      ● 再送要求のパケット
      ● 再送されたパケット
  • このTCPの追加情報を下記の表に示す。
    これを元にWiresharkのフィルタ機能を使用して、問題となっているパケットを特定できる。
    • TCPの追加情報
      #区分TCPの追加情報説明
      1ウィンドウサイズの異常
      1-1TCP Window Fullウィンドウサイズを0にするパケットに付与される。
      ※ この後、項番2の[TCP Zero Window]が返される。
      1-2TCP Zero Windowウィンドウサイズが0になったことを示すメッセージのパケットに付与される。
      このパケットを受信した場合、送信を一旦停止する。
      ※ この後、項番5の[TCP Window Update]が返される。
      1-3TCP Zero Window Violationウィンドウサイズが0で送信されたパケットに付与される。
      1-4TCP Zero Window Probe[TCP Zero Window]の受信後に送信される。
      ウィンドウ プローブ(探査)パケットに付与される。
      1-5TCP Zero Window Probe Ack[TCP Zero Window Probe]に対する応答。
      1-6TCP Window Updateウィンドウサイズが拡張されたことを示すメッセージのパケットに付与される。
      このパケットを受信した場合、送信が再開される。
      2パケットの消失と再送
      2-1TCP Previous segment lostシーケンス番号が不正である(期待する番号より大きい)パケットに付与される
      (パケットが失われたと判断する)。
      2-2TCP Dup ACK同じACK番号が入った再送要求のACKパケットに付与される
      (パケットが失われた際の再送要求を意味する)。
      2-3TCP Restansmission再送要求で再送されたパケットに付与される。
      送信の際にTCP 再送タイマを開始(通常は3秒に初期化)、
      タイマの有効期限が切れる前に送信データに対するACK応答が受信されない場合、データを再送信する。
      2-4TCP Fast Restansmission再送要求で高速再送 されたパケットに付与される。
      TCP Dup ACKが3回到着した場合、パケットをロスしたと判断し、すぐにそのロスト パケットを再送する。
      3キープアライブ
      3-1TCP Keep - Alive直前のパケットと同じシーケンス番号であるパケットに付与される(TCPキープアライブ パケット)。
      3-2TCP Keep - Alive ACKTCPキープアライブ パケットへのレスポンス
      4その他
      4-1TCP Out – Of - Orderシーケンス番号が不正である(期待する番号より小さい)パケットに付与される(不明なステータス)。
      4-2TCP ACKed lost segmentACKに対するパケットが見つからない場合に、そのACKパケットに付与される(不明なステータス)。
  • TCP追加情報のフィルタ式を入力する場合、[Filter Expression]ダイアログを使用する。
    • TCP追加情報の[Field name]として、以下のものを利用できる。

      TCPの追加情報(フィルタ式)

      #追加情報フィルタ式
      1TCP Window Fulltcp.analysis.window_full
      2TCP Zero Windowtcp.analysis.zero_window
      3TCP Zero Window Violationtcp.analysis.zero_window
      4TCP Zero Window Probetcp.analysis.zero_window_probe
      5TCP Zero Window Probe Acktcp.analysis.zero_window_probe_ack
      6TCP Window Updatetcp.analysis.window_update
      7TCP Previous segment losttcp.analysis.lost_ segment
      8TCP Dup ACKtcp.analysis.duplicate_ack
      9TCP Restansmissiontcp.analysis.restansmission
      10TCP Fast Restansmissiontcp.analysis.fast_restansmission
  • 以下は、[TCP Dup ACK]のパケットをフィルタした所である。
    パケット詳細部([TCP Dup ACK]追加情報があるパケットをフィルタ)
  • TCPストリームで上位プロトコルを確認する
    • TCPストリームを確認する場合は、パケット一覧部で1つのTCP/IP通信のレコードを選択した状態で、
      メニューの[Analyze] ⇒ [Follow TCP Stream]を選択する。
    • すると、TCPコネクションのオープンからクローズまでの1つの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回のリクエスト ~ レスポンスを確認できる。
    HTTPのTCPストリームとHTTP Keep-AliveのTCPストリーム
  • また、SMBプロトコル(ここではファイル共有サービス)のキャプチャ レコードを選択した状態で、
    [Follow TCP Stream]を選択すれば、SMBプロトコルのTCPストリームのデータを確認できる。
    • 同様に、送信データと受信データが赤色・青色で分類されている。
      しかし、SMBプロトコルのコマンドはHTTPなどと異なり複雑で、テキストでの分析は困難である。
      SMBのTCPストリーム
  • SMBなどのテキストで分析し難いプロトコルの詳細は、SMBのプロトコル パーサ が
    出力するパケット詳細部の情報を元に、1パケット毎、SMBコマンドを分析する。
    パケット詳細部(SMB)
  • エラー・警告・注意パケットの抽出
    • メニューの[Analyze] ⇒ [Expert Info]を選択することで[Expert Infos]ダイアログに、
      TCPのコネクション、ウィンドウ・フロー制御(ウィンドウ サイズの状態、パケット遅延、ロストしたパケット、再送要求のパケット、再送されたパケット)
      などのエラー・警告・注意パケットの情報を抽出できる。

      [Expert Infos]ダイアログにおけるパケットの分類

      分類分類説明
      1Errorエラーフィールドと実際のパケットの長さが違う.etc、エラーを示す。
      2Warn警告TCPのパケット欠落、高速再送の発生.etcを警告する。
      3Note注意再送要求、再送の発生、ウィンドウサイズの問題.etcを注意する。
      4Chat会話HTTPのリクエスト レスポンス、TCPのコネクションの接続・切断, etc.を示す。
      [Expert Infos]ダイアログ
  • また、メニューの[Analyze] ⇒ [Expert Info Composite]を選択することで、[Expert Info Composite]ダイアログに、
    統計情報も含めたトラブルシューティングに役立つエラー・警告、コネクションの情報を抜き出して表示できる
    ([Details]タブには、[Expert Infos]ダイアログの内容が表示される)。
    [Expert Infos Composite]ダイアログ

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]のみを抽出する場合は、フィルタ式(ビット)のビットマスクを使用する。
      3ウェイ ハンドシェイク部分をフィルタ
  • [Expert Info Composite]ダイアログの[Chats]・[Details]タブを分析する。
  • 予期せぬ接続の切断、輻輳などを確認する
    • 予期せぬ接続の切断を確認する場合は、RSTパケットを抜き出すため、以下のフィルタ式を適用する。
      tcp.flags.reset == 1
    • 例えば、リスニング ポートが重複していた場合など、コネクション確立後、直ちにRSTパケットにより接続が切断されることがある。
      [RST]フラグがあるパケットをフィルタ

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

  • pingコマンドは通るが、通信できないなどの問題が発生した場合など、
    • 初めにnetstatコマンドを使用して
      リスニング ポート、プログラム、F/Wのパケット フィルタリング
      などのパラメタ設定ミスがないかを確認する。
    • これでも問題が解決しない場合は、UDPのパケット内のデータを確認して問題を検出する。
  • UDPの問題は、コネクション、ウィンドウ・フロー制御など、複雑な制御に起因することは無い
    (これは必要であればアプリケーション側で実装される)。
    • このため、UDPプロトコルのデータ(UDPヘッダ)自体に情報は殆ど無く、大部分がデータである。
    • 従って、UDPパケットの解析は、パケット キャプチャ ツールを使用してクライアント - サーバ間のデータをダンプして比較するだけになる。
      単純に思えるが、個々のパケット単位での照合は難しいので注意が必要になる(パケットの順番がずれることもある)。

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

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

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

セッション層以上のプロトコルのトラブルシュート事例

  • トラブルシュート事例(HTTP, FTP)
    #プロトコル現象原因と、その特定方法
    1HTTP
    1-1HTTPの画面表示の遅延が大きい
    原因HTTPキープアライブが無効になっていたため、SSLの使用や遅延の大きいネットワークでHTMLから複数のリンク ファイルをダウンロードする際に、接続確立のオーバヘッドが大きくなった。
    特定方法HTTPクライアントのNICをパケット キャプチャし、[Follow TCP Stream]ダイアログ、[Expert Info Composite]ダイアログを分析したところ、TCPコネクションの接続・切断が多発していることを確認した。
    1-2Webアプリケーション サーバでエラーが発生する
    原因IEのキャッシュ制御の仕様がファジー(不明確)で、度々エラーが発生していた。
    特定方法HTTPクライアントのNICをパケット キャプチャし、[Follow TCP Stream]ダイアログでHTTPリクエスト・レスポンスを確認し、WWWブラウザのキャッシュ制御の仕様を分析した。キャッシュ制御の分析は「Fiddler(HTTP デバッグ プロキシ)」を使用しても良い。
    2FTP
    2-1FTPサーバからダウンロードできない(アクティブモード)
    原因アクティブモードのFTPでは、FTPサーバからFTPクライアントのファイル データ受信専用の、不特定の非特権ポートにアクティブ オープンに行く。このクライアント側F/Wのポートを空けていなかった。
    特定方法FTPサーバのNICをパケット キャプチャし、クライアント側F/Wでフィルタリングされるポートに対してTCPのパケットが飛んでいることを確認した。
    2-2FTPサーバからダウンロードできない(パッシブモード)
    原因パッシブモードのFTPでは、FTPクライアントからFTPサーバのファイル データ受信専用の、不特定の非特権ポートにアクティブ オープンに行く。このサーバ側F/Wのポートを空けていなかった。
    特定方法FTPクライアントのNICをパケット キャプチャし、サーバ側F/Wでフィルタリングされるポートに対してTCPのパケットが飛んでいることを確認した。
    2-3FTPでファイルが見つからないエラー
    原因FTPサーバが本来、相対パスでファイル一覧を返すところを、絶対パスで返すと言うFTPサーバ プログラム上のエラー。
    特定方法FTPクライアントのNICをパケット キャプチャし、FTPサーバのレスポンスから本来の相対パスのファイル一覧ではなく、絶対パスのファイル一覧が返っていることを確認した。
  • トラブルシュート事例(SMB, その他)
    #プロトコル現象原因と、その特定方法
    3SMB
    3-1Excelファイルのオープンが遅い
    原因ネットワークにパケット遅延があり、更にExcelから発行されるSMBコマンドが多いことでオーバヘッドが大きくなった。
    特定方法ネットワーク経由のファイル オープン時、Excelによる排他制御などのSMBコマンドの実行が多発していることを確認した。
    3-2特定のアプリケーションで、SMB経由の保存ができない(NAS)
    原因UNIX・FAT優先モードになっており、NTFS用のアクセス・マスクのリクエストが処理できない。
    特定方法ファイル サーバのNICをパケット キャプチャし、正常ケース・異状系ケースのパケット詳細部の差異を見つけて、NASの開発元(サポート)に連絡、NASの設定に問題があることを確認した。
    3-3SMBで認証できない(WindowsCE + NAS)
    原因クライアント・サーバ プログラムの作り込みの不一致。
    特定方法ファイル サーバのNICをパケット キャプチャし、正常ケース・異状系ケースのパケット詳細部の差異を見つけて、NASの開発元(サポート)に連絡、NAS側のプログラムに問題があることを確認した。
    WindowsでないSMB/CIFSサーバは、問題が起こることが多いので注意が必要。
    4その他
    4-1認証でエラー
    原因パスワードの入力・設定ミス
    特定方法クライアントのNICをパケット キャプチャし、パケット詳細部(SMB)や、[Follow TCP Stream]ダイアログ(HTTP, POP3)を確認して、パスワードを確認する。
    4-2FTPサーバのレスポンス遅延
    原因FTPサーバがログ出力のためDNSを逆引き(IPアドレス⇒FQDN名)をしているが、DNSに当該レコードが無かったためレスポンスが大幅に遅延していた。
    特定方法FTPサーバのNICをパケット キャプチャし、リクエスト ~ レスポンスの間にDNS逆引きのDNSクエリが実行されていることを確認した。
  • 以下は、HTTPとPOP3の認証エラーのトラブルシュート時のパケット キャプチャ例である。
    HTTPのプロキシ認証、基本認証のTCPストリーム
    POP3の認証のTCPストリーム

HTTPのキャプチャ

  • Wiresharkは、OSI参照モデルで言う所の第4・5層のキャプチャをする。
  • 従って、キャプチャした情報は、フレームやパケット単位で見ることになる。
  • HTTPのリクエスト・レスポンス(OSI参照モデルで言う所の第6層以上)
    のコンテンツについては、[Follow TCP Stream]で確認することができる。

参考

Wiresharkの使い方

下記を参照下さい。

Wiresharkを使った通信監視

WinPcap?

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

tshark

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


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


添付ファイル: fileTCPStreamOfHttpAuth.png 157件 [詳細] fileTCPStreamOfPOP3.png 130件 [詳細] fileTroubleshootOfRST.png 149件 [詳細] filePacketDetailPart3WayHandshaking.png 325件 [詳細] fileExpertInfosDialog.png 349件 [詳細] fileExpertInfosCompositeDialog.png 338件 [詳細] filePacketDetailPartSMB.png 335件 [詳細] fileTCPStreamOfSMB.png 137件 [詳細] fileTCPStreamOfHttp.png 190件 [詳細] filePacketDetailPartTCPDupACK.png 418件 [詳細] filePacketDetailPartRST.png 407件 [詳細] filePacketDetailPartTCP.png 347件 [詳細] filePacketDetailPartIP.png 402件 [詳細] fileGraphAnalysisDialog.png 410件 [詳細] fileFlowGraphDialog.png 331件 [詳細] fileTroubleshootOfSubnet.png 138件 [詳細] fileTroubleshootOfVPN2.png 145件 [詳細] fileTroubleshootOfVPN1.png 138件 [詳細] filePacketDataPartOfProtocolNo.png 303件 [詳細] filePacketDataPartOfQosControl.png 340件 [詳細] filePacketDataPartOfFragment.png 361件 [詳細] fileGratuitousARP.png 332件 [詳細] fileConversationsDialog.png 369件 [詳細] fileEndpointsDialog.png 332件 [詳細] fileIOGraphsDialog2.png 408件 [詳細] fileIOGraphsDialog1.png 338件 [詳細] fileProtocolHierarchyStaticsDialog.png 231件 [詳細] fileSummaryDialog.png 161件 [詳細] fileFilterExpressionDialogHostNameInHttp2.png 327件 [詳細] fileFilterExpressionDialogHostNameInHttp1.png 398件 [詳細] fileDisplayFilterDialog2.png 358件 [詳細] fileDisplayToolbar.png 337件 [詳細] fileStatusBar.png 153件 [詳細] filePacketDataPart.png 277件 [詳細] filePacketDetailPart_AdditionalInformationAndLinksHTTP.png 306件 [詳細] filePacketDetailPart_AdditionalInformationAndLinksDNS.png 278件 [詳細] filePacketDetailPart_AdditionalInformationAndLinks3.png 318件 [詳細] filePacketDetailPart_AdditionalInformationAndLinks1.png 348件 [詳細] filePacketDetailPart_AdditionalInformationAndLinks2.png 363件 [詳細] filePacketDetailPart2.png 347件 [詳細] filePacketDetailPart1.png 384件 [詳細] filePacketListPart.png 273件 [詳細] fileFilterExpressionDialog.png 362件 [詳細] fileDisplayFilterDialog1.png 323件 [詳細] fileFilterToolBar.png 362件 [詳細] filePacketPrintingDialog.png 288件 [詳細] filePacketSearchDialog.png 246件 [詳細] fileMenu6.png 328件 [詳細] fileMenu5.png 343件 [詳細] fileMenu4.png 350件 [詳細] fileMenu3.png 325件 [詳細] fileMenu2.png 426件 [詳細] fileMenu1.png 350件 [詳細] fileMainScreen.png 418件 [詳細] fileCaptureFormInterfaceDialog.png 377件 [詳細] fileCaptureFilterDialog.png 398件 [詳細] fileCaptureOptionDialog.png 386件 [詳細] fileCaptureInterfacesDialog.png 359件 [詳細] fileInstallationOptionOfWireshark.png 152件 [詳細] fileClassificationOfLanAnalyzer.png 381件 [詳細]

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-01-16 (火) 16:21:49 (695d)