Wireshark-Howto: TCP-Retransmits, Three-Way-Handshake und Performance-Spots finden

Dieses Wireshark-Howto beginnt mit klaren Voraussetzungen und einer pragmatischen Checkliste, damit Sie TCP-Retransmits, Three-Way-Handshake-Probleme und Performance-Spots in Ihrem Netz schnell und belastbar eingrenzen können. Das Fokus-Keyword Wireshark-Howto steht bewusst am Anfang: Ziel sind praktische Anleitungen für Administratoren, System Engineers, Operatoren und IT-Dienstleister. Ich erkläre Fachbegriffe wie RTT (Round-Trip-Time: Laufzeit für Hin- und Rückweg) oder Zero Window (der Empfänger signalisiert, aktuell keine Daten puffern zu können) jeweils kurz und zeige, warum ein Befund typischerweise Netz- oder Host-seitig ist.

Capture-Strategie: Wo mitscheiden und warum es zählt

Die Aussagekraft Ihrer Analyse hängt primär vom Capture-Ort ab. Ein Capture an der falschen Stelle liefert irreführende Retransmit‑Muster oder verschleiert asymmetrisches Routing. Planen Sie die Mitschnitte so, dass Sie die Richtung des Nachrichtenflusses nachvollziehen können.

Capture-Orte im Vergleich

• Client‑nah: Deckt Client‑Stack, lokale Firewalls, VPN‑Clients und WLAN‑Retransmits ab.
• Server‑nah: Zeigt, ob der Server SYNs erhält, wie er antwortet und ob lokale Limits (Backlog, ulimits) greifen.
• Firewall/Load‑Balancer‑nah: Wichtig bei NAT, Conntrack oder TLS‑Inspection; häufig sehen Sie nur eine Richtung, weshalb ein zusätzliches Capture sinnvoll ist.
• SPAN vs. TAP: SPAN‑Ports sind leicht zugänglich, können aber bei hoher Last droppen; TAPs liefern vollständigere Daten, erfordern aber Hardware und Planung.

Betriebsrisiken und Compliance

• Datenschutz: Mitschnitte enthalten oft Nutzdaten und müssen nach Datenschutzanforderungen minimiert, anonymisiert oder schnell gelöscht werden.
• Performance: Capture auf produktiven Hosts kann CPU-/IO‑Last erhöhen. Verwenden Sie Ringbuffer oder Fernspeicher für pcap-Dateien.
• TLS: Verschlüsselung versteckt Payload‑Inhalte, nicht Timing, Flags oder Fensterzustand – diese Metadaten reichen für TCP‑Mechanik‑Analysen.

Pragmatische Capture‑Beispiele

Nutzen Sie gezielte Filter und Ringbuffer, um belastbare PCAPs zu erzeugen. Hier zwei praxiserprobte Beispiele für Linux und Windows.

# Linux: gezielt Host/Port mitschneiden, Ringbuffer nutzen
sudo tcpdump -i eth0 -s 0 -nn 
  'host 10.20.30.40 and tcp port 443' 
  -C 200 -W 10 -w /var/tmp/capture_%Y%m%d_%H%M%S.pcap

# Windows: pktmon verwenden, dann ins pcap-Format konvertieren
pktmon filter remove
pktmon filter add -p 443
pktmon start --etw -m real-time
# Tests durchführen, dann stoppen:
pktmon stop
pktmon format PktMon.etl -o capture.pcap

Führen Sie Testfälle vor und nach Änderungen immer mit gleichen Parametern durch, damit Messungen vergleichbar sind.

Wichtige Wireshark‑Ansichten für TCP

Wireshark bietet mehrere Funktionen, die besonders nützlich sind: Display‑Filter (für gezielte Ansicht), Conversations (Flows), Follow TCP Stream (ordnet Flow) und Time‑Sequence‑Graph (visualisiert Sequenzen, ACKs und Retransmits). Diese Ansichten helfen, Muster zu erkennen und die Richtung des Problems zu bestimmen.

Offloading‑Effekte verstehen

Begriffe wie TSO (TCP Segmentation Offload), GRO (Generic Receive Offload) und LRO (Large Receive Offload) bedeuten, dass die Netzwerkkarte Teile der TCP‑Arbeit übernimmt. Captures auf dem Host können deshalb übergroße Segmente oder fehlende kleine Segmente zeigen. Bei widersprüchlichen Befunden prüfen Sie das Capture auf einem TAP oder deaktivieren Offloading temporär.

# Offloading (temporär) deaktivieren - Linux
sudo ethtool -K eth0 tso off gso off gro off

Three‑Way‑Handshake analysieren

Der Three‑Way‑Handshake (SYN, SYN‑ACK, ACK) bestätigt, dass eine TCP‑Verbindung aufgebaut werden kann. Scheitert dieser Schritt, kommt es typischerweise gar nicht zu Datenübertragung. Achten Sie auf TCP‑Optionen in SYN/SYN‑ACK: MSS (Maximum Segment Size), Window Scale (Fensterskalierung) und SACK (Selective Acknowledgement) liefern Hinweise auf MTU‑, Fenster‑ und Retransmit‑Probleme.

Prüfsequenz beim Handshake

1. Flow filtern: 5‑Tuple (Client IP, Server IP, Client Port, Server Port, Protokoll).
2. SYN vom Client sichtbar? Kommt ein SYN‑ACK vom Server zurück?
3. Fehlt das finale ACK? Prüfen Sie Capture auf beiden Seiten, um den Rückweg zu verifizieren.

Typische Ursachen bei gescheiterten Handshakes sind Firewall‑ACLs, asymmetrisches Routing (Stateful Box verwirft Antworten), SYN‑Proxy/SYN‑Cookies oder Server‑Limits wie volle Backlogs.

TCP‑Retransmits richtig einordnen

Retransmits sind die Reaktion von TCP auf vermuteten Paketverlust. Wichtige Unterscheidungen:

• Fast Retransmission: Erfolgt nach Duplicate ACKs und deutet auf echten Paketverlust hin.
• RTO Retransmission: Tritt nach einem Timeout auf und wirkt sich stark auf Durchsatz aus.
• Spurious Retransmission: Scheint zu existieren, kann aber durch Reordering oder Capture‑Artefakte entstehen.

Nützliche Display‑Filter

• tcp.analysis.retransmission
• tcp.analysis.fast_retransmission
• tcp.analysis.duplicate_ack
• tcp.analysis.out_of_order
• tcp.analysis.zero_window || tcp.analysis.zero_window_probe

Interpretationstipps: Duplicate ACKs ohne Retransmits deuten auf Reordering (z. B. ECMP) hin. Retransmits ohne Duplicate ACKs können Capture‑Lücken oder echte RTOs sein.

Performance‑Spots: typische Ursachen und Messmuster

Wenn der Handshake erfolgreich ist, bleiben verschiedene Wartezustände, die den Datendurchsatz limitieren. Die häufigsten Ursachen und ihre Signaturen sind:

Hohe RTT und Jitter

Hohe RTT (Round‑Trip‑Time) oder stark schwankender Jitter deuten auf Queueing (volle Puffer), Linküberlastung, WLAN‑Retransmits oder Firewall‑Inspection hin. Im Time‑Sequence‑Graph sehen Sie verlängerte Abstände zwischen Daten‑Segmenten und ACKs.

Zero Window: Host‑ oder Applikationsproblem?

Zero Window bedeutet, dass der Empfänger sein Receive‑Window auf 0 setzt, weil der Anwendungspuffer voll ist. Das ist häufig ein Anwendungs- oder I/O‑Problem (langsame Verarbeitung, Garbage Collection oder blockierende Writes). Nur wenn Netzwerklatenzen so stark sind, dass ACKs verzögert werden, ist es primär ein Netzproblem.

MTU / MSS‑Probleme

Pfad‑MTU‑Probleme (z. B. durch Tunnel wie GRE, VPN oder PPPoE) führen zu Fragmentierung oder zum Drop größerer Segmente, wenn das DF‑Flag gesetzt und ICMP‑Messages blockiert werden. Prüfen Sie MSS im SYN und nutzen Sie DF‑Pings zur Validierung.

# MTU testen (Linux): DF-Flag setzen, Payload anpassen
ping -M do -s 1472 10.20.30.40
# Bei Fehlschlag: iterativ verkleinern

Firewall‑ und NAT‑spezifische Prüfungen

Firewall‑Devices (stateful) und NAT/Conntrack sind häufige Ursachen für scheinbare Paketverluste oder asymmetrische Flows. Hier einige praktische Prüfungen und Kommandos.

Conntrack‑Limits und Timeouts prüfen

Conntrack (Connection Tracking) ist ein Mechanismus in Firewalls, der TCP‑Flows in einer Tabelle verwaltet. Wenn die Tabelle voll oder Timeouts zu kurz sind, werden Sessions verworfen.

# Conntrack-Statistiken (Linux nftables/conntrack-tools)
sudo conntrack -S
# Anzahl der Einträge prüfen
sudo conntrack -L | wc -l

Reduzieren Sie unnötig aggressive Timeouts für etablierte Verbindungen und prüfen Sie Port‑Exhaustion bei NAT‑Maschinen (Source‑Port‑Erschöpfung bei hoher Anzahl an Verbindungen pro IP).

Asymmetrisches Routing erkennen

Wenn Anfragen einen Pfad nehmen und Antworten einen anderen (z. B. wegen ECMP, Pfadänderung oder Multi‑ISP), verwirft eine stateful Firewall Antworten, weil kein State existiert. Zwei Captures (inside/outside) beseitigen schnell die Unsicherheit.

Messgrößen, Schwellen und Monitoring

Für ein nachhaltiges Troubleshooting sollten Sie Kennzahlen definieren und überwachen. Wichtige Metriken:

• Retransmits pro Sekunde und als Prozentwert der gesendeten Pakete
• Duplicate ACKs pro Flow
• Durchschnittliche und 95‑Perzentil RTT
• Zero‑Window‑Events pro Minute
• Conntrack‑Table‑Auslastung

Als Richtwert gilt: Einzelne Retransmits sind normal, beständige Retransmit‑Raten >1–2% des Datenverkehrs deuten auf ein ernstzunehmendes Problem. Schwellen hängen vom Anwendungstyp ab (interaktive Anwendungen sind latenzsensitiv, Bulk‑Transfers toleranter).

Praktische Troubleshooting‑Abläufe

1. Flow isolieren: Conversations → Top Talkers → 5‑Tuple‑Filter setzen.
2. Handshake prüfen: SYN/SYN‑ACK/ACK an beiden Enden vergleichen.
3. Retransmits quantifizieren: tcp.analysis.* Filter nutzen, Anzahl und Richtung bestimmen.
4. Middlebox‑Checks: Conntrack, NAT, Firewall‑Logs und Load‑Balancer‑Health prüfen.
5. Host‑Checks: CPU, IO, Socket‑Buffer, netstat/tcpstat

# Beispiel: TCP-Socket-Statistiken (Linux)
ss -tan state established sport = :443
# Kernel TCP Counters (Rx/Tx/Retransmits)
cat /proc/net/snmp | egrep 'Tcp|TcpExt' -n
# Switchport-Fehler prüfen (Beispiel vendorabhängig)

Änderungen, Tests und Rollback

Änderungen an Firewalls, MTU oder NAT sind wirksam, können aber Nebenwirkungen haben. Folgen Sie diesen Regeln:

• Scope begrenzen: Änderungen zuerst für ein Subnetz, VIP oder Testsegment durchführen.
• Vorher/Nachher: Gleiche Testfälle, gleicher Capture‑Ort, PCAPs sichern.
• Rollback vorbereiten: Konfiguration vor der Änderung exportieren, Zeitbox und Metriken für Rückrollkriterium definieren.

Typische Stolperfallen und wie Sie sie vermeiden

• Capture‑Artefakte: SPAN‑Port Drop, Offloading oder Zeitstempelungen verfälschen die Interpretation. Wenn möglich TAP verwenden oder Offloading deaktivieren.
• Unvollständige Daten: Nur eine Seite capturen führt oft zu Fehlzuweisungen. Zwei Seiten sind die Regel.
• Falsche Filter: Zu breite Filter überfluten, zu enge verbergen Muster. Beginnen Sie breit, dann eingrenzen.
• Datenschutz: Mitschnitte nicht länger als nötig aufbewahren; sensiblen Datenfluss anonymisieren.

Fazit

Dieses Wireshark-Howto liefert eine strukturierte Arbeitsweise: Beginnen Sie mit dem richtigen Capture‑Ort, prüfen Sie den Three‑Way‑Handshake zur Basisvalidierung, quantifizieren Sie Retransmits und ordnen Sie diese anhand ihrer Signaturen ein (Fast Retransmit vs. RTO). Zero Window weist oft auf Host‑ oder Applikationsprobleme, während Duplicate ACKs und Fast Retransmits Netzwerk‑ oder Linkfehler nahelegen. Vor allem bei Firewall‑ und NAT‑Problemen sind synchronisierte Captures an beiden Seiten und Conntrack‑Prüfungen entscheidend. Planen Sie Änderungen mit Rollback und messen Sie vorher/nachher – das reduziert Betriebsrisiken und beschleunigt die Lösung.

Nutzen Sie diese Anleitung als Basis für Runbooks in Ihrem Team: klar definierte Prüfpfade, reproduzierbare Tests und eine enge Abstimmung zwischen Netzwerk-, Firewall‑ und System‑Teams beschleunigen die Fehlerfindung und erhöhen die Zuverlässigkeit Ihrer Produktionsumgebung.

Wireshark-Howto: Capture‑Automation, Zeit‑Synchronisation und SIEM‑Integration

Als Ergänzung zum praktischen Howto lohnt es sich, Capture‑Arbeit in bestehende Betriebsprozesse zu integrieren. Dieses Kapitel beschreibt Architektur‑ und Betriebsaspekte, die in längeren Incident‑Szenarien, bei Compliance‑Anforderungen oder bei wiederkehrenden Performance‑Checks entscheidend sind. Das Fokus‑Keyword Wireshark-Howto hilft, die Anleitung in Ihre Dokumentation zu verorten.

Architektur: zentrale versus temporäre Capture‑Punkte

• Dauerhafte Collector: Eine dedizierte Aggregationsschnittstelle (TAP oder Mirror + dedizierter Capture‑Host) reicht mehrere Tage oder Wochen PCAPs, ermöglicht Langzeit‑Analysen und automatisches Indexing. Vorteil: konsistente Vergleichsgrundlage. Nachteil: Speicher, Datenschutz, und Zugriffskontrolle.
• Ephemere Captures: Kurzzeit‑Captures bei Vorfällen; sie sind flexibel, aber für Trendanalysen weniger geeignet. Kombinieren Sie beides: permanente Metadaten‑Extraktion, kurzfristige vollständige PCAPs bei Alarm.

Zeit‑Synchronisation und Korrelation

Zeitstempel sind das Rückgrat verteilter Analysen. Wenn Hosts und Netzwerk‑Collector nicht synchron sind, lassen sich ACKs, Retransmits und Firewall‑Logs nicht zuverlässig korrelieren. Prüfen Sie die Zeitquelle auf allen beteiligten Geräten:

# NTP/chrony prüfen (Linux)
timedatectl status
# oder für chrony
chronyc tracking

Bei sehr feinen Latenzanalysen kann PTP nötig sein; für typische TCP‑Fehler reicht konsistente NTP‑Synchronisation.

Automatisches Extrahieren von Metriken

Vollständige PCAPs sind groß. Extrahieren Sie automatisiert Kennzahlen (Retransmits, Duplicate ACKs, RTT‑Perzentile) mit tshark und indexieren Sie die Ergebnisse in Ihrem SIEM oder einer Zeitreihen‑DB. Beispiel: Zähle Retransmits pro Flow in einer PCAP.

tshark -r capture.pcap -Y "tcp.analysis.retransmission" 
  -T fields -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport 
  | sort | uniq -c | sort -rn

Die Ausgabe lässt sich per Log‑Forwarder in Elasticsearch/Prometheus überführen und mit Alerting‑Regeln verknüpfen (z. B. Retransmit‑Rate > X% über 5 Minuten).

Containerisierte Umgebungen und Namensräume

In Containerlandschaften sind Interfaces oft kurzlebig (veths, bridge). Captures auf dem Host sehen nicht immer den internen Stack in den Namespaces. Verwenden Sie namespacespezifische Capture‑Agenten oder port‑spiegelnde CNI‑Funktionen, um vollständige Flows zu erhalten.

Sichere Aufbewahrung, Redaction und Compliance

• Setzen Sie klare Aufbewahrungsfristen und automatisierte Löschjobs, um DSGVO/P11D‑Risiken zu minimieren.
• Reduzieren Sie Aufnahmeumfang durch Filter (IP/Port) oder Paketkopf‑Only‑Mode, wenn Payload nicht nötig ist.
• Sichern Sie PCAP‑Archive verschlüsselt und protokollieren Sie Zugriffe.

Operationalisierung / Runbook‑Schritte

1. Alarm definiert → automatischer Snapshot (voller PCAP) auslösen.
2. Metadaten extrahieren (tshark/Zeek) und Dashboard updaten.
3. Erste Analysis: Zeit/Flow‑Korrelation, Retransmit‑Rate, Zero‑Window‑Events.
4. Änderung mit Scope, Metriken und Rollback‑Plan (wie bereits beschrieben) durchführen.

Diese betrieblichen Erweiterungen machen Ihr Wireshark‑Howto reproduzierbar und skalierbar: Automatisierte Extraktion, saubere Zeitbasis und rechtskonforme Aufbewahrung reduzieren Betriebsaufwand und beschleunigen Fehlerbehebung im Team zwischen Netzwerk‑, Firewall‑ und System‑Verantwortlichen.

Für dieses Thema sind auch Tcp Retransmits und Tcp Handshake Analyse wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.