AES-256-GCM nicht gefunden: Client-Fähigkeit oder Aushandlung?

Ein OpenVPN-Profil, das anderswo funktioniert, meldet, dass AES-256-GCM nicht gefunden wird, oder dass die Peers keine gemeinsame Chiffre teilen, und der erste Impuls ist, das Profil zu bearbeiten. Diese beiden Meldungen beschreiben unterschiedliche Fehler. Die eine sagt, dass das lokale Programm diesen Algorithmus nicht hat; die andere, dass beide Seiten Algorithmen haben, aber keine gemeinsame Wahl. Das Profil zu bearbeiten behebt keines von beiden, bis Sie wissen, welches Sie haben.

Lesen Sie den genauen Fehlertext und das Programm, das ihn erzeugt hat.

Bestimmen Sie, welchen Fehler Sie haben

Die Meldung über eine nicht gefundene Chiffre stammt aus der Optionsauswertung auf dem lokalen Rechner, bevor irgendein Paket gesendet wird. Sie bedeutet, dass die ausführbare Datei vor Ihnen oder die Bibliothek, gegen die sie linkt, diesen Algorithmus nicht anbietet. Die Meldung über keine gemeinsame Chiffre kommt später, während der Aushandlung, und bedeutet, dass beide Seiten Chiffren unterstützen, sich aber nicht auf eine einigen können.

Der Unterschied zählt, weil das eine ein Problem der Softwareversion und das andere ein Konfigurationsproblem ist. Das erste klärt eine Versionsnummer. Das zweite klärt der Vergleich zweier Listen.

Eine lokale Fähigkeitslücke

Alte Community-Builds sind älter als moderne Vorgaben, und eine Desktop-Anwendung kann ihre eigene Engine mitbringen, die sich vom daneben installierten Kommandozeilenpaket unterscheidet. Führen Sie die Prüfungen an der ausführbaren Datei aus, die die Verbindung tatsächlich gestartet hat, und wählen Sie dann einen unterstützten Build, statt einem alten Programm einen neuen Algorithmus beibringen zu wollen.

openvpn --version
openvpn --show-ciphers | grep -i gcm
openvpn --show-tls | head -5

Erscheint AES-256-GCM nicht in dieser Liste, fügt keine Profilzeile es hinzu. Die Lösung ist ein neuerer Client oder ein anderer Build, und die Einschränkungen des älteren Peers werden zu einer eigenen Designfrage.

Bei Clients auf Basis von OpenVPN 3 unterscheiden sich Engine und akzeptierte Direktiven von der Community-Linie 2.x, sodass derselbe Profiltext aus Gründen scheitern kann, die nichts mit der Chiffrenliste zu tun haben.

Eine Aushandlungslücke

Wenn beide Peers den Algorithmus auflisten, bleibt die Frage, welche Liste jede Seite anbietet. Das Community-OpenVPN benannte die Aushandlungsdirektive um: ncp-ciphers in 2.4 wurde data-ciphers in 2.5, und in 2.6 dient die ältere cipher-Zeile überwiegend der Kompatibilität und dem Rückfall statt der Festlegung des ausgehandelten Satzes.

Deshalb kann eine Änderung nur an einer alten cipher-Zeile die Aushandlungsliste unberührt lassen. Die alte Zeile bleibt für den Rückfall wichtig, und das ist eine eigene Aufgabe. Beides zu verwechseln erzeugt Änderungen, die sichtbar nichts bewirken.

openvpn --version | head -2
grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn

Vergleichen Sie die Listen beider Enden und die Ablehnungsmeldung des Servers. Ist die Schnittmenge leer, gleichen Sie die Listen bewusst an, statt einen Wert aus einem Beitrag für eine andere Version zu kopieren. Eine zu großzügige Liste schwächt still jede Verbindung. Eine zu enge Liste schließt den Peer aus, den Sie behalten wollten.

Halten Sie Kompatibilität explizit

Ein Rückfall für einen alten Peer ist eine Entscheidung mit Kosten: die gesamte Bereitstellung akzeptiert eine schwächere Option, damit ein Gerät sich verbinden kann. Schreiben Sie es als solches auf und beschränken Sie es auf den Peer, der es braucht.

Zwei Bedingungen entscheiden den Ausgang. Ist der Fehler lokal, ersetzen Sie den Build. Ist der Fehler ausgehandelt, gleichen Sie die Listen auf beiden Seiten an und notieren Sie, welche Versionen Sie unterstützen.

Melden Sie dann den genauen Fehler mit angehängter Versions- und Fähigkeitsausgabe. Dieses Paar trennt einen fehlenden Algorithmus von einer Meinungsverschiedenheit und stoppt die nächste Runde spekulativer Änderungen, bevor sie beginnt.