Importierte VPN-Routen weichen vom funktionierenden Client ab? Vergleichen Sie beide

Manche privaten Dienste antworten über das VPN, während sich gewöhnlicher Internetverkehr völlig anders verhält als auf dem Rechner eines Kollegen, und man möchte schließen, dass der Ubuntu-Client defekt ist. Dieser Schluss überspringt einen Schritt. Ein funktionierender privater Vorgang und ein abweichender öffentlicher Pfad sind zwei Beobachtungen, und der Unterschied liegt meist in der Verkehrsrichtlinie, die jeder Client installiert hat, nicht im Client selbst.

Die gespeicherte Konfiguration mit dem tatsächlichen Netzwerkzustand zu vergleichen kostet drei Befehle und beantwortet die Frage, die das Raten beantworten wollte.

Zuerst das gespeicherte Profil, dann der effektive Zustand

Eine importierte OpenVPN-Verbindung wird zu einem eigenen NetworkManager-Profil. Die .ovpn-Datei, aus der sie stammt, ist in dem Moment keine Wahrheitsquelle mehr, in dem der Import abgeschlossen ist, sodass eine spätere Bearbeitung dieser Datei nichts an der verwendeten Verbindung ändert. Hier geht der Vergleich zuerst schief, und zwar lautlos.

nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn

Lesen Sie die UUID, wenn Namen kollidieren; doppelte Namen überleben Neuinstallationen und Profilwiederherstellungen, und Sie können eine Stunde damit verbringen, die Kopie zu bearbeiten, die nicht benutzt wird. Die Werte, die Sie sehen, beschreiben die gespeicherte Absicht: ob das Profil die Standardroute übernehmen darf, welche Routen gespeichert wurden und welche Resolver und Suchdomänen es anfordert. Sie beschreiben nicht, was beim Aktivieren der Verbindung geschah, denn ein Plugin oder ein Push des Servers kann Zustand hinzufügen, den das Profil nicht erwähnt. Deshalb ist der nächste Befehl wichtig.

Schauen Sie dann, was das System tatsächlich mit dieser Absicht getan hat, einschließlich Richtlinienregeln und aller Tabellen, nicht nur der Haupttabelle. Gespeicherte Eigenschaften sind Eingaben, und die installierten Tabellen sind das Ergebnis.

ip -4 rule show
ip -4 route show table all

Zwei Ziele, ein Vergleich

Wählen Sie ein funktionierendes privates Ziel und ein gewöhnliches öffentliches Ziel und fragen Sie dann den Kernel, welchen Pfad jedes nehmen würde. Erst der Vergleich auf beiden Rechnern macht aus einem vagen Unterschied einen konkreten.

ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20

Die Adressen sind Beispiele, die Sie durch eigene ersetzen; entscheidend ist das Paar, nicht die Zahlen. Vergleichen Sie Schnittstelle, Quelladresse und die in jeder Ausgabe genannte Tabelle. Wenn die private Abfrage den Tunnel nennt und die öffentliche Abfrage ihn ebenfalls nennt, haben Sie einen vollen Tunnel, und der andere Client hat vielleicht einen geteilten, oder umgekehrt.

Verlangen Sie nicht, dass beide Clients identischen Text ausgeben. In OpenVPN wird redirect-gateway def1 üblicherweise als zwei Halbpräfix-Routen statt einer Standardroute ausgedrückt, und ein Manager, der sie anders darstellt, ist deshalb nicht falsch. Beurteilen Sie die Abdeckung, die die Abfragen zeigen, nicht die Formatierung.

Wo sich die beiden Clients zu Recht unterscheiden

Client-Standardwerte sind Richtlinienentscheidungen und dürfen voneinander abweichen. Ein Produkt kann einen vollen Tunnel bevorzugen, ein anderes behält die lokale Standardroute und leitet nur die privaten Präfixe, und ein drittes folgt dem, was der Server geschickt hat. Ein Unterschied ist nur dann ein Fehler, wenn er der Anforderung widerspricht, die Sie erhalten haben.

Vergleichen Sie also jeden Client mit der genehmigten Absicht eines geteilten oder vollen Tunnels, nicht miteinander. Wenn die Anforderung lautet, dass privater Verkehr den Tunnel nutzt und der lokale Internetpfad lokal bleibt, dann ist ein voller Tunnel der Fehler und ein geteilter Tunnel richtig, unabhängig davon, welcher Client was getan hat. Schreiben Sie die Absicht auf, bevor Sie eine der Konfigurationen ansehen, sonst wird der erste Client, den Sie prüfen, stillschweigend zum Maßstab.

DNS ist eine zweite Achse und versagt unabhängig. Eine korrekte Route kann Abfragen dennoch an einen Resolver schicken, der für die private Zone nicht antworten kann, und ein korrekter Resolver repariert keine falsche Route. Prüfen Sie beides, und behandeln Sie einen privaten Namen, der sich auflöst, während eine private Adresse es nicht tut, als Beleg dafür, dass die beiden Schichten getrennt gelöst werden.

Halten Sie den Vergleich sauber

Betreiben Sie jeweils nur einen Verbindungsinhaber. Eine OpenVPN-Sitzung auf der Kommandozeile, die neben dem importierten Profil läuft, installiert eigene Routen und eigenen Resolverzustand, und die entstehende Mischung ist das Verhalten keines der beiden Clients. Beenden Sie die eine, bevor Sie die andere messen. Starten Sie neu, wenn Sie unsicher sind, was noch Zustand hält, denn eine veraltete Route von vor einer Stunde sieht genau wie ein Richtlinienproblem aus.

Halten Sie auch alles andere fest: derselbe Endpunkt, dasselbe Konto, dieselben Softwareversionen, dasselbe Netzwerk. Ein Erfolg auf dem Windows-Laptop eines Kollegen testet einen anderen Client, eine andere Resolver-Integration und möglicherweise ein anderes Serverprofil, ist also kein Beleg über den Ubuntu-Manager.

Die IPv4-Einstellungsreferenz von NetworkManager definiert never-default und die gespeicherten Routeneigenschaften genau, was sich vor dem Ändern eines verwalteten Werts zu lesen lohnt. Und denken Sie an die Reichweite dieses Vergleichs: Er deckt IPv4 ab und sagt nichts über die entsprechende IPv6-Richtlinie, die eigene Standardwerte und ihre eigene Art hat, Sie zu überraschen.