Promiskuitiver Modus auf einem VPN-Adapter tötet die Verbindung

Wireshark verhält sich auf einer Ethernet-Schnittstelle einwandfrei, und dann, auf einem VPN-Adapter, hört der Tunnel in dem Moment auf, Verkehr durchzuleiten, in dem der Mitschnitt beginnt. Das Mitschnittfenster füllt sich weiter, sodass das Werkzeug gesund aussieht, während die Verbindung darunter stirbt. Der promiskuitive Modus ist die übliche Ursache, denn ein Tunneltreiber, der jedes Frame auf einem Segment anfordert, das er nicht hat, kann in einen Zustand geraten, in dem nichts mehr hinausgeht.

Schalten Sie diese Option zuerst ab und entscheiden Sie dann, welche Schicht Sie wirklich sehen müssen.

Zwei Adapter, zwei unterschiedliche Sichten

Ein VPN-Client bietet normalerweise zwei Schnittstellen: die physische, die den verschlüsselten Transport trägt, und eine virtuelle, die den entschlüsselten inneren Verkehr trägt. Sie beantworten unterschiedliche Fragen. Der physische Mitschnitt zeigt Endpunkte, Ports und Paketgrößen, während die virtuelle die Anwendungsprotokolle so zeigt, wie der Tunnel sie ausliefert. Wer eine davon wählt, ohne zu wissen, welche Frage er stellt, verschwendet den Mitschnitt.

Keine der beiden Sichten ist eine Obermenge der anderen, und ein Mitschnitt beantwortet selten beide Fragen gleichzeitig.

Wählen Sie die Schnittstelle nach der Frage und nicht nach der Reihenfolge in der Liste, denn ein Client im PPP-Stil kann seinen Adapter als Ethernet-Gerät darstellen, und der Anzeigename verrät Ihnen nicht, welche Schicht Sie ausgewählt haben. Ein Mitschnitt an einem Gateway oder einem Spiegelport fügt eine dritte Sicht hinzu, die den Pfad nach der Weiterleitung zeigt, und dort werden asymmetrisches Routing und Filterung sichtbar.

Warum der promiskuitive Modus einen Tunneladapter zerstört

Der promiskuitive Modus bittet den Treiber, Frames auszuliefern, die nicht an den Host adressiert sind, was auf einem gemeinsam genutzten Ethernet-Segment sinnvoll ist und auf einem Punkt-zu-Punkt-Tunnel sehr wenig Sinn ergibt. Manche Treiber gehen mit der Anforderung gelassen um; andere hören auf, Sendeverkehr aus der Warteschlange zu nehmen, und die Schnittstelle wird stillschweigend zu einem schwarzen Loch. Der Mitschnitt zeichnet weiterhin auf, was ankommt, also sieht die Datei wie der Beweis einer funktionierenden Verbindung aus. Genau diese Lücke zwischen dem, was die Datei zeigt, und dem, was die Schnittstelle getan hat, ist die ganze Falle.

Schalten Sie die Option vor dem ersten Paket ab, halten Sie den Mitschnittfilter eng und verwenden Sie einen kleinen Puffer. Ein großer Ringspeicher auf einer stark belasteten Schnittstelle verwirft genau die Frames, auf die es ankam, was einen Mitschnitt ergibt, der überall vollständig ist außer dort, wo der Fehler lag.

Stockt die Verbindung mitten im Mitschnitt, halten Sie ihn an und beobachten Sie die Erholung. Diese eine Beobachtung trennt einen Nebeneffekt des Mitschnitts von einem echten Tunneldefekt, und sie kostet weniger Zeit als jede Filteroptimierung.

Einen IPsec-Mitschnitt lesbar machen

Ein IPsec-Mitschnitt allein ist nicht lesbar, weil ESP die Nutzlast verschlüsselt. Wireshark kann ihn dekodieren, wenn Sie die Sitzungsschlüssel liefern, oder wenn es die IKE-Aushandlung mitverfolgen kann, die sie erzeugt hat, was bedeutet, dass der Handshake in derselben Datei sein muss.

Schlüssel verfallen. Nachdem die Partner die Schlüssel erneuert haben, funktioniert ein Satz alter Schlüssel mitten im Mitschnitt nicht mehr, und das Ergebnis sieht wie ein Fehler des Dekoders aus statt wie eine Zeitgrenze.

Halten Sie sich an das dokumentierte Schlüsselformat des Herstellers, statt Material aus einer unabhängigen Quelle zu importieren, und rechnen Sie damit, dass manche Plattformen den Arbeitsablauf rundweg ablehnen. Wenn das Gateway keine Schlüssel herausgibt oder den Mitschnitt nicht erlaubt, akzeptieren Sie, dass die Nutzlast von Ihrem Standort aus nicht einsehbar ist. Endpunktprotokolle und Schnittstellenzähler sind die verbleibenden Belege, und sie reichen für eine Routing-Frage meist aus.

Ein Mitschnitt, den Sie sicher teilen können

Ein innerer Mitschnitt ist näher an einem Auszug von Anmeldedaten als an einem Protokoll. Er kann Namen, Adressen und Klartext aus Protokollen enthalten, die unter der Annahme geschrieben wurden, dass niemand sie je lesen würde, was die Datei selbst zum sensiblen Artefakt macht und nicht die Analyse.

Vergewissern Sie sich, dass Host und Netzwerk solche sind, auf denen Sie mitschneiden dürfen, notieren Sie Schnittstelle und Filter zusammen mit dem Ergebnis, begrenzen Sie die Sitzung auf die wenigen Minuten, die die Frage beantworten, und entfernen Sie die Datei, wenn Sie fertig sind. Muss sie geteilt werden, beschreiben Sie zuerst den Fluss oder entfernen Sie die Nutzlast.

Wiederholen Sie dann die ursprüngliche Benutzeraufgabe. Ein Mitschnitt, der beweist, dass ein Paket ankam, ist kein Beweis dafür, dass die Anwendung die Antwort akzeptiert hat, und die Differenz zwischen beidem ist meist der Ort, an dem der eigentliche Fehler liegt.