Wiresharkを使った解析
Wiresharkを使ったパケット全体の流れの解析、1つ1つのパケットの解析方法について説明しています。
Wiresharkの基本的な使い方については、前ページの「Wiresharkの使い方」をご参照下さい。
パケット一覧概略
パケット一覧(Packet List)は、概ね以下のようになっています。
赤枠で囲った部分の説明は、以下の通りです。
項目 | 説明 |
---|---|
No. | 採取したパケットの順番を示します。 |
Time | 1番目のパケットから経過した時間を秒で示します。「表示」から「時刻表示形式」を選択すると何時何分、1つ前のパケットからの間隔等に表示を切り替える事が出来ます。 |
Source | 送信元のIPアドレスを示します。IPアドレスがない場合はMacアドレスが表示されます。 |
Destination | 送信先のIPアドレスを示します。IPアドレスがない場合はMacアドレスが表示されます。 |
Protocol | プロトコルを示します。 |
Length | フレームの長さをByteで表示します。 |
Info | そのパケットがどんな意味を持つか概略を表示します。 |
パケット一覧での解析
表示されているパケットについて説明していきます。
表示されているパケットは、以下のようにパソコンからインターネットにあるWebサーバーにブラウザでアクセスした際に採取したパケットを加工したもので、IPアドレスも以下の図のように加工しています。
赤枠部分はARPのやりとりを示します。No.1のパケットは、パソコンがルーターのMacアドレスを知るために宛先をブロードキャストとしてARP解決を行おうとしています。Destination部分がBroadcast、Info部分がWho has 172.16.1.1となっているのが確認出来ると思います。
No.2のパケットは、ルーターからの応答で自身のMacアドレスを応答しています。Info部分で172.16.1.1 is at 11:ff:11:ff:11:ffとなっているのが確認出来ると思います。
既にパソコンのARPテーブルに載っている場合は、この通信は発生しません。
赤枠部分はDNSのやりとりを示します。No.3のパケットで、パソコンがルーターにexample.comのIPアドレスを教えてくれるように問い合わせています。Info部分がStandard query 0x0cf3 A example.comになっているのが確認出来ると思います。queryは問い合わせを意味します。
No.4のパケットは、ルーターからの回答でexample.comのIPアドレスは172.16.2.1である事が分かります。responseは応答を意味します。
既にパソコンのDNSキャッシュに載っている場合は、この通信は発生しません。
DNSの応答がない場合は、DNSサーバーと通信出来ていない可能性があります。存在しないFQDNで問い合わせをしても、DNSサーバーからは存在しないと応答があるためです。
ここまでで通信先のIPアドレスが分かったため、次からがWebサーバーとの通信です。
赤枠部分で、TCP通信を開始する時の3ウェイハンドシェイクを行っています。パソコン→Webサーバー、Webサーバーから応答、パソコンから再度応答の順で、info部分では[SYN]、[SYN,ACK]、[ACK]と順番になっているのが確認出来ると思います。
最初の[SYN]が送信されているにも関わらず、[SYN,ACK]が返ってこない場合は正常にルーティング出来ていない、フィルタリングされている等の要因が考えられます。
通信出来ない場合は、多くの場合、ここまでのどこかで止まっていると思います。
3ウェイハンドシェーク完了後、パソコンからWebサーバーにコンテンツの要求を示すコマンドを送信しています。info部分でGET / HTTP/1.1が確認出来ると思います。これはhttpのコマンドで、他にはPOST等があります。
No.9と10のパケットで、パソコンからの要求に応じてWebサーバーからデータを送信しています。No.11はそのAckで正常にデータを受信している事を示しています。ここでは「TCP通信の流れ」で示したWindowsの遅延Ackに従い、2つ受信したらAckを返しています。
No.12から14も同様で、繰り返しになります。その際、サーバーからのデータ送信のシーケンス番号はMSS値である1414byte足した分増えて行きます。No.9、No.10、No.12、No.13のinfo部分でSeq=1、Seq=1415、Seq=2829、Seq=4243と変わっているのが確認出来ると思います。
又、パソコンからの応答は、最後にサーバーから受信したシーケンス番号にMSS値である1414byteを足した数がAck番号になります。No.11はNo.10のSeq=1415に1414を足してAck=2829、No.14はNo.13のSeq=4243に1414を足してAck=5657となっているのが確認出来ると思います。
通信の終わりを示します。パソコンから[FIN,ACK]を送信し、サーバー側では[ACK]で応答します。又、サーバー側からも[FIN,ACK]を送信し、パソコンから[Ack]の応答があります。
通信に異常がある場合は黒や茶色等で分かるように色分けされて表示されるため、そのパケットに注目すると解析し易くなります。
パケット詳細概略
パケット詳細(Packet Details)は、以下のように最初は要約された情報だけが表示されていますが、左の>部分をクリックする事で詳細が見れるようになります。
例えば上から2つ目の>をクリックすると、以下のようになります。
見たい部分の>をクリックしていく事で、詳細が見れるようになっています。
IPヘッダー部分で>をクリックすると、以下のように表示されます。
各項目の意味は、以下の通りです。
項目 | 説明 |
---|---|
Version | 上記ではIPv4を示しています。IPv6では6になります。 |
Header length | IPヘッダーの長さをbyteで示しています。 |
Differentiated Services Field | DSCPと記述している部分ではQosで使う優先度が表示されます。上の例ではセットされていません。 |
Total length | パケットの長さをbyteで示しています。 |
Identification | IDを示し、通信が進むにつれて増えて行きます。 |
Frags | パケットを途中でフラグメントして良いかを示します。上の例ではDon't fragmentになっているため途中でのフラグメントを許可していません。 |
Time to live | TTLを示します。ルーターを介する度に1引かれ、0になると破棄されます。 |
Protocol | 上位レイヤーのプロトコルを示します。上の例ではTCPを示しています。 |
Header checksum | IPヘッダーのチェックサムです。 |
Source | 送信元IPアドレスです。 |
Destination | 送信先IPアドレスです。 |
上記は、応用編「パケット」の「パケットヘッダー構造」で示した構造に従って、16進数を分かり易い形にして表示したものになります。
TCPヘッダー部分で>をクリックすると、以下のように表示されます。
各項目の意味は以下の通りです。
項目 | 説明 |
---|---|
Source port | 送信元のポート番号を示しています。 |
Destination port | 送信先のポート番号を示しています。 |
Sequence number | シーケンス番号を示しています。 |
Acknowledgment number | Ack番号を示しています。 |
Header length | TCPヘッダーの長さをbyteで示しています。 |
Flags | SYNやAck等を示します。 |
Windows size value | ウィンドウサイズを示しています。スライディングウィンドウで受信出来ない程送られてくるとここを0で応答し、一時的に送ってこないようにしてその間にデータを処理するようにします。 |
Checksum | TCPヘッダーのチェックサムです。 |
Urgent pointer | 受信側で処理を優先する緊急データの位置を示します。緊急データが含まれていない場合は0になります。 |
TCP payload | ヘッダーを除いた長さです。TCP segment dataと同じです。 |
TCP segment data | データ部分の長さを示し、この値がMSSに当たります。 |
上記は、応用編「TCP・UDP」の「TCPヘッダーの構造」で示した構造に従って16進数を分かり易い形にして表示したものになりますが、[]で囲まれた部分はWiresharkが独自に追加した情報です。例えば、Nextsequence numberでは次のシーケンス番号が確認出来ます。
トラブル時の解析例
通信開始の際、以下のようにARPが沢山出力されていて次に進んでいないとします。
ゲートウェイに対してARP解決しようとしていますが応答がないため、Macアドレスが分からず通信出来ない状態です。
ケーブルが接続されていない、リンクアップしていない、VLANが違う、ネゴシエーションが合っていない等レイヤーが低い位置を疑う必要があります。
次は、以下のようにDNSの部分から次に進んでいない場合の例です。
1番目のパケットでDNSのリクエストを送信し、2番目で応答がありますが、Info部分を見て分かる通りNo such nameで名前解決出来ていません。
存在しないサーバーと通信しようとしているか、DNSの設定が間違っている等が考えられます。
DNSが原因の場合、このように分かり易い時もありますが、通信の途中でDNSの通信があって遅くなる場合もあります。この場合は、Timeの部分を確認して下さい。DNSの通信があって次のパケットが送信されるまで間隔が長い場合、DNSが正常に引けてなくて通信が遅くなっている可能性があります。
次は、以下の場合です。
5番目のパケットのパケット詳細でFlags部分を確認すると、Don't Fragmentになっているのが確認出来ると思います。サーバー側でこのままMSSを小さくせずにフラグメント化も許可しない場合は、通信出来ないままタイムアウトになります。
このようにトラブル発生時の解析では、どこで通信が止まっているかパケット一覧で確認し、その前後のパケットをパケット詳細で見てどこに原因があるか推測していきます。止まっていないように見えても、再送を繰り返している事もあります。その場合は、シーケンス番号やAck番号を確認する事も必要です。
前のページ「Wiresharkの使い方」
- トラブル対応「ポートミラーリング」