OpenVPN lehnt die erste Zeile ab? Die Datei ist wahrscheinlich UTF-16

Der Fehler zeigt auf die erste Zeile einer .ovpn-Datei und zitiert etwas, das wie durcheinandergewürfelte Buchstaben aussieht, wo client stehen sollte. Die Datei öffnet sich im Editor einwandfrei, die erste Zeile lautet client, und die Direktive ist völlig gewöhnlich. Beide Beobachtungen stimmen, weil der Editor die Bytes dekodiert und der Client nicht. Was Sie sehen, ist fast immer ein Kodierungsproblem und kein Syntaxproblem.

Der Mythos: Der Editor zeigt Ihnen die Datei

Ein Texteditor dekodiert Bytes mit einer Kodierung, die er entweder erkennt oder errät, in Zeichen. Wenn er UTF-16 errät, sieht die Datei auf dem Bildschirm perfekt aus, während die zugrunde liegenden Bytes Paare sind, mit einem Nullbyte nach jedem lateinischen Buchstaben. OpenVPN liest diese Bytes als Zeichen, und die Diskrepanz zeigt sich bei der ersten Direktive, die es zu parsen versucht.

Also sind die sichtbare Zeile und die ausgelieferte Zeile zwei verschiedene Dinge. Die seltsamen Zeichen zu löschen, die Sie sehen, ändert die Anzeige und nicht die Kodierung, und der nächste Parse schlägt aus demselben Grund mit einer etwas anderen Meldung fehl. Deshalb führt die Jagd nach dem Token in der Fehlermeldung stets nirgendwohin. Die Bytes sind an der Quelle falsch, und jeder Leser stromabwärts rät dieselbe kaputte Sequenz.

Die konkrete Form des Fehlschlags lohnt sich zu erkennen, weil sie auf eine bestimmte Weise diagnostisch ist. Ein Token ganz am Anfang der Datei, in einem Profil, das sonst auf anderen Rechnern funktioniert hat, ist eine Frage der Byte-Reihenfolge und keine Frage des Wortschatzes.

Was die ersten Bytes tatsächlich sagen

Lesen Sie die Bytes statt der Zeichen. Zwei kleine Befehle klären es in Sekunden, und keiner davon verlangt, die Datei in einer Anwendung zu öffnen, die sie verändern könnte:

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

Das Muster, nach dem Sie suchen, ist ein Paar führender Bytes, gefolgt von Text, in dem jedes zweite Byte null ist. FF FE kennzeichnet UTF-16 little-endian, FE FF kennzeichnet big-endian, und EF BB BF kennzeichnet UTF-8 mit Byte-Order-Mark. Eine einfache UTF-8-Datei ohne Markierung beginnt direkt mit dem Byte des ersten Buchstabens.

Nullbytes zwischen den Buchstaben sind der Hinweis. In UTF-16 little-endian belegt das Wort client zwölf Bytes statt sechs, weil jedem ASCII-Zeichen eine Null folgt. Diese Struktur kann Ihnen die Anzeige eines Editors nicht zeigen, und ein Löschen von zwei Bytes kann sie nicht beseitigen.

Hier liegt eine wichtige Nuance: Der Konfigurationsleser von OpenVPN überspringt tatsächlich ein UTF-8-Byte-Order-Mark am Anfang einer Datei, wie der Konfigurationsleser 2.6 zeigt. Diese Toleranz gilt genau für diese Markierung und bewirkt nichts bei einer UTF-16-Datei, deren Buchstaben mit Nullen aufgefüllt sind. Die beiden Markierungen als dasselbe Problem zu behandeln, ist die zweite Hälfte des Mythos.

Konvertieren ist Speichern unter, nicht Löschen

Bewahren Sie vor allem anderen eine unberührte Kopie des Originals des Betreibers auf, und arbeiten Sie an einer separaten Datei. Ein Profil kann einen privaten Schlüssel oder Kontomaterial enthalten, daher ist die Kopie sowohl Ihr Rückweg als auch Ihre Referenz.

Führen Sie dann eine echte Kodierungskonvertierung durch, entweder über das ausdrückliche Kodierungsmenü des Editors oder mit einem Konverter, der seine Eingabe- und Ausgabekodierung angibt:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

Überprüfen Sie das Ergebnis, statt dem Exit-Status des Befehls zu vertrauen. Die Konvertierung sollte jede Direktive erhalten, und sie muss jeden eingebetteten Zertifikats- oder Schlüsselblock Byte für Byte innerhalb seiner Markierungen erhalten. PEM-Daten neu umzubrechen, Zeilenenden innerhalb eines Blocks zu ändern oder das Profil während der Konvertierung neu zu formatieren, schafft ein neues Problem, während das alte behoben wird.

Richten Sie den Client oder Dienst auf die konvertierte Datei und sehen Sie sich den ersten Fehler an, den er meldet. Wenn das durcheinandergewürfelte Token verschwunden ist, ist die Kodierungsarbeit erledigt, und alles, was danach fehlschlägt, ist eine andere Frage.

Was eine behobene Kodierung nicht behebt

Die Kodierung bestimmt, wie Text gelesen wird; sie sagt nichts darüber aus, ob die Optionen für den Client vor Ihnen gültig sind. Ein für eine andere Implementierung exportiertes Profil kann sauber geparst werden und dennoch wegen einer Option abgelehnt werden, die der laufende Build nicht unterstützt, oder wegen einer Direktive, deren Argument in diesem Client etwas anderes bedeutet.

Diese späteren Fehler verdienen ihre eigene Untersuchung: die genaue Schreibweise, die Syntax des Arguments und die Version, die es akzeptiert. Betrachten Sie einen erfolgreichen Parse nicht als erfolgreiches Profil.

Halten Sie die Untersuchung dabei lokal. Öffentliche Online-Konverter und eingefügte Hex-Dumps sind ein schlechter Ort für eine Datei, die einen privaten Schlüssel enthalten kann, denn das Kodierungsproblem ist leicht zu beheben und ein geleakter Schlüssel nicht.