# 9.2 TCP-Handshake, Timeouts und TCP Reset **Ziel dieser Seite** Diese Seite beschreibt den vollständigen Lebenszyklus einer TCP-Verbindung: - Verbindungsaufbau zwischen Client und Server; - Aushandlung wichtiger TCP-Optionen; - zuverlässige und geordnete Datenübertragung; - Bestätigungen, Sequenznummern und Wiederholungen; - kontrollierter Verbindungsabbau; - Timeouts auf unterschiedlichen Ebenen; - abrupter Verbindungsabbruch durch TCP Reset; - systematische Diagnose mit Windows, Linux, macOS und Paketaufzeichnungen. Nach der Bearbeitung muss unterschieden werden können: - ob bereits der TCP-Verbindungsaufbau scheitert; - welche Seite den Verbindungsaufbau nicht fortsetzt; - ob ein Port aktiv abgelehnt wird; - ob Pakete verworfen oder verzögert werden; - ob TCP erfolgreich aufgebaut wurde und erst das Anwendungsprotokoll scheitert; - ob eine Verbindung kontrolliert mit `FIN` oder abrupt mit `RST` beendet wurde; - ob ein Timeout aus TCP, der Anwendung, einem Proxy oder einer Firewall stammt; - welche Gegenstelle oder Zwischenkomponente wahrscheinlich einen Reset erzeugt hat; - ob Wiederholungen auf Paketverlust oder lediglich auf eine unvollständige Aufzeichnung zurückzuführen sind. Ein TCP-Fehler darf nicht allein anhand einer Anwendungsmeldung wie „Timeout“ oder „Connection reset“ eingeordnet werden. Er muss mit Socketzuständen, Zeitpunkten, Protokollen und bei Bedarf einer begrenzten Paketaufzeichnung korreliert werden. --- **Sicherheits- und Wirkungsklassen** | Kennzeichnung | Bedeutung | |---|---| | **LESEND** | Erfasst ausschließlich vorhandene Zustände. | | **NETZAKTIV** | Erzeugt Netzwerkverkehr zum geprüften Ziel. | | **SENSITIV** | Kann interne Adressen, Verbindungen oder Nutzdaten sichtbar machen. | | **ÄNDERND** | Verändert Konfiguration oder Laufzeitzustand. | | **AUSFALLRISIKO** | Kann Verbindungen, Prozesse oder Dienste beeinträchtigen. | Paketaufzeichnungen können enthalten: - interne und externe IP-Adressen; - Portnummern; - Hostnamen; - Anwendungsdaten; - Authentifizierungsinformationen; - Cookies oder Tokens; - unverschlüsselte Nutzdaten; - Zertifikatsinformationen; - Kommunikationsbeziehungen. Aufzeichnungen müssen technisch und zeitlich begrenzt, geschützt gespeichert und nach Abschluss der Diagnose kontrolliert entfernt werden. --- **Grundlegende Eigenschaften von TCP** TCP stellt Anwendungen einen zuverlässigen, geordneten und bidirektionalen Bytestrom zur Verfügung. TCP bietet unter anderem: - verbindungsorientierte Kommunikation; - Sequenznummern; - Bestätigungen; - Prüfsummen; - Wiederholungen verlorener Segmente; - Flusskontrolle; - Überlastkontrolle; - geordnete Übergabe der Daten; - kontrollierten Verbindungsabbau; - Erkennung bestimmter ungültiger oder nicht mehr existierender Verbindungen. TCP stellt keine Anwendungsnachrichten bereit. Eine Anwendung übergibt einen Bytestrom. Die Aufteilung in einzelne TCP-Segmente kann sich während der Übertragung ändern. Folgende Annahmen sind deshalb falsch: ```text Eine TCP-Verbindung entspricht einer Anfrage. Ein TCP-Segment entspricht einer Anwendungsnachricht. Ein ACK bedeutet, dass die Anwendung die Daten verarbeitet hat. Ein erfolgreicher Handshake bedeutet, dass HTTP, TLS oder die Anwendung funktioniert. ``` Ein TCP-ACK bestätigt grundsätzlich, dass die TCP-Implementierung der Gegenstelle die entsprechenden Bytes angenommen hat. Es beweist nicht, dass: - die Anwendung die Bytes gelesen hat; - die Anwendung die Anfrage verstanden hat; - Daten auf einen Datenträger geschrieben wurden; - eine Transaktion erfolgreich abgeschlossen wurde; - eine Anwendungsantwort erzeugt wurde. --- **TCP-Verbindung eindeutig bestimmen** Eine TCP-Verbindung wird durch ihre Endpunkte unterschieden: ```text Transportprotokoll lokale IP-Adresse lokaler Port entfernte IP-Adresse entfernter Port ``` Beispiel: ```text Client: 192.0.2.100:53124 Server: 192.0.2.25:443 ``` Die Verbindung kann kompakt dargestellt werden als: ```text 192.0.2.100:53124 → 192.0.2.25:443 ``` Auf der Serverseite ist dieselbe Verbindung aus umgekehrter Perspektive sichtbar: ```text lokal: 192.0.2.25:443 remote: 192.0.2.100:53124 ``` Bei NAT, Load Balancern oder Proxys können sich Adressen und Ports entlang des Pfads verändern. Paketaufzeichnungen auf verschiedenen Seiten müssen deshalb anhand von: - Zeitpunkt; - Richtung; - TCP-Flags; - Sequenznummern; - Nutzdaten; - übersetzten Adressen und Ports korreliert werden. --- **Wichtige TCP-Flags** | Flag | Bedeutung | |---|---| | `SYN` | Synchronisiert Sequenznummern und beginnt normalerweise den Verbindungsaufbau. | | `ACK` | Das Bestätigungsfeld ist gültig. | | `FIN` | Der Sender hat keine weiteren Daten mehr zu senden. | | `RST` | Verbindung zurücksetzen oder ungültige Verbindung ablehnen. | | `PSH` | Kennzeichnet Daten für eine zeitnahe Weitergabe innerhalb des TCP-Datenstroms. | | `URG` | Das Urgent-Pointer-Feld ist relevant. | | `ECE` | Wird im Zusammenhang mit Explicit Congestion Notification verwendet. | | `CWR` | Signalisiert eine reduzierte Congestion Window nach ECN. | `PSH` definiert keine Anwendungsnachricht und garantiert keine bestimmte Paketgröße oder sofortige Verarbeitung durch die Anwendung. --- **Verbindungsaufbau zwischen Client und Server** Der reguläre TCP-Verbindungsaufbau wird als Three-Way Handshake bezeichnet. ```text Client Server CLOSED LISTEN | | | SYN, Seq=x | |------------------------------------------>| | | | SYN, ACK, Seq=y, Ack=x+1 | |<------------------------------------------| | | | ACK, Ack=y+1 | |------------------------------------------>| | | ESTABLISHED ESTABLISHED ``` Die drei logischen Schritte sind: 1. Der Client sendet ein Segment mit `SYN`. 2. Der Server bestätigt das Client-SYN und sendet sein eigenes SYN mit `SYN, ACK`. 3. Der Client bestätigt das Server-SYN mit `ACK`. Das dritte Segment kann abhängig von Anwendung und TCP-Erweiterungen bereits Daten enthalten. Für die grundlegende Diagnose wird es dennoch als dritter Handshake-Schritt betrachtet. --- **Sequenznummern beim Handshake** Beispiel: ```text Client → Server: SYN Seq = 1000 Server → Client: SYN, ACK Seq = 7000 Ack = 1001 Client → Server: ACK Seq = 1001 Ack = 7001 ``` Ein SYN verbraucht eine Sequenznummer. Deshalb bestätigt der Server: ```text 1000 + 1 = 1001 ``` Auch das SYN des Servers verbraucht eine Sequenznummer. Der Client bestätigt: ```text 7000 + 1 = 7001 ``` Die tatsächlich verwendeten Initial Sequence Numbers werden von den TCP-Implementierungen bestimmt und sind nicht als einfache fortlaufende Werte vorhersehbar. --- **TCP-Zustände während des Verbindungsaufbaus** | Zustand | Bedeutung | |---|---| | `CLOSED` | Es besteht keine TCP-Verbindung. | | `LISTEN` | Der Server wartet auf neue Verbindungsanfragen. | | `SYN-SENT` | Ein SYN wurde gesendet; eine passende Antwort steht aus. | | `SYN-RECEIVED` | SYN wurde empfangen und mit SYN/ACK beantwortet; abschließendes ACK steht aus. | | `ESTABLISHED` | Der Handshake ist abgeschlossen. | Eine große Zahl von Verbindungen in `SYN-SENT` kann bedeuten: - Zieladresse nicht erreichbar; - Zielport wird gefiltert; - Rückweg ist fehlerhaft; - Server antwortet nicht; - SYN/ACK wird verworfen; - falsche IPv4- oder IPv6-Adresse; - Überlastung oder Ressourcenproblem; - ausgehende Verbindung wird lokal blockiert. Viele Einträge in `SYN-RECEIVED` können bedeuten: - abschließende ACKs erreichen den Server nicht; - Rückweg vom Server zum Client funktioniert, Hinweg des ACKs jedoch nicht; - Clients brechen den Aufbau ab; - SYN-Flood oder ungewöhnlich viele unvollständige Verbindungsversuche; - vorgeschaltete Systeme oder Health Checks öffnen Verbindungen nicht vollständig; - Serverwarteschlangen oder Ressourcen sind erschöpft. Ein einzelner kurz sichtbarer Zustand `SYN-SENT` oder `SYN-RECEIVED` ist normal. Entscheidend sind Häufigkeit, Dauer und Vergleich mit einer Baseline. --- **TCP-Optionen während des Handshakes** Wichtige Optionen werden typischerweise in SYN-Segmenten angeboten oder ausgehandelt. | Option | Zweck | |---|---| | `MSS` | Maximale TCP-Nutzdatenmenge, die die jeweilige Seite in einem Segment empfangen möchte. | | `Window Scale` | Erweitert die darstellbare TCP-Empfangsfenstergröße. | | `SACK Permitted` | Erlaubt Selective Acknowledgment. | | `Timestamps` | Unterstützt unter anderem RTT-Messungen und Schutzmechanismen gegen alte Segmente. | | `ECN` | Ermöglicht Überlastsignalisierung ohne zwingenden Paketverlust, sofern der Pfad sie unterstützt. | Bei der Diagnose müssen die SYN- und SYN/ACK-Optionen verglichen werden. Zu prüfen sind: - bietet der Client eine MSS an? - bietet der Server eine abweichende MSS an? - wird Window Scaling angeboten? - wird SACK unterstützt? - werden TCP-Timestamps verwendet? - verschwinden Optionen zwischen Client und Server? - verändert eine Firewall oder Optimierungskomponente SYN-Pakete? - unterscheiden sich erfolgreiche und fehlerhafte Verbindungen? Ein Handshake kann trotz unterschiedlicher angebotener Optionen erfolgreich sein. Die Optionen können jedoch das spätere Übertragungsverhalten beeinflussen. --- **Erfolgreicher TCP-Handshake** Eine normale Paketfolge ist: ```text Client → Server SYN Server → Client SYN, ACK Client → Server ACK ``` Dieser Befund beweist: - der Client konnte ein SYN senden; - das SYN erreichte einen antwortenden TCP-Endpunkt; - eine SYN/ACK-Antwort erreichte den Client; - das abschließende ACK konnte gesendet werden; - die TCP-Verbindung wurde mindestens kurzfristig aufgebaut. Dieser Befund beweist nicht: - dass TLS funktioniert; - dass das richtige Zertifikat geliefert wird; - dass HTTP antwortet; - dass der virtuelle Host stimmt; - dass die Anwendung gesund ist; - dass Authentifizierung funktioniert; - dass eine Datenbankanfrage verarbeitet wird; - dass die Verbindung dauerhaft stabil bleibt. --- **SYN ohne Antwort** Typischer Paketbefund: ```text Client → Server SYN Client → Server SYN erneut Client → Server SYN erneut ... Timeout ``` Mögliche Ursachen: - Zielhost ist nicht erreichbar; - Routing ist fehlerhaft; - lokale Firewall verwirft das SYN; - Netzwerkfirewall verwirft das SYN; - Zielport wird still verworfen; - SYN erreicht den Server nicht; - Server-SYN/ACK wird auf dem Rückweg verworfen; - falsche Zieladresse; - falsche Adressfamilie; - NAT-Zuordnung fehlt; - Load Balancer besitzt kein erreichbares Frontend; - Server oder Zwischenkomponente ist überlastet; - Paketaufzeichnung wurde am falschen Punkt durchgeführt. Aus einer alleinigen Clientaufzeichnung kann nicht sicher geschlossen werden, ob das SYN den Server erreicht hat. Dafür wird eine korrelierte Aufzeichnung am Server oder an einem geeigneten Zwischenpunkt benötigt. --- **SYN wird mit Reset beantwortet** Typischer Paketbefund: ```text Client → Server SYN Server → Client RST, ACK ``` Typische Einordnung: - Zielhost ist erreichbar; - auf dem angesprochenen Endpunkt existiert häufig kein passender Listener; - das Betriebssystem oder eine Zwischenkomponente lehnt die Verbindung aktiv ab; - eine Firewall kann mit einem Reset ablehnen; - ein Load Balancer besitzt möglicherweise kein verwendbares Backend; - Portweiterleitung zeigt auf einen geschlossenen Zielport. Eine Anwendung meldet in diesem Fall häufig: ```text Connection refused Verbindung abgelehnt No connection could be made because the target machine actively refused it ``` Die Meldung beweist nicht, dass der eigentliche Zielserver selbst den Reset erzeugt hat. Firewalls, Proxys und Load Balancer können ebenfalls TCP-Reset-Segmente erzeugen. --- **Server sendet SYN/ACK, erhält aber kein ACK** Typischer Befund am Server: ```text Client → Server SYN Server → Client SYN, ACK Server → Client SYN, ACK erneut Server → Client SYN, ACK erneut ... ``` Mögliche Ursachen: - SYN/ACK erreicht den Client nicht; - Clientfirewall verwirft die Antwort; - asymmetrischer Rückweg; - NAT-Zustand ist fehlerhaft; - Client sendet das ACK über einen anderen Pfad; - Quelladressprüfung verwirft das Paket; - Clientprozess wurde beendet; - fehlerhafte oder unvollständige Paketaufzeichnung; - Zwischenkomponente verwirft das abschließende ACK. Zur Eingrenzung werden Aufzeichnungen auf Client- und Serverseite benötigt. --- **Handshake funktioniert nur teilweise** | Paketbefund | Einordnung | |---|---| | kein SYN sichtbar | Anwendung startet keinen TCP-Aufbau oder Aufzeichnungspunkt ist falsch | | SYN sichtbar, keine Antwort | Filterung, Routing, Verlust oder fehlender Rückweg | | SYN gefolgt von RST | aktive Ablehnung | | SYN/ACK wird wiederholt | abschließendes ACK fehlt | | Handshake vollständig, danach keine Daten | Anwendung wartet, Protokollmissverständnis oder falsche Rolle | | Handshake vollständig, danach RST | Anwendung, Betriebssystem oder Zwischenkomponente bricht ab | | Handshake vollständig, danach FIN | kontrollierte Beendigung | | Handshake vollständig, TLS beginnt und stoppt | TLS- oder Anwendungsproblem, nicht TCP-Verbindungsaufbau | --- **Die kontrollierte Datenübertragung bei TCP** Nach dem Handshake können beide Seiten Daten senden. TCP arbeitet als bidirektionaler Bytestrom: ```text Client ⇄ Server ``` Jede Richtung besitzt eigene: - Sequenznummern; - Bestätigungen; - Empfangsfenster; - Sendepuffer; - Empfangspuffer; - Wiederholungszustände. Ein Client kann gleichzeitig Daten senden und Daten des Servers empfangen. --- **Sequenznummern bei der Datenübertragung** Beispiel: ```text Client sendet: Seq = 1001 TCP-Nutzdatenlänge = 500 Bytes ``` Der Server bestätigt als nächste erwartete Sequenznummer: ```text Ack = 1501 ``` Berechnung: ```text 1001 + 500 = 1501 ``` Die Bestätigungsnummer bezeichnet das nächste Byte, das die empfangende Seite erwartet. Wenn der Server `Ack = 1501` sendet, bestätigt er kumulativ alle Bytes bis einschließlich Sequenznummer `1500`. --- **Kumulative Bestätigungen** TCP-ACKs sind grundsätzlich kumulativ. Beispiel: ```text Segment 1: Seq 1001, Länge 500 Segment 2: Seq 1501, Länge 500 Segment 3: Seq 2001, Länge 500 ``` Wenn der Empfänger anschließend sendet: ```text Ack = 2501 ``` sind damit alle zusammenhängend empfangenen Bytes bis `2500` bestätigt. Ein fehlendes Segment kann dazu führen, dass der Empfänger weiterhin dieselbe nächste erwartete Sequenznummer bestätigt. --- **Selective Acknowledgment** Wenn SACK während des Handshakes erlaubt wurde, kann der Empfänger zusätzlich mitteilen, welche späteren Datenblöcke bereits angekommen sind. Beispiel: ```text Segment 1 angekommen Segment 2 fehlt Segment 3 angekommen Segment 4 angekommen ``` Der kumulative ACK verweist weiterhin auf Segment 2. SACK-Informationen können jedoch anzeigen, dass Segment 3 und Segment 4 bereits vorhanden sind. Dadurch muss der Sender nicht zwingend alle späteren Daten erneut übertragen. --- **Verzögerte ACKs** TCP-Implementierungen können Bestätigungen kurz verzögern, um: - mehrere empfangene Segmente gemeinsam zu bestätigen; - ACKs mit eigenen ausgehenden Daten zu kombinieren; - unnötige kleine Pakete zu reduzieren. Ein nicht sofort sichtbares ACK ist deshalb nicht automatisch ein Fehler. Entscheidend sind: - tatsächliche Verzögerungsdauer; - Wiederholungen; - Anwendungsreaktion; - Vergleich mit erfolgreichen Verbindungen; - Betriebssystem- und Protokollverhalten. --- **Flusskontrolle** Der Empfänger teilt über das TCP-Empfangsfenster mit, wie viele weitere Bytes er aufnehmen kann. Vereinfacht: ```text Sender darf nur so viele unbestätigte Daten senden, wie das angekündigte Empfangsfenster zulässt. ``` Ein kleiner werdendes Empfangsfenster kann darauf hindeuten, dass die empfangende Anwendung Daten nicht schnell genug aus dem Socket liest. Ein Empfangsfenster von null bedeutet, dass momentan kein weiterer Empfangspuffer verfügbar ist. Die ausführliche Diagnose von Zero Window und Übertragungsstillständen erfolgt auf der dafür vorgesehenen Seite zu Retransmissions, Zero Window und MTU-Problemen. --- **Überlastkontrolle** Zusätzlich zur Flusskontrolle begrenzt TCP die Sendemenge anhand des vermuteten Netzzustands. Wichtige Begriffe: | Begriff | Bedeutung | |---|---| | `cwnd` | Congestion Window des Senders | | `rwnd` | vom Empfänger angekündigtes Receive Window | | `RTT` | gemessene Round Trip Time | | `RTO` | berechneter Retransmission Timeout | | Slow Start | vorsichtige Erhöhung der Sendemenge zu Beginn oder nach bestimmten Verlusten | | Congestion Avoidance | kontrollierte Anpassung der Sendemenge | | Fast Retransmit | schnelle Wiederholung bei Verlusthinweisen | | Fast Recovery | Wiederherstellung nach bestimmten Verlustereignissen | Die tatsächlich sendbare unbestätigte Datenmenge wird unter anderem durch Empfangsfenster und Congestion Window begrenzt. --- **Retransmission Timeout** Ein Sender startet für noch nicht bestätigte Daten einen Wiederholungstimer. Der RTO wird aus gemessenen Laufzeiten und deren Schwankungen berechnet. Er ist kein fester universeller Wert. Wenn eine Bestätigung nicht rechtzeitig eintrifft: - läuft der Wiederholungstimer ab; - das betreffende Segment kann erneut gesendet werden; - der Wiederholungstimer wird typischerweise vergrößert; - die Sendegeschwindigkeit kann reduziert werden; - nach weiteren erfolglosen Versuchen kann die Verbindung aufgegeben werden. Die genaue Anzahl der Versuche und die Gesamtdauer sind abhängig von: - Betriebssystem; - TCP-Implementierung; - Verbindungsphase; - Anwendung; - Socketoptionen; - Systemkonfiguration; - Zwischenkomponenten. Es darf kein universeller TCP-Timeoutwert angenommen werden. --- **Fast Retransmit** Beim klassischen Fast-Retransmit-Verfahren können mehrere Duplicate ACKs den Sender darauf hinweisen, dass ein früheres Segment fehlt, während spätere Segmente angekommen sind. Der Sender kann das fehlende Segment wiederholen, bevor der normale RTO abläuft. Moderne TCP-Implementierungen können zusätzlich oder alternativ weitere Verlustalgorithmen und SACK-Informationen verwenden. Deshalb darf nicht jeder Fast-Retransmit ausschließlich anhand einer festen Zahl von Duplicate ACKs erklärt werden. --- **Duplicate ACKs richtig einordnen** Duplicate ACKs können entstehen durch: - tatsächlich verlorenes Segment; - Paketumordnung; - duplizierte Pakete; - verzögerte Übertragung; - unvollständige Paketaufzeichnung; - asymmetrische Aufzeichnung; - unterschiedliche Netzwerkpfade; - Captureverlust am Analysesystem. Ein Duplicate ACK ist ein Hinweis und kein alleiniger Beweis für Paketverlust. --- **TCP-Retransmissions richtig einordnen** Eine als Retransmission markierte Übertragung kann bedeuten: - ursprüngliches Segment ging im Netzwerk verloren; - Bestätigung ging verloren; - ursprüngliches Segment wurde am Aufzeichnungspunkt nicht erfasst; - Pakete trafen in anderer Reihenfolge ein; - Aufzeichnungssoftware verlor Pakete; - Daten wurden durch Offloading anders dargestellt; - Wireshark ordnete den Datenstrom heuristisch ein. Wireshark-Analysefelder wie `tcp.analysis.retransmission` sind Analyseergebnisse und keine im TCP-Paket übertragenen Flags. --- **TCP Checksum Offloading berücksichtigen** Bei einer Aufzeichnung auf dem sendenden Host kann eine TCP-Prüfsumme als fehlerhaft erscheinen, obwohl das Netzwerkpaket später korrekt übertragen wird. Mögliche Ursache: - die Netzwerkkarte berechnet die Prüfsumme erst nach dem Aufzeichnungspunkt; - TCP Segmentation Offload zerlegt große Datenblöcke erst in der Netzwerkkarte; - Generic Receive Offload oder Large Receive Offload fasst Daten zusammen. Deshalb gilt: ```text Eine lokal als fehlerhaft angezeigte TCP-Prüfsumme beweist ohne weitere Prüfung keinen Netzwerkfehler. ``` Zu vergleichen sind: - Aufzeichnung am sendenden Host; - Aufzeichnung auf einem externen Messpunkt; - Offloading-Anzeige des Analysewerkzeugs; - erfolgreiche und fehlerhafte Verbindungen. --- **TCP besitzt keine Anwendungs-Lebendigkeitsprüfung** Eine bestehende TCP-Verbindung kann im Zustand `ESTABLISHED` verbleiben, obwohl: - die Gegenstelle ausgefallen ist; - ein Kabel getrennt wurde; - eine Firewall den Sitzungszustand gelöscht hat; - der Netzwerkpfad nicht mehr funktioniert; - die Anwendung der Gegenstelle nicht mehr reagiert. Solange keine Daten übertragen oder Prüfmechanismen ausgelöst werden, erkennt TCP einen solchen Zustand nicht zwingend sofort. Mögliche zusätzliche Mechanismen sind: - TCP Keepalive; - anwendungsspezifische Heartbeats; - Request-Timeouts; - Health Checks; - Sitzungszeitüberschreitungen; - erneuter Verbindungsaufbau. Ein TCP-Keepalive beweist nur eine Reaktion des TCP-Endpunkts. Es beweist nicht automatisch, dass die Anwendung fachlich gesund ist. --- **Timeout ist nicht gleich Timeout** Die Meldung „Timeout“ kann aus verschiedenen Ebenen stammen. | Timeoutart | Phase | Typischer Befund | |---|---|---| | DNS-Timeout | vor TCP | kein SYN zum eigentlichen Server | | TCP-Connect-Timeout | Handshake | SYN bleibt unbeantwortet | | TCP-Retransmission-Timeout | Datenübertragung | unbestätigte Segmente werden wiederholt | | TLS-Handshake-Timeout | nach TCP-Aufbau | TCP steht, TLS wird nicht abgeschlossen | | Application-Read-Timeout | nach Anfrage | TCP steht, erwartete Antwort fehlt | | Application-Write-Timeout | Datenversand | Anwendung kann nicht rechtzeitig schreiben | | Proxy-Connect-Timeout | Proxy zum Backend | Client erreicht Proxy, Proxy nicht das Backend | | Proxy-Read-Timeout | Proxy wartet auf Backend | Backendverbindung besteht, Antwort dauert zu lange | | Firewall-Idle-Timeout | längere Inaktivität | Sitzungszustand der Firewall wird entfernt | | NAT-Idle-Timeout | längere Inaktivität | NAT-Zuordnung läuft ab | | Load-Balancer-Idle-Timeout | längere Inaktivität | Load Balancer verwirft inaktive Sitzung | | TCP-Keepalive-Timeout | Prüfmechanismus | Gegenstelle reagiert nicht auf Keepalive-Probes | | Anwendungsdeadline | beliebige Phase | Anwendung bricht nach eigener Gesamtfrist ab | Vor einer Änderung muss festgestellt werden, welcher Zeitgeber tatsächlich abgelaufen ist. --- **Connect-Timeout erkennen** Typischer Ablauf: ```text Anwendung startet Verbindung Client sendet SYN keine verwertbare Antwort SYN wird wiederholt Anwendung meldet Timeout ``` Zu prüfen sind: - Zeitpunkt des ersten SYN; - Anzahl und Abstand der SYN-Wiederholungen; - Zeitpunkt der Anwendungsmeldung; - kommt ein SYN/ACK oder RST an? - erreicht das SYN den Server? - erreicht die Antwort den Client? - beendet die Anwendung den Versuch vor dem TCP-Stack? - versucht die Anwendung danach eine weitere Zieladresse? Bei mehreren DNS-Adressen kann die Anwendung nacheinander oder parallel unterschiedliche Ziele versuchen. Die sichtbare Gesamtdauer muss daher nicht dem Timeout eines einzelnen TCP-Versuchs entsprechen. --- **Anwendungs-Timeout nach erfolgreichem Handshake** Typischer Ablauf: ```text SYN SYN, ACK ACK Anwendungsanfrage keine oder verspätete Anwendungsantwort Anwendung meldet Timeout ``` TCP ist in diesem Fall grundsätzlich aufgebaut. Mögliche Ursachen: - Serveranwendung verarbeitet die Anfrage zu langsam; - Backenddienst reagiert nicht; - Datenbankabfrage blockiert; - Thread- oder Workerpool ist erschöpft; - Empfangsfenster wird klein oder null; - Proxy wartet auf ein Backend; - falsches Anwendungsprotokoll; - Deadlock oder Ressourcensperre; - Antwortpakete gehen verloren; - Anwendung verwendet eine zu kurze Frist. Die Diagnose darf nicht bei einem erfolgreichen Porttest enden. --- **Idle-Timeout erkennen** Typischer Ablauf: ```text TCP-Verbindung wird erfolgreich aufgebaut Datenübertragung funktioniert Verbindung bleibt längere Zeit inaktiv erste neue Übertragung schlägt fehl eine neue TCP-Verbindung funktioniert wieder ``` Mögliche Ursachen: - Firewall hat Sessiontabelleneintrag entfernt; - NAT-Zuordnung ist abgelaufen; - Load Balancer hat die Verbindung geschlossen; - Proxy hat seine Idle-Frist erreicht; - Serveranwendung hat die Sitzung beendet; - Client verwendet eine veraltete Verbindung aus einem Connection Pool; - TCP Keepalive ist nicht aktiv oder zu spät eingestellt. Benötigter Nachweis: - genaue Dauer der Inaktivität; - Zeitpunkt der letzten erfolgreichen Datenübertragung; - Paketfolge beim ersten erneuten Sendeversuch; - Verhalten bei einer frisch aufgebauten Verbindung; - konfigurierte Idle-Timeouts aller Zwischenkomponenten; - Anwendungspool- und Keepalive-Konfiguration. --- **TCP Reset** Ein TCP-Reset wird durch das Flag `RST` signalisiert. Ein Reset bedeutet grundsätzlich: ```text Diese TCP-Verbindung soll sofort zurückgesetzt werden oder der angesprochene TCP-Zustand ist nicht gültig. ``` Im Unterschied zu einem geordneten Abbau mit `FIN` ist ein Reset ein abrupter Abbruch. Mögliche Anwendungsmeldungen: ```text Connection reset by peer ECONNRESET An existing connection was forcibly closed by the remote host Die Verbindung wurde vom Kommunikationspartner zurückgesetzt SocketException: Connection reset ``` Die Formulierung „by peer“ bedeutet nicht zwingend, dass der eigentliche Anwendungsprozess der Gegenstelle den Reset absichtlich erzeugt hat. Der Reset kann stammen von: - Betriebssystem der Gegenstelle; - Anwendung; - lokalem Betriebssystem; - Firewall; - Load Balancer; - Reverse Proxy; - NAT-Gateway; - Intrusion-Prevention-System; - Service Mesh; - Container- oder Cloudnetzkomponente. --- **Typische Ursachen eines TCP Reset** - Verbindung zu einem geschlossenen TCP-Port; - Anwendung bricht einen Socket ausdrücklich ab; - Prozess wird beendet oder stürzt ab; - Anwendung schließt mit ungelesenen Eingangsdaten; - ungültiges Segment für eine nicht mehr existierende Verbindung; - Gegenstelle hat den Verbindungszustand verloren; - Host wurde neu gestartet; - alte Verbindung wird nach längerer Inaktivität erneut verwendet; - Firewall oder Load Balancer hat den Sitzungszustand entfernt; - Proxy lehnt eine Verbindung oder Anfrage ab; - Backend ist nicht verfügbar; - Protokoll wird auf dem falschen Port verwendet; - Sicherheitskomponente beendet die Sitzung; - Verbindungslimit oder Ressourcenlimit wurde erreicht; - Zeitüberschreitung führt zu einem erzwungenen Abbruch; - fehlerhafte NAT- oder Sessionzuordnung; - Paket gehört zu einer früheren Verbindung mit wiederverwendetem Port; - Anwendung verwendet eine abortive Socket-Schließung. Nicht jede Prozessbeendigung erzeugt zwingend einen Reset. Abhängig vom Socketzustand und Betriebssystem kann auch ein kontrollierter FIN-Abbau erfolgen. --- **Reset während des Handshakes** Paketfolge: ```text Client → Server SYN Server → Client RST, ACK ``` Mögliche Einordnung: - kein Listener auf dem Zielport; - Firewall lehnt aktiv ab; - Portweiterleitung zeigt auf geschlossenen Port; - Load Balancer lehnt ab; - falsche Zieladresse; - Dienst wurde beendet; - Listener existiert nur auf einer anderen lokalen Adresse; - IPv4-/IPv6-Bindung passt nicht. Nächster Nachweis: - Listener direkt auf dem Zielsystem prüfen; - Prozessbesitzer bestimmen; - Zieladresse und Adressfamilie bestätigen; - Paketaufzeichnung auf Serverseite durchführen; - Firewall- und NAT-Pfad prüfen. --- **Reset unmittelbar nach erfolgreichem Handshake** Paketfolge: ```text SYN SYN, ACK ACK RST ``` Mögliche Ursachen: - Anwendung akzeptiert und verwirft die Verbindung sofort; - Prozess- oder Workerlimit erreicht; - Zugriffskontrolle lehnt ab; - Proxy besitzt kein Backend; - Client beendet den Socket abrupt; - Server erwartet sofortige Protokolldaten; - Health Check verwendet ein unpassendes Protokoll; - Verbindungszustand ist zwischen Komponenten inkonsistent. Zu prüfen sind: - wer sendet den Reset? - wird vor dem Reset Anwendungsnutzlast übertragen? - existiert im Serverlog eine passende Verbindung? - tritt der Fehler bei jedem Client auf? - funktioniert ein protokollspezifischer Test? --- **Reset nach Übertragung einer Anfrage** Paketfolge: ```text Handshake erfolgreich Client sendet Anfrage Server oder Zwischenkomponente sendet RST ``` Mögliche Ursachen: - ungültiges Anwendungsprotokoll; - TLS-Daten an einem Klartextport; - Klartextdaten an einem TLS-Port; - fehlerhafte oder verbotene Anfrage; - Anwendung stürzt bei der Verarbeitung ab; - Proxy oder WAF beendet die Verbindung; - maximale Anfragegröße überschritten; - Sicherheitsrichtlinie löst aus; - Backend schließt abrupt; - Server liest die Anfrage nicht vollständig; - Client sendet weiter, nachdem der Server bereits geschlossen hat. Der Inhalt unmittelbar vor dem Reset ist für die Ursachenbestimmung besonders wichtig. --- **Reset nach längerer Inaktivität** Typischer Ablauf: ```text Verbindung ist ESTABLISHED keine Übertragung über längere Zeit Client sendet neue Daten RST wird empfangen ``` Mögliche Ursache: - Zwischenkomponente hat den Sitzungszustand gelöscht; - Server hat die Verbindung lokal bereits beendet; - Anwendung verwendet einen veralteten Socket; - Connection Pool prüft die Verbindung vor Wiederverwendung nicht; - Idle-Timeouts verschiedener Komponenten sind nicht abgestimmt. Zu vergleichen sind: - TCP-Keepalive; - Anwendungsheartbeat; - Firewall-Idle-Timeout; - NAT-Timeout; - Proxy-Timeout; - Load-Balancer-Timeout; - Connection-Pool-Lebensdauer. --- **Reset nach Wiederholungen** Möglicher Ablauf: ```text Daten werden gesendet Bestätigung fehlt Daten werden wiederholt weitere Wiederholungen RST oder lokaler Verbindungsabbruch ``` Ein Reset nach Wiederholungen kann bedeuten: - Netzwerkpfad war unterbrochen; - Gegenstelle hat den Zustand verloren; - Anwendung oder Betriebssystem gibt die Verbindung auf; - eine Zwischenkomponente reagiert auf eine nicht mehr bekannte Sitzung; - Prozess wurde während des Fehlers beendet. Die zeitliche Reihenfolge muss genau ausgewertet werden. Der Reset kann Folge und nicht Ursache des ursprünglichen Problems sein. --- **Reset-Absender bestimmen** In der Clientaufzeichnung ist zunächst die Quelladresse des Reset-Segments sichtbar. Sie ist jedoch nicht immer ein eindeutiger Beweis für den tatsächlichen Erzeuger. Zwischenkomponenten können: - mit der Adresse des Servers antworten; - Verbindungen stellvertretend terminieren; - NAT-Adressen verwenden; - einen eigenen TCP-Endpunkt darstellen; - Reset-Segmente erzeugen. Belastbarer Nachweis: 1. Aufzeichnung am Client. 2. Aufzeichnung am Server. 3. Zeitliche Synchronisation beider Systeme. 4. Vergleich derselben TCP-Verbindung. 5. Prüfung, ob der Reset den Server verlässt. 6. Prüfung, ob der Server den Reset überhaupt empfängt. 7. Protokolle von Firewall, Proxy und Load Balancer korrelieren. Beispiel: ```text Client sieht einen RST. Serveraufzeichnung zeigt keinen ausgehenden RST. Firewallprotokoll zeigt eine aktive Sitzungsbeendigung. Einordnung: Der Reset wurde wahrscheinlich von der Firewall erzeugt. ``` Dies ist eine Schlussfolgerung aus mehreren Befunden und nicht allein aus der IP-Quelladresse. --- **FIN, RST und Timeout unterscheiden** | Befund | Bedeutung | |---|---| | `FIN` | Sender beendet seine Senderichtung geordnet. | | `RST` | Verbindung wird abrupt zurückgesetzt. | | Timeout | Innerhalb der erwarteten Frist kam keine verwertbare Reaktion. | | ICMP-Fehler | IP- oder Netzwerkebene meldet ein Problem. | | Anwendungsfehler | TCP kann funktionieren, während das höhere Protokoll fehlschlägt. | Ein FIN bedeutet nicht zwingend, dass die gesamte Verbindung sofort beendet ist. TCP unterstützt einen geordneten Abbau je Richtung. --- **Verbindungsabbau zwischen Client und Server** Ein regulärer TCP-Abbau besteht logisch aus: ```text Teilnehmer A Teilnehmer B ESTABLISHED ESTABLISHED | | | FIN, ACK | |------------------------------------------>| | | FIN-WAIT-1 CLOSE-WAIT | | | ACK | |<------------------------------------------| | | FIN-WAIT-2 CLOSE-WAIT | | | FIN, ACK | |<------------------------------------------| | | TIME-WAIT LAST-ACK | | | ACK | |------------------------------------------>| | | TIME-WAIT CLOSED | | nach Ablauf der Wartezeit | CLOSED ``` Dies wird häufig als Four-Way Termination bezeichnet. In einer echten Aufzeichnung müssen nicht immer vier getrennte Pakete sichtbar sein. ACK und FIN können kombiniert werden. --- **FIN verbraucht eine Sequenznummer** Wie SYN verbraucht auch FIN eine Sequenznummer. Beispiel: ```text Teilnehmer A sendet: FIN, Seq = 5000 Teilnehmer B bestätigt: ACK = 5001 ``` Das FIN signalisiert: ```text Ich werde in dieser Richtung keine weiteren Daten mehr senden. ``` Die Gegenrichtung kann abhängig vom Anwendungs- und Socketzustand noch Daten übertragen. --- **Half-Close** Bei einem Half-Close wurde nur eine Senderichtung geordnet geschlossen. Beispiel: ```text Client sendet FIN. Server bestätigt FIN. Server sendet weiterhin verbleibende Antwortdaten. Server sendet später sein eigenes FIN. ``` Half-Close ist nicht dasselbe wie eine Half-Open Connection. | Begriff | Bedeutung | |---|---| | Half-Close | Eine Richtung wurde geordnet mit FIN beendet. | | Half-Open | Beide Endpunkte besitzen unterschiedliche Vorstellungen darüber, ob die Verbindung noch existiert. | Eine Half-Open Connection kann beispielsweise entstehen, wenn ein System neu startet und den früheren TCP-Zustand verliert, während die Gegenstelle die Verbindung weiterhin als vorhanden betrachtet. --- **TCP-Zustände beim Verbindungsabbau** | Zustand | Bedeutung | |---|---| | `FIN-WAIT-1` | Lokales FIN wurde gesendet; Bestätigung oder FIN der Gegenstelle steht aus. | | `FIN-WAIT-2` | Lokales FIN wurde bestätigt; FIN der Gegenstelle steht aus. | | `CLOSE-WAIT` | FIN der Gegenstelle wurde empfangen; lokale Anwendung hat noch nicht geschlossen. | | `CLOSING` | Beide Seiten haben nahezu gleichzeitig FIN gesendet. | | `LAST-ACK` | Lokales FIN wurde nach empfangenem FIN gesendet; abschließendes ACK steht aus. | | `TIME-WAIT` | Endpunkt wartet, damit verspätete Segmente einer alten Verbindung nicht falsch zugeordnet werden. | | `CLOSED` | Verbindung ist vollständig beendet. | --- **CLOSE-WAIT richtig interpretieren** `CLOSE-WAIT` bedeutet: ```text Die Gegenstelle hat ihre Senderichtung geschlossen. Das lokale Betriebssystem wartet darauf, dass die lokale Anwendung ihren Socket schließt. ``` Viele dauerhaft vorhandene `CLOSE-WAIT`-Sockets können hinweisen auf: - Anwendung liest EOF, schließt aber nicht; - Fehler im Connection-Handling; - blockierte Threads; - fehlende Fehlerbehandlung; - Ressourcenleck; - Anwendung wartet auf einen internen Vorgang; - Prozess reagiert nicht. `CLOSE-WAIT` wird nicht durch das bloße Ändern eines TCP-Timers behoben. Zuerst müssen Prozess und Anwendungscode beziehungsweise Herstellerprotokolle geprüft werden. --- **FIN-WAIT-2 richtig interpretieren** `FIN-WAIT-2` bedeutet: ```text Die lokale Seite hat ihre Senderichtung geschlossen. Die Gegenstelle hat dies bestätigt, aber noch kein eigenes FIN gesendet. ``` Mögliche Ursachen bei ungewöhnlich langen Beständen: - Gegenanwendung hält ihre Senderichtung offen; - Anwendung wartet auf weitere Verarbeitung; - Gegenprozess reagiert nicht; - Half-Close wird absichtlich verwendet; - Netzwerk- oder Zustandsproblem. Ein kurzfristiger `FIN-WAIT-2`-Zustand ist nicht automatisch fehlerhaft. --- **TIME-WAIT richtig interpretieren** `TIME-WAIT` schützt unter anderem davor, dass verspätete Segmente einer alten Verbindung einer späteren Verbindung mit denselben Endpunkten zugeordnet werden. Viele `TIME-WAIT`-Einträge können bei folgenden Arbeitslasten normal sein: - viele kurze HTTP-Verbindungen; - häufige Health Checks; - Proxy- oder API-Aufrufe; - fehlendes oder nicht genutztes Connection Pooling; - Lasttests; - Microservice-Kommunikation. Zu prüfen sind: - Rate neuer Verbindungen; - Wiederverwendung bestehender Verbindungen; - Quellportbestand; - Verbindungslaufzeit; - Baseline; - Anwendungskonfiguration. `TIME-WAIT` darf nicht vorsorglich durch aggressive Timeränderungen beseitigt werden. --- **Windows: TCP-Zustände prüfen** **LESEND** Alle TCP-Verbindungen: ```powershell Get-NetTCPConnection | Sort-Object State, LocalPort ``` Verbindungen im Zustand `SYN-SENT`: ```powershell Get-NetTCPConnection ` -State SynSent ``` Verbindungen im Zustand `SYN-RECEIVED`: ```powershell Get-NetTCPConnection ` -State SynReceived ``` Aufgebaute Verbindungen: ```powershell Get-NetTCPConnection ` -State Established ``` `CLOSE-WAIT`: ```powershell Get-NetTCPConnection ` -State CloseWait ``` `TIME-WAIT`: ```powershell Get-NetTCPConnection ` -State TimeWait ``` Bestimmten entfernten Port prüfen: ```powershell Get-NetTCPConnection ` -RemotePort 443 | Select-Object ` LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` Serververbindungen eines lokalen Ports: ```powershell Get-NetTCPConnection ` -LocalPort 443 | Select-Object ` LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` Kurzlebige Zustände können zwischen zwei Abfragen verschwinden. Eine Paketaufzeichnung ist für die vollständige zeitliche Reihenfolge zuverlässiger. --- **Windows: Prozess zuordnen** **LESEND** ```powershell Get-NetTCPConnection ` -RemotePort 443 | ForEach-Object { $connection = $_ $process = Get-Process ` -Id $connection.OwningProcess ` -ErrorAction SilentlyContinue [pscustomobject]@{ LocalAddress = $connection.LocalAddress LocalPort = $connection.LocalPort RemoteAddress = $connection.RemoteAddress RemotePort = $connection.RemotePort State = $connection.State ProcessId = $connection.OwningProcess ProcessName = $process.ProcessName } } ``` Ein Prozess kann zwischen Socketabfrage und Prozessabfrage bereits beendet sein. Fehlende Prozessinformationen müssen deshalb mit Zeitpunkt und Ereignisprotokollen korreliert werden. --- **Windows: TCP-Verbindung aktiv testen** **NETZAKTIV** ```powershell Test-NetConnection ` -ComputerName "app.example.test" ` -Port 443 ` -InformationLevel Detailed ``` Wichtige Felder: - `ComputerName`; - `RemoteAddress`; - `RemotePort`; - `InterfaceAlias`; - `SourceAddress`; - `TcpTestSucceeded`. `TcpTestSucceeded = True` bestätigt einen erfolgreichen TCP-Verbindungsaufbau für diesen Versuch. Es bestätigt nicht die Funktion von TLS, HTTP oder der eigentlichen Anwendung. Getrennte Prüfung einer konkreten Adresse: ```powershell Test-NetConnection ` -ComputerName "192.0.2.25" ` -Port 443 ` -InformationLevel Detailed ``` --- **Windows: TCP-Statistiken prüfen** **LESEND** ```cmd netstat -s -p tcp ``` IPv6-TCP-Statistiken: ```cmd netstat -s -p tcpv6 ``` Verfügbare Leistungsindikatoren suchen: ```powershell Get-Counter ` -ListSet "*TCP*" ``` Die Namen der Leistungsindikatoren können von Sprache und Windows-Version abhängen. Zähler müssen über einen definierten Zeitraum als Differenz oder Rate ausgewertet werden. Ein hoher kumulierter Wert seit dem Systemstart beweist keine aktuelle Störung. --- **Windows: Paketaufzeichnung mit pktmon** `pktmon` verändert den Aufzeichnungszustand und erstellt Dateien. **SENSITIV · ÄNDERND** Vorhandene Aufzeichnung stoppen: ```cmd pktmon stop ``` Vorhandene Filter entfernen: ```cmd pktmon filter remove ``` Filter für TCP-Port `443` anlegen: ```cmd pktmon filter add TCP443 -t TCP -p 443 ``` Aufzeichnung starten: ```cmd pktmon start --capture --pkt-size 0 --file-name C:\Temp\tcp443.etl ``` Nach reproduziertem Fehler stoppen: ```cmd pktmon stop ``` In PCAPNG konvertieren: ```cmd pktmon etl2pcap C:\Temp\tcp443.etl --out C:\Temp\tcp443.pcapng ``` Temporären Filter entfernen: ```cmd pktmon filter remove ``` Voraussetzungen: - Zielverzeichnis existiert; - ausreichend freier Speicher ist vorhanden; - Aufzeichnungszeitraum ist begrenzt; - Datei wird geschützt gespeichert; - Filter und Aufzeichnungszustand werden anschließend zurückgesetzt. --- **Linux: TCP-Zustände mit ss prüfen** **LESEND** Alle TCP-Sockets: ```bash ss -tan ``` TCP-Sockets mit Prozessinformationen: ```bash sudo ss -tanp ``` `SYN-SENT`: ```bash ss -tan state syn-sent ``` `SYN-RECEIVED`: ```bash ss -tan state syn-recv ``` Aufgebaute Verbindungen: ```bash ss -tan state established ``` `CLOSE-WAIT`: ```bash ss -tan state close-wait ``` `TIME-WAIT`: ```bash ss -tan state time-wait ``` Erweiterte TCP-Informationen für Zielport `443`: ```bash sudo ss -tin \ 'dport = :443' ``` Erweiterte Informationen für einen lokalen Serverport: ```bash sudo ss -tin \ 'sport = :443' ``` Je nach Zustand und Kernel können erweiterte Angaben enthalten sein: - RTT; - RTO; - Congestion Window; - Retransmissions; - Sendemenge; - Empfangsmenge; - Window Scaling; - MSS; - Timer. Die konkrete Ausgabe hängt von Kernel und TCP-Zustand ab. --- **Linux: TCP-Zähler prüfen** **LESEND** ```bash nstat -az ``` Bestimmte Zähler: ```bash nstat -az TcpRetransSegs ``` ```bash nstat -az TcpAttemptFails ``` ```bash nstat -az TcpEstabResets ``` Zusätzliche klassische Statistik: ```bash netstat -s ``` Zu beachten: - Zähler sind häufig kumulativ; - ein Reset-Zähler nennt nicht automatisch die betroffene Anwendung; - Container oder Netzwerk-Namespaces können eigene Sichten besitzen; - für eine aktuelle Störung sind Vorher-Nachher-Differenzen notwendig. --- **macOS: TCP-Zustände prüfen** **LESEND** ```bash netstat -anv -p tcp ``` TCP-Verbindungen mit Prozesszuordnung: ```bash sudo lsof -nP -iTCP ``` Aufgebaute TCP-Verbindungen: ```bash sudo lsof \ -nP \ -iTCP \ -sTCP:ESTABLISHED ``` Interaktive TCP-Ansicht: ```bash nettop -m tcp ``` TCP-Statistiken: ```bash netstat -s -p tcp ``` Kurzlebige Handshakezustände können auch unter macOS leichter mit einer Paketaufzeichnung als mit wiederholten Socketabfragen erfasst werden. --- **Aktive Tests unter Linux und macOS** TCP-Porttest: **NETZAKTIV** ```bash nc -vz app.example.test 443 ``` Linux mit begrenzter Wartezeit, abhängig von der installierten `nc`-Variante: ```bash nc -vz -w 5 app.example.test 443 ``` macOS mit TCP-Verbindungsfrist: ```bash nc -vz -G 5 app.example.test 443 ``` HTTP- oder HTTPS-Test mit getrennten Fristen: ```bash curl \ --connect-timeout 5 \ --max-time 15 \ -v \ https://app.example.test/ ``` Bedeutung: - `--connect-timeout` begrenzt die Verbindungsphase; - `--max-time` begrenzt den gesamten Aufruf. Ein Fehler nach erfolgreicher `Connected`-Meldung ist kein reiner TCP-Connect-Fehler mehr. --- **Paketaufzeichnung unter Linux** **SENSITIV · LESEND** Auf Port `443` begrenzen: ```bash sudo tcpdump \ -ni any \ 'tcp port 443' \ -c 200 ``` Auf einen Host und Port begrenzen: ```bash sudo tcpdump \ -ni any \ 'host 192.0.2.25 and tcp port 443' \ -c 200 ``` Mit ausführlicheren TCP-Informationen in Datei schreiben: ```bash sudo tcpdump \ -ni any \ -s 0 \ -w /tmp/tcp443.pcap \ 'host 192.0.2.25 and tcp port 443' ``` Nach reproduziertem Fehler mit `Strg+C` beenden. Die Datei enthält möglicherweise sensible Daten und muss anschließend geschützt ausgewertet und kontrolliert entfernt werden. --- **Paketaufzeichnung unter macOS** Verwendbare Schnittstellen anzeigen: ```bash tcpdump -D ``` Auf einer konkreten Schnittstelle: ```bash sudo tcpdump \ -ni en0 \ 'host 192.0.2.25 and tcp port 443' \ -c 200 ``` Lokale Loopback-Verbindung: ```bash sudo tcpdump \ -ni lo0 \ 'tcp port 8080' \ -c 200 ``` In Datei schreiben: ```bash sudo tcpdump \ -ni en0 \ -s 0 \ -w /tmp/tcp443.pcap \ 'host 192.0.2.25 and tcp port 443' ``` --- **Wireshark-Filter für TCP** Bestimmter Port: ```text tcp.port == 443 ``` Bestimmte IP-Adresse und Port: ```text ip.addr == 192.0.2.25 && tcp.port == 443 ``` Nur initiale SYN-Segmente: ```text tcp.flags.syn == 1 && tcp.flags.ack == 0 ``` SYN/ACK: ```text tcp.flags.syn == 1 && tcp.flags.ack == 1 ``` Reset: ```text tcp.flags.reset == 1 ``` FIN: ```text tcp.flags.fin == 1 ``` Vermutete Wiederholungen: ```text tcp.analysis.retransmission ``` Vermuteter Fast Retransmit: ```text tcp.analysis.fast_retransmission ``` Duplicate ACKs: ```text tcp.analysis.duplicate_ack ``` Zero Window: ```text tcp.analysis.zero_window ``` Ein bestimmter TCP-Datenstrom: ```text tcp.stream == 7 ``` Die Nummer des TCP-Streams wird von Wireshark innerhalb der geöffneten Aufzeichnung vergeben und ist keine übertragene Protokollnummer. --- **Aufzeichnung richtig planen** Vor Beginn sind festzulegen: ```text Client: Server: Port: Zeitfenster: Testhandlung: Aufzeichnungspunkte: Erwartete Paketfolge: Fehlerkriterium: ``` Die Systemzeiten der beteiligten Geräte müssen ausreichend synchron sein. Anderenfalls können Client-, Server-, Firewall- und Proxyprotokolle nicht zuverlässig korreliert werden. --- **Aufzeichnung am Client und Server vergleichen** | Clientaufzeichnung | Serveraufzeichnung | Mögliche Einordnung | |---|---|---| | SYN sichtbar | SYN nicht sichtbar | Fehler vor dem Server | | SYN sichtbar | SYN sichtbar | Hinweg funktioniert | | kein SYN/ACK am Client | SYN/ACK verlässt Server | Rückweg oder Filterung | | RST am Client | RST verlässt Server | Server oder Serveranwendung wahrscheinlich beteiligt | | RST am Client | kein RST am Server | Zwischenkomponente wahrscheinlich beteiligt | | Daten am Client gesendet | Daten erreichen Server | Hinweg der Daten funktioniert | | ACK fehlt am Client | ACK verlässt Server | Rückwegproblem | | Server erhält ACK nicht | Client sendet ACK | Filterung oder asymmetrischer Pfad | | FIN auf beiden Seiten | FIN verlässt ursprünglichen Sender | kontrollierter Abbau | | unterschiedliche Paketfolgen | Übersetzung oder Verlust | NAT, Proxy, Capturepunkt oder Netzwerkpfad prüfen | --- **NAT, Firewall, Proxy und Load Balancer berücksichtigen** Eine Ende-zu-Ende-Verbindung kann tatsächlich aus mehreren getrennten TCP-Verbindungen bestehen. Beispiel mit Reverse Proxy: ```text Client → TCP-Verbindung 1 → Reverse Proxy → TCP-Verbindung 2 → Backend ``` Ein Reset zwischen Proxy und Backend muss nicht als Reset zwischen Proxy und Client weitergegeben werden. Der Proxy kann stattdessen eine HTTP-Fehlerantwort erzeugen. Beispiel mit NAT: ```text Client intern: 192.0.2.100:53124 NAT extern: 203.0.113.10:62000 Server: 198.51.100.25:443 ``` Zu prüfen sind: - übersetzte Quelladresse; - übersetzter Quellport; - Sessiontabelleneintrag; - Ablaufzeit; - Rückweg; - Verbindung zum Backend; - getrennte Timeouts je TCP-Abschnitt; - welcher Abschnitt den Reset enthält. --- **Container und Kubernetes berücksichtigen** Eine TCP-Verbindung kann durch mehrere Netzwerk-Namespaces laufen: ```text Client → Hostport → Container-Netzwerk → Containersocket ``` oder: ```text Client → Load Balancer → Kubernetes-Service → Pod-IP → Anwendungscontainer ``` Zu prüfen sind: - Handshake am externen Endpunkt; - Handshake zum Backend; - Listener im Container oder Pod; - Host- und Containerport; - Service-`port` und `targetPort`; - Sidecar- oder Service-Mesh-Verbindung; - NetworkPolicy; - Readiness und EndpointSlices; - Reset innerhalb des Pods; - Reset am Ingress oder Gateway. Ein erfolgreicher Handshake zum Load Balancer beweist keinen erfolgreichen Handshake zum Backend. --- **Typische Fehlermeldungen einordnen** | Meldung | Mögliche TCP-Einordnung | |---|---| | `Connection refused` | häufig Reset als Antwort auf SYN | | `Connection timed out` | Handshake oder Datenübertragung ohne rechtzeitige Antwort | | `Connection reset by peer` | gültiger Reset wurde empfangen | | `Broken pipe` | Schreiben auf bereits geschlossene Verbindung | | `EOF` | Gegenstelle hat den Datenstrom beendet | | `Operation timed out` | Frist der Anwendung oder Bibliothek abgelaufen | | `No route to host` | Routing- oder lokal gemeldeter Erreichbarkeitsfehler | | `Network is unreachable` | keine verwendbare Route | | `TLS handshake timeout` | TCP möglicherweise erfolgreich, TLS nicht abgeschlossen | | `Read timed out` | Verbindung steht, erwartete Daten fehlen | | `Write timed out` | Daten konnten nicht innerhalb der Frist geschrieben werden | Der genaue Wortlaut hängt von Betriebssystem, Programmiersprache, Bibliothek und Anwendung ab. --- **Hypothese und Gegenbeweis** Beispiel für einen Connect-Timeout: ```text Hypothese: Eine Netzwerkfirewall verwirft die SYN-Pakete zum TCP-Port 443. Erwarteter Befund: Der Client sendet wiederholt SYN-Pakete. Der Server empfängt diese SYN-Pakete nicht. Es wird weder SYN/ACK noch RST empfangen. Gegenbeweis: Die Serveraufzeichnung zeigt das eingehende SYN und ein ausgehendes SYN/ACK. Testmethode: Zeitgleich begrenzte Paketaufzeichnung auf Client und Server. Erfolgskriterium: Der genaue Punkt des Paketverlusts ist eingegrenzt. Risiko: Die Aufzeichnung enthält interne Verbindungsdaten und muss geschützt werden. ``` Beispiel für einen Reset: ```text Hypothese: Der Reverse Proxy erzeugt den Reset, weil kein Backend verfügbar ist. Erwarteter Befund: Der Client-Handschlag mit dem Proxy ist erfolgreich. Der Proxy kann keine Verbindung zum Backend aufbauen. Der Client empfängt anschließend einen Reset. Das Backend empfängt keinen Verbindungsversuch oder lehnt ihn ab. Gegenbeweis: Der Backend-Handschlag ist erfolgreich und der Reset verlässt nachweislich das Backend. Testmethode: Aufzeichnungen und Protokolle an Client, Proxy und Backend korrelieren. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | Listener starten oder Bindung korrigieren | Reset wegen fehlendem Listener bestätigt | geänderte Erreichbarkeit | | Firewallregel korrigieren | Paketverlust an der Firewall nachgewiesen | unbeabsichtigte Freigabe | | Rückweg korrigieren | asymmetrischer oder fehlender Rückweg bestätigt | weitere Netze können betroffen sein | | NAT-Zuordnung korrigieren | falsche Übersetzung bestätigt | bestehende Sitzungen werden beeinflusst | | Proxy-Backend korrigieren | fehlerhafter Backendpfad nachgewiesen | produktiver Datenverkehr wird umgeleitet | | Idle-Timeout abstimmen | Sitzungsablauf nach Inaktivität bestätigt | mehr Sitzungszustand und Ressourcenverbrauch | | Connection-Pool-Lebensdauer anpassen | Wiederverwendung veralteter Verbindungen bestätigt | mehr neue Verbindungen | | Anwendungs-Timeout anpassen | Verarbeitung dauert legitim länger und Ursache ist bekannt | Fehler werden eventuell später erkannt | | TCP-Keepalive gezielt konfigurieren | verwaiste Idle-Verbindungen bestätigt | zusätzlicher Netzwerkverkehr | | Anwendung korrigieren | `CLOSE-WAIT`, abortives Schließen oder Absturz bestätigt | Dienstneustart oder Deployment erforderlich | | Backendkapazität erhöhen | Ressourcenengpass nachgewiesen | Kosten und Betriebsänderung | | Protokoll oder Zielport korrigieren | falsches Protokoll beziehungsweise falscher Port bestätigt | Clientkonfiguration ändert sich | Timeouts dürfen nicht pauschal verlängert werden, um Paketverlust, Deadlocks oder überlastete Backends zu verdecken. --- **Systematischer Diagnoseablauf** 1. Exakte Anwendungsmeldung aufnehmen. 2. Datum, Uhrzeit und Zeitzone dokumentieren. 3. Client, Server, Zielname und Zielport bestimmen. 4. Verwendete IP-Adresse und Adressfamilie erfassen. 5. Transportprotokoll bestätigen. 6. Erwarteten Listener auf dem Server prüfen. 7. Besitzenden Prozess bestimmen. 8. Lokalen TCP-Test am Server durchführen. 9. TCP-Test vom betroffenen Client durchführen. 10. Socketzustand während des Versuchs beobachten. 11. Prüfen, ob ein SYN erzeugt wird. 12. Prüfen, ob der Server das SYN empfängt. 13. Prüfen, ob SYN/ACK oder RST zurückgesendet wird. 14. Prüfen, ob das abschließende ACK ankommt. 15. Bei erfolgreichem Handshake Anwendungsdaten prüfen. 16. Connect- und Anwendungs-Timeout unterscheiden. 17. FIN und RST unterscheiden. 18. Reset-Richtung und Reset-Zeitpunkt bestimmen. 19. Client-, Server- und Zwischenprotokolle korrelieren. 20. Retransmissions und Duplicate ACKs auswerten. 21. Captureverlust und Offloading berücksichtigen. 22. NAT-, Firewall- und Proxyzustand prüfen. 23. Load Balancer und Backendverbindung getrennt prüfen. 24. Container- und Netzwerk-Namespace berücksichtigen. 25. Idle-Phase und Timeoutwerte dokumentieren. 26. Frische und wiederverwendete Verbindung vergleichen. 27. Hypothese und Gegenbeweis formulieren. 28. Genau eine kontrollierte Maßnahme durchführen. 29. Identischen Verbindungsversuch wiederholen. 30. Anwendungsprotokoll vollständig verifizieren. 31. Weitere repräsentative Clients prüfen. 32. Temporäre Filter und Aufzeichnungen entfernen. 33. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | kein SYN sichtbar | Anwendung, DNS oder lokaler Socketaufruf | Anwendungstrace und Zieladresse | | SYN wiederholt, keine Antwort | Drop, Routing oder Rückweg | serverseitige Aufzeichnung | | SYN erreicht Server nicht | Netzpfad vor dem Server | Zwischenpunkte und Firewalllogs | | SYN erreicht Server, kein SYN/ACK | lokaler Filter, kein Listener oder Überlastung | Socketliste und Servertrace | | SYN wird mit RST beantwortet | aktive Ablehnung | Reset-Erzeuger und Listener prüfen | | SYN/ACK verlässt Server, erreicht Client nicht | Rückweg oder Filterung | Client- und Firewallaufzeichnung | | SYN/ACK wird wiederholt | abschließendes ACK fehlt | Clientaufzeichnung | | Handshake vollständig | TCP-Connect funktioniert | Anwendungsprotokoll prüfen | | Handshake vollständig, keine Nutzdaten | Anwendung wartet oder startet Anfrage nicht | Anwendungstrace | | Anfrage gesendet, keine Antwort | Backend oder Anwendung langsam | Server- und Backendprotokolle | | RST direkt nach Handshake | Anwendung oder Zwischenkomponente lehnt ab | Reset-Sender und Logs | | RST nach Anfrage | Protokoll-, Anwendungs- oder Sicherheitsfehler | Daten vor dem Reset auswerten | | RST nach langer Inaktivität | Idle-Timeout oder veralteter Socket | Timeoutwerte und frische Verbindung | | FIN nach Anfrage | kontrollierte Schließung | Anwendungsergebnis prüfen | | viele `CLOSE-WAIT` | lokale Anwendung schließt nicht | Prozess- und Threadanalyse | | viele `TIME-WAIT` | viele kurzlebige Verbindungen | Verbindungsrate und Pooling | | viele `SYN-SENT` | Ziele antworten nicht | Ziel- und Pfadvergleich | | viele `SYN-RECEIVED` | Handshake bleibt unvollständig | Serverwarteschlange und Clientpfad | | Retransmissions nur in einer Capturedatei | Captureverlust oder Offloading möglich | zweiter Aufzeichnungspunkt | | frische Verbindung funktioniert | alte Verbindung fehlerhaft | Idle- und Poolingverhalten | | Porttest funktioniert, TLS scheitert | TCP funktioniert, TLS fehlerhaft | TLS-Handshake analysieren | | nur große Übertragung stockt | Verlust, Window oder MTU möglich | Folgeseite zu Retransmissions und MTU | | nur ein Backend erzeugt Resets | Backend- oder Pfadproblem | direkte Backendtests | | Reset am Client, nicht am Server | Zwischenkomponente wahrscheinlich | Firewall-, Proxy- und LB-Protokolle | --- **Typische Diagnosefehler** - Anwendungstimeout und TCP-Timeout gleichsetzen. - Einen erfolgreichen Ping als TCP-Nachweis verwenden. - Einen offenen TCP-Port als vollständigen Anwendungsnachweis bewerten. - Nur `Test-NetConnection` oder `nc` verwenden. - DNS-Zeit und TCP-Verbindungszeit vermischen. - Nur auf dem Client aufzeichnen. - Aus einer fehlenden Clientantwort schließen, dass der Server nichts gesendet hat. - Aus der RST-Quelladresse sicher auf den Erzeuger schließen. - Firewall, Proxy oder Load Balancer als Reset-Erzeuger ignorieren. - FIN und RST gleich behandeln. - `CLOSE-WAIT` durch Änderung von TCP-Timern beheben wollen. - `TIME-WAIT` pauschal als Fehler bewerten. - Wiederholungen ohne Sequenznummern und ACKs auswerten. - Duplicate ACKs automatisch als Paketverlust bewerten. - Wireshark-Analysemarkierungen als echte TCP-Flags interpretieren. - Checksum-Offloading ignorieren. - Captureverlust am Analysesystem ignorieren. - IPv4 und IPv6 nicht getrennt prüfen. - Client- und Serverzeit nicht synchronisieren. - NAT-Adressen und ursprüngliche Adressen verwechseln. - Proxyverbindung und Backendverbindung als eine einzige TCP-Verbindung behandeln. - Host-, Container- und Pod-Namespace verwechseln. - Veraltete Verbindung aus einem Pool nicht berücksichtigen. - Idle-Timeout ohne Messung vermuten. - Timeout pauschal erhöhen. - TCP Keepalive als Nachweis der Anwendungsgesundheit betrachten. - Firewall vollständig deaktivieren. - Prozess vorsorglich beenden. - Server vorsorglich neu starten. - mehrere Einstellungen gleichzeitig verändern. - Paketaufzeichnung ohne Filter laufen lassen. - sensible Capturedateien ungeschützt speichern. - nach der Maßnahme nur einen einzelnen erfolgreichen Versuch prüfen. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - Zielname wird zur richtigen Adresse aufgelöst; - richtige IPv4- oder IPv6-Adresse wird verwendet; - erwarteter TCP-Listener ist vorhanden; - richtiger Prozess besitzt den Listener; - SYN erreicht den Server; - SYN/ACK erreicht den Client; - abschließendes ACK erreicht den Server; - TCP-Verbindung erreicht `ESTABLISHED`; - keine unerwarteten Reset-Segmente entstehen; - Daten werden in beiden Richtungen übertragen; - ACKs bestätigen die erwarteten Sequenzbereiche; - Retransmissionsrate entspricht der Baseline; - Anwendung antwortet innerhalb der vorgesehenen Frist; - TLS funktioniert, sofern vorgesehen; - Proxy erreicht sein Backend; - Load Balancer verwendet gesunde Backends; - NAT- und Firewallzustand bleiben während der Sitzung bestehen; - wiederverwendete Verbindungen funktionieren; - Verhalten nach repräsentativer Inaktivität ist korrekt; - Verbindung wird kontrolliert beendet; - keine dauerhaft wachsenden `CLOSE-WAIT`-Bestände entstehen; - `TIME-WAIT`-Bestand ist zur Arbeitslast plausibel; - mehrere aufeinanderfolgende Versuche funktionieren; - weitere repräsentative Clients funktionieren; - temporäre Capturefilter wurden entfernt; - Aufzeichnungen wurden geschützt oder kontrolliert gelöscht; - Ursache, Maßnahme und Prävention wurden dokumentiert. Ein einzelner erfolgreicher Three-Way Handshake ist keine vollständige Verifikation der Anwendung. --- **Dokumentationsvorlage** ```text Störung: Zeitpunkt: Client: Server: Zielname: Zielport: Adressfamilie: Anwendung: Exakte Fehlermeldung: Verwendete Quelladresse: Verwendete Zieladresse: Listener: Handshake-Befund: Socketzustände: Anwendungsdaten: Timeoutart: Timeoutdauer: Reset-Absender: Nachweis des Reset-Absenders: Retransmissions: FIN-Befund: Zwischenkomponenten: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum, Uhrzeit und Zeitzone erfasst - [ ] Client und Server bestimmt - [ ] Zielname dokumentiert - [ ] Zieladresse dokumentiert - [ ] Quelladresse dokumentiert - [ ] Quell- und Zielport erfasst - [ ] IPv4 und IPv6 unterschieden - [ ] TCP-Listener geprüft - [ ] Prozessbesitzer bestimmt - [ ] lokalen TCP-Test durchgeführt - [ ] entfernten TCP-Test durchgeführt - [ ] SYN sichtbar - [ ] SYN/ACK oder RST ausgewertet - [ ] abschließendes ACK geprüft - [ ] Zustand `SYN-SENT` berücksichtigt - [ ] Zustand `SYN-RECEIVED` berücksichtigt - [ ] Zustand `ESTABLISHED` bestätigt - [ ] TCP-Optionen bei Bedarf verglichen - [ ] MSS geprüft - [ ] Window Scaling berücksichtigt - [ ] SACK-Unterstützung berücksichtigt - [ ] Anwendungsdaten nach dem Handshake geprüft - [ ] Sequenz- und Bestätigungsnummern ausgewertet - [ ] Retransmissions geprüft - [ ] Duplicate ACKs berücksichtigt - [ ] Captureverlust ausgeschlossen - [ ] Checksum-Offloading berücksichtigt - [ ] Connect-Timeout bestimmt - [ ] Anwendungs-Timeout bestimmt - [ ] TLS-Timeout bei Bedarf berücksichtigt - [ ] Proxy-Timeout bei Bedarf berücksichtigt - [ ] Idle-Timeout berücksichtigt - [ ] frische Verbindung getestet - [ ] wiederverwendete Verbindung getestet - [ ] TCP Keepalive bei Bedarf geprüft - [ ] RST-Richtung bestimmt - [ ] Reset-Absender eingegrenzt - [ ] FIN und RST unterschieden - [ ] Verbindungsabbau geprüft - [ ] `CLOSE-WAIT` berücksichtigt - [ ] `FIN-WAIT-2` berücksichtigt - [ ] `TIME-WAIT` berücksichtigt - [ ] Clientaufzeichnung durchgeführt - [ ] Serveraufzeichnung durchgeführt - [ ] Firewallprotokolle korreliert - [ ] NAT-Zustand berücksichtigt - [ ] Proxy und Backend getrennt geprüft - [ ] Load Balancer berücksichtigt - [ ] Container- oder Pod-Namespace berücksichtigt - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen Test wiederholt - [ ] Anwendungsprotokoll verifiziert - [ ] weitere repräsentative Clients geprüft - [ ] temporäre Filter entfernt - [ ] Capturedateien geschützt oder entfernt - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl oder Filter | |---|---| | Windows-TCP-Verbindungen | `Get-NetTCPConnection` | | Windows `SYN-SENT` | `Get-NetTCPConnection -State SynSent` | | Windows `SYN-RECEIVED` | `Get-NetTCPConnection -State SynReceived` | | Windows `ESTABLISHED` | `Get-NetTCPConnection -State Established` | | Windows `CLOSE-WAIT` | `Get-NetTCPConnection -State CloseWait` | | Windows `TIME-WAIT` | `Get-NetTCPConnection -State TimeWait` | | Windows-TCP-Test | `Test-NetConnection -ComputerName -Port -InformationLevel Detailed` | | Windows-TCP-Statistik | `netstat -s -p tcp` | | Windows-Paketmonitor | `pktmon` | | Linux-TCP-Sockets | `ss -tan` | | Linux-TCP-Details | `sudo ss -tin` | | Linux `SYN-SENT` | `ss -tan state syn-sent` | | Linux `SYN-RECEIVED` | `ss -tan state syn-recv` | | Linux `ESTABLISHED` | `ss -tan state established` | | Linux `CLOSE-WAIT` | `ss -tan state close-wait` | | Linux `TIME-WAIT` | `ss -tan state time-wait` | | Linux-TCP-Zähler | `nstat -az` | | macOS-TCP-Sockets | `netstat -anv -p tcp` | | macOS-Prozesszuordnung | `sudo lsof -nP -iTCP` | | macOS-Liveansicht | `nettop -m tcp` | | TCP-Porttest | `nc -vz ` | | HTTP-/HTTPS-Test | `curl --connect-timeout 5 --max-time 15 -v ` | | Linux-Aufzeichnung | `sudo tcpdump -ni any 'tcp port ' -c 200` | | macOS-Aufzeichnung | `sudo tcpdump -ni 'tcp port ' -c 200` | | Wireshark: Port | `tcp.port == ` | | Wireshark: initiales SYN | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | Wireshark: SYN/ACK | `tcp.flags.syn == 1 && tcp.flags.ack == 1` | | Wireshark: Reset | `tcp.flags.reset == 1` | | Wireshark: FIN | `tcp.flags.fin == 1` | | Wireshark: Retransmission | `tcp.analysis.retransmission` | | Wireshark: Fast Retransmit | `tcp.analysis.fast_retransmission` | | Wireshark: Duplicate ACK | `tcp.analysis.duplicate_ack` | | Wireshark: TCP-Stream | `tcp.stream == ` | --- **Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen** ```text Stop-Process taskkill Stop-Service Restart-Service netsh int ip reset netsh winsock reset Set-NetFirewallRule New-NetFirewallRule Deaktivieren der Windows-Firewall kill kill -9 systemctl stop systemctl restart sysctl -w iptables nft ufw disable firewall-cmd --permanent docker restart docker stop kubectl delete kubectl rollout restart pauschales Erhöhen aller Timeouts aggressives Verkürzen von TIME-WAIT unkontrolliertes Aktivieren oder Ändern von TCP Keepalive Deaktivieren von TCP-Offloading ohne Vergleichstest Neustart von Firewall, Proxy oder Load Balancer ``` Ein Neustart kann TCP-Zustände, Sessiontabellen und den für die Diagnose wichtigen Ausgangszustand zerstören. --- **Quellen** **Standards** - [RFC 9293 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc9293) - [RFC 1122 – Requirements for Internet Hosts – Communication Layers](https://datatracker.ietf.org/doc/html/rfc1122) - [RFC 5681 – TCP Congestion Control](https://datatracker.ietf.org/doc/html/rfc5681) - [RFC 6298 – Computing TCP's Retransmission Timer](https://datatracker.ietf.org/doc/html/rfc6298) - [RFC 7323 – TCP Extensions for High Performance](https://datatracker.ietf.org/doc/html/rfc7323) - [RFC 2018 – TCP Selective Acknowledgment Options](https://datatracker.ietf.org/doc/html/rfc2018) - [RFC 2883 – An Extension to the Selective Acknowledgement Option](https://datatracker.ietf.org/doc/html/rfc2883) - [RFC 5961 – Improving TCP's Robustness to Blind In-Window Attacks](https://datatracker.ietf.org/doc/html/rfc5961) **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – netstat](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat) - [Microsoft Learn – Packet Monitor](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) - [Microsoft Learn – pktmon filter add](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-filter-add) - [Microsoft Learn – Troubleshoot TCP/IP connectivity](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting) - [Microsoft Learn – Guidance for troubleshooting TCP/IP communication](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-tcp-ip-communication-guidance) **Offizielle Linux-Dokumentation** - [Linux man-pages – ss(8)](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux man-pages – tcp(7)](https://man7.org/linux/man-pages/man7/tcp.7.html) - [Linux man-pages – tcpdump(8)](https://man7.org/linux/man-pages/man8/tcpdump.8.html) - [Linux Kernel Documentation – SNMP counters](https://docs.kernel.org/networking/snmp_counter.html) **Offizielle Wireshark-Dokumentation** - [Wireshark User’s Guide – TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) - [Wireshark Display Filter Reference – TCP](https://www.wireshark.org/docs/dfref/t/tcp.html) - [Wireshark User’s Guide](https://www.wireshark.org/docs/wsug_html/) Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.