Wo man den Verkehr eines OpenVPN-Clients am Gateway beobachtet

Sie möchten wissen, welche Ziele ein verbundener Client erreicht, also öffnen Sie eine Shell auf dem VPN-Server und tippen ss. Es erscheint nichts Nützliches, und die Schlussfolgerung, der Tunnel sei defekt, folgt etwas zu leicht. Ein geroutetes OpenVPN-Gateway leitet die Pakete des Clients weiter; es beendet ihre TCP-Verbindungen nicht und besitzt keine Sockets für sie. Der Nachweis liegt woanders, und wo, hängt davon ab, wie der Verkehr behandelt wird, nachdem er den Tunnel verlässt.

Entscheiden Sie, welche Anordnung Sie vor sich haben

Zwei übliche Formen liefern völlig unterschiedliche Nachweise. Ein routendes Gateway entkapselt, leitet weiter und betreibt womöglich Source-NAT, sodass die Verbindung des Clients Ende zu Ende weiterbesteht, ohne lokalen Socket.

Ein Proxy beendet den Verkehr: Er nimmt die Verbindung an und öffnet dann seine eigene Verbindung nach oben. In dieser Anordnung gibt es zwei Verbindungen für eine Anfrage, und die Zuordnung zwischen ihnen existiert nur in den eigenen Aufzeichnungen des Proxys. Zu wissen, welche dieser Varianten Sie betreiben, entscheidet, ob Sie den Flow-Zustand des Kernels oder Anwendungslogs lesen sollten.

Der meiste Wirrwarr entsteht aus Vermutungen. Bestätigen Sie die Form, bevor Sie das Werkzeug wählen. Lesen Sie zuerst die Serverkonfiguration auf eine Proxy-Direktive, denn ihre Anwesenheit ändert jeden späteren Schritt. Ohne eine ist der Paketpfad Routing, und der Flow-Zustand des Kernels ist Ihr Nachweis.

Binden Sie zuerst die Adresse an eine Sitzung

Beginnen Sie beim Sitzungszustand des Servers und ermitteln Sie die aktuelle innere Adresse des Clients. Pool-Adressen werden wiederverwendet, daher ist eine Adresse für sich ein Leasing und keine Person.

Notieren Sie Zeit und authentifizierte Identität gemeinsam und vermerken Sie, ob ein ganzes LAN hinter diesem Client steckt. Wenn das entfernte Ende ein Subnetz routet, können die inneren Adressen, die Sie sehen, ursprüngliche Hosts oder übersetzte sein.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Dieses Paar beantwortet zwei Fragen zugleich: welches Präfix die Tunnelschnittstelle bedient und welche Sitzung in dem Intervall aktiv war, das Sie interessiert. Tun Sie das, bevor Sie irgendeinen Flow-Eintrag deuten, denn ein überzeugendes Tupel, das an die falsche Sitzung gehängt ist, ist schlimmer als gar kein Nachweis.

Lesen Sie die Flow-Tabelle auf einem routenden Gateway

Sind Adresse und Intervall gesichert, zeigt eine schreibgeschützte Auflistung verfolgter Verbindungen, was das Gateway für sie weiterleitet. Filtern Sie auf die ursprüngliche Quelle, damit Sie nicht die ganze Tabelle lesen.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Jeder Eintrag enthält zwei Tupel, Original und Antwort, die die beiden Richtungen eines Flows sind und nicht zwei Anwendungen. Auf einem Source-NAT-Pfad behält das Originaltupel die Tunneladresse, während die Antwortseite die übersetzte Gateway-Adresse zeigt, und genau das lässt die Ausgabe auf den ersten Blick falsch aussehen.

Behandeln Sie die Auflistung als lebenden Zustand und nicht als Historie. Kurze Flows sind vielleicht schon abgelaufen, unverfolgter Verkehr erscheint nie, und ein anderer Netzwerk-Namespace zeigt eine andere Tabelle. Die conntrack-Referenz dokumentiert die Filter und die zweiseitige Ausgabe.

Ein begrenzter Mitschnitt zur Bestätigung der Lesung

Wenn die Tunnelschnittstelle dort sichtbar ist, wo Sie hinsehen, entscheidet ein einziger begrenzter Mitschnitt, ob die von Ihnen bestimmten Pakete die auf der Leitung sind. Halten Sie den Filter eng und das Paketlimit klein.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Vergleichen Sie Zeitstempel, Protokoll und Ports mit dem Flow-Eintrag und mit der Anfrage, die Sie als Test gestellt haben. Ein nach dem NAT genommener Mitschnitt zeigt nur die öffentliche Adresse des Gateways, während die Tunnelseite noch die des Clients zeigen kann, und dieser Unterschied ist Information und kein Widerspruch.

Sieht die Schnittstelle nichts, prüfen Sie den Datenpfad, bevor Sie schließen, der Client sei untätig: Verkehr zwischen Clients und manche Offload-Pfade durchlaufen den beobachteten Punkt nie.

Proxy-Logs und die Grenzen des Gesehenen

Steht ein Proxy im Pfad, sind seine Upstream-Sockets in der Socket-Tabelle sichtbar, bilden aber nicht eins zu eins auf VPN-Clients ab, besonders bei Pooling oder Multiplexing. Nutzen Sie das konfigurierte Transaktionslog des Proxys, um Client-Identität, Ziel, Zeitstempel und jede aufgezeichnete Anfragekennung zu korrelieren.

Prüfen Sie die Logging-Konfiguration der eingesetzten Version, statt anzunehmen, jede Anfrage werde standardmäßig protokolliert.

Seien Sie schließlich genau beim Umfang. Zieladresse und Port sind Metadaten, keine URL und kein Seiteninhalt, denn die innere HTTPS-Sitzung behält ihren eigenen Schutz unabhängig vom Tunnel. Berichten Sie, was Sie beobachtet haben, von welchem Beobachtungspunkt und zu welcher Zeit.