Läuft der Verkehr wirklich durch das VPN? So prüfen Sie es

Zwei Fehlerbilder sehen im Infobereich identisch aus: Verkehr, der in den Tunnel geht, und Verkehr, der ihn stillschweigend umgeht. Der Client meldet in beiden Fällen Connected, denn Connected heißt nur, dass die Tunnelschnittstelle existiert und der Client die gewünschten Routen installiert hat. Ob ein Paket einer Anwendung diese Routen tatsächlich genutzt hat, ist eine eigene Frage, die an anderer Stelle im Stack beantwortet wird. Vier Messungen klären das meiste — die Routenabfrage, der erste Hop, ein Mitschnitt am physischen Adapter und eine Beobachtung von außen — und die Sitzungsansicht auf dem Server deckt den Rest ab.

Beginnen Sie mit der Route, die das Paket nehmen wird

Die Routing-Tabelle ist die Entscheidung, fragen Sie sie also nach einem Ziel, statt alles zu lesen und zu raten. Unter Linux nennt ip route get die Schnittstelle und die Quelladresse, die der Kernel gewählt hat:

ip route get 203.0.113.10
ip route get 10.20.5.7

Unter Windows ist Find-NetRoute -RemoteIPAddress 203.0.113.10 aus demselben Grund nützlicher als route print -4: Es meldet die Route, die gewonnen hat, nicht alle vorhandenen Routen. Lesen Sie die Tabelle trotzdem einmal wegen ihrer 0.0.0.0-Zeile. Ein /1-Paar dort bedeutet, dass ein Full-Tunnel-Client die Standardroute umgeschrieben hat: OpenVPNs redirect-gateway def1 installiert 0.0.0.0/1 und 128.0.0.0/1 durch den Tunnel, was die vorhandene 0.0.0.0/0 beim längsten Präfix gewinnt, ohne die physische Standardroute zu löschen. Deshalb können zwei Standardrouten koexistieren, während alles trotzdem in den Tunnel geht.

Zwei Details machen die Tabelle lügnerisch. Erstens: Prüfen Sie das Präfix, das gepasst hat, statt die Zahl der Standardrouten, denn eine Schnittstellenmetrik oder ein /1-Paar entscheidet den Gewinner. Zweitens: Eine bereits bestehende Verbindung behält den Weg, mit dem sie aufgebaut wurde; nach dem Aufbau des Tunnels kann eine offene Sitzung die alte Route weiter nutzen, bis sie zurückgesetzt wird, weshalb ein erneutes Verbinden einen Routingfehler zu beheben scheint. Ein laufender Client — ps ax | grep openvpn — beweist nur, dass der Prozess gestartet ist.

Verfolgen Sie einen internen und einen öffentlichen Namen

Die Routenabfrage zeigt die Absicht; der Weg zeigt die Zustellung. Verfolgen Sie im verbundenen Zustand einen Namen, der intern sein muss, und einen, der es nicht sein darf, und vergleichen Sie den ersten Hop:

traceroute intranet.corp.example
traceroute 1.1.1.1

Derselbe erste Hop für beide bedeutet, dass der interne Name nie in den Tunnel gelangt ist und der Fehler darüber liegt, meist ein Name, der zu einer öffentlichen Adresse auflöst, oder eine Route, die nie installiert wurde. Wenn interner Verkehr über 10.8.0.1 hinausgeht, während öffentlicher Verkehr über 192.168.1.1 hinausgeht, tut Split-Tunneling genau das, wofür es konfiguriert wurde. Ein Trace, der das VPN-Gateway erreicht und dann nur Zeitüberschreitungen zurückgibt, ist meist ein Rückweg- oder Server-Firewall-Problem, keine fehlende Weiterleitungsroute.

Gefiltertes ICMP macht diese Prüfung lügnerisch: Sterne auf beiden Traces sehen wie ein toter Tunnel aus und sind meist eine Firewall. Testen Sie einen TCP-Port, wo Sie können — traceroute -T -p 443 unter Linux — und bedenken Sie, dass der Trace nichts darüber sagt, welcher Resolver geantwortet hat: Ein Name kann lokal aufgelöst und trotzdem über den Tunnel erreicht werden.

Mitschneiden am physischen Adapter, nicht am Tunnel

Die physische Strecke ist der einzige Ort, der zeigt, was das Netz tatsächlich sieht. Bei aufgebautem Tunnel sollte eine Sitzung zum Büro als verschlüsselte Nutzlast erscheinen, die an den VPN-Server adressiert ist, nicht als Verbindung zu 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Der erste Filter fängt die Namensauflösung ab, die lokal hinausgeht, was das häufigste und leiseste Leck ist — die Seite lädt trotzdem, der Resolver hat nur die Anfrage gesehen. Der zweite fängt gewöhnlichen Verkehr zu einer internen Adresse ab, die nur im Tunnel existieren sollte. Unter Windows leistet pktmon dasselbe ohne Treiber: pktmon filter add -p 53, dann pktmon start --capture --pkt-size 128, dann pktmon stop und pktmon format pktmon.etl -o capture.txt. Diese Flags unterscheiden sich ein wenig zwischen Windows-Builds, prüfen Sie also pktmon filter add /?, bevor Sie der Syntax trauen.

Schneiden Sie die physische Schnittstelle mit, um Lecks zu finden; ein Mitschnitt am Tunnel enthält die Pakete, von denen Sie ohnehin glauben, dass sie da sind, und auf einem Server enthält er unlesbare äußere Pakete, deren Quelle das Gateway ist. Byte-Zähler auf einer beliebigen Schnittstelle beschreiben Pakete, nicht Programme; um Verkehr einem Prozess zuzuordnen, braucht es einen Monitor, der Sockets auf Prozesse abbildet.

Fragen Sie einen externen Dienst, und fragen Sie ihn pro Anwendung erneut

Die einzige Prüfung, die den Ausgang beweist, ist eine Antwort von außen: ein Dienst, der die gesehene Quelladresse zurückspiegelt. Starten Sie ihn aus einer Shell, wo Sie die Schnittstelle wählen können, und starten Sie ihn zweimal:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Unterschiedliche Antworten liefern den Beweis für beide Wege und eine Möglichkeit, eine bestimmte Anwendung zu testen: Binden Sie sie, oder starten Sie sie in einem Netzwerk-Namensraum mit einer einzigen Route, und sehen Sie, welche Adresse das andere Ende vermerkt. Identische Antworten sind der interessante Fehler: Entweder hat die Bindung nicht gewirkt, oder etwas zwischen Host und Gegenstelle schreibt die Quelladresse um, bevor sie ankommt. Unter Windows will curl --interface die Adresse des Adapters statt seines Namens.

Ein Browser, der die VPN-Adresse meldet, beweist den Browser. Ein Mailclient, ein Paketmanager, ein Backup-Agent oder ein zweites Browserprofil können jeweils einen anderen Weg nehmen, besonders wenn eine Proxy-Einstellung oder eine Split-Tunnel-Route eines davon abdeckt. Eine Adressänderung ist für sich genommen kein Beweis für ein Leck: Ein Lastverteiler kann je nach gesehenem Ausgang anders antworten, vergleichen Sie also die aufgezeichnete Quelladresse, nicht die Seite.

Nutzen Sie die Serversicht, um den Peer zu bestätigen

Der Server beantwortet eine andere Frage: ob ein Peer verbunden ist, wie viel er übertragen hat und ob die Sitzung neu gestartet wurde. Ein Peer, der auf dem Server aktiv ist, während die Zähler des Clients kaum steigen, bedeutet, dass der Anwendungsverkehr nicht in den Tunnel gelangt, egal was die Client-Tabelle sagte. Ein Peer, der viele Daten für einen Nutzer bewegt, der meldet, dass nichts funktioniert, ist eine andere Untersuchung.

Hier lauern zwei Fallen. Ein maskierter Tunnel lässt jeden Fluss so aussehen, als käme er vom Gateway, sodass Protokolle und Abrechnung pro Client auf eine Adresse zusammenfallen. Und ein Client gilt als lokaler Host, sodass die Frage, ob jemand Dateien über das VPN kopiert, durch Dateifreigabeverkehr auf dem Server oder durch Host-Auditierung auf dem Server beantwortet wird — die Beobachtung des Tunnels liefert Endpunkte und Volumen, keine Dateinamen.

Unterscheiden Sie eine Designentscheidung von einem Leck

Nicht alles außerhalb des Tunnels ist ein Leck. Link-Local- und Broadcast-Verkehr bleibt konstruktionsbedingt lokal, ein per Multicast gefundener Drucker kündigt sich weiter im LAN an, und DHCP muss lokal hinausgehen. Eine an eine bestimmte Schnittstelle gebundene Anwendung umgeht die Routing-Tabelle absichtlich, und nur eine Firewall-Regel, ein Namensraum oder eine Policy-Route ändert das.

IPv6 verdient eine eigene Zeile auf der Checkliste. Ein Tunnel, der nur IPv4 trägt, lässt einem Dual-Stack-Host einen zweiten nutzbaren Weg, und ein Dual-Stack-Ziel wird ihn bevorzugen — auch DNS, wenn der Resolver über IPv6 erreichbar ist. Deaktivieren Sie IPv6 am Adapter, oder bestätigen Sie, dass der Tunnel es trägt, bevor Sie ein IPv4-Ergebnis als vollständig betrachten.

Wenn die Prüfungen uneinig sind, benennt die Uneinigkeit meist den Fehler:

Eine Reihenfolge, die funktioniert: Speichern Sie die Routing-Tabelle vor und nach dem Verbinden, verfolgen Sie einen internen und einen öffentlichen Namen, schneiden Sie DNS am physischen Adapter mit, spiegeln Sie die Ausgangsadresse aus der Shell für die jeweilige Anwendung und lesen Sie dann den Server zum Volumen. Stimmen die ersten vier überein, trägt der Tunnel das, was Sie annehmen, und das verbleibende Problem liegt darüber. Widersprechen sich zwei davon, ist das widersprüchliche Paar der Fehler, nicht das Symbol.