tls-auth key-direction: 0 und 1 müssen sich unterscheiden, nicht übereinstimmen
Bei tls-auth brauchen beide Seiten entgegengesetzte Richtungen, 0 und 1, oder beide müssen die Einstellung weglassen. Dieselbe Zahl scheitert, und tls-crypt nutzt sie nie.
Eine Seite des Tunnels signiert den Steuerkanal mit einem Schlüsselslot, den die andere Seite nie prüft, und die Verbindung stirbt mit einem Authentifizierungsfehler, bevor ein einziges Zertifikat ausgetauscht ist. So sieht eine Richtungsabweichung bei tls-auth aus, und sie ist deterministisch: dieselben zwei Dateien scheitern bei jedem Versuch, aus jedem Netz. Nichts im Protokoll benennt die Option, nach der Sie suchen, deshalb bauen Leute Schlüssel neu und stellen Zertifikate neu aus, die nie defekt waren. Die Lösung ist, die beiden Seiten komplementär zu machen oder beide bidirektional zu lassen, statt die Prüfung zu schwächen.
Der Fehler tritt vor den Zertifikaten auf
Bei tls-auth halten beide Peers denselben gemeinsamen Schlüssel, und jeder nutzt einen von zwei daraus abgeleiteten Slots: Der eine Slot signiert ausgehende Steuerpakete, der andere prüft eingehende. Richtung 0 und Richtung 1 weisen diese Rollen in umgekehrter Reihenfolge zu, deshalb muss das Paar komplementär sein, damit die HMAC-Prüfungen zusammenpassen. Wird die Zuordnung auf einer Seite umgedreht, sucht der Empfänger eine Signatur im falschen Slot und verwirft das Paket. Die Sitzung endet dort, und deshalb betrifft der Fehler die Paketauthentifizierung und nicht etwas, das der Zertifikatsspeicher erzeugen würde.
Die Deterministik ist für die Diagnose wichtig, denn ein Zeit- oder Pfadproblem hinterlässt eine andere Signatur: unregelmäßige Abbrüche, eine Richtung, die ausfällt, oder eine Sitzung, die nur in einem bestimmten Netz stirbt. Eine Richtungsabweichung scheitert jedes Mal beim ersten Handshake, und sie scheitert identisch auf einer anderen Maschine mit denselben zwei Dateien. Lesen Sie das Protokoll mit --verb 4 und finden Sie das erste verworfene Paket statt der letzten Zeile. Geschieht diese Verwerfung vor jedem Zertifikatsaustausch, sind der gemeinsame Schlüssel und seine Richtung die beiden Dinge, die eine Prüfung wert sind.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
Wo die Zahl lebt
Das Handbuch zu OpenVPN 2.6 dokumentiert zwei Stellen für die Richtung: das zweite Argument von tls-auth, wenn der Schlüssel in einer eigenen Datei liegt, und eine eigenständige Zeile key-direction, wenn der Schlüssel ins Profil eingebettet ist. Beide setzen denselben Wert, ein Profil sollte also die eine oder die andere Form verwenden, nie beide. Auch das Weglassen ist eine Wahl, und es bringt beide Peers in eine bidirektionale Anordnung, die funktioniert, wenn keine Seite eine Richtung nennt. Zwei Peers mit derselben Zahl sind nicht in dieser Anordnung: Jeder erwartet, in einem Slot zu signieren und im anderen zu prüfen, und beide tun es auf dieselbe Weise.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
Die eingebettete Form ist eine Direktive auf einer eigenen Zeile, kein Attribut am öffnenden Tag des Schlüsselblocks, und ein Argument an dieses Tag anzuhängen ist ein Fehler, keine Richtungsänderung. Auch der Platz ist wichtig: Die Direktive steht außerhalb des Blocks, zu dem sie gehört, ein innerhalb des Blocks geschriebener Wert wird also als Schlüsselmaterial gelesen. Kopieren Sie die Anordnung, die der Verteiler des Profils vorgesehen hat, statt eine Paarung zu erfinden, denn ein Profil, das gegen einen Server funktioniert, ist auf der anderen Seite vielleicht schon gespiegelt.
Was die Option unangetastet lässt
Sie verschlüsselt keinen Anwendungsverkehr. tls-auth legt einen HMAC um die Pakete des Steuerkanals, während der Datenkanal durch Sitzungsschlüssel geschützt ist, die beim Handshake ausgehandelt werden, eine Frage zu Durchsatz oder Verschlüsselung hat also nichts mit der Richtungszahl zu tun. Die Einstellung fügt auch keine zweite Verschlüsselungsschicht hinzu, und genau diese Annahme schickt Leute auf die Suche nach einem längeren Schlüssel.
Sie gilt nicht für tls-crypt, einen anderen Steuerkanal-Mechanismus mit eigenen Optionen und eigener Schlüsselbehandlung, und sie sagt nichts über die Zertifikatsidentität irgendeines Peers. Eine funktionierende Richtungsübereinstimmung beweist daher nur, dass sich beide Seiten einig sind, wie der Steuerkanal authentifiziert wird, nicht dass die Vertrauenskette validiert wurde.
Das Paar ausrichten, dann neu verbinden
Vergleichen Sie beide Konfigurationen, bevor Sie eine ändern, denn die Seite zu bearbeiten, die schon korrekt war, verdoppelt die Arbeit. Der grep unten zeigt, welchen Mechanismus jede Datei wählt; der ausführliche Lauf zeigt, ob der Steuerkanal überhaupt authentifiziert wurde. Behalten Sie beide Ausgaben, damit die nächste Änderung mit einem bekannten Zustand verglichen werden kann.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
Starten Sie beide Peers nach jeder Änderung neu, denn diese Optionen werden beim Start einmal gelesen, und das Neuladen einer Seite lässt das Paar für die Lebensdauer der alten Sitzung inkonsistent. Wenn das Deployment derzeit ohne konfigurierte Richtung funktioniert, reproduziert das Hinzufügen der Einstellung auf einem Peer den Fehler, mit dem Sie begonnen haben; lassen Sie entweder beide in Ruhe oder konfigurieren Sie beide. Ändern Sie jeweils ein Ende und behalten Sie die vorherige Datei, damit eine Regression ein Zwei-Minuten-Rückbau ist und kein Neuaufbau.
Notieren Sie Mechanismus, Schlüsseldatei und Richtung für jedes Ende in den Deployment-Notizen, denn sonst liest die nächste Person zwei ähnliche Dateien und nimmt an, die Zahlen müssten zueinander passen. Die Richtung ist ein Koordinationsdetail, kein Sicherheitsupgrade: Sie trennt die beiden Richtungen des Steuerkanals und tut nichts weiter.