Wie OpenVPN data-ciphers die Cipher des Datenkanals auswählt

Der Tunnel kommt hoch, das Log zeigt eine Cipher, und die Profilprüfung geht weiter. Dann trifft ein Upgrade bei einem Peer ein, und dasselbe Profil scheitert mit einer Meldung über keine gemeinsame Cipher, was Leute auf die Suche nach einer zu löschenden Direktive schickt. Verstehenswert ist, dass data-ciphers eine Aushandlung beschreibt, keine Einstellung. Eine Seite bietet eine Liste an, die andere wählt daraus, und das Ergebnis ist ein einzelner Algorithmus, den beide unterstützen. Wer diesen Austausch liest, erklärt die meisten dieser Fehler, bevor er eine Zeile ändert.

Zwei Kanäle, zwei Konfigurationen

Eine OpenVPN-Sitzung hat einen Steuerkanal und einen Datenkanal. Der Steuerkanal führt den TLS-Handshake aus, der die Peers authentifiziert und Schlüssel aushandelt. Der Datenkanal verschlüsselt die Pakete, die Ihren Verkehr tragen.

data-ciphers konfiguriert den zweiten. Der Steuerkanal hat eigene Optionen, und die Identitätsprüfungen des Profils sind ein drittes, getrenntes Anliegen. Eine Änderung am einen behebt das andere nicht, weshalb ein Profil korrekt aussehen und trotzdem an einer bestimmten Stelle scheitern kann.

Halten Sie die drei in eigenen Schubladen, wenn Sie eine Konfigurationsdatei lesen.

Lesen Sie die Aushandlung aus dem Log

Das Client-Log nennt beide Ergebnisse, wenn die Verbindung gelingt. Eine Zeile meldet den Steuerkanal und seine TLS-Details, eine andere meldet die ausgewählte Cipher des Datenkanals.

Lesen Sie beide, denn sie beantworten unterschiedliche Fragen. Ein Fehler im Steuerkanal stoppt die Verbindung, bevor irgendeine Daten-Cipher wichtig wird. Eine Abweichung im Datenkanal erscheint nach einem erfolgreichen Handshake, mit einer Meldung über keine gemeinsame Cipher.

Vergleichen Sie dann die angebotenen Listen auf beiden Seiten. Ein Name, den die Version des einen Peers oder sein Krypto-Backend nicht bereitstellt, kann nicht ausgewählt werden, egal wie früh er in der Liste des anderen Peers erscheint.

Wie die Auswahl tatsächlich abläuft

Der Server schiebt seine data-ciphers-Liste während des Handshakes zum Client, und der Client wählt den ersten Eintrag dieser Liste, den er ebenfalls unterstützt. Die Reihenfolge gehört daher zur Konfiguration des Servers, nicht zu der des Clients.

Dieses Detail erklärt eine Klasse verwirrender Ergebnisse. Eine Umsortierung der Client-Liste ändert nichts, solange die Server-Liste entscheidet. Auch das Hinzufügen einer Cipher, die der Client nicht bereitstellen kann, ändert nichts, denn der Client muss den gewählten Eintrag verwenden können.

Neuere Versionen änderten die Standardliste und benannten die Option um, die sie früher enthielt, sodass zwei Peers auf verschiedenen Versionen uneinig sein können, ohne dass jemand ein Profil bearbeitet. Prüfen Sie die Version auf jeder Seite, bevor Sie einen Tippfehler annehmen.

Eine Liste ist in der Abstraktion kein Stärke-Ranking. Sie ist eine Menge von Kandidaten, und der ausgewählte ist der erste beidseitig unterstützte Eintrag in der Reihenfolge des Servers. Deshalb können zwei Listen, die unterschiedlich aussehen, dieselbe Cipher aushandeln. Deshalb können auch zwei Listen, die identisch aussehen, scheitern.

Ältere Peers brauchen einen bewussten Fallback

Ein Peer, der gar nicht aushandeln kann, weil er älter als der Mechanismus ist oder ihn deaktiviert hat, braucht eine dokumentierte Kompatibilitätsregelung. Die Fallback-Option existiert genau für diesen Fall und gilt für Peers, die nicht an der Aushandlung teilnehmen.

Das ist nicht dasselbe wie das Aktivieren jeder Alt-Cipher, damit eine Meldung verschwindet. Eine breite Liste schwächt die Sitzung für jeden Peer, auch für die, die etwas Starkes ausgehandelt hätten.

Stimmen Sie die beiden Seiten ab, statt unbeteiligte Algorithmusnamen zu bearbeiten. Wenn ein Server-Upgrade eine alte Option entfernt hat, gehört die Korrektur in den Versionsplan, nicht in eine Hektik beim Client.

Bewahren Sie die Verifikation unversehrt

Eine Abweichung im Datenkanal ist kein Grund, einen ungeprüften Server zu akzeptieren. Zertifikatsprüfung, der erwartete Servername und die Schutz-Einstellungen des Steuerkanals sind von der Cipher-Auswahl getrennt und sollten jede Kompatibilitätsänderung überstehen.

Halten Sie die ausgehandelte Daten-Cipher, die Client-Version und die Server-Version zusammen fest, damit der nächste Vergleich von Fakten ausgeht und nicht von der Profildatei.

Testen Sie nach einer unterstützten Korrektur die initiale Verbindung und eine erneute Aushandlung, denn eine Sitzung, die einmal zustande kommt, kann bei der Schlüsselerneuerung immer noch scheitern.

Wenn der Tunnel steht und Seiten weiterhin scheitern, ist die Cipher nicht mehr verdächtig. Fahren Sie mit Routing und DNS fort. Reihenfolge der Arbeit: beide Logzeilen lesen, beide Listen vergleichen, Versionen prüfen, einen Fallback nur für einen Peer hinzufügen, der einen braucht, und dann den Erneuerungspfad erneut testen.