Warum das Kopieren der OpenVPN-Serverkonfiguration in eine Filiale scheitert

Die funktionierende Serverkonfiguration kopieren, ein paar Adressen tauschen und das Ganze Filialprofil nennen erzeugt meist eine Verbindung. Das ist das schlechteste Ergebnis, denn die Filiale läuft dann mit der falschen Rolle, legt Material offen, das den Hub nicht verlassen darf, und hinterlässt eine Routenzuordnung, an deren Entstehung sich niemand erinnert. Die Verbindung verbirgt drei Probleme auf einmal, und der Tunnel steht, bevor jemand sie prüft.

Die Filiale als Peer mit eigener Identität und Netzwerkrolle zu behandeln macht das Profil korrekt. Die Lösung ist keine bessere Kopie, und der Rest dieser Seite handelt davon, was ein Client tatsächlich halten sollte.

Zwei Rollen, die wie eine Datei aussehen

Im TLS-Modus haben die beiden Seiten komplementäre Aufgaben. Eine Seite lauscht, hält das Serverzertifikat und den Schlüssel und entscheidet, welche Clients sich verbinden dürfen. Die andere Seite initiiert, prüft den Lauscher und legt ihre eigene Identität vor.

Eine Serverdatei enthält Direktiven, die auf einem Client keinen Sinn ergeben: eine Bind-Adresse und einen Port zum Lauschen, einen Adresspool zum Verteilen und oft eine Push-Liste für Einstellungen, die die Clients erhalten sollen. Diese in eine Filiale zu kopieren erzeugt ein Gerät, das gleichzeitig Lauscher und Client sein will.

Der private Schlüssel ist der Teil, auf den es am meisten ankommt. Ein Client darf niemals den privaten Schlüssel des Servers tragen, und er braucht auch nicht den Signaturschlüssel der CA. Ein CA-Zertifikat ist öffentliches Vertrauensmaterial; der Signaturschlüssel gehört dorthin, wo Zertifikate ausgestellt werden.

Was ein Filialprofil enthalten muss

Ein Filialprofil braucht den entfernten Endpunkt und den Transport, die vertrauenswürdige Serveridentität, das eigene Zertifikat und den Schlüssel der Filiale sowie die Routen und DNS-Einstellungen, die die Filiale tatsächlich benötigt. Nichts sonst ist zwingend.

Halten Sie die Identität der Filiale je Standort getrennt. Zwei Filialen mit einem gemeinsamen Zertifikat bedeuten, dass der Widerruf der einen die andere abschaltet, und die Logs des Hubs können sie nicht unterscheiden. Eine Identität je Standort ist das, was sowohl den Prüfpfad als auch die Widerrufsgeschichte funktionieren lässt.

Seien Sie vorsichtig mit Geräte-Workflows. Das Client-Export-Paket von pfSense erzeugt Profile für geeignete Remote-Access-Kontexte, und seine Serverliste enthält nur Server, die in einem Remote-Access-Modus konfiguriert sind. Ein Site-to-Site-Server eines anderen Modus erscheint nicht, und dieses Fehlen ist eine Information, keine Einladung, die Geheimnisse des Servers zu kopieren.

Wenn das Gerät das benötigte Profil nicht exportiert, nutzen Sie seinen dokumentierten Site-to-Site-Client-Workflow oder bauen Sie das Profil aus dem unterstützten Beispiel der installierten Version. Exportieren Sie eine Serversicherung nur dann in die Filiale, wenn der Plan ist, einen Server wiederherzustellen, was nicht der Fall ist. Eine Sicherung trägt auch das private Material des Hubs, deshalb ist das Verschieben in eine Filiale eine Entscheidung zum Schlüsselumgang und kein Dateitransfer. Lassen Sie sie auf dem Hub und erzeugen Sie die Clientidentität dort, wo Zertifikate ausgestellt werden.

Die Zuordnung zwischen Peer und Netzwerk ist getrennt

Ein Filialclient, der sich erfolgreich verbindet, kann noch keinen Verkehr für sein LAN durchleiten, bis der Hub weiß, dass dieser Peer dieses Präfix besitzt. Diese Zuordnung liegt auf dem Hub, an die Identität des Clients gebunden, und sie ist getrennt von der eigenen Route der Filiale zu den entfernten Netzen. Ohne sie erscheinen die Hosts der Filiale in der Statistik des Tunnels erreichbar und sind es in der Praxis nicht. Das Log des Hubs ist der Ort, an dem bestätigt wird, ob die Zuordnung angewandt wurde.

Eine Route im Betriebssystem des Hubs hinzuzufügen ist nicht dasselbe, wie OpenVPN zu sagen, welcher Client das Präfix besitzt. Ohne die Zuordnung je Client erreicht das Paket die Tunnelschnittstelle und wird verworfen, weil kein Peer das Ziel beansprucht.

Auf der Filialseite ist der entsprechende Bedarf eine Route zu den Netzen, die sie erreichen soll, plus ein LAN-Router, der weiß, wie Verkehr zur Filiale zurückkehrt. Eigentum auf der Serverseite und Zielrouten auf der Clientseite sind verschiedene Objekte, und ein funktionierender Tunnel beweist nur den ersten Sprung. Schreiben Sie beides in die Übergabenotizen der Filiale, denn der nächste Ingenieur wird nur eines davon finden.

Beweisen, dass die Filiale der Peer ist, den Sie meinen

Prüfen Sie die Identität, bevor Sie den Verkehr prüfen. Das Log des Hubs sollte den Common Name des Filialzertifikats zeigen, und die Adresse, die der Client erhielt, sollte zum vorgesehenen Pool oder zur festen Zuweisung passen. Zeigt das Log einen anderen Namen, trägt das Profil die Identität von jemand anderem.

Prüfen Sie dann die Zuordnung, indem Sie eine Anfrage von einem Host der Filiale an eine Ressource auf der Hubseite senden und bestätigen, dass sie mit der erwarteten Quelladresse erfolgreich ist. Testen Sie ein Ziel, das die Filiale nicht erreichen darf, und bestätigen Sie, dass es fehlschlägt, denn eine großzügige Route, die zufällig funktioniert, ist nicht dasselbe wie eine korrekte Richtlinie.

Widerrufen Sie schließlich die Identität der Filiale und bestätigen Sie, dass die Verbindung fehlschlägt, während das eigene Zertifikat des Hubs und andere Standorte weiterarbeiten. Wenn der Widerruf den Hub bricht, wurden Rollen und Identitäten irgendwo geteilt, und das ist der Befund, der zurück in das Design gehört.

Eine fertige Filiale hat eine dokumentierte Identität, ein reines Clientprofil, eine Zuordnung zwischen Peer und Netzwerk auf dem Hub und einen getesteten Rückweg. Text in einer Serverdatei umzudrehen liefert nichts davon.