次の方法で共有

TCP/IP 接続のトラブルシューティング

  • [アーティクル]

仮想オペレーターを試す - Active Directory レプリケーションに関する一般的な問題をすばやく特定、解決するのに役立ちます。

適用対象: サポートされているバージョンの Windows クライアントと Windows Server

この記事では、TCP/IP 接続エラーのトラブルシューティングに関する包括的なガイドを提供します。

症状と分析

アプリケーション レベルで接続の問題が発生したり、タイムアウト エラーが発生したりする可能性があります。 一般的なシナリオを次に示します。

  • データベース サーバーへのアプリケーション接続
  • SQL タイムアウト エラー
  • BizTalk アプリケーションのタイムアウト エラー
  • リモート デスクトップ プロトコル (RDP) エラー
  • ファイル共有のアクセスエラー
  • 一般的な接続

ネットワーク関連の問題が疑われる場合は、ネットワーク パケット キャプチャを収集することをお勧めします。 このキャプチャをフィルター処理して、問題のある TCP 接続を特定し、障害の原因を特定できます。

トラブルシューティング プロセス中に、ネットワーク キャプチャで TCP RESET が発生する可能性があります。これは、ネットワークの問題を示している可能性があります。

TCP の導入

TCP は、接続指向で信頼性の高いプロトコルとして特徴付けられます。 ハンドシェイク プロセスを通じて信頼性が確保されます。 TCP セッションは、3 方向ハンドシェイクで開始され、その後にデータ転送が続き、4 方向のクロージャで終了します。

  • 送信側と受信側の両方がセッションの終了に同意する 4 方向のクロージャは、グレースフル クロージャと呼ばれます。 これは、1 に設定されている TCP ヘッダーの FIN フラグによって識別されます。

  • 4 方向クロージャの後、マシンはポートを解放する前に 4 分間 (既定) 待機します。 これはTIME_WAIT状態と呼びます。 このTIME_WAIT状態では、TCP 接続の保留中のパケットを処理できます。 TIME_WAIT状態が完了すると、接続に割り当てられているすべてのリソースが解放されます。

  • TCP リセットは突然セッションが終了し、割り当てられたリソースが即時に解放され、すべての接続情報が消去されます。 これは、1 に設定されている TCP ヘッダーの RESET フラグによって識別されます。 送信元と宛先で同時に収集されたネットワーク トレースは、トラフィックのフローを特定し、障害点を特定するのに役立ちます。

次のセクションでは、RESET が発生する可能性があるシナリオについて説明します。

ネットワーク経由のパケット損失

TCP ピアが応答を受信せずにパケットを送信すると、ピアはデータを再送信します。 まだ応答がない場合、セッションは ACK RESET で終了します。これは、アプリケーションが交換されたデータを確認するが、パケット損失のために接続を閉じることを示します。

ソースと宛先の両方で同時にネットワーク トレースを実行すると、この動作を確認できます。 送信元側では、再送信されたパケットを確認できます。 宛先側では、これらのパケットは存在しません。 このシナリオは、送信元と宛先の間のネットワーク デバイスがパケットをドロップしていることを示します。

シナリオ 1: 初期 TCP ハンドシェイク中のパケット損失

パケットのドロップが原因で初期 TCP ハンドシェイクが失敗した場合、TCP SYN パケットは既定で 3 回再送信されます。

Note

TCP SYN パケットが再送信される回数は、OS によって異なる場合があります。 これは、コマンド netsh int tcp show globalを使用して表示できる TCP Global パラメーターの値 Max SYN Retransmissions によって決まります。

IP アドレス 10.10.10.1 のソース マシンが、TCP ポート 445 経由で IP アドレス 10.10.10.2 を使用して宛先に接続しているとします。 次のスクリーンショットは、送信元マシンで収集されたネットワーク トレースのスクリーンショットです。これは、TCP SYN パケットが送信され、宛先から応答が受信されなかったため、送信元によって再送信される初期 TCP ハンドシェイクを示しています。

ネットワーク モニターのフレームの概要のスクリーンショット。

宛先で収集されたネットワーク トレースに表示されるのと同じ TCP 会話は、上記のパケットが宛先によって受信されなかったことを示しています。 これは、TCP SYN パケットが中間ネットワーク経由で破棄されたことを意味します。

ネットワーク モニターのフィルターを使用したフレームの概要のスクリーンショット。

TCP SYN パケットが宛先に到達しても宛先が応答しない場合は、接続先の TCP ポートが宛先マシンで LISTENING 状態であるかどうかを確認します。 これは、コマンド netstat -anobの出力で確認できます。

ポートがリッスンしていて、まだ応答がない場合は、Windows フィルタリング プラットフォーム (WFP) にドロップする可能性があります。

シナリオ 2: TCP 接続確立後のデータ転送中のパケット損失

TCP 接続が確立された後に送信されたデータ パケットがネットワーク経由で破棄されるシナリオでは、TCP は既定でパケットを 5 回再送信します。

IP アドレス 192.168.1.62 のソース マシンが、TCP ポート 445 経由で IP アドレス 192.168.1.2 を持つ宛先マシンとの接続を確立したとします。 ソース マシンは、次に示すように、再送信されるデータ (SMB ネゴシエート パケット) を 5 回送信しています。 宛先からの応答がない場合、ソース マシンは ACK-RST を送信してこの TCP 接続を閉じます。

ソース 192.168.1.62 側トレース:

パケット側トレースを示すスクリーンショット。

上記のパケットが宛先に到達することは一切ありません。

内部ネットワーク チームと連携して、送信元と宛先の間のさまざまなホップを調査し、いずれかのホップがパケットドロップの原因となっている可能性があるかどうかを確認する必要があります。

TCP ヘッダーのパラメーターが正しくありません

この動作は、ネットワーク内の中間デバイスがパケットを変更し、受信側の TCP がパケットを拒否した場合に発生します。 たとえば、TCP シーケンス番号が変更されたり、TCP シーケンス番号が変更された中間デバイスによってパケットが再生されたりすることがあります。

送信元と宛先の同時ネットワーク トレースは、TCP ヘッダーに対する変更を識別するのに役立ちます。

まず、送信元と宛先のトレースを比較して、パケットの変更、または送信元の代わりに宛先に到達する新しいパケットの存在を検出します。

このような場合は、内部ネットワーク チームに支援を求めて、宛先へのパケットを変更または再生しているデバイスを特定することをお勧めします。 一般的な原因には、Riverbed デバイスや WAN アクセラレータが含まれます。

アプリケーション レベルのリセット

リセットがパケットのドロップ、正しくないパラメーター、またはパケットの変更 (ネットワーク トレースによって識別される) によるものでないと判断した場合、問題はアプリケーション レベルのリセットであると結論付けることができます。

アプリケーション レベルのリセットは、受信確認 (ACK) フラグがリセット (R) フラグと共に 1 に設定されていることを特徴とします。 これは、サーバーがパケットの受信を確認したが、何らかの理由で接続を受け入れないことを示します。 この問題は、通常、パケットを受信するアプリケーションがデータ内で許容できないものを見つけた場合に発生します。

次のスクリーンショットでは、送信元と宛先の両方のパケットが同一であり、変更やドロップは行われません。 ただし、明示的なリセットは宛先によってソースに送信されます。

ソース側トレース:

ネットワーク モニターのソース側のパケットのスクリーンショット。

宛先側のトレース:

ネットワーク モニターの宛先側のパケットのスクリーンショット。

ACK + RST フラグ付き TCP パケットは、TCP SYN パケットが送信されるときにも発生する可能性があります。TCP SYN パケットは、特定のポートで接続を確立するために、ソース マシンによって開始されます。 ただし、宛先サーバーが何らかの理由でパケットを受け入れたくない場合、サーバーは ACK + RST パケットで応答します。

ACK RSK フラグを持つパケットのスクリーンショット。 このような場合は、(ポート番号で識別される) リセットの原因となっているアプリケーションを調査して、接続がリセットされる理由を理解することが不可欠です。

Note

上記の情報は、UDP ではなく TCP の観点からのリセットに関連します。 UDP はコネクションレス プロトコルであり、パケットは信頼性の低い方法で送信されます。 そのため、UDP をトランスポート プロトコルとして使用する場合、再送信やリセットは行われません。 ただし、UDP はエラー報告プロトコルとして ICMP を利用します。 宛先にリストされていないポートに UDP パケットが送信されると、宛先は ICMP "Destination Host Unreachable: Port Unreachable" メッセージですぐに応答します。

10.10.10.1  10.10.10.2  UDP UDP:SrcPort=49875,DstPort=3343
 
10.10.10.2  10.10.10.1  ICMP    ICMP:Destination Unreachable Message, Port Unreachable,10.10.10.2:3343

TCP/IP 接続の問題のトラブルシューティング中に、ネットワーク トレースで、マシンがパケットを受信しても応答しない場合があります。 これは、移行先サーバーのネットワーク スタックでのドロップを示している可能性があります。

ローカルの Windows ファイアウォールがパケットをドロップしているかどうかを確認するには、次のコマンドを使用して、コンピューター上の Windows フィルター プラットフォーム (WFP) の監査を有効にします。

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable

その後、セキュリティ イベント ログを確認して、関連付けられている WFP フィルター ID と共に、特定の TCP ポートと IP アドレスのパケット ドロップを識別できます。

フィルター ID を持つイベント プロパティのスクリーンショット。

次に、wfpstate.xml ファイルを生成するコマンド netsh wfp show stateを実行します。

このファイルは、メモ帳を使用して開き、イベント ログで見つかった ID をフィルター処理できます (サンプル イベントの2944008など)。 その結果、接続をブロックしているフィルター ID に関連付けられているファイアウォール規則の名前が表示されます。

接続をブロックしているフィルター ID に関連付けられているファイアウォール規則名を含む wfpstate xml ファイルのスクリーンショット。