Windows-OpenVPN-Profil scheitert auf Ubuntu: drei Ebenen

Starten Sie dasselbe Profil im Terminal, und die Meldung, die die meisten kopieren, ist eine Warnung, nicht der Grund, warum der Client stehen blieb. Drei unabhängige Ebenen scheitern hier: eine übertragene Direktive, die der Linux-Build nicht umsetzt, die Rechte zum Anlegen eines tun-Geräts und der Resolver-Helfer, der aus einer Verbindung funktionierendes DNS macht. Arbeiten Sie sie der Reihe nach ab, denn jede kann die nächste verdecken.

Bewahren Sie den Download so auf, wie er ankam, und bearbeiten Sie eine Kopie, damit ein frischer Download Ihre Änderungen nicht still zurücknimmt.

Lesen Sie die Warnung, bevor Sie sie beschuldigen

block-outside-dns sperrt DNS unter Windows über die Windows Filtering Platform, und der Linux-Client hat nichts, womit er das abbilden könnte. Wenn der Server es überträgt, gibt der Client für diesen übertragenen Eintrag eine Zeile über eine unbekannte Option aus und fährt fort, weil eine übertragene Option nicht als fatal gilt. Dieselbe Zeile in Ihrer eigenen Datei ist etwas anderes: dort hält der Parser an. Entscheiden Sie, welche der beiden Sie haben, bevor Sie irgendetwas anfassen, denn nur eine davon beendet den Lauf.

Um das Rauschen zu entfernen, filtern Sie es vor dem Parsen: ein pull-filter ignore-Eintrag für diesen Namen oder --ignore-unknown-option, wenn die Zeile in der lokalen Datei steht. Beide bringen eine Zeile zum Schweigen, die Sie bereits gelesen haben; keines repariert einen Fehler, den Sie nicht diagnostiziert haben.

Rechte scheitern vor allem anderen

Ein tun-Gerät und die zugehörigen Routen sind privilegierte Objekte, und ein normales Konto kann sie nicht anlegen. Die Option --user erklärt die Trennung: Der Daemon gibt seine Privilegien erst auf, nachdem die privilegierte Arbeit erledigt ist. Starten Sie ihn als root oder über eine Unit, die ihn so startet, und suchen Sie dann einen Berechtigungsfehler, bevor Sie Zertifikate ansehen. Gelockerte Dateirechte am Profil geben dem Prozess nicht die fehlenden Rechte.

Ein TLS-Fehler bedeutet, dass der Client diese Ebene passiert hat. Eine Beschwerde über Gerät oder Route bedeutet, dass er die Ebene darüber nie erreicht hat.

Was die GUI tut, was das Terminal nicht tut

Erfolgreich verbinden, während jede Abfrage weiter scheitert, ist die dritte Ebene. NetworkManager erledigt seine eigene Resolver-Arbeit, weshalb ein Desktop-Import DNS verteilen kann, selbst wenn das up-Skript des Profils nie erfolgreich lief. Der Befehl openvpn --config führt aus, was --up benennt, und fehlt dieser Helfer, erscheint die Schnittstelle, während Abfragen weiter zu den vorigen Servern gehen. Vergleichen Sie die Skripte beider Wege, bevor Sie etwas installieren.

Nutzen Sie den paketierten Helfer Ihrer Distribution; ein aus einem Blogbeitrag kopiertes Skript zielt meist auf einen anderen Resolver. Die für systemd-resolved ausgelieferte Integration ist nicht das generische Skript im vpnc-Stil, und jede erwartet eigene Argumente und Variablen vom Client. Benutzerdefinierte up-Skripte benötigen außerdem script-security 2, bevor der Client sie überhaupt ausführt.

Trennen Sie die Ebenen beim nächsten Lauf

Starten Sie einmal mit --verb 4 und lesen Sie das Protokoll in der Reihenfolge des Geschehens: Geräteanlage, Routen, TLS-Handshake, dann die Ausgabe des up-Skripts. Der erste Fehler in dieser Folge ist es wert, behoben zu werden; alles danach ist meist eine Folge. Ein Tunnel, der aufgebaut wird, während der Resolver es nicht tut, bringt Sie auf Ebene drei, wo das Zertifikat keine Rolle spielt. Lassen Sie das heruntergeladene Profil beim Vergleichen unangetastet.

Sobald jede Betreiber-Anpassung eine weitere abgelehnte Zeile erzeugt, ist die Datei auf eine andere Plattform gerichtet. Fordern Sie einen Linux-Export an, statt eine dauerhafte Filterliste zu bauen.

Notieren Sie, welche Ebene scheiterte und was sie verändert hat, denn die nächste Person mit derselben Datei bleibt sonst ebenfalls bei der Warnung stehen.