Statischer Schlüssel oder TLS für eine OpenVPN-Verbindung zwischen zwei Peers?

Zwei Maschinen, die nur miteinander sprechen, können diese Topologie beibehalten und trotzdem ausgehandelte Verkehrsschlüssel erhalten. Netzform und Schutzmodus sind unabhängige Entscheidungen, und ihre Vermischung ist der Grund, warum Leute versuchen, ein statisches Geheimnis zu rotieren, indem sie eine Datei austauschen, während beide Daemons weiterlaufen. Der Austausch der Schlüsseldatei unter einem laufenden Paar rotiert nichts. Der Static-Key-Modus, den OpenVPN 2.6 als veraltet kennzeichnet, hält einen Schlüssel für die Lebensdauer des Tunnels, sodass Datei auf der Platte und Schlüssel im Speicher erst nach einem Neustart beider Enden wieder übereinstimmen. Wenn automatische Erneuerung die Anforderung ist, muss sich der Schutzmodus ändern.

Was der Static-Key-Modus nicht kann

Im Secret-Modus teilen beide Peers einen vorab geteilten Schlüssel, der den Tunnel direkt verschlüsselt und authentifiziert. Es gibt keinen Handshake, also keinen Mechanismus, mit dem eine Seite neues Schlüsselmaterial vorschlagen, eine Identität beweisen oder sich ohne Eingreifen des Betreibers von einer Abweichung erholen könnte. Beide Eigenschaften folgen aus dem Fehlen eines Steuerkanals und nicht aus einer fehlenden Option, und kein Konfigurationsschalter fügt diesem Modus einen hinzu.

Das OpenVPN-2.6-Handbuch sagt ausdrücklich, dass der Schlüssel bestehen bleibt, bis ein neuer erzeugt wird. Das ist akzeptabel für eine Laborverbindung oder ein festes Gerätepaar mit dokumentiertem Rotationsverfahren und inakzeptabel, wo ein langlebiges Geheimnis ein echtes Risiko darstellt. Ein Dateiaustausch erzeugt keinen neuen Schlüssel für ein laufendes Paar; er erzeugt zwei Peers, die sich widersprechen. Das Ersetzen der Datei fügt daher einen Ausfall hinzu, ohne eine Rotation hinzuzufügen.

Es gibt auch keinen Begriff von Peer-Identität jenseits des Besitzes der Datei. Wer den Schlüssel hat, ist ein Peer, und nichts im Tunnel hält fest, welche Seite welche ist, daher ist Widerruf alles oder nichts.

Umstieg auf TLS ohne Neuentwurf der Verbindung

Der TLS-Modus fügt einen Steuerkanal hinzu und damit die Fähigkeit, Schlüssel des Datenkanals auszuhandeln. In einer Punkt-zu-Punkt-Bereitstellung übernimmt eine Seite die Serverrolle und die andere die Clientrolle, aber die Topologie bleibt eine Verbindung zwischen zwei Peers: Jede Seite kennt den Endpunkt der anderen, und es erscheint kein Pool und kein Mehrbenutzerdienst. Die Rollen sind ein Handshake-Detail, keine neue Architektur.

Geben Sie jeder Maschine eine eigene Identität. Jede Seite braucht ein Zertifikat und einen privaten Schlüssel, den Vertrauensanker, der die andere validiert, und eine Peer-Verifikationsregel, die benennt, wer erwartet wird. Verwenden Sie nicht den privaten Schlüssel des einen Peers auf dem anderen, um Zeit zu sparen; das macht aus zwei Identitäten eine und entfernt die Möglichkeit, jede Seite getrennt zu widerrufen. Die Registrierung ist der Ort, um das richtig zu machen, denn eine spätere Korrektur bedeutet, Zertifikate neu auszustellen.

Halten Sie den Netzwerkvertrag unverändert, während sich der Schutz ändert. Dieselben Tunneladressen, Routen und erlaubten Dienste sollten vorher und nachher gelten, damit ein Fehler während der Migration ein Schutzproblem ist und keine getarnte Routing-Überraschung. Schreiben Sie die Adressen und Routen vor der Änderung auf; sie danach zu vergleichen ist schneller, als sie aus dem Gedächtnis zu rekonstruieren.

Manche Bereitstellungen schützen auch den Steuerkanal mit einem eigenen statischen Schlüssel, der nicht mit dem Datenkanal rotiert. Dieser Schlüssel bewacht den Handshake statt der Nutzlast, sodass eine Kompromittierung die Aushandlung und nicht den Verkehr offenlegt. Bewahren Sie ihn getrennt vom Datenkanalmaterial auf und geben Sie ihm ein Ersetzungsdatum, das eine benannte Person verantwortet. Ihn zu rotieren bedeutet, beide Peers in einem koordinierten Fenster neu zu starten, weshalb er einen Kalendereintrag und nicht eine Erinnerung verdient.

Wer was erneuert, und wann

Im TLS-Modus wird die Erneuerung durch konfigurierte Grenzen gesteuert: ein Zeitintervall, eine Byteanzahl oder eine Paketanzahl. Die dokumentierte Zeitsteuerung ist das, worauf sich die meisten Bereitstellungen verlassen, und der niedrigere effektive Wert über beide Peers kann die Ersetzung auslösen, sodass eine Erhöhung nur auf einer Seite das Ereignis nicht aufhält. Volumenbasierte Grenzen existieren, weil eine ausgelastete Verbindung einen Schlüssel lange vor der Uhr erschöpfen kann. Keine der Grenzen ist eine Zustandsprüfung, und keine sagt Ihnen, dass eine Erneuerung erfolgreich war.

Deshalb ist es irreführend, eine wiederkehrende Neuverhandlung aus einer einzigen Konfigurationsdatei zu diagnostizieren. Lesen Sie die Einstellungen auf beiden Peers und schauen Sie dann auf den Übergang im Protokoll, statt einen Fehler anzunehmen. Eine Erneuerung, die sauber abgeschlossen wird, sieht wie ein kurzer Schub Steuerkanalverkehr aus, nicht wie eine Trennung.

Halten Sie die Objekte im Kopf getrennt. Das Zertifikat beweist langfristige Identität und wird nach einem Zeitplan ersetzt, den Sie kontrollieren. Der Datenkanalschlüssel wird automatisch erneuert, und ein separater Authentifizierungsaustausch, falls die Bereitstellung einen verlangt, folgt der Kontorichtlinie und kann eigene Regelungen für spätere Austausche brauchen.

Die Erneuerung ganz zu deaktivieren, indem das Intervall auf null gesetzt wird, ist keine Lösung für ein lautes Protokoll. Es verwandelt ein gesundes Lebenszyklusereignis in einen dauerhaften Schlüssel, was Sie zu der Eigenschaft zurückbringt, die Sie hinter sich lassen wollten.

Die Änderung annehmen

Bauen Sie die neue Konfiguration aus dem unterstützten Beispiel der installierten Version statt aus einem alten minimalen Schnipsel, dessen Algorithmen und Dateipfade von woanders übernommen wurden. Koordinieren Sie den Wechsel so, dass beide Peers gemeinsam wechseln, und halten Sie einen genehmigten Wiederherstellungsweg bereit, falls eine Seite nicht hochkommt. Bringen Sie die Verbindung bewusst herunter, statt auf einen Ausfall zu warten, um den Rollback zu testen. Ein geübter Rollback ist mehr wert als ein beschriebener.

Testen Sie drei Dinge: die anfängliche Identitätsprüfung gelingt, der beabsichtigte Anwendungsfluss funktioniert, und eine kontrollierte Erneuerung geschieht ohne Verkehrsverlust. Lesen Sie dann den Übergang im Protokoll daraufhin, was er tatsächlich beweist: Eine neue Schlüsselkennung bedeutet, dass die Peers eine Ersetzung abgeschlossen haben, nicht dass der Tunnel sich neu verbunden hat. Behandeln Sie ihn als Beleg für einen Schritt und prüfen Sie die Verkehrszähler, bevor Sie die Migration für abgeschlossen erklären.

Was ein Versprechen ohne Unterbrechung verbergen würde, ist der Fehler, den Sie noch nicht gesehen haben. Eine fehlgeschlagene Erneuerung, ein ablaufendes Zertifikat oder ein Pfadfehler können die Verbindung weiterhin stören, und keiner davon wird durch einen sauberen Testlauf ausgeschlossen. Die Eigenschaft, für die es sich zu entwerfen lohnt, ist enger und nützlicher: Der routinemäßige Schlüsselaustausch hört auf, ein manueller Dateiaustausch zu sein.