OpenVPN-Fehler: unbekannte Option tls-remote oder keysize

Meist beginnt es mit einem Profil, das jahrelang verbunden war, auf einem neueren Client geöffnet wird und scheitert, bevor der Tunnel überhaupt startet. Das Terminal gibt etwas wie Options error: Unrecognized option ... in client.ovpn:130: tls-remote aus, mit einer Version in Klammern am Ende. Lesen Sie das als Beschwerde des Parsers: Die Datei enthält eine Direktive, die dieser Client nicht mehr kennt.

Diese eine Meldung erklärt, warum das Neuerzeugen von Schlüsseln, das erneute Eingeben des Passworts oder das Prüfen des Servers nichts bewirkt. Der Fehler tritt auf, während der Client seine eigene Konfiguration liest, bevor er einen Socket öffnet. Die nützliche Arbeit besteht darin, die abgelehnte Direktive zu identifizieren und sie durch das aktuelle Äquivalent zu ersetzen.

Lesen Sie die fehlerhafte Zeile, bevor Sie etwas ändern

Starten Sie den Client selbst, statt ihn über ein Tray-Icon zu öffnen, damit die Meldung sichtbar ist und der Profilpfad eindeutig bleibt. Öffnen Sie die Datei an der gemeldeten Zeile und sehen Sie sich das Token an, das der Client genannt hat. Die Zeilennummer ist die Profilzeile, keine Version, was viele verwirrt, weil dieselbe Nummer in Klammern als Release-Kennung erscheint.

Alte Profilgeneratoren gaben nicht eine schlechte Direktive aus, sondern mehrere. Beheben Sie den ersten Fehler, starten Sie den Client erneut und erwarten Sie, dass der nächste auftaucht. Diese Abfolge ist normal und kein Zeichen dafür, dass die Änderungen alles schlimmer gemacht haben.

Was mit keysize und tls-remote passiert ist

keysize verlangte eine Chiffrierschlüssellänge in der Ära, in der das Profil die Chiffre ausdrücklich wählte. OpenVPN 2.4 erklärte sie für veraltet, und spätere Clients entfernten sie aus der Optionstabelle, sodass der Parser die Zeile nun ablehnt, statt sie zu ignorieren. Moderne Aushandlung leitet die Schlüssellänge aus der gewählten Chiffre ab, weshalb der Direktive nichts mehr zu steuern bleibt.

tls-remote wurde in 2.4 entfernt. Es verglich das Serverzertifikat mit einem erwarteten Namen, und sein Ersatz ist verify-x509-name, das strenger damit umgeht, wie der Name abgeglichen wird. Die alte Direktive ist verschwunden, ein Profil, das sie enthält, wird auf einem aktuellen Client also nie geparst.

Beheben Sie pro Versuch eine Direktive. Wenn das Profil zusätzlich eine Chiffre angibt, die der Client nicht anbietet, erzeugt das später einen anderen Fehler, und beide Änderungen in einer Bearbeitung zu mischen macht es unmöglich zu sagen, welche den Handshake gebrochen hat. Verbinden Sie sich nach jeder Änderung neu und bewahren Sie den Fehlertext auf. Diese Gewohnheit bewahrt auch einen funktionierenden Rückfall, falls eine Änderung alles verschlimmert.

Schreiben Sie die Serveridentitätsprüfung neu

Der Ersatz nimmt den erwarteten Namen und einen Vergleichsmodus. verify-x509-name vpn.example.edu name verlangt, dass der Betreff des Zertifikats genau diesem Wert entspricht. Andere Modi gleichen ein Präfix oder eine vollständige Betreffzeichenkette ab, und der falsche Modus verwandelt ein funktionierendes Profil in einen sauberen Verifizierungsfehler.

Wenn das alte tls-remote-Argument der vollständige Common Name des Servers war, ist ein exakter name-Vergleich meist richtig. Wenn es ein Teilwert war, verwenden Sie den Präfixmodus, statt den erwarteten Namen zu kürzen, denn eine kürzere exakte Übereinstimmung wird nicht verifizieren. Wenn der ursprüngliche Wert nicht notiert ist, fragen Sie den Betreiber des Servers nach dem Betreff, den er veröffentlicht.

Schalten Sie die Prüfung nicht stumm, damit der Fehler verschwindet. Das Entfernen der Serveridentitätsprüfung macht aus einem behebbaren Profilproblem einen ungeprüften Tunnel, und genau das ist das Risiko, das die Direktive verhindern sollte.

Korrigiertes Profil, lokale Bearbeitung oder älterer Client

Wenn jemand anderes den Server betreibt, ist der sauberste Weg ein aktuelles Profil von dort. Ihre Kopie stammt von einem älteren Generator, und dessen Export nutzt bereits die aktuellen Direktiven. Ein Download beseitigt die ganze Fehlerkategorie und hält künftige Änderungen an einem Ort.

Wenn Sie beide Enden besitzen, bearbeiten Sie eine Kopie und behalten Sie das Original. Ändern Sie eine Direktive, speichern Sie, verbinden Sie sich und notieren Sie die getestete Clientversion. Halten Sie neben jeder Änderung eine kurze Notiz fest, denn ein über mehrere Sitzungen bearbeitetes Profil lässt sich aus dem Gedächtnis schwer prüfen. Kommandozeilenläufe gegen die bearbeitete Datei machen diese Schleife schnell, weil der Fehler direkt im Terminal landet.

Das Anheften oder Zurückrollen auf einen Client vor 2.4 lässt die Meldung ebenfalls verschwinden, und bei einem Gerät, das nie aktualisiert wird, kann das der einzige gangbare Notbehelf sein. Behandeln Sie es als vorübergehend: Ein alter Client auf einem aktuellen Desktop bedeutet meist eine alte Bibliothek und eine nicht unterstützte Konfiguration, was ein aufgeschobenes statt gelöstes Problem ist.

Wenn der Tunnel steht, lesen Sie das ganze Profil noch einmal. Profile, die eine entfernte Direktive enthielten, enthalten oft noch eine weitere, und die zweite zeigt sich erst, nachdem die erste weg ist.