TCP RST と接続リセット PCAP 分析: 誰が接続を閉じたのか、そしてなぜ

TCP RST、ピアによる接続のリセット、SYN 後のリセット、TLS 中のリセット、ファイアウォールのリセット、アプリケーションの終了、およびパケット キャプチャの証拠を分析する方法。

TCP最初, ピアによって接続がリセットされました, pcap 分析, ファイアウォールのリセット, TLSリセット, ネットワークのトラブルシューティング

「ピアによる接続のリセット」は、HTTP クライアント、データベース、TLS ツール、プロキシ、カスタム TCP アプリケーションでよく見られるエラーです。ユーザーは、「TCP RST pcap 分析」、「ピア Wireshark による接続リセット」、「SYN 後の RST」、「TLS 接続リセット」、および「ファイアウォール TCP リセット」を検索します。これは、誰が接続を終了したか、リセットがアプリケーション、オペレーティング システム、ファイアウォール、ロード バランサー、またはサーバーから来たのかを知る必要があるためです。

TCP RST は明示的です。 「この接続を中止します」と表示されます。難しいのは帰属です。

リセットの調査には、方向、タイムスタンプ、シーケンス番号、およびリセット前の十分なパケットを含む、クリーンで焦点を絞ったトレースが必要であるため、PCAP 手術が役立ちます。

よくあるリセットパターン

RST が発生する可能性があります。

  • SYN直後。
  • SYN-ACK 後。
  • ClientHello の後。
  • HTTPリクエスト後。
  • アイドルタイムアウト中。
  • 無効なプロトコル データの後。
  • アプリケーションが未読データのあるソケットを閉じるとき。
  • ファイアウォールがポリシーを拒否した場合。
  • ロード バランサーに正常なバックエンドがない場合。
  • サーバープロセスがクラッシュするか、状態を拒否したとき。

タイミングがどこを見るべきかを教えてくれます。

RST を送信した人

まず、リセット パケットの送信元 IP、送信元ポート、宛先 IP、宛先ポートを特定します。サーバー IP が RST を送信した場合、サーバー側、またはサーバー側になりすました何かが RST を終了させます。クライアント IP が RST を送信すると、クライアント側が RST を終了します。 TTL、MAC、またはパスの動作がミドルボックスを示唆する場合、リセットが挿入される可能性があります。

申請書の文言だけに頼らないでください。 「ピアによるリセット」は、RSTを受信した側から通知される場合があります。

SYN後にリセット

SYN の後の RST は、多くの場合、ポートが閉じられているか、ポリシーによって接続が拒否されていることを意味します。 SYN が RST をすぐに受信した場合、アプリケーションは TLS または HTTP に到達しませんでした。

探す:

  • SYN -> RST、ACK
  • ServerHello がありません
  • アプリケーションデータがありません
  • 試行間で一貫した動作

これは証明書の失敗や HTTP エラーではありません。これは、TCP 到達可能性/サービス状態の障害です。

TLS中にリセット

ClientHello 後の RST は、間違ったポート、サポートされていない TLS、SNI の不一致、ミドルボックス ポリシー、またはサーバーの拒否によって発生する可能性があります。 DNS および ClientHello メタデータを保存して、ホスト名、ALPN、TLS バージョン、タイミングを確認できるようにします。

TLS アラートの後にリセットが到着した場合、アラートはリセットよりも有益です。アラートがない場合、リセットは下位レベルまたはポリシー主導で行われる可能性があります。

要求後にリセットする

HTTP リクエスト、データベース クエリ、またはプロトコル コマンドの後の RST は、多くの場合、アプリケーションがリクエストを拒否またはクラッシュすることを十分に理解していることを意味します。また、アップストリームが利用できないためにプロキシが閉じられたことを意味する場合もあります。

相関させる:

  • 最後に送信されたアプリケーション バイト。
  • サーバーの応答または応答の欠如。
  • リセット前のアイドル時間。
  • バックエンド/ロードバランサーのログ。
  • リセットが特定のリクエスト サイズに対してのみ発生するかどうか。

Checklist

このワークフローを使用します。

  1. 会話内の最初の RST を特定します。
  2. 誰が送信したかを特定します。
  3. 直前に何が起こったのかを調べます。
  4. TCPハンドシェイクが完了したかどうかを確認します。
  5. TLS が開始したか完了したかを確認します。
  6. 申請データが送信されたか確認してください。
  7. アイドルタイムアウトのタイミングを確認してください。
  8. ミドルボックス挿入の TTL/MAC/パスの手がかりを比較します。
  9. リセット前後の DNS、TCP、TLS、およびアプリケーション バイトを保持します。
  10. サーバー/ロードバランサーのログを使用して帰属を確認します。

最終診断

TCP RST は接続の中断ですが、その理由はタイミングと送信者によって異なります。 pcap は、ポートのクローズ、ファイアウォールの拒否、TLS の拒否、アプリケーションの終了、アイドル タイムアウト、ロード バランサーの障害、ミドルボックスのリセットを区別できます。

PCAP 手術は、誰が接続をリセットしたのか、その直前に何が起こったのかという最も重要な質問に答えるパケット シーケンスを保存するのに役立ちます。