tcpdump と Wireshark の一般的なメッセージのトラブルシューティング - ECS

ネットワークパケットキャプチャは、トラブルシューティングやセキュリティ監査などのシナリオで広く使用されています。この Topic では、tcpdump または Wireshark を使用してパケットをキャプチャする際に発生する可能性のある一般的な問題と、その解決方法について説明します。

背景

tcpdump と Wireshark は、強力なネットワークプロトコル分析ツールです。Wireshark は、Linux、Windows、macOS など、ほとんどの主流のオペレーティングシステムをサポートしています。通常、クラウド環境の Linux インスタンスには、デフォルトでグラフィカルユーザーインターフェイス (GUI) がインストールされていません。したがって、クラウド環境の Linux インスタンスでネットワークパケットをキャプチャする必要がある場合は、tcpdump ツールを使用することをお勧めします。2 つのツールのインストール方法と使用方法の詳細については、「パケットキャプチャツールを使用してネットワークパケットをキャプチャする」をご参照ください。

tcpdump の一般的なメッセージとソリューション

[キャプチャ中にパケットサイズが制限されました]

問題: 次の図に示すように、パケットの長さは 171 バイトですが、最初の 96 バイトのみがキャプチャされます。

考えられる原因: このメッセージは、完全なパケットがキャプチャされなかったことを示します。これは通常、パケットキャプチャツールのデフォルト設定が原因で発生します。

ソリューション: 一部のオペレーティングシステムでは、tcpdump はデフォルトで各フレームの最初の 96 バイトのみをキャプチャします。-s パラメーターを使用して、キャプチャするバイト数を指定できます。コマンドの例を次に示します。

sudo tcpdump -i eth0 -s 1000 -w tcpdump.cap

Wireshark の一般的なメッセージとソリューション

[TCP Previous segment not captured]

問題: パケットキャプチャ中にパケット損失またはパケットの欠落が発生します。次の図に例を示します。

考えられる原因: このメッセージは、前の TCP セグメントがキャプチャされず、キャプチャされたデータセグメントが不完全であることを示します。これは通常、パケット損失またはキャプチャツールによるパケットの欠落が原因です。

ソリューション: 上記の例に基づいてパケットキャプチャ結果を分析し、特定の状況を判断します。

説明

TCP プロトコルを使用したデータ転送中、同じホストから送信されるデータセグメントは連続している必要があります。具体的には、後続のデータセグメントの Seq は、前のデータセグメントの Seq にデータペイロード長 (つまり、Seq + Len - TCP ヘッダー長) を加えたものと等しくなければなりません。また、受信側の Ack フィールドの値は、送信側のデータセグメントの Seq にデータペイロード長を加えたものと等しく、次に受信が期待されるバイトのシーケンス番号を示します (3 ウェイハンドシェイクまたは 4 ウェイハンドシェイクのシナリオを除く)。後続のデータセグメントの Seq が、前のデータセグメントの Seq にデータペイロード長を加えたものより大きく、中間のデータセグメントが観測されない場合、次の状況が考えられます。

パケットキャプチャの欠落 (TCP Previous segment not captured): 後続の Ack にキャプチャされなかった Seq の範囲が含まれている場合 (たとえば、送信側が Seq=1000 と Seq=2000 を送信し、受信側が Ack=2000 を返す場合)、中間データが受信側によって確認応答されたものの、キャプチャツールがそれを欠落させたことを示します。
パケット損失: 後続の Ack がキャプチャされなかった Seq の範囲をカバーしていない場合 (たとえば、送信側が Seq=1000 と Seq=2000 を送信し、受信側が Ack=1000 を返す場合)、中間データが受信側によって確認応答されておらず、パケット損失が発生した可能性があることを示します。
ネットワーク内のデータセグメントは、順序が乱れる (後のセグメントが前のセグメントより先に到着する) ことがあります。この場合、受信側は、欠落したセグメントが受信されるまで、Seq を介して受信された連続したデータに対し、Ack を繰り返し送信します。

順序の乱れとウィンドウメカニズムの処理ロジックは次のとおりです。

データセグメントの Seq が受信ウィンドウ (Window) の範囲を超えた場合、受信側はそのセグメントを破棄し、回復はタイムアウト再送または高速再送メカニズムに依存します。
データセグメントの Seq が受信ウィンドウ (Window) の範囲を超えた場合、受信側はそのセグメントを破棄し、回復はタイムアウト再送または高速再送メカニズムに依存します。

[TCP ACKed unseen segment]

問題: パケットキャプチャ中に [TCP ACKed unseen segment] メッセージが表示されます。次の図に例を示します。

考えられる原因: このメッセージは、ACK されたパケットがキャプチャされなかったことを示します。上の図の 32 行目の情報によると、シーケンス番号 (Seq) の値に長さ (Len) を加えると 6889 + 1448 で 8337 になります。サーバーの次のパケットのシーケンス番号は 8337 になることが期待されます。しかし、35 行目ではシーケンス番号が 11233 となっており、8337 から 11232 までの情報がキャプチャされなかったことを示しています。後続の確認応答パケットのみがキャプチャされ、先行するデータパケットはキャプチャされませんでした。8337 から 11232 までの情報は、34 行目の前に表示されるべきでした。

ソリューション: これは、おそらく最も一般的な Wireshark メッセージです。上記の例に基づいてパケットキャプチャ結果を分析し、特定の状況を判断する必要があります。

[TCP Out-of-Order]

問題: パケットキャプチャ中に [TCP Out-of-Order] メッセージが表示されます。次の図に例を示します。

考えられる原因: このメッセージは、データパケットの順序が乱れていることを示します。Wireshark は、後続のパケットの Seq が前のパケットの Seq + Len よりも小さいことを検出すると、順序が乱れていると見なします。順序の乱れたパケットのスパンが小さい場合、たとえば元の順序 1, 2, 3, 4, 5 が 2, 1, 3, 4, 5 にスクランブルされた場合など、影響はほとんどありません。ただし、スパンが大きいと高速再送がトリガーされる可能性があります。たとえば、順序が 2, 3, 4, 5, 1 にスクランブルされると、パケットの再送を引き起こすのに十分な「Dup ACK」メッセージがトリガーされます。

ソリューション: 上記の例に基づいてパケットキャプチャ結果を分析します。時折発生する小規模な順序の乱れは無視できます。ただし、大規模な順序の乱れが頻繁に発生する場合は、MTR などのツールを使用してさらに分析とトラブルシューティングを行うか、スイッチやルーターなどの中間デバイスのログを確認してさらに分析することができます。

[TCP Dup ACK]

問題: パケットキャプチャ中に [TCP Dup ACK] メッセージが表示されます。次の図に例を示します。

考えられる原因: このメッセージは、重複する ACK が発生したことを示します。順序の乱れたパケットまたはパケット損失が発生すると、受信側は期待値より大きい Seq 値を持つパケットを受信します。このようなパケットを受信するたびに、受信側は期待される Seq 値で応答して送信側に通知するため、重複する ACK が発生します。

ソリューション: この状況が頻繁に発生する場合は、MTR などのツールを使用してさらに分析とトラブルシューティングを行うか、スイッチやルーターなどの中間デバイスのログを確認してさらに分析することができます。

[TCP Retransmission]

問題: パケットキャプチャ中に [TCP Retransmission] メッセージが表示されます。次の図に例を示します。

考えられる原因: このメッセージは、データパケットが再送されていることを示します。パケットが失われ、受信側で「Dup ACK」をトリガーできる後続のパケットがない場合、高速再送は発生しません。この場合、送信側はタイムアウト再送を待つしかありません。上の図に示すように、クライアントは元のパケット番号 1053 を送信し、対応する ACK を待ち続けました。100 ミリ秒以上経過してからパケット 1225 を再送する必要がありました。

説明

TCP は、データを送信するときにタイマーを設定してパケット確認応答の問題に対処することにより、信頼性の高い伝送を提供します。タイマーが期限切れになったときに確認応答が受信されない場合、データは再送されます。再送時間の計算方法については、RFC2988 がソリューションを提供しており、Linux は現在もそれを使用しています。詳細については、TCP-IP ドキュメントの RTT および RTO のセクションをご参照ください。

[TCP Fast Retransmission]

問題: パケットキャプチャ中に [TCP Fast Retransmission] メッセージが表示されます。次の図に例を示します。

考えられる原因: このメッセージは、データパケットが高速再送されていることを示します。送信側が 3 つ以上の「TCP Dup ACK」メッセージを受信すると、以前に送信したパケットが失われた可能性があることを認識し、高速再送を開始します。上の図に示すように、サーバーが 3 つの「TCP Dup ACK」メッセージを受信すると、Seq が 991851 のパケット 1177 を再送しました。

説明

高速再送メカニズムは、パケット損失評価のための別の標準を実装します。受信側が 3 つの連続した重複 ACK を受信すると、送信側は再送タイマーが期限切れになるのを待つ必要がなく、未確認のセグメントをより早く再送できます。

[TCP zerowindow]

問題: パケットキャプチャ中に [TCP zerowindow] メッセージが表示されます。次の図に例を示します。

考えられる原因: このメッセージは、受信ウィンドウが 0 で、バッファーがいっぱいであり、これ以上データを受け入れないことを示します。「win=」は、このパケットの送信側がデータを受信するために利用できるバッファースペースの量を示します。「Win=0」は、バッファーがいっぱいであることを示し、上の図に示すように、これ以上データを受信しないことを相手方に通知します。

ソリューション: この問題の考えられる原因には、受信側の処理能力の不足やネットワーク帯域幅リソースの不足などがあります。具体的な原因を特定するには、さらに分析が必要です。

[TCP window Full]

問題: パケットキャプチャ中に [TCP window Full] メッセージが表示されます。次の図に例を示します。

考えられる原因: このメッセージは、送信ウィンドウがいっぱいであることを示します。上の図に示すように、パケットの送信側が相手方によって宣言された受信ウィンドウを使い果たし、一時的にこれ以上データを送信できないことを示します。

説明

Bytes in flight は相手方の受信ウィンドウと等しく、送信側が送信した値から相手方が最後に確認応答した値を引いたものが、確認応答された値の数と等しいことを示します。つまり、Seq + Len = Ack であり、これが最新の Ack です。次の 2 つのフィールドは、送信が一時停止しており、注意が必要であることを示します。

Bytes in flight は受信側の受信ウィンドウと等しく、送信側が送信したバイト数から受信側が最後に確認応答したバイト数を引いたものが、確認応答されたバイト数と等しいことを示します。つまり、Seq + Len = Ack であり、これが最新の Ack です。次の 2 つのフィールドは、送信が一時停止しており、特に注意が必要であることを示します。

[TCP segment of a reassembled PDU]

問題: パケットキャプチャ中に [TCP segment of a reassembled PDU] メッセージが表示されます。次の図に例を示します。

考えられる原因: このメッセージは、再構成された PDU の TCP プロトコルセグメントを示します。これは、Wireshark が同じアプリケーション層 PDU に属する TCP パケットを仮想的にグループ化できることを示します。

ソリューション: ソフトウェアを設定するには、[編集] > [設定] > [プロトコル] > [TCP] を選択し、「Allow sub dissector to reassemble TCP streams」が有効になっていることを確認する必要があります。ACK 確認パケット番号は同じです。

[Continuation to #X]

問題: パケットキャプチャ中に [Continuation to #X] メッセージが表示されます。次の図に例を示します。

考えられる原因: このメッセージは、「Allow sub dissector to reassemble TCP streams」が無効になっていることを示します。実際の状況に応じて有効にしてください。

ソリューション: ソフトウェアを設定するには、[編集] > [設定] > [プロトコル] > [TCP] を選択し、「Allow sub dissector to reassemble TCP streams」が有効になっていることを確認する必要があります。

Time-to-live exceeded (Fragment reassembly time exceeded)

問題: パケットキャプチャ中に Time-to-live exceeded (Fragment reassembly time exceeded) メッセージが表示されます。次の図に例を示します。

考えられる原因: このメッセージは、Time-to-Live (TTL) を超えたこと、具体的にはフラグメントの再構成時間を超えたことを示します。これは、このパケットの送信側が以前にいくつかのフラグメントを受信したものの、何らかの理由でそれらを再構成できなかったことを示します。上の図に示すように、上海から北京への一部のパケットがフラグメントで送信され、一部が転送中に失われたため、北京はそれらを再構成できず、この ICMP エラーを使用して相手方に通知する必要がありました。

ソリューション: この問題が長期間続く場合は、ルーティングテーブルの確認、MTR ツールを使用したネットワークループのトラブルシューティング、初期 TTL 値の調整、MTU の調整、またはネットワーク帯域幅の最適化によって解決できます。

リファレンス

Wireshark の詳細については、「Wireshark 公式ドキュメント」をご参照ください。
パケットキャプチャツールの使用方法の詳細については、「パケットキャプチャツールを使用してネットワークパケットをキャプチャする」をご参照ください。
インスタンスに ping はできるがポートに接続できない問題のトラブルシューティング方法の詳細については、「ECS インスタンスに ping はできるがポートに接続できない問題のトラブルシューティング方法」をご参照ください。
MTR ツールを使用してネットワークリンクを分析する方法の詳細については、「MTR ツールを使用してネットワークリンクを分析する」をご参照ください。