Netzwerk-Forensik & Troubleshooting

Wireshark-Profifilter — Die Filter, die 90 % aller Netzwerkprobleme lösen

Die meisten Administratoren kennen Wireshark, aber nur wenige nutzen die Display-Filter wirklich effektiv. Der Unterschied zwischen einem Anfänger und einem Profi liegt nicht im Tool selbst, sondern in der Fähigkeit, aus Millionen von Paketen genau die relevanten Daten herauszufiltern. Die folgenden Filter decken die häufigsten Netzwerkprobleme ab — von Paketverlust über überlastete Server bis hin zu langsamen DNS-Antworten. Entscheidend ist das Verständnis, was die Filter aufdecken: tcp.analysis.retransmission zeigt erneut gesendete Pakete, wobei eine Retransmission-Rate von über 0,5 % bereits auf ein ernstes Problem hindeutet. tcp.analysis.zero_window offenbart Server, deren Empfangspuffer voll ist — ein klares Zeichen dafür, dass die Anwendung nicht schnell genug Daten aus dem TCP-Stack liest.

Ein oft übersehener, aber extrem wertvoller Filter ist frame.time_delta_displayed > 1, der Lücken in einer Konversation sichtbar macht und damit exakt zeigt, wo Latenz eingeführt wird. In Kombination mit tcp.stream eq N, der eine einzelne TCP-Verbindung isoliert, und der Funktion Statistics > IO Graph mit aktivem Filter lässt sich präzise bestimmen, ob die Verzögerung auf der Client-Seite, im Netzwerk oder beim Server entsteht. Ein weiterer Profi-Trick: Der Display-Filter ip.addr == x erfasst sowohl Quell- als auch Ziel-IP, während der Capture-Filter host x deutlich effizienter arbeitet, da er bereits beim Erfassen filtert und damit die pcap-Datei erheblich kleiner hält.

• tcp.analysis.retransmission: Findet alle TCP-Retransmissions — erneut gesendete Pakete aufgrund von Paketverlust oder Timeout. Eine Rate über 0,5 % deutet auf Probleme hin: defekte Netzwerkkabel, überlastete Switches oder fehlerhafte QoS-Konfigurationen. Kombinieren Sie diesen Filter mit Statistics > IO Graph, um zeitliche Muster zu erkennen.
• tcp.analysis.zero_window: Zeigt Pakete, in denen der Empfänger sein TCP-Window auf 0 setzt — die Anwendung liest nicht schnell genug aus dem Socket-Puffer. Häufige Ursache: Datenbankabfragen blockieren den Application Thread, während weitere Daten eintreffen. Die Lösung liegt nicht im Netzwerk, sondern in der Anwendungsoptimierung.
• tcp.analysis.duplicate_ack: Doppelte ACKs deuten auf Lücken im TCP-Stream hin — der Empfänger bestätigt wiederholt das letzte korrekt empfangene Segment, weil nachfolgende Pakete fehlen. Drei aufeinanderfolgende Duplicate ACKs lösen TCP Fast Retransmit aus. Oft liegt die Ursache bei einem überlasteten Zwischengerät (Switch, Router, Firewall).
• dns.time > 0.5: Filtert DNS-Antworten mit mehr als 500 ms Antwortzeit. Interne DNS-Server sollten unter 50 ms antworten — alles darüber deutet auf Überlastung, fehlerhafte Forwarder-Konfiguration oder unerreichbare autoritätive Server. Prüfen Sie zusätzlich dns.flags.rcode != 0 für fehlgeschlagene DNS-Abfragen.
• http.time > 2: Zeigt HTTP-Antworten, die länger als 2 Sekunden dauern. Kombinieren Sie mit http.host als Spalte, um langsame Zielserver zu identifizieren. Dieser Filter unterscheidet zuverlässig zwischen Netzwerk- und Serverproblemen: Wenn die TCP-Handshake-Zeit normal ist, aber http.time hoch, liegt das Problem beim Backend.
• tls.handshake.type == 1: Filtert alle TLS Client-Hello-Nachrichten und zeigt die angebotenen Cipher Suites, die SNI (Server Name Indication) und die TLS-Version. Unverzichtbar für TLS-Audits: Finden Sie veraltete TLS 1.0/1.1-Verbindungen oder schwache Cipher Suites, die noch im Einsatz sind.
• tcp.flags.syn==1 && tcp.flags.ack==0: Zeigt alle neuen TCP-Verbindungsanfragen (SYN-only). Ideal zum Erkennen von Connection Storms — wenn ein Client hunderte Verbindungen pro Sekunde öffnet, deutet das auf eine fehlerhafte Anwendung, einen Scan oder einen SYN-Flood-Angriff hin. Zählen Sie mit Statistics > Endpoints die Verbindungen pro IP.

TCP/IP-Probleme, die kaum jemand findet

Jenseits der offensichtlichen Netzwerkprobleme gibt es eine Klasse von TCP/IP-Anomalien, die selbst erfahrene Administratoren tagelang beschäftigen können. Diese Probleme sind deshalb so tückisch, weil die Symptome oft irreführend sind: Kleine Datentransfers funktionieren einwandfrei, aber große Dateien bleiben hängen. Verbindungen sind schnell im LAN, aber querlahm über VPN. Ping funktioniert, aber die Anwendung nicht. Die Ursache liegt fast immer in subtilen TCP-Mechanismen, die im Normalbetrieb unsichtbar bleiben und erst unter bestimmten Bedingungen — hohe Latenz, bestimmte Paketgrößen, asymmetrisches Routing — sichtbar werden.

Ein besonders perfides Problem ist die Nagle/Delayed-ACK-Interaktion, auch bekannt als der „40-ms-Latenz-Bug“. Der Nagle-Algorithmus (RFC 896) verzögert kleine ausgehende Pakete, bis ein ACK für das vorherige Paket eintrifft. Gleichzeitig verzögert Delayed ACK (RFC 1122) die Bestätigung um bis zu 40 ms, um mehrere ACKs zu bündeln. Wenn beide Mechanismen zusammenwirken, wartet der Sender auf ein ACK, das der Empfänger erst nach 40 ms sendet — jeder einzelne Request bekommt 40 ms zusätzliche Latenz. Die Lösung ist die Socket-Option TCP_NODELAY auf der Anwendungsseite, die den Nagle-Algorithmus deaktiviert.

Ebenso schwer zu diagnostizieren sind Half-Open-Connections im Status SYN_RECV. Wenn der Befehl netstat -an | grep SYN_RECV tausende Einträge zeigt, liegt entweder ein SYN-Flood-Angriff vor, oder die Connection-Tracking-Tabelle (nf_conntrack_max) läuft voll. Letzteres äußert sich in kryptischen Symptomen: neue Verbindungen scheitern, während bestehende noch funktionieren. Die Lösung: sysctl net.netfilter.nf_conntrack_max prüfen und erhöhen, sowie nf_conntrack_tcp_timeout_established reduzieren.

• MTU/MSS-Clamping bei blockiertem ICMP: Path MTU Discovery (PMTUD) benötigt ICMP „Fragmentation Needed“-Nachrichten, um die maximale Paketgröße auf dem Pfad zu ermitteln. Wenn Firewalls ICMP pauschal blockieren, scheitert PMTUD — kleine Pakete funktionieren, große Transfers hängen („Black Hole“). Lösung: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu oder MSS manuell auf VPN-Interfaces setzen (typisch: 1400 bei IPsec, 1360 bei OpenVPN).
• TCP Window Scaling (RFC 7323): Ältere Firewalls und Load Balancer strippen TCP-Optionen aus dem SYN-Paket, darunter die Window-Scale-Option. Ohne Window Scaling ist das TCP-Fenster auf 64 KB begrenzt — auf Links mit hoher Latenz (z. B. 100 ms) ergibt das maximal 5 Mbit/s Durchsatz, unabhängig von der verfügbaren Bandbreite. Diagnose: Im Wireshark das SYN-Paket prüfen — fehlt die WS-Option, ist ein Zwischengerät der Übeltäter.
• Asymmetrisches Routing mit Stateful Firewalls: Wenn Pakete einer Verbindung in eine Richtung über Firewall A und in die andere Richtung über Firewall B laufen, scheitert die Stateful Inspection: Die Firewall sieht nur die Hälfte der Verbindung und sendet TCP-RST. Lösung: HA-Cluster mit State Synchronization oder gezieltes Deaktivieren der Stateful Inspection für betroffene Flows. Diagnose: Packet Capture auf beiden Firewalls gleichzeitig.
• DNS TTL=0 und Caching-Resolver: Einige CDNs und Cloud-Dienste nutzen TTL=0 für sofortiges Failover. Viele Resolver (insbesondere Windows DNS Server) cachen TTL=0-Antworten dennoch für 30 bis 300 Sekunden. Das Ergebnis: Failover funktioniert im Test, aber nicht in der Produktion, weil der Resolver veraltete Einträge ausliefert. Prüfen Sie MaxCacheTtl und MaxNegativeCacheTtl in der Resolver-Konfiguration.
• Nagle + Delayed ACK — der 40-ms-Bug: Der Nagle-Algorithmus verzögert kleine Sends, bis ein ACK eintrifft. Delayed ACK verzögert ACKs um bis zu 40 ms. Zusammen ergibt sich eine 40 ms Latenz pro Request — bei 25 aufeinanderfolgenden API-Calls summiert sich das auf eine volle Sekunde. Fix: TCP_NODELAY per setsockopt() auf der Anwendungsseite, oder TCP_QUICKACK auf Linux-Systemen.

Profi-Toolchain & Flow-Analyse

Wireshark ist das Standardwerkzeug für tiefe Paketanalyse, aber in Produktionsumgebungen mit Datenraten über 1 Gbit/s ist Full Packet Capture weder praktikabel noch notwendig. Hier kommen Flow-basierte Analysetools ins Spiel: NetFlow v9, sFlow und IPFIX erfassen nur Metadaten — Quell- und Ziel-IP, Ports, Protokoll, Bytes und Pakete pro Flow — und reduzieren das Datenvolumen um den Faktor 500 bis 1000. Tools wie ntopng, Elastiflow (Elasticsearch-basiert) und nfdump/nfsen aggregieren diese Flow-Daten und ermöglichen Top-Talker-Analysen, Bandbreitentrends und Anomalieerkennung in Echtzeit.

Für die Kommandozeile ist tcpdump unverzichtbar — es läuft auf praktisch jedem Linux-System und erfordert keine grafische Oberfläche. Der Einzeiler tcpdump -i eth0 -w /tmp/capture.pcap -G 3600 -W 24 'not port 22' erfasst kontinuierlich Traffic, rotiert die Capture-Datei stündlich (-G 3600), behält maximal 24 Dateien (-W 24) und schließt SSH-Traffic aus, um die eigene Analysesession nicht mitzuschneiden. tshark, die Kommandozeilenversion von Wireshark, eignet sich hervorragend für automatisierte Auswertungen: tshark -r file.pcap -T fields -e ip.src -e ip.dst -e tcp.dstport | sort | uniq -c | sort -rn liefert eine Top-Talker-Liste nach Quell-IP, Ziel-IP und Port.

Neben der passiven Analyse sind aktive Diagnosetools unverzichtbar. nmap kann weit mehr als Port-Scans: nmap -sV --script ssl-enum-ciphers target führt ein vollständiges TLS-Audit durch und zeigt alle unterstützten Cipher Suites mit Bewertung. nmap --script smb-vuln-* prüft auf bekannte SMB-Schwachstellen (EternalBlue, SMBGhost). Das Timing mit -T2 ist für Stealth-Scans geeignet, -T4 für schnelle interne Scans. Für Bandbreitentests ist iperf3 der Standard: iperf3 -c server -P 10 -t 60 testet mit 10 parallelen Streams über 60 Sekunden, und der Vergleich von TCP- vs. UDP-Ergebnissen enthüllt QoS-Shaping-Policies. Der Parameter -R wechselt die Richtung und testet den Rückkanal.

• tcpdump-Einzeiler für Produktion: tcpdump -i eth0 -w /tmp/capture.pcap -G 3600 -W 24 'not port 22' — rollierende 24-Stunden-Erfassung mit stündlicher Rotation. Ohne -W läuft die Festplatte voll. Tipp: -s 96 erfasst nur Header und reduziert die Dateigröße um 90 %, reicht aber für die meisten Analysen aus.
• tshark für Automatisierung: tshark -r file.pcap -T fields -e ip.src -e ip.dst -e tcp.dstport | sort | uniq -c | sort -rn — Top-Talker-Analyse direkt aus der Kommandozeile. Weitere Möglichkeit: tshark -r file.pcap -qz conv,tcp zeigt alle TCP-Konversationen mit Byte-Volumen und Dauer, ideal für die Identifikation von Bandbreitenfressern.
• NetFlow/IPFIX für >1 Gbit/s: Full Packet Capture ist bei hohen Datenraten nicht praktikabel — NetFlow erfasst nur Metadaten (ca. 1/500 des Datenvolumens). Tools: ntopng (Echtzeit-Webinterface), Elastiflow (Elasticsearch/Kibana-Stack), nfdump (CLI-basiert, extrem performant). Konfigurieren Sie NetFlow-Export auf Routern und Switches mit ip flow-export destination.
• nmap jenseits des Port-Scans: nmap -sV --script ssl-enum-ciphers target für TLS-Audit mit Cipher-Suite-Bewertung. nmap --script smb-vuln-* für SMB-Schwachstellenprüfung (EternalBlue, SMBGhost). Timing: -T2 für Stealth (IDS-Evasion), -T4 für schnelle interne Scans. -sn für reinen Host-Discovery ohne Port-Scan.
• iperf3 für Bandbreitentests: iperf3 -c server -P 10 -t 60 (10 parallele Streams, 60 Sekunden). TCP vs. UDP-Vergleich enthüllt QoS-Shaping: Wenn UDP höheren Durchsatz zeigt, greift TCP-spezifisches Traffic Shaping. -R für Reverse-Test (Server sendet, Client empfängt). --bidir für gleichzeitigen bidirektionalen Test.
• mtr (My Traceroute) für Hop-Analyse: mtr -n -c 100 target — 100 Pakete pro Hop, numerische Ausgabe. Besser als traceroute, da mtr kontinuierlich misst und Paketverlust pro Hop in Prozent anzeigt. Ein Hop mit über 5 % Verlust ist problematisch — aber Vorsicht: ICMP-Rate-Limiting auf Routern kann fälschlicherweise Verlust anzeigen. Nur wenn nachfolgende Hops ebenfalls Verlust zeigen, ist das Problem real.
• Wireshark-Profile für Effizienz: Erstellen Sie spezialisierte Profile (Edit > Configuration Profiles): Ein „DNS-Debug“-Profil mit DNS-Spalten und Coloring Rules, ein „Performance“-Profil mit TCP-Delta-Time-Spalte und Retransmission-Markierungen, ein „Security“-Profil mit TLS-Handshake-Details. Profilwechsel geht per Rechtsklick auf die Statusleiste — spart Minuten pro Analyse.