OpenVPN meldet ncp-disable als unbekannt: Was hat es ersetzt?

Der Client startet nicht und meldet einen Optionsfehler, in dem ncp-disable genannt wird, obwohl das Profil auf dem vorigen Rechner lief. Diese Meldung heißt nicht, dass die Option falsch geschrieben ist oder dass die Verschlüsselung defekt ist. Sie heißt, dass die Binärdatei vor Ihnen die Direktive überhaupt nicht kennt, und dafür gibt es zwei sehr verschiedene Gründe. Welcher zutrifft, entscheidet, ob Sie das Profil bearbeiten oder den Client wechseln.

Der Fehler kann von einer neueren Binärdatei stammen

Ein Fehler über eine unbekannte Option betrifft den Parser, nicht den Tunnel. OpenVPN 2.4 fügte aushandelbare Cipher-Parameter hinzu, 2.5 erklärte den Schalter, der sie abschaltete, für veraltet, und 2.6 entfernte ihn vollständig. Ein für 2.3 oder 2.4 geschriebenes Profil scheitert daher an einem aktuellen Client, selbst wenn sich in der Datei nichts geändert hat. Die Version, die sich beschwert, ist neuer, nicht älter.

Finden Sie heraus, welche ausführbare Datei die Meldung erzeugt hat, bevor Sie etwas bearbeiten. Ein Desktop-Client bringt seine eigene Engine mit, während eine separat installierte Binärdatei für die Kommandozeile ihre eigene Version hat. Beide können auf demselben Rechner voneinander abweichen.

openvpn --version klärt das für die Binärdatei, die Sie testen. Ein GUI-Client zeigt diesen Befehl möglicherweise nicht an; lesen Sie dann seinen Info-Bildschirm oder die Version der mitgelieferten Bibliothek.

Was die Option tatsächlich steuerte

Die Direktive schaltete die Aushandlung kryptografischer Parameter ab, sodass beide Enden auf älteres Auswahlverhalten zurückfielen, das von der Einstellung cipher gesteuert wurde. Sie hat nie die Verschlüsselung abgeschaltet und den Tunnel nie in Klartext verwandelt. Sie als Sicherheitsschalter zu lesen, ist die erste falsche Abbiegung, und sie führt zu Änderungen, die die Verbindung schlechter statt besser machen.

Sobald die Aushandlung existiert, lautet die entsprechende Frage, welche Cipher jede Seite zu verwenden bereit ist. Das ist eine Richtlinienfrage, und die Richtlinie lebt ab 2.5 in data-ciphers.

Der ältere Name ncp-ciphers gehört zu 2.4. Beide Namen zwischen Partnern zu vermischen ist eine häufige Ursache für einseitige Aushandlungsfehler. Ein Profil, das beide trägt, ist ein Profil, das zwei Personen zu verschiedenen Zeiten bearbeitet haben.

Ersetzen Sie die Richtlinie, nicht die Schreibweise

Setzen Sie data-ciphers auf beiden Seiten mit einer beabsichtigten gemeinsamen Auswahl und halten Sie die Liste kurz genug, dass ein Prüfer sie durchdenken kann. Eine beliebige Zeile zu ändern beweist nichts; das Ergebnis hängt von der Schnittmenge beider Listen und davon ab, was der TLS-Stack unterstützt. Bestätigen Sie die Einigkeit der Partner, indem Sie das ausgehandelte Ergebnis statt der Konfiguration lesen. Schreiben Sie dann beide Listen in die Bereitstellungsakte, damit die nächste Änderung von einem bekannten Stand ausgeht.

Aktualisieren Sie das Profil über denjenigen, dem es gehört. Eine Ignorier-Option hinzuzufügen, um eine veraltete Direktive zu verstecken, lässt die Richtlinienfrage unbeantwortet.

Wenn ein älterer Partner wirklich Kompatibilitätsbehandlung braucht, begrenzen Sie sie auf diese Bereitstellung. Veraltetes Verhalten global wiederherzustellen ist keine Voraussetzung, um moderne Partner zu verbinden. Die Ausnahme sollte den Partner benennen, für den sie existiert.

Zwei Zeilen, die wie eine Cipher-Liste aussehen, es aber nicht sind

Zwei Cipher-Zeilen zu stapeln stellt die Aushandlung ebenfalls nicht wieder her, und das Ergebnis ist ein Profil, das wie eine Liste aussieht, sich aber wie ein einzelner Wert verhält. Eine Zeile mit AES-256-CBC und die nächste mit CBC ist ein häufiger Versuch. CBC allein benennt einen Modus und keinen Algorithmus, daher kann ein Parser es an einer Stelle annehmen und an der nächsten ablehnen. Wiederholte cipher-Direktiven setzen dieselbe Option zweimal, statt Kandidaten anzusammeln.

Prüfen Sie akzeptierte Namen mit openvpn --show-ciphers auf der Ziel-Binärdatei, statt eine Liste aus einer Anleitung für einen anderen Zweig zu kopieren. Die Liste ändert sich zwischen Releases. Ein in einem Zweig gültiger Name ist im anderen nicht unbedingt gültig.

Wenn das Ziel ein Leistungsvergleich war, halten Sie die Algorithmen und die Last fest. Der Wechsel zu CBC ist kein Beleg dafür, dass Verschlüsselung fehlt.

Prüfen Sie, was die Verbindung tatsächlich ausgehandelt hat

Bauen Sie eine neue Verbindung auf und lesen Sie die Datenkanal-Zeile im Protokoll, die die verwendete Cipher nennt. Die Suite des Steuerkanals wird getrennt entschieden, daher zeigt die erlaubte Liste in der Datei nur, was angeboten wurde. Wenn die beiden Partner etwas gewählt haben, das Sie nicht erwartet haben, sind die Listen die richtige Stelle zum Nachsehen und nicht die Tunnelschnittstelle. Bestätigen Sie das Ergebnis nach jeder Änderung an einer zweiten Verbindung, denn ein Neustart kann eine zwischengespeicherte Sitzung wiederverwenden.

Bewahren Sie das ausgehandelte Ergebnis in der Bereitstellungsakte neben der Profilversion auf. Genau diese Tatsache beantwortet die nächste Frage, welche Cipher den Verkehr wirklich schützt.