Warum das Hinzufügen von opt-verify den OpenVPN-Verschlüsselungsfehler nicht behebt

Sie finden den Vorschlag, opt-verify hinzuzufügen, fügen die Zeile ein, und der Verschlüsselungsfehler bleibt genau dort, wo er war. Dieses Ergebnis ist vorhersehbar, denn die Option hat nie eine Verschlüsselung ausgehandelt. Sie war eine Prüfung der Optionskonsistenz, in 2.6 veraltet und in 2.7 entfernt, und ein Profil, das damit noch geparst wird, hat dadurch nichts durchgesetzt.

Es hilft zu wissen, was die Zeile früher tat, bevor man schließt, dass sie das fehlende Teil ist. Die Geschichte erklärt auch, warum sie jetzt nicht helfen kann.

Was die Option früher durchsetzte

Das Handbuch zu 2.6 kennzeichnet opt-verify als veraltet und beschreibt das frühere Verhalten: Der Server verwirft Clients, deren angegebene Optionen nicht zu seinen eigenen passen, wobei er Dinge wie Gerätetyp und MTU vergleicht. Diese Prüfung hängt auch davon ab, dass die Prüfung der Optionskonsistenz aktiviert bleibt, sodass ein Server mit disable-occ sie nie hatte. Beachten Sie, woraus der Vergleich besteht: aus Text, der die Konfiguration einer Gegenstelle beschreibt. Er sagt nichts darüber, welche Verschlüsselung der Datenkanal verwenden wird.

Das ist der erste Grund, warum das Flag einen Verschlüsselungsfehler nicht reparieren kann. Die Verschlüsselungswahl wird durch die data-ciphers-Richtlinie und durch das bestimmt, was beide Seiten unterstützen, und eine textliche Konsistenzprüfung erweitert diese Liste weder noch führt sie die Aushandlung durch. Ein zweiter Grund ist der Umfang: Die Prüfung betrifft, ob angegebene Optionen kompatibel aussehen, nicht die Qualität des daraus entstehenden Pfades.

Was 2.7 tut, wenn es die Zeile sieht

In 2.7 ist die Option verschwunden. Der Parser erkennt den Namen noch, weshalb ein altes Profil ohne Syntaxfehler lädt, und er meldet, dass die Option entfernt wurde, statt sie stillschweigend zu übergehen. Einen Namen zu erkennen und ein Verhalten durchzusetzen sind verschiedene Dinge, und nur das Erste geschieht noch. Die Entfernungshinweise nennen den Grund: Sobald Parameter ausgehandelt werden können, dürfen zwei Seiten legitimerweise unterschiedliche Optionsstrings haben, während sie sich über die Verbindung einig sind.

Ein Profil, das geparst wird, ist daher kein Beleg dafür, dass irgendeine Zulassungsprüfung lief. Wenn Ihr einziges Signal ist, dass der Client sich verbunden hat, haben Sie erfahren, dass die Syntax akzeptiert wurde.

Wo der Fehler tatsächlich liegt

Bewahren Sie den ersten konkreten Fehler auf, bevor Sie etwas ändern, denn spätere Meldungen sind meist Folgen davon. Ein Aushandlungsfehler des Datenkanals gehört zur genehmigten Verschlüsselungsrichtlinie und zu den Fähigkeiten, die beide Seiten tatsächlich ankündigen. Ein Fehler bei TLS-Version oder -Suite gehört zum Kontrollkanal. Eine Zertifikatsablehnung braucht die Identität und die Vertrauenskette, nicht ein Kompatibilitätsflag.

Bestimmen Sie auch die Engine an beiden Enden. Eine Desktop-Anwendung kann einen anderen Build mitbringen als die Kommandozeilen-Binärdatei, mit der Sie getestet haben, und die Optionsunterstützung unterscheidet sich zwischen ihnen. Prüfen Sie die Dokumentation dieser Engine, statt anzunehmen, dass jedes Programm, das ein Profil importiert, sich gleich verhält.

Ersetzen Sie die Absicht, nicht nur die Zeile

Wenn ein älterer verwalteter Server tatsächlich auf der Konsistenzprüfung beruhte, halten Sie fest, welche Einschränkung er vor dem Upgrade durchsetzte. Eine ignorierte Option in einem neueren Profil zu behalten, kann diese Richtlinie nicht bewahren, und wahlloses Löschen von Zeilen ebenso wenig.

Reagieren Sie nicht auf einen alten Vorschlag, alle Verschlüsselungen seien deaktiviert, indem Sie jeden historischen Algorithmus aktivieren.

Prüfen Sie nach einer genehmigten Korrektur die ausgehandelten Ergebnisse auf einer neuen Verbindung und testen Sie die Anwendung, die der Benutzer tatsächlich braucht. Halten Sie die Serverversion und die effektive Richtlinie neben diesem Ergebnis fest, damit die nächste Person sieht, was vereinbart wurde, statt nur, was akzeptiert wurde.

Das Ziel ist eine unterstützte Einschränkung und ein funktionierender authentifizierter Pfad, kein Alt-Flag, das noch geparst wird.