TCP RST und Connection Reset PCAP-Analyse: Wer hat die Verbindung geschlossen und warum

„Verbindung durch Peer zurückgesetzt“ ist ein häufiger Fehler in HTTP-Clients, Datenbanken, TLS-Tools, Proxys und benutzerdefinierten TCP-Anwendungen. Benutzer suchen nach „TCP RST PCAP-Analyse“, „Verbindungszurücksetzung durch Peer Wireshark“, „RST nach SYN“, „TLS-Verbindungszurücksetzung“ und „Firewall-TCP-Zurücksetzung“, weil sie wissen müssen, wer die Verbindung beendet hat und ob die Zurücksetzung von der Anwendung, dem Betriebssystem, der Firewall, dem Load Balancer oder dem Server stammt.

Ein TCP-RST ist explizit. Es heißt „Diese Verbindung abbrechen“. Der schwierige Teil ist die Zuschreibung.

Die PCAP-Chirurgie ist nützlich, da für Reset-Untersuchungen eine saubere, fokussierte Spur mit Richtung, Zeitstempeln, Sequenznummern und genügend Paketen vor dem Reset erforderlich ist.

Gängige Reset-Muster

RST kann passieren:

• Unmittelbar nach SYN.
• Nach SYN-ACK.
• Nach ClientHallo.
• Nach HTTP-Anfrage.
• Während des Leerlauf-Timeouts.
• Nach ungültigen Protokolldaten.
• Wenn eine Anwendung einen Socket mit ungelesenen Daten schließt.
• Wenn eine Firewall eine Richtlinie ablehnt.
• Wenn ein Load Balancer kein fehlerfreies Backend hat.
• Wenn ein Serverprozess abstürzt oder den Status verweigert.

Der Zeitpunkt sagt Ihnen, wo Sie suchen müssen.

Wer hat den RST gesendet?

Identifizieren Sie zunächst die Quell-IP, den Quell-Port, die Ziel-IP und den Ziel-Port des Reset-Pakets. Wenn die Server-IP RST sendet, wurde es von der Serverseite oder etwas, das sich als diese Seite ausgibt, beendet. Wenn die Client-IP RST sendet, hat die Clientseite es beendet. Wenn TTL, MAC oder Pfadverhalten auf eine Middlebox schließen lassen, kann der Reset injiziert werden.

Verlassen Sie sich nicht nur auf den Bewerbungstext. „Reset by peer“ kann von der Seite gemeldet werden, die den RST empfangen hat.

Zurücksetzen nach SYN

RST nach SYN bedeutet oft, dass der Port geschlossen ist oder die Richtlinie die Verbindung ablehnt. Wenn SYN RST sofort empfängt, hat die Anwendung weder TLS noch HTTP erreicht.

Suchen:

• SYN -> RST,ACK
• Kein ServerHallo
• Keine Bewerbungsdaten
• Konsistentes Verhalten bei allen Versuchen

Dies ist kein Zertifikatfehler oder HTTP-Fehler; Es handelt sich um einen TCP-Erreichbarkeits-/Dienststatusfehler.

Zurücksetzen während TLS

RST nach ClientHello kann durch falschen Port, nicht unterstütztes TLS, SNI-Nichtübereinstimmung, Middlebox-Richtlinie oder Serverablehnung verursacht werden. Behalten Sie DNS- und ClientHello-Metadaten bei, damit Sie Hostname, ALPN, TLS-Versionen und Timing sehen können.

Wenn die Zurücksetzung nach einer TLS-Warnung erfolgt, ist die Warnung informativer als die Zurücksetzung. Wenn keine Warnung vorliegt, erfolgt das Zurücksetzen möglicherweise auf einer niedrigeren Ebene oder ist richtliniengesteuert.

Nach Aufforderung zurücksetzen

RST nach einer HTTP-Anfrage, einer Datenbankabfrage oder einem Protokollbefehl bedeutet oft, dass die Anwendung genug verstanden hat, um die Anfrage abzulehnen oder abzustürzen. Es kann auch bedeuten, dass ein Proxy geschlossen wurde, weil der Upstream nicht verfügbar war.

Korrelat:

• Letzte gesendete Anwendungsbytes.
• Serverantwort oder fehlende Antwort.
• Leerlaufzeit vor dem Zurücksetzen.
• Backend-/Load-Balancer-Protokolle.
• Ob das Zurücksetzen nur für bestimmte Anforderungsgrößen erfolgt.

Checklist

Verwenden Sie diesen Workflow:

1. Identifizieren Sie den ersten RST im Gespräch.
2. Identifizieren Sie, wer es gesendet hat.
3. Untersuchen Sie, was unmittelbar davor passiert ist.
4. Überprüfen Sie, ob der TCP-Handshake abgeschlossen ist.
5. Überprüfen Sie, ob TLS begonnen oder abgeschlossen wurde.
6. Prüfen Sie, ob Bewerbungsdaten übermittelt wurden.
7. Überprüfen Sie den Zeitpunkt der Leerlaufzeitüberschreitung.
8. Vergleichen Sie TTL/MAC/Pfad-Hinweise für die Middlebox-Injektion.
9. Behalten Sie DNS-, TCP-, TLS- und Anwendungsbytes während des Zurücksetzens bei.
10. Verwenden Sie Server-/Load-Balancer-Protokolle, um die Zuordnung zu bestätigen.

Endgültige Diagnose

TCP RST ist ein Verbindungsabbruch, der Grund hängt jedoch vom Zeitpunkt und vom Absender ab. Ein PCAP kann zwischen geschlossenem Port, Firewall-Ablehnung, TLS-Ablehnung, Anwendungsschließung, Leerlauf-Timeout, Load-Balancer-Fehler und Middlebox-Reset unterscheiden.

PCAP Surgery hilft dabei, die Paketsequenz beizubehalten, die die wichtigste Frage beantwortet: Wer hat die Verbindung zurückgesetzt und was ist unmittelbar davor passiert?