Kann eine OpenVPN-Verbindung mit statischem Schlüssel mehrere Clients bedienen?

Der Modus mit statischem Schlüssel verbindet genau zwei Peers, und das ist sein Entwurf, keine Einschränkung, die jemand aufzuheben vergaß. client-to-client ist eine Weiterleitungsoption im Servermodus, daher ändert ihr Hinzufügen zu einer --secret Konfiguration nichts daran, wie viele Clients sich verbinden können. Die Entscheidung ist nicht, welches Flag hinzugefügt wird, sondern ob die Bereitstellung eine Punkt-zu-Punkt-Verbindung oder einen Dienst für mehrere Clients braucht. Wenn sich mehrere Geräte unabhängig verbinden müssen, ändert sich der Schutzmodus, und jedes Gerät erhält eine Identität.

Zwei Peers, ein Schlüssel und kein Zustand pro Client: diese Form ist die ganze Geschichte des Modus.

Wofür der Modus mit statischem Schlüssel gedacht ist

Im Geheimnis-Modus teilen beide Peers eine Schlüsseldatei, und dieser Schlüssel schützt den Verkehr direkt. Es gibt keinen Handshake, keinen Zertifikatsaustausch und keine Sitzung pro Client, weil es keine Clients im Server-Sinn gibt, nur zwei Endpunkte.

Der Modus bleibt für ein festes Maschinenpaar mit dokumentiertem Schlüsselrotationsverfahren nützlich, und OpenVPN 2.6 kennzeichnet ihn gerade deshalb als veraltet, weil der TLS-Modus diese Fälle mit besseren Eigenschaften abdeckt. Was er nicht kann, ist ein verbindendes Gerät von einem anderen zu unterscheiden, da der Besitz der Datei die gesamte Authentifizierungsgeschichte ist. Ein drittes Gerät hinzuzufügen bedeutet, denselben Schlüssel mit ihm zu teilen, wonach die ersten beiden es nicht mehr von sich selbst unterscheiden können.

Deshalb ist die Grenze von zwei Peers strukturell und keine Einstellung, die man ändern könnte.

Warum client-to-client nicht das fehlende Teil ist

client-to-client steuert, ob verbundene Clients Verkehr über den Server austauschen dürfen. Es lässt keine Clients zu, vergibt keine Identitäten und erzeugt keinen Servermodus, der nicht konfiguriert wurde, und in einer Konfiguration mit statischem Schlüssel gibt es keine Clientliste, die es verwalten könnte.

Die andere häufige Verwechslung betrifft Material für tls-crypt oder tls-auth. Ein TLS-Server kann einen dieser Schlüssel an alle Clients verteilen, weil er den Steuerkanal schützt, statt zu beweisen, wer welcher Client ist. Ein gemeinsam genutzter Steuerkanalschlüssel im TLS-Modus ist ein anderes Objekt als ein gemeinsam genutzter statischer Datenschlüssel, obwohl beide als Dateien ankommen, die ähnlich aussehen.

Die Wahl zwischen den Modi läuft auf zwei Fragen hinaus. Muss sich mehr als ein Gerät unabhängig verbinden, und braucht die Bereitstellung einen Widerruf pro Gerät? Ein Nein auf beides hält den Modus mit statischem Schlüssel lebensfähig; ein Ja auf eines von beidem weist auf TLS. Es gibt keine dritte Option, in der ein zweiter Client ohne eigene Identität zugelassen wird.

Den Server für mehrere Clients aufbauen

Ein Server für mehrere Clients braucht den TLS-Modus, ein serverseitiges Zertifikat und eine Identität pro Client. Der Serverhelfer richtet den Adresspool und den Mehrclient-Modus ein, liefert aber nicht die TLS-Konfiguration, den Vertrauensanker oder die Clientzertifikate, die eine Zulassung aussagekräftig machen.

Tragen Sie jedes Gerät über die bestehende Zertifizierungsstelle ein, statt die Anmeldedaten eines Clients zu kopieren. Eindeutige Identitäten ermöglichen Widerruf, Routing pro Client und brauchbare Protokolle, und ein einziges gemeinsam genutztes Clientzertifikat bringt alle drei zum Einsturz.

Wenn die Bereitstellung Benutzer über ein externes Verzeichnis oder einen zweiten Faktor authentifiziert, bleibt dieses Design wie es ist. Der Wechsel in den TLS-Servermodus entscheidet, wie sich Peers auf der Tunnelschicht ausweisen, und er schreibt das Konto-Backend nicht vor. Halten Sie die beiden Entscheidungen getrennt, damit eine Änderung in der einen nicht stillschweigend die andere verändert.

Entscheiden Sie dann die Weiterleitungsrichtlinie bewusst. client-to-client aktiviert Verkehr zwischen Clients im Serverpfad im Benutzerraum, was viele Bereitstellungen wollen und manche nicht haben dürfen. Es ist ein Richtlinien-Schalter, kein Identitätsmechanismus, und er sollte eingeschaltet werden, weil der Entwurf es verlangt, nicht weil ein Tutorial ihn enthielt.

Prüfen, ob die Clients wirklich unabhängig sind

Verbinden Sie zwei Clients und bestätigen Sie, dass sie unterschiedliche Adressen erhalten und mit unterschiedlichen Identitäten im Protokoll des Servers erscheinen. Widerrufen Sie dann einen und bestätigen Sie, dass der andere weiter funktioniert, was der praktische Test dafür ist, dass die Identitäten nicht geteilt wurden.

Testen Sie den erlaubten Dienst zwischen den Peers und einen, der blockiert bleiben soll. Zwei erfolgreiche Anmeldungen belegen die Zulassung, nicht die Isolation, und der Unterschied zählt, wenn die Bereitstellung Benutzergruppen trennen soll.

Lesen Sie schließlich den Servermodus aus der laufenden Konfiguration statt aus dem Gedächtnis. Eine Konfiguration mit statischem Schlüssel und zusätzlichen Optionen ist weiterhin eine Punkt-zu-Punkt-Verbindung, und ein korrekter TLS-Server ist die einzige Anordnung, in der mehrere Clients wirklich getrennte Peers sind.

Wenn das Protokoll einen gemeinsamen Namen für jedes Gerät zeigt, ist nicht der Modus das Problem. Das Problem ist der Eintragungsprozess.