Inhalt des Artikels

Client-Logs sind wunderbar, solange sie etwas aussagen. Doch irgendwann stehst du vor einer Wand: Die Anwendung schreibt lapidar connection reset, der Proxy schweigt in seinen Logs, und der Zielserver beteuert, bei ihm sei alles in Ordnung. Wer lügt? Niemand. Du schaust nur aus dem obersten Stockwerk auf das Problem, während die Wahrheit auf Paketebene lebt. Und dorthin musst du hinabsteigen.

Dieser Artikel ist ein ausführlicher Ingenieurleitfaden für die Arbeit mit tcpdump und Wireshark, wenn der Traffic über einen Proxy läuft. Wir schauen uns an, was ein Beobachter vor und nach dem Proxy sieht, warum innerhalb eines HTTPS-Tunnels nur die CONNECT-Anfrage sichtbar ist und sonst nichts, und wie du anhand eines einzigen Dumps einen Abbruch auf deiner Seite von einem Abbruch beim Zielserver unterscheidest. Hier geht es nicht um Abfangen oder Ersetzen von HTTPS auf Anwendungsebene – es geht um die Paketebene und ehrliche Diagnose von Abbrüchen.

Einleitung: Wenn Client-Logs nicht mehr ausreichen

Stell dir eine typische Infrastruktur vor. Deine Anwendung greift über einen HTTP-Proxy Proxeon auf eine externe API zu. Normalerweise funktioniert alles. Doch fünf Prozent der Anfragen scheitern mit einem Fehler, und du verstehst nicht, warum. Die Anwendungslogs zeigen nur die Tatsache des Abbruchs. Die Proxy-Logs zeigen, dass der Tunnel aufgebaut wurde. Der Zielserver liegt außerhalb deiner Kontrolle. Du steckst zwischen drei Black Boxes fest.

Genau hier beginnt die Paketdiagnose. Ein Traffic-Dump ist das stenografische Protokoll eines Gesprächs zwischen Maschinen, wörtlich aufgezeichnet, ohne Interpretation und ohne das Recht zu lügen. Ein Paket ist entweder angekommen oder nicht. Das RST-Flag ist entweder gesetzt oder nicht. TCP kann nicht vorgeben. Und wenn du lernst, dieses Protokoll zu lesen, hörst du auf zu raten.

Aus diesem Leitfaden erfährst du: wie du mit dem Befehl tcpdump einen Dump ziehst, ohne die Festplatte mit Gigabytes zu fluten; welche Anzeigefilter in Wireshark Stunden sparen; wie du den TLS-Handshake auch ohne Entschlüsselung liest; wie du anhand der Flags den Verursacher des Abbruchs bestimmst; und wie du deinen eigenen Traffic legal über die Variable SSLKEYLOGFILE entschlüsselst. Am Ende erwartet dich eine fertige Checkliste für Supportanfragen und ein ausführliches FAQ.

Grundlagen: Drei Segmente einer Verbindung

Das Erste, was du verinnerlichen musst: Wenn ein Client über einen Proxy arbeitet, ist das nicht eine Verbindung, sondern mindestens zwei verschiedene TCP-Verbindungen. Eine vom Client zum Proxy. Eine vom Proxy zum Zielserver. Das ist das Fundament, ohne das die weitere Analyse sinnlos ist.

Was ein Dump ist und wie er aufgebaut ist

Ein Paket-Dump ist eine Abfolge von Netzwerkpaketen, die an einer bestimmten Netzwerkschnittstelle einer bestimmten Maschine aufgezeichnet wurden. Das Schlüsselwort ist bestimmten. Du siehst immer nur den Traffic, der physisch durch den Aufzeichnungspunkt läuft. Wenn du einen Dump beim Client ziehst, siehst du das Gespräch Client-Proxy. Beim Proxy siehst du beide Seiten. Beim Zielserver nur das Gespräch Proxy-Server.

Jedes Paket trägt Header der Ebenen: Ethernet, IP, TCP oder UDP, und die Nutzlast. Für die Diagnose von Abbrüchen interessiert uns in erster Linie die TCP-Ebene: Portnummern, Sequenznummern (sequence), Bestätigungen (ACK) und die Flags – SYN, ACK, FIN, RST, PSH.

Proxy-Modell: Zwei Verbindungen statt einer

Schauen wir uns das Schema der Traffic-Bewegung bei der Arbeit mit einem HTTP-Proxy im Tunnelmodus an:

  • Segment A (Client – Proxy). Der Client öffnet eine TCP-Verbindung zur IP und zum Port des Proxys. Über diesen Kanal sendet er den Befehl, einen Tunnel aufzubauen.
  • Segment B (Proxy – Zielserver). Der Proxy öffnet in eigenem Namen eine separate TCP-Verbindung zum Zielserver. Das ist eine andere src-IP, ein anderer src-Port, ein anderer Zustand.
  • Logischer Tunnel. Nach dem Aufbau beginnt der Proxy blind, Bytes aus Segment A in Segment B und umgekehrt weiterzuleiten. Er analysiert nicht, was drin steckt.

Warum ist das für die Diagnose wichtig? Weil der Abbruch in jedem der beiden Segmente auftreten kann und das Symptom aus Sicht des Clients gleich aussieht – die Verbindung ist zusammengebrochen. Aber die Ursache, und damit die Lösung, ist unterschiedlich.

HTTP-Proxy, SOCKS und Tunneling

Bei einer normalen HTTP-Anfrage ohne Verschlüsselung sieht der Proxy sowohl Methode als auch URL und Header. Doch sobald es um HTTPS geht, ändert sich das Bild. Der Client kann dem Proxy keine unverschlüsselte Anfrage übergeben – sonst ginge der Sinn der Verschlüsselung verloren. Deshalb kommt der Tunnelmechanismus zum Einsatz: Der Client sagt dem Proxy verbinde mich mit diesem Host an diesem Port und mische dich dann nicht ein. Dieser Befehl ist CONNECT.

Deep Dive: Warum im Tunnel nur CONNECT sichtbar ist

Das ist wohl die häufigste Quelle des Erstaunens bei Ingenieuren, die zum ersten Mal einen Dump von HTTPS-Traffic über einen Proxy öffnen. Man erwartet Anfragen und Antworten zu sehen, und sieht eine Zeile und danach unleserlichen Brei. Lass uns klären, warum das so ist und warum es richtig ist.

Anatomie von CONNECT

Wenn ein Client über einen Proxy eine geschützte Verbindung aufbauen möchte, sendet er dem Proxy folgende Anfrage im Klartext:

CONNECT api.example.com:443 HTTP/1.1\r\nHost: api.example.com:443\r\n\r\n

Der Proxy öffnet eine TCP-Verbindung zu api.example.com auf Port 443, und wenn alles geklappt hat, antwortet er dem Client:

HTTP/1.1 200 Connection established\r\n\r\n

Ab diesem Moment verwandelt sich der Proxy in ein stumpfes Rohr. Alles, was der Client danach sendet, leitet der Proxy Byte für Byte an den Server weiter und umgekehrt. Und was sendet der Client als Nächstes? TLS ClientHello, den Beginn des Handshakes. Verschlüsselter Austausch. Der Proxy hat keine Schlüssel und kann physisch nicht hineinschauen.

Was das für den Beobachter mit Dump bedeutet

Wenn du einen Dump beim Client oder beim Proxy ziehst, siehst du:

  • Den Aufbau der TCP-Verbindung zum Proxy (SYN, SYN-ACK, ACK).
  • Den Klartext der CONNECT-Anfrage mit dem Namen des Zielhosts und dem Port.
  • Die Antwort des Proxys über den Status des Tunnelaufbaus.
  • Und danach nur noch TLS-Records, einen verschlüsselten Strom, aus dem mit bloßem Auge nur die Metadaten des Handshakes lesbar sind.

Hier ist die zentrale Erkenntnis: Der Name des Zielhosts ist im Dump immer sichtbar – in der CONNECT-Zeile. Selbst ohne ein einziges entschlüsseltes Byte weißt du, wohin genau der Client zu gelangen versuchte. Das ist bei der Diagnose unbezahlbar: Damit entfällt sofort die Frage, ob die Anfrage überhaupt dorthin ging.

TLS SNI: Eine zweite Quelle des Hostnamens

Selbst wenn es kein CONNECT gäbe (etwa bei einer direkten Verbindung ohne Proxy), ist der Hostname oft im Feld SNI innerhalb des ClientHello sichtbar. Server Name Indication wird zu Beginn des Handshakes im Klartext übertragen. Wireshark zeigt ihn wunderbar an. In modernen Netzen gewinnt Encrypted Client Hello an Bedeutung, das SNI verbirgt, doch bei der Arbeit über einen CONNECT-Tunnel behindert das die Diagnose nicht – der Hostname wurde ja bereits im CONNECT genannt.

tcpdump in der Praxis: Dump ziehen ohne Gigabytes

Jetzt geht's an die Handarbeit. tcpdump ist ein Kommandozeilen-Tool zum Paketmitschnitt, das fast in jedem Unix-ähnlichen System verfügbar ist. Es ist mächtig, leichtgewichtig und unverzichtbar auf Servern ohne Grafik. Schauen wir uns die wichtigsten Szenarien an.

Basis-Mitschnitt auf der richtigen Schnittstelle

Zuerst schauen wir uns die Liste der Schnittstellen an:

tcpdump -D

Mitschnitt auf einer bestimmten Schnittstelle mit Ausgabe auf dem Bildschirm:

tcpdump -i eth0 -n

Das Flag -n deaktiviert die Namensauflösung, damit tcpdump nicht bei DNS-Anfragen bremst und saubere IPs zeigt. Das ist wichtig: Echtzeit-Resolver verzerrt das Bild und verlangsamt den Mitschnitt.

Filterung nach Host und Port

Den gesamten Traffic einer Schnittstelle auf einem ausgelasteten Server mitzuschneiden, ist der sichere Weg zu Gigabytes Müll. Filtere von Anfang an. Mitschnitt des Traffics zu einem bestimmten Proxy nach IP und Port:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080

Mitschnitt nur zum Zielserver (nützlich auf der Proxy-Seite):

tcpdump -i eth0 -n host api.example.com and port 443

Kombination: Traffic zum Proxy ODER zum Zielserver:

tcpdump -i eth0 -n "(host 203.0.113.10 and port 8080) or (host 198.51.100.5 and port 443)"

Achte auf die Anführungszeichen: Wenn im Ausdruck Klammern und logische Operatoren vorkommen, umschließe den Filter mit Anführungszeichen, damit die Shell die Sonderzeichen nicht interpretiert.

Schreiben in eine Datei und das richtige Format

Für die spätere Analyse in Wireshark brauchst du eine Datei im pcap-Format. Das Flag -w schreibt rohe Pakete in eine Datei:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -w dump.pcap

Ein äußerst wichtiger Punkt: -s 0 oder das moderne Standardverhalten erfasst das Paket vollständig (snaplen). Alte Versionen schnitten Pakete ab. Wenn du vollständige Daten brauchst, stelle sicher, dass snaplen ausreicht:

tcpdump -i eth0 -n -s 0 host 203.0.113.10 and port 8080 -w dump.pcap

Wenn du nur die Header für die Diagnose von Abbrüchen brauchst (Flags, seq, ack) und nicht den Inhalt, begrenze snaplen, damit die Datei kompakter wird:

tcpdump -i eth0 -n -s 96 host 203.0.113.10 and port 8080 -w headers.pcap

Dateirotation: Wie du die Festplatte nicht flutest

Bei langwieriger Diagnose eines intermittierenden Problems kann der Mitschnitt Stunden dauern. Damit du nicht eine monströse Datei bekommst, nutze die Rotation nach Größe und Anzahl der Dateien. Das Flag -C legt die Dateigröße in Megabyte fest, -W die Anzahl der Dateien im Ringpuffer:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -w dump-%Y%m%d-%H%M%S.pcap -C 100 -W 10

Dieser Befehl erstellt bis zu zehn Dateien à einhundert Megabyte. Wenn die zehnte voll ist, beginnt tcpdump, die erste zu überschreiben. So behältst du immer das etwa letzte Gigabyte Traffic und überfüllst nie die Festplatte. Das Zeitmuster im Dateinamen macht das Archiv lesbar.

Alternative – Rotation nach Zeit. Das Flag -G legt ein Intervall in Sekunden fest, nach dem eine neue Datei erstellt wird:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -G 3600 -w dump-%Y%m%d-%H%M%S.pcap

Jede Stunde eine neue Datei. Praktisch, wenn du später schnell das Zeitintervall des Vorfalls finden musst.

Mitschnitt rund um das Ereignis: Ein seltenes Abbruch einfangen

Die tückischste Situation – das Problem reproduziert sich einmal pro Stunde und unvorhersehbar. Du startest den Ringpuffer und wartest. Sobald die Anwendung einen Fehler protokolliert, notierst du die genaue Zeit und stoppst den Mitschnitt. Dann gehst du in der Analyse zur richtigen Sekunde. Praktischer Trick: Lass die Anwendung bei einem Fehler einen genauen Zeitstempel mit Millisekunden ins Log schreiben – das ist dein Anker im Dump.

Filter nach TCP-Flags direkt in tcpdump

Manchmal ist es nützlich, nur Pakete mit bestimmten Flags aufzuzeichnen. Zum Beispiel nur Pakete mit dem RST-Flag, um sofort zu sehen, ob Resets fliegen:

tcpdump -i eth0 -n "tcp[tcpflags] & tcp-rst != 0"

Nur SYN-Pakete – praktisch, um Versuche nachzuverfolgen, eine Verbindung aufzubauen:

tcpdump -i eth0 -n "tcp[tcpflags] & tcp-syn != 0"

Die Kombination RST oder FIN zur Überwachung von Verbindungsabschlüssen zum Proxy:

tcpdump -i eth0 -n "host 203.0.113.10 and (tcp[tcpflags] & (tcp-rst|tcp-fin) != 0)"

Wireshark: Den Dump wie ein offenes Buch lesen

tcpdump fängt, Wireshark liest. Es ist ein grafischer Analysator mit einem reichhaltigen System von Anzeigefiltern und Protokolldecodern. Du öffnest die gespeicherte pcap-Datei und beginnst die Untersuchung. Schauen wir uns die Tools an, die für unsere Aufgabe wirklich gebraucht werden.

Anzeigefilter versus Capture-Filter

Wichtig, sie nicht zu verwechseln. Der Capture-Filter (der in tcpdump) trennt Pakete vor der Aufzeichnung heraus – was nicht eingefangen wurde, ist nicht da. Der Anzeigefilter in Wireshark ist eine Linse: Er blendet nur Überflüssiges aus der bereits geladenen Datei aus, ohne etwas zu löschen. Die Syntax unterscheidet sich. Im Folgenden sind es Anzeigefilter.

Basis-Anzeigefilter

Nur Traffic zu einer bestimmten IP anzeigen:

ip.addr == 203.0.113.10

Nur TCP-Port des Proxys:

tcp.port == 8080

Kombination von Host und Port:

ip.addr == 203.0.113.10 && tcp.port == 8080

Nur Pakete mit dem RST-Flag anzeigen – alle Verbindungsresets sofort sichtbar:

tcp.flags.reset == 1

Nur Pakete mit FIN:

tcp.flags.fin == 1

Nur SYN ohne ACK – Versuche, eine Verbindung zu öffnen:

tcp.flags.syn == 1 && tcp.flags.ack == 0

CONNECT und HTTP-Header finden

Um die CONNECT-Anfrage selbst im Dump zu finden:

http.request.method == "CONNECT"

Die Antwort des Proxys über den Tunnelaufbau erscheint als HTTP-Antwort. Alle HTTP-Anfragen filtern:

http.request

Alle HTTP-Antworten mit Codes:

http.response

Follow TCP Stream: Das Gespräch zusammensetzen

Das ist womöglich die wertvollste Wireshark-Funktion für unsere Aufgabe. Rechtsklick auf ein beliebiges Paket der Verbindung, dann Follow, dann TCP Stream. Wireshark sammelt den gesamten bidirektionalen Austausch in einem Fenster, in dem Daten von Client und Server in verschiedenen Farben dargestellt werden. Bei unverschlüsseltem Traffic siehst du reinen Text: die CONNECT-Anfrage, die Antwort des Proxys und danach unleserliche TLS-Bytes.

Genau in Follow Stream siehst du den Abbruch auf CONNECT anschaulich. Die ersten Zeilen lesen sich wie menschlicher Text, dann beginnt der verschlüsselte Bereich. Das bestätigt: Der Tunnel ist aufgebaut, danach läuft Verschlüsselung, und ohne Schlüssel kommst du nicht tiefer – was völlig normal ist.

Den TLS-Handshake ohne Entschlüsselung lesen

Selbst ohne Schlüssel erzählt der TLS-Handshake viel. Filtere die Handshake-Records:

tls.handshake

ClientHello finden, wo sich der Client dem Server vorstellt:

tls.handshake.type == 1

ServerHello finden, die Antwort des Servers:

tls.handshake.type == 2

Was bringt dieses Paar? Wenn du ClientHello siehst, aber nie ServerHello – der Server hat nicht auf den Handshake geantwortet. Ursache: Entweder ist der Zielserver hinter dem Proxy nicht erreichbar, oder der Abbruch erfolgte vor der Antwort. Wenn du beide siehst, aber danach einen Abbruch – das Problem liegt tiefer, bereits im verschlüsselten Austausch oder auf Anwendungsebene.

Innerhalb des ClientHello ist ohne jede Entschlüsselung das SNI-Feld lesbar – der Hostname, an den die Anfrage geht:

tls.handshake.extensions_server_name == "api.example.com"

Du siehst auch die angebotenen TLS-Versionen und Cipher Suites. Wenn der Server mit einem Alert statt mit ServerHello antwortet, wurde der Handshake abgelehnt – etwa wegen Inkompatibilität von Versionen oder Ciphers. Filter für Alerts:

tls.alert_message

Diagnose per Dump: Wer hat die Verbindung tatsächlich abgebrochen

Wir sind beim Herzstück des Artikels angekommen. Die Verbindung ist zusammengebrochen – die Frage ist, wer sie abgebrochen hat und warum. TCP hinterlässt Spuren, und anhand dieser lässt sich ein Urteil fällen. Schauen wir uns die wichtigsten Signale an.

Normales Ende: FIN

Das ordnungsgemäße Schließen einer Verbindung erfolgt über den Austausch von FIN-Paketen. Eine Seite sagt ich habe mit dem Senden fertig, die andere bestätigt und sendet ebenfalls FIN. Das ist ein höflicher Abschied. Wenn du im Dump einen sauberen Austausch FIN-ACK-FIN-ACK siehst, wurde die Verbindung korrekt geschlossen. Die Frage ist nur, ob dein Client dieses Schließen erwartet hat. Wenn der Server FIN gesendet hat, nachdem er die Antwort vollständig geliefert hat, ist alles gut. Wenn FIN mitten in den erwarteten Daten kam – der Server hat vorzeitig geschlossen.

Abruptes Ende: RST

Das RST-Flag ist ein grober Abbruch. Kein Abschied, sondern ein Türenknallen. RST bedeutet: Diese Verbindung ist ungültig, vergiss sie sofort. Die Ursachen können unterschiedlich sein:

  • Port geschlossen – niemand hört auf der anderen Seite. RST kommt fast sofort nach SYN.
  • Die Anwendung auf der anderen Seite hat den Socket abgebrochen geschlossen.
  • Ein Zwischengerät (Firewall, Load Balancer, der Proxy selbst) hat die Verbindung wegen Timeout oder Policy zwangsweise zurückgesetzt.
  • Eine der Seiten hat ein Paket für eine Verbindung erhalten, die sie bereits vergessen hat.

Der Schlüssel zum Rätsel – wer hat RST gesendet. Schau auf die Source-IP des Pakets mit RST. Wenn RST von der IP des Proxys kommt – der Proxy oder etwas zwischen Proxy und dir hat abgebrochen. Wenn von der IP des Zielservers – dann ist das Segment Proxy-Server bis zum Server gelangt, und er oder ein Gerät in seiner Nähe hat abgebrochen.

Aber denk an die zwei Segmente. Wenn du den Dump beim Client ziehst, siehst du RST nur von der IP des Proxys, weil du nicht direkt mit dem Server kommunizierst – zwischen euch liegt der Proxy. Um zu verstehen, was in Segment B vor sich geht, brauchst du einen Dump auf der Proxy-Seite. Darüber sprechen wir im Abschnitt zur Checkliste.

Wiederholte Übertragungen: Retransmission

Wireshark markiert wiederholte Übertragungen automatisch. Filter:

tcp.analysis.retransmission

Eine Retransmission bedeutet, dass der Sender kein ACK für das gesendete Segment rechtzeitig erhalten hat und es erneut sendet. Einzelne Retransmissionen sind für das Internet normal. Aber eine Lawine von Retransmissionen ist ein Symptom für Paketverlust auf dem Weg. Besonders typisch für mobile und instabile Netze.

Verwandte nützliche Filter. Duplikate ACK, die auf ein verlorenes Segment hinweisen:

tcp.analysis.duplicate_ack

Alle problematischen Ereignisse, die Wireshark erkennen konnte:

tcp.analysis.flags

Wenn du eine Serie von Retransmissionen siehst, gefolgt von RST, ergibt sich das Bild: Pakete gingen verloren, eine Seite hat das Warten satt und die Verbindung abgebrochen. Das ist eine typische Geschichte für einen schlechten Kanal.

Zero Window: Der Empfänger ist überfordert

TCP hat einen Mechanismus zur Flusskontrolle über das Empfangsfenster. Wenn der Empfänger mit der Verarbeitung nicht nachkommt, meldet er zero window – Puffer voll, brems dich. Filter:

tcp.analysis.zero_window

Zero Window ist kein Netzwerkverlust, sondern ein Signal, dass die empfangende Anwendung langsam aus dem Socket liest. Zum Beispiel empfängt dein Client eine große Antwort, verarbeitet sie aber in einem einzigen Thread und kommt nicht hinterher. Der Sender wartet, das Fenster öffnet sich nicht, und irgendwann kann ein Timeout greifen. Wenn nach Zero Window ein Window Update kommt, hat sich alles normalisiert. Wenn nach Zero Window Stille herrscht und dann RST folgt – der Empfänger ist hängen geblieben oder abgestürzt.

Ein verwandtes Signal – Window Full, wenn der Sender an das angekündigte Fenster stößt und nicht weiter senden kann:

tcp.analysis.window_full

Urteilsmatrix

Fassen wir die Logik in einem praktischen Framework zusammen. Schau auf die letzten Pakete der lebenden Verbindung vor dem Abbruch:

  • SYN vorhanden, SYN-ACK fehlt, danach RST oder Stille. Die Verbindung wurde nicht aufgebaut. Der Zielpunkt ist unerreichbar oder der Port geschlossen. Bei der Arbeit über einen Proxy kommt RST vom Proxy, wenn der Server dahinter unerreichbar ist.
  • Aufbau geklappt, CONNECT gesendet, keine Antwort. Der Proxy hat den Befehl angenommen, konnte aber den Zielserver nicht erreichen oder dieser schweigt. Warte auf den Timeout.
  • ClientHello vorhanden, ServerHello fehlt. Der Zielserver hat nicht auf den Handshake geantwortet. Das Problem liegt im Segment Proxy-Server.
  • Daten liefen, dann RST vom Server. Der Server hat die Verbindung abrupt geschlossen – Überlastung, Anwendungsfehler, Timeout auf seiner Seite.
  • Daten liefen, dann FIN vom Server mitten in der Antwort. Der Server hat ordnungsgemäß geschlossen, aber früher als der Client erwartet hat – wahrscheinlich ein Limit für die Antwortgröße oder ein Timeout der Anfrage.
  • Lawine von Retransmissionen, dann RST. Verluste im Kanal. Suche das Problem im Netz – mobile Verbindung, überlastete Route.
  • Zero Window, dann Stille. Dein Client hat die Daten nicht schnell genug gelesen. Das Problem liegt auf deiner Seite in der Verarbeitung.

Eigenen Traffic über SSLKEYLOGFILE entschlüsseln

Manchmal reichen die Metadaten nicht aus – du musst den Inhalt des verschlüsselten Austauschs sehen. Das ist legal und korrekt nur dann, wenn der Traffic dein eigener ist: dein Client, deine Schlüssel, deine Anwendung. Wir fangen nichts Fremdes ab und ersetzen keine Zertifikate. Wir bitten unseren eigenen Client freundlich, Sitzungsschlüssel in eine Datei zu schreiben, um sie dann Wireshark zu füttern.

Wie das funktioniert

Viele TLS-Clientbibliotheken unterstützen die Umgebungsvariable SSLKEYLOGFILE. Wenn sie gesetzt ist, schreibt die Bibliothek Sitzungsgeheimnisse im Standardformat in die angegebene Datei. Wireshark kann diese Datei lesen und die entsprechenden Sitzungen im Dump entschlüsseln. Keine Magie und kein Hack – der Client gibt freiwillig seine Schlüssel heraus, weil du, der Eigentümer des Clients, es so angeordnet hast.

Beispiel für die Kommandozeile und Browser auf einer unterstützenden Engine

Setzen der Variable vor dem Start der Anwendung in einem Unix-ähnlichen System:

export SSLKEYLOGFILE=/home/user/tls-keys.log

Start des Clients, etwa curl, der diese Variable unterstützt, wenn er mit einer passenden Bibliothek gebaut wurde:

SSLKEYLOGFILE=/home/user/tls-keys.log curl -x http://203.0.113.10:8080 https://api.example.com/status

Hier legt das Flag -x den Proxy Proxeon fest, und SSLKEYLOGFILE erzwingt das Schreiben der Sitzungsschlüssel. Parallel ziehst du einen Dump mit tcpdump. Danach hast du sowohl pcap als auch die Schlüsseldatei.

Schlüssel in Wireshark einbinden

Öffne in Wireshark die Einstellungen, finde den Abschnitt zum TLS-Protokoll und gib den Pfad zur Schlüsseldatei im Feld für die Pre-Master-Secret-Logdatei an. Danach lies den Dump neu ein. Zuvor unleserliche TLS-Records werden entschlüsselt: Du siehst die tatsächlichen HTTP-Anfragen und -Antworten innerhalb des Tunnels. Nun zeigt Follow TLS Stream den Anwendungsaustausch vollständig.

Wichtige Grenzen der Anwendbarkeit

  • Entschlüsselt wird nur der Traffic, dessen Schlüssel in der Datei gelandet sind. Fremde Sitzungen bleiben verschlüsselt – und das ist richtig so.
  • Schlüssel sind sensibel. Die Datei tls-keys.log öffnet faktisch den Inhalt deiner Sitzungen. Bewahre sie wie ein Geheimnis auf, lösche sie nach dem Debugging.
  • Die Methode ist für das Debugging eigener Anwendungen gedacht, nicht für die Beobachtung fremden Traffics. Das ist eine prinzipielle ethische und rechtliche Grenze.

Typische Abbruchbilder und wie man sie liest

Theorie ohne erkennbare Muster verfliegt schnell. Schauen wir uns einige charakteristische Szenarien an, die dir immer wieder begegnen werden. Lerne, sie auf den ersten Blick zu erkennen.

Konnekt-Timeout: Server hinter dem Proxy unerreichbar

Das Bild im Dump beim Client: TCP zum Proxy ist normal aufgebaut, der Client hat CONNECT gesendet, und dann Stille. Es gibt keine 200-Antwort vom Proxy. Nach einiger Zeit kommt entweder RST vom Proxy oder die Anwendung schließt die Verbindung selbst wegen ihres Timeouts.

Was das bedeutet: Der Proxy hat deinen Befehl angenommen, versucht, Segment B zum Zielserver zu öffnen, aber dieser hat nicht geantwortet. Der Zielserver liegt danieder, der Port ist geschlossen oder die Route dorthin ist unterbrochen. Deine Seite und der Proxy arbeiten ordnungsgemäß. Aktion: Erreichbarkeit des Zielhosts prüfen, bei Bedarf einen Dump auf der Proxy-Seite ziehen, um Segment B zu sehen.

Abbruch mitten in der Antwort

Bild: Tunnel aufgebaut, TLS funktionierte, Daten flossen, ein Teil der Antwort ist angekommen, und plötzlich FIN oder RST von der Serverseite. Der Client hat eine unvollständige Antwort erhalten und beschwert sich über abgeschnittenen Inhalt.

Wenn es FIN ist, hat der Server ordnungsgemäß geschlossen, aber vorzeitig – vielleicht griff ein Zeitlimit für die Antwortgenerierung oder eine Größenbeschränkung auf seiner Seite. Wenn es RST ist, haben der Server oder ein Gerät in seiner Nähe abrupt abgebrochen. Aktion: Wenn das Problem sich bei großen Antworten wiederholt – nach Timeouts und Limits suchen. Die Entschlüsselung des eigenen Traffics über SSLKEYLOGFILE hilft zu sehen, ob der HTTP-Header empfangen wurde und wie viel Body angekommen ist.

Verluste im Mobilfunknetz

Bild: Zahlreiche Pakete sind als Retransmission markiert, Duplikate ACK treten auf, deutliche Zeitsprünge zwischen Paketen sind zu beobachten. Die Verbindung ist entweder quälend langsam oder bricht schließlich per Timeout ab.

Das ist Klassiker eines instabilen Funkkanals. Pakete gehen verloren, TCP sendet sie erneut, die Geschwindigkeit sinkt. Mobile Netze neigen zudem dazu, lange untätige Verbindungen durch NAT-Timeouts der Zwischengeräte des Betreibers zu trennen: Mitten in der Stille kommt plötzlich ein RST, wenn eine Seite den Austausch über eine Verbindung fortsetzen will, die der Betreiber längst vergessen hat. Aktion: Vernünftige Keep-Alive- und Timeout-Werte einstellen, Wiederholungsversuche auf Anwendungsebene, keine langen untätigen Verbindungen halten.

Proxy überhaupt nicht erreichbar

Bild: Der Client sendet SYN an IP und Port des Proxys, erhält aber kein SYN-ACK. Entweder Stille und SYN-Retransmissionen, oder ein sofortiges RST. Bei Stille – zwischen dir und dem Proxy filtert etwas die Pakete oder der Proxy hört nicht. Bei sofortigem RST – auf diesem Port antwortet niemand. Aktion: Adresse und Port des Proxys prüfen, die Netzwerkerreichbarkeit, die Korrektheit der Konfiguration.

Langsamer Client: Zero Window

Bild: Der Austausch läuft, aber periodisch meldet der Client Zero Window, der Sender pausiert, dann setzt ein Window Update den Strom fort. Wenn das häufig wiederkehrt, liest deine Anwendung langsamer aus dem Socket, als der Server liefert. Aktion: Die Verarbeitung der Antwort optimieren, den Strom in einem separaten Thread lesen, Puffer vergrößern.

Typische Fehler beim Ziehen und Lesen von Dumps

Erfahrung ist eine Sammlung von Beulen. Fassen wir die häufigsten Fehler zusammen, damit du sie nicht wiederholst.

  • Den Dump an der falschen Stelle ziehen. Du suchst einen Abbruch im Segment Proxy-Server, hast aber den Dump beim Client gezogen, wo dieses Segment überhaupt nicht sichtbar ist. Denk immer daran, welches Segment du brauchst, und ziehe den Dump an der richtigen Stelle.
  • Alles aufzeichnen. Ohne Filter auf einem ausgelasteten Server bekommst du Gigabytes und ertrinkst darin. Filtere von Anfang an nach Host und Port.
  • Abgeschnittenes snaplen, wo Daten benötigt werden. Wenn du den Inhalt sehen willst und ein kurzes snaplen gesetzt hast, wird die Nutzlast abgeschnitten und Follow Stream zeigt Fragmente.
  • Namensauflösung aktiviert. Das Flag -n vergessen, und tcpdump bremst bei DNS, verzerrt die Timings. Immer -n beim Mitschnitt.
  • Die Richtung von RST ignorieren. Man sieht RST und zieht einen Schluss, ohne zu schauen, wer es gesendet hat. Die Source-IP des RST-Pakets ist die halbe Antwort.
  • Ordentliches FIN mit einem Absturz verwechseln. FIN ist ein normales Schließen. Panik ist nicht wegen des FIN selbst angebracht, sondern wegen eines FIN, das früher als das erwartete Ende der Daten kommt.
  • Zeitzonen und genaue Zeit vergessen. Anwendungslogs und Dump müssen zeitlich synchronisiert sein, sonst findest du den richtigen Moment nicht. Halte NTP in Ordnung.
  • Die Schlüsseldatei SSLKEYLOGFILE aufbewahren. Nach dem Debugging muss sie gelöscht werden. Sie ist ein Geheimnis, das den Inhalt deiner Sitzungen offenlegt.
  • Schlüsse aus einer einzigen Verbindung ziehen. Intermittierende Probleme erfordern Statistik. Eine einzelne gescheiterte Anfrage kann Zufall sein, ein Muster aus einem Dutzend – eine Diagnose.

Werkzeuge und Ressourcen des Ingenieurs

Fassen wir das Arsenal zusammen, das du bei der Arbeit mit Proxy-Traffic zur Hand haben solltest.

Mitschnitt

  • tcpdump – das Hauptwerkzeug für den Mitschnitt auf Servern und in der Konsole. Leichtgewichtig, immer verfügbar, flexibler Filter.
  • dumpcap – das Konsolenwerkzeug aus dem Wireshark-Paket, speziell für effizienten Mitschnitt mit Rotation optimiert.
  • tshark – die Konsolenversion von Wireshark. Ermöglicht die Anwendung von Anzeigefiltern ohne Grafik, praktisch für Skripte und entfernte Server.

Analyse

  • Wireshark – grafischer Analysator, Decoder für Hunderte Protokolle, mächtiges Filtersystem, Follow Stream, Statistiken zu Verbindungen.
  • Wireshark Expert Information – die eingebaute Leiste, die Anomalien hervorhebt: Retransmissionen, Resets, Zero Window. Beginne die Untersuchung genau damit.
  • Conversations-Statistik – die Tabelle aller TCP-Verbindungen im Dump mit Bytes und Dauer. Schnell sieht man, welche Verbindung anormal kurz ist.

Nützliche Kommandozeilentricks

Den Inhalt einer pcap in der Konsole schnell mit tshark und einem Anzeigefilter anzeigen:

tshark -r dump.pcap -Y "tcp.flags.reset == 1"

Nur die CONNECT-Anfragen aus der Datei ausgeben:

tshark -r dump.pcap -Y "http.request.method == \"CONNECT\""

Alle Retransmissionen anzeigen:

tshark -r dump.pcap -Y "tcp.analysis.retransmission"

Diese Befehle sind unbezahlbar, wenn es keine Grafik gibt und du dich hier und jetzt per ssh kümmern musst.

Fälle und Ergebnisse aus der Praxis

Nichts überzeugt besser als echte Geschichten. Ich führe Sammelfälle auf, die die reale Ingenieurpraxis der Diagnose von Proxy-Traffic widerspiegeln.

Fall 1: Fünf Prozent der Anfragen scheitern nachts

Das Integrationsteam klagte: Etwa fünf Prozent der Anfragen an eine externe API über den Proxy scheiterten mit abgeschnittener Antwort, überwiegend nachts. Die Anwendungslogs zeigten unvollständigen Inhalt. Die Proxy-Logs – aufgebaute Tunnel ohne Fehler.

Wir zogen einen Dump beim Client mit Ringrotation über mehrere Stunden und der genauen Fehlermarkierung aus dem Log. Im Moment des Vorfalls sahen wir: Tunnel aufgebaut, TLS funktionierte, ein Teil des Antwort-Bodys kam, dann FIN vom Proxy. Die Entschlüsselung des eigenen Traffics über SSLKEYLOGFILE zeigte: Der HTTP-Header kam korrekt mit Angabe der Body-Größe, aber der Body brach in der Mitte ab. Schlussfolgerung: Der Zielserver schloss die Verbindung wegen seines Timeouts für die Generierung großer Nachtberichte. Die Lösung auf der Integrationsseite – die Daten seitenweise in kleineren Portionen anfordern. Das Problem verschwand vollständig.

Fall 2: Ein rätselhaftes sofortiges RST

Ein anderer Ingenieur erhielt sofortigen Reset direkt nach dem Senden von CONNECT für einen bestimmten Host, während für andere Hosts alles funktionierte. Der erste Verdacht fiel auf den Proxy.

Der Dump beim Client zeigte: CONNECT ging raus, und fast sofort kam RST von der IP des Proxys. Doch die Sofortigkeit war verdächtig – üblicherweise gibt eine Unerreichbarkeit des Servers einen Timeout, nicht einen sofortigen Reset. Wir zogen einen Dump auf der Proxy-Seite und sahen Segment B: Der Proxy öffnete eine Verbindung zum Zielhost am benötigten Port, und der Zielserver antwortete mit RST auf SYN – der Port war geschlossen. Der Proxy übertrug diese Ablehnung ehrlich an den Client. Es stellte sich heraus, dass der Zieldienst kürzlich den Port gewechselt hatte. Schlussfolgerung: Ein sofortiges RST ist meist ein geschlossener Port, nicht ein Problem des Proxys. Der richtige Port stellte die Funktion wieder her.

Fall 3: Degradation im Mobilsegment

Eine Anwendung auf Mobilgeräten, die über einen Proxy arbeitet, verlor bei einem Teil der Nutzer regelmäßig die Verbindung. Ein Dump vom Gerät in einer Problemzone der Abdeckung zeigte das klassische Bild: Serien von Retransmissionen, Duplikate ACK, wachsende Intervalle und am Ende RST nach langer Untätigkeit – das Ergebnis eines NAT-Timeouts beim Betreiber.

Schlussfolgerung: das Netz, nicht der Proxy und nicht der Server. Die Lösung – auf Anwendungsebene wurden adaptive Wiederholungsversuche, vernünftige Keep-Alives und eine grazile Behandlung von Abbrüchen mit Neuaufbau der Verbindung eingeführt. Die Zahl der für den Nutzer sichtbaren Fehler sank um ein Vielfaches, obwohl der Funkkanal derselbe blieb. Der Paket-Dump ermöglichte es, keine Zeit mit falschen Hypothesen über den Proxy zu verschwenden und sich auf die reale Ursache zu konzentrieren.

Die gemeinsame Erkenntnis aus den Fällen

In allen drei Geschichten sparte der Dump Wochen der Korrespondenz und gegenseitiger Schuldzuweisungen zwischen den Teams. Pakete lügen nicht. Sobald ein Dump mit der Richtung von RST, dem Vorhandensein oder Fehlen von ServerHello und dem Bild der Retransmissionen auf dem Tisch liegt, ist der Streit über den Verursacher in Minuten beendet. Das ist der eigentliche Wert der Methode: Sie überführt die Diagnose von der Ebene der Meinungen in die Ebene der Fakten.

Checkliste für das Ziehen eines Dumps für eine Supportanfrage

Wenn du den Support kontaktierst – sei es der Proxy-Anbieter Proxeon oder der Inhaber der Ziel-API – beschleunigt ein fachgerecht gezogener Dump die Lösung um ein Vielfaches. Hier eine Checkliste, die du vor der Kontaktaufnahme abarbeiten solltest.

Vor dem Mitschnitt

  • Notiere die genaue Startzeit der Diagnose und synchronisiere die Uhren aller beteiligten Maschinen per NTP.
  • Bestimme die Aufzeichnungspunkte: mindestens beim Client, nach Möglichkeit auch auf der Seite, wo du Zugriff hast.
  • Sammle die Rahmendaten: IP und Port des Proxys, Name und Port des Zielhosts, erwartetes und tatsächliches Verhalten.

Während des Mitschnitts

  • Starte tcpdump mit einem Filter nach Proxy-Host und Ziel-Port, mit vollem snaplen und Rotation: 
    tcpdump -i eth0 -n -s 0 "host 203.0.113.10 and port 8080" -w support-%Y%m%d-%H%M%S.pcap -C 100 -W 10
  • Reproduziere das Problem und notiere die genaue Zeit des Vorfalls mit Millisekunden aus dem Anwendungslog.
  • Vergiss nicht, parallel die Anwendungslogs für dasselbe Intervall zu speichern.

Was der Anfrage beigelegt werden sollte

  • Die pcap-Datei selbst, beschnitten auf das relevante Zeitintervall, damit nicht Gigabytes verschickt werden.
  • Die genauen Zeitstempel des Vorfalls und die Zeitzone.
  • IP und Port des Proxys, Name und Port des Zielhosts, Beschreibung des Szenarios.
  • Ein Auszug aus den Anwendungslogs mit dem Fehler.
  • Deine vorläufige Analyse: Wer hat RST oder FIN gesendet, war ServerHello vorhanden, sind Retransmissionen beobachtet worden. Das zeigt, dass du die Hausaufgaben gemacht hast.

Wie man die pcap auf das gewünschte Intervall beschneidet

Eine riesige Datei lässt sich zeitlich über tshark oder editcap zuschneiden. Beispiel für das Ausschneiden nach Paketnummern oder Filter:

tshark -r big.pcap -Y "frame.time >= \"2026-01-01 03:00:00\" && frame.time <= \"2026-01-01 03:05:00\"" -w small.pcap

Einen so akkurat zugeschnittenen, fokussierten Dump verarbeitet der Support schnell, weil er nicht die Nadel im Heuhaufen suchen muss.

FAQ: Häufige Fragen zu Dumps über Proxys

Warum sehe ich im Dump von HTTPS-Traffic über einen Proxy nur CONNECT und danach etwas Unleserliches?

Weil der Proxy nach dem Aufbau des Tunnels nur verschlüsselte TLS-Bytes weiterleitet, ohne Schlüssel dafür zu haben. Im Klartext läuft nur der CONNECT-Befehl mit dem Hostnamen und die Antwort des Proxys über den Aufbau. Alles Weitere ist durch Verschlüsselung geschützt – und genau dafür existiert HTTPS. Um den Inhalt deines eigenen Traffics zu sehen, verwende SSLKEYLOGFILE.

Wie erkenne ich, dass die Verbindung vom Zielserver abgebrochen wurde und nicht vom Proxy?

Schau auf die Source-IP des Pakets mit RST oder FIN. Aber denk an die zwei Segmente: Im Dump vom Client siehst du nur die IP des Proxys, weil du nicht direkt mit dem Server kommunizierst. Um den Abbruch sicher dem Zielserver zuzuschreiben, brauchst du einen Dump auf der Proxy-Seite, wo das Segment Proxy-Server sichtbar ist. Wenn RST in Segment B von der IP des Servers kommt – er hat abgebrochen.

Worin unterscheidet sich Retransmission von RST im diagnostischen Sinn?

Retransmission ist das erneute Senden eines unbestätigten Segments, ein Anzeichen für Paketverlust im Kanal, aber die Verbindung lebt noch und kämpft. RST ist ein Ende, ein Befehl, die Verbindung zu vergessen. Eine Lawine von Retransmissionen, die in RST übergeht, liest sich als: Der Kanal verlor Pakete, die Seite wurde des Wartens müde und brach ab. Einzelne Retransmissionen sind normal im Internet.

Was bedeutet Zero Window und ist der Proxy daran schuld?

Zero Window meldet der Empfänger, dessen Empfangspuffer überläuft, weil die Anwendung langsam liest. Der Proxy ist daran nicht schuld – es ist ein Signal über den Zustand des empfangenden Anwendungs-Sockets. Wenn nach Zero Window ein Window Update kommt, normalisiert sich alles. Wenn nach Zero Window Stille herrscht und dann RST – der Empfänger ist hängen geblieben oder abgestürzt.