次の方法で共有

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

  • [アーティクル]

仮想エージェントを試す - Active Directory レプリケーションに関する一般的な問題をすばやく特定して修正するのに役立ちます。

適用対象: Windows 10

アプリケーションの終了エラーまたはタイムアウト エラーで接続エラーが発生する可能性があります。 最も一般的なシナリオを次に示します。

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

問題がネットワーク上にあると思われる場合は、ネットワーク トレースを収集します。 その後、ネットワーク トレースがフィルター処理されます。 接続エラーのトラブルシューティング中に、ネットワークの問題を示す可能性のあるネットワーク キャプチャで TCP リセットが発生する可能性があります。

  • TCP は、接続指向で信頼性の高いプロトコルとして定義されます。 TCP が信頼性を確保する方法の 1 つは、ハンドシェイク プロセスを使用することです。 TCP セッションの確立は、3 方向ハンドシェイクから始まり、続いてデータ転送、4 方向のクローズから始まります。 送信者と受信側の両方がセッションの終了に同意する 4 方向のクロージャは、正常なクロージャと呼ばれます。 4 方向のクローズ後、サーバーは 4 分の時間 (既定値) を許可します。その間、ネットワーク上の保留中のパケットが処理されます。この期間はTIME_WAIT状態です。 TIME_WAIT状態が完了すると、この接続に割り当てられたすべてのリソースが解放されます。
  • TCP リセットは、セッションの突然の終了です。これにより、接続に割り当てられたリソースがすぐに解放され、接続に関するその他のすべての情報が消去されます。
  • TCP リセットは、TCP ヘッダーの RESET フラグによって 1 に設定されて識別されます。

送信元と宛先のネットワーク トレースは、トラフィックのフローを特定し、障害が発生した時点を確認するのに役立ちます。

次のセクションでは、RESET が表示されるシナリオの一部について説明します。

パケット ドロップ

一方の TCP ピアが、もう一方の側から受信した応答がない TCP パケットを送信している場合、TCP ピアはデータを再送信し、受信した応答がない場合は ACK RESET を送信してセッションを終了します (この ACK RESET は、アプリケーションがこれまでに交換されたデータを確認することを意味します。 ただし、パケットドロップのため、接続は閉じられます)。

送信元と宛先の同時ネットワーク トレースは、送信元側で再送信されるパケットが表示され、宛先にこれらのパケットが表示されない場合に、この動作を確認するのに役立ちます。 このシナリオは、送信元と宛先の間のネットワーク デバイスがパケットをドロップしていることを示します。

パケットドロップが原因で最初の TCP ハンドシェイクが失敗した場合、TCP SYN パケットが再送信されるのは 3 回だけであることがわかります。

ポート 445 でのソース側の接続:

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

宛先側: 同じフィルターを適用すると、パケットは表示されません。

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

残りのデータの場合、TCP はパケットを 5 回再送信します。

ソース 192.168.1.62 側トレース:

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

宛先 192.168.1.2 側トレース:

上記のパケットは表示されません。 ネットワーク チームをEngageして、さまざまなホップを使用して調査し、いずれかのホップがネットワークのドロップの原因となっている可能性があるかどうかを確認します。

SYN パケットが宛先に到達しているのに宛先がまだ応答していない場合は、接続しようとしているポートがリッスン状態であるかどうかを確認します。 (Netstat 出力が役立ちます)。 ポートがリッスンしていて応答がない場合は、wfp ドロップが発生する可能性があります。

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

この動作は、パケットが中間デバイスによってネットワーク内で変更され、受信側の TCP が、変更されているシーケンス番号や、シーケンス番号を変更して中間デバイスによって再生されるパケットなど、パケットを受け入れることができない場合に表示されます。 ここでも、送信元と宛先の同時ネットワーク トレースは、TCP ヘッダーのいずれかが変更されているかどうかを通知できます。 まず、ソース トレースと宛先トレースを比較すると、パケット自体に変更があるかどうか、またはソースに代わって新しいパケットが宛先に到達しているかどうかを確認できます。

この場合は、パケットを変更したり、宛先へのパケットを再生したりするデバイスを特定するために、ネットワーク チームのヘルプが必要になります。 最も一般的なものは、RiverBed デバイスまたは WAN アクセラレータです。

アプリケーション側のリセット

リセットが、再送信や正しくないパラメーターまたはパケットがネットワーク トレースの助けを借りて変更されたことが原因ではないことを確認したら、アプリケーション レベルのリセットに絞り込みます。

アプリケーションのリセットは、受信確認フラグがリセット フラグと共に 1 に設定されている場所です。 この設定は、サーバーがパケットの受信を確認していることを意味しますが、何らかの理由で接続を受け入れなくなります。 このステージは、パケットを受信したアプリケーションが受信した内容を気に入らなかった場合です。

次のスクリーンショットでは、ソースと宛先に表示されるパケットは、変更やドロップなしで同じですが、宛先からソースに送信された明示的なリセットが表示されます。

ソース側

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

宛先側のトレース

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

また、TCP 確立パケット SYN が送信されるときに、ACK+RST フラグ パケットも表示されます。TCP SYN パケットは、クライアントが特定のポートで接続する場合に送信されますが、何らかの理由で宛先/サーバーがパケットを受け入れたくない場合は、ACK+RST パケットが送信されます。

ACK RSK フラグを持つパケットのスクリーンショット。

リセットの原因となっているアプリケーション (ポート番号で識別) を調査して、接続をリセットする原因を理解する必要があります。

注:

上記の情報は、UDP ではなく TCP の観点からのリセットに関する情報です。 UDP はコネクションレス プロトコルであり、パケットは信頼できない状態で送信されます。 UDP をトランスポート プロトコルとして使用する場合、再送信やリセットは表示されません。 ただし、UDP では、エラー報告プロトコルとして ICMP が使用されます。 UDP パケットがポートで送信され、宛先にポートが一覧に表示されていない場合、 ICMP 宛先ホスト を送信する宛先が到達不能と表示されます。UDP パケットの直後に到達できないメッセージをポートします。

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

接続の問題のトラブルシューティング中に、マシンがパケットを受信しても応答しないネットワーク トレースにも表示される場合があります。 このような場合は、サーバー レベルで低下する可能性があります。 ローカル ファイアウォールがパケットを削除しているかどうかを理解するには、マシンでファイアウォール監査を有効にします。

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

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

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

次に、 コマンド netsh wfp show stateを実行すると、この実行によって wfpstate.xml ファイルが生成されます。 このファイルを開き、上記のイベント (2944008) で見つけた ID をフィルター処理すると、接続をブロックしているこの ID に関連付けられているファイアウォール規則名が表示されます。

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