Runbook: zwei OpenVPN-Kunden getrennt einbinden

Zwei Kunden auf einem Host klingen nach einem weiteren Serverblock und einem zweiten Port. Es wird ein anderes Projekt, sobald man alles auflistet, was ein Kunde tatsächlich besitzt: einen Listener, einen Tunnel-Pool, eine Identität, Trust-Dateien, Routen und einen Sperrplan. Lässt man eines davon weg, erbt der zweite Kunde stillschweigend ein Stück des ersten. Legen Sie pro Kunde eine Karte an und füllen Sie sie aus, bevor sich der erste Client verbindet.

Weisen Sie jedem Kunden eine vollständige Ressourcenkarte zu

Reservieren Sie das ganze Set gemeinsam: öffentlicher Port, Tunnel-Subnetz, Konfigurationspfad, Logziel, Name der Dienstinstanz und Gerät. Die Benennung als Gruppe verhindert die klassische Kopie einer funktionierenden Datei, die noch den Pool oder das Interface des ersten Kunden enthält. Die Werte sind Beispiele, keine reservierten Ports, prüfen Sie also, was der Host bereits nutzt. Ein Dienst, der startet, ist nicht dasselbe wie ein Kunde, der vollständig ist.

Bewahren Sie die Karte neben der Konfiguration auf und aktualisieren Sie sie bei jeder Wertänderung. Dokumentation, die von der Realität abdrifftet, ist schlimmer als keine.

Halten Sie Vertrauensmaterial innerhalb jedes Kunden

Eine separate ausstellende Stelle pro Kunde macht die Grenze leicht nachvollziehbar und hält den Signaturschlüssel vom internetzugewandten Host fern. Eine gemeinsame Root kann auch funktionieren, aber ein gemeinsamer Anker macht aus zwei Diensten keine gemeinsame Mitgliedschaftsdomäne. Legen Sie fest, welche Ketten jeder Listener akzeptiert und welche Client-Identitäten er autorisiert, und schreiben Sie beides auf. Entfernen Sie Zertifikate nicht per Versuch und Irrtum aus einer Kette, bis etwas sich verbindet.

Der eigene private Schlüssel des Servers gehört in eine geschützte Datei pro Kunde, nicht in ein Vorlagenverzeichnis, das zusammen mit der Konfiguration repliziert wird.

Trennen Sie die Netze ebenso wie die Prozesse

Zwei Prozesse auf zwei Ports teilen sich weiterhin einen Host und eine Routing-Tabelle, solange Sie sie nicht trennen. Bestätigen Sie, was lauscht, bevor Sie dem Design trauen.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

Die Listener-Prüfung zeigt, welcher Prozess welchen öffentlichen Port besitzt, und die Verifikation zeigt, ob ein Client-Zertifikat zum vorgesehenen Anker führt. Keine der Ausgaben beweist, dass der Client von A das Subnetz von B nicht erreichen kann, definieren Sie also Quell- und Zielpolitik, Rückrouten und jeden bewusst geteilten Dienst. Netzwerk-Namespaces oder Container trennen Routing-Kontexte und verringern versehentliche Vermischung, aber sie sind keine vollständige Mandantengrenze für sich allein. Wählen Sie einen stärkeren Isolationsmechanismus, wenn das Bedrohungsmodell es verlangt.

Liefern Sie die Sperrung vor der Übergabe aus

Ein Zertifikats-Rollout ist unvollständig, bis die Sperrung einen Auslieferungsweg hat. Prüfen Sie Aussteller und Gültigkeitsfenster der CRL als Teil des Onboardings.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

Die CRL-Prüfung meldet, wann die Liste ausgestellt wurde und wann sie abläuft, und der Dienststatus bestätigt, dass die Instanz läuft, die sie liest. Erneuern Sie die Liste nach dem Zeitplan der Ausstellungsrichtlinie, auch wenn nichts Neues gesperrt wurde, denn eine abgelaufene CRL kann jeden Client ablehnen. Veröffentlichen Sie eine vollständige Datei, statt Leser auf einen teilweisen Schreibvorgang treffen zu lassen, und validieren Sie die Signatur vor dem Ausrollen. Halten Sie fest, wer Ausstellung, Endpunktbetrieb und Außerbetriebnahme besitzt, damit das Abschalten von Kunde A nicht B stört.

Führen Sie dann das Abnahmepaar aus: Ein erlaubter Client erreicht seinen eigenen Dienst, und eine A-Berechtigung wird vom Listener von B abgelehnt. Das ist die Grenze, als Test ausgedrückt.