Von Access Server zu Community OpenVPN: Was neu aufgebaut werden muss

Access Server und Community OpenVPN sprechen dasselbe Protokoll und fast nichts anderes auf dieselbe Weise. Handshake, Cipher-Aushandlung und Datenebene des Tunnels sind kompatibel, sodass ein Client sich oft mit beiden verbinden kann, ohne sein Profil zu bearbeiten. Der Unterschied liegt darin, wem die Konfiguration gehoert: Das eine Produkt liefert eine Verwaltungsschicht, die Richtlinien schreibt und durchsetzt, das andere gibt Ihnen eine Konfigurationsdatei und einige Hooks und erwartet, dass Sie entscheiden.

Dieser Unterschied ist der Migrationsplan. Alles, was das alte Produkt fuer Sie entschieden hat, muss irgendwo im neuen Deployment eine ausdrueckliche Entscheidung werden.

Wo die beiden Deployments aufhoeren, austauschbar zu sein

In Access Server gehoeren der Weboberflaeche Benutzer, Gruppen, Berechtigungen pro Benutzer, Zertifikatsausstellung und das Profilpaket, das eine Person herunterlaedt. Der darunterliegende Daemon wird von dieser Schicht konfiguriert, sodass der laufende Dienst das Produkt eines gespeicherten Zustands ist, den Sie selten von Hand bearbeiten. In Community OpenVPN ist die Konfigurationsdatei der Zustand: Sie benennt den Listener, die Zertifizierungsstelle, den Authentifizierungs-Hook und jede gepushte Option, und nichts schreibt sie fuer Sie um. Dieselbe TLS-Maschinerie steht daher unter zwei sehr unterschiedlichen Eigentumsmodellen.

Eine kurze Zuordnung macht die Luecke konkret. Benutzer und Gruppen existieren nur in der alten Datenbank, bis Sie sie neu anlegen. Profilpakete werden zu einer Konfigurationsdatei plus Zertifikaten, die Sie selbst verteilen. Berechtigungen pro Benutzer werden zu Direktiven in client-config-dir. Die Verwaltungsoberflaeche wird zu welchem Prozess auch immer Sie fuer Zertifikatsausstellung und Dateibearbeitung waehlen.

Schreiben Sie diese Zuordnung auf, bevor Sie einen Server anfassen. Jede Zeile, die Sie nicht fuellen koennen, ist eine Funktion, die Sie verlieren werden, und eine still zu verlieren ist der Weg, auf dem eine Migration zwei Wochen spaeter zu einem Ausfall wird.

Identitaet wird nicht mit den Zertifikatsdateien uebertragen

Zertifikate der alten Stelle koennen im neuen Dienst korrekt geparst werden und trotzdem die falsche Identitaet sein, weil das alte Produkt sie mit Kontozustand verknuepft hat, den das neue nicht sieht. Entscheiden Sie zuerst, ob das neue Deployment allein per Zertifikat authentifiziert, per Plugin, das PAM oder RADIUS erreicht, oder per Kombination, und pruefen Sie dann, ob jede Option die Eigenschaften bewahrt, die Sie brauchen. Ein gemeinsames Zertifikat ohne Identitaet pro Benutzer ist ein Ausweis fuer alle, die es besitzen. Widerruf muss ebenfalls vom ersten Tag an funktionieren, was in Community OpenVPN eine CRL-Datei bedeutet, auf die crl-verify verweist, plus einen Prozess, der sie neu erzeugt.

Planen Sie die Registrierung vor dem Umstieg, nicht danach. Neue Zertifikate, ein getesteter Widerrufspfad und eine dokumentierte Moeglichkeit, eine Person zu deaktivieren, sind Voraussetzungen, keine Nacharbeit. Wenn Multi-Faktor-Authentifizierung aus der Integration des alten Produkts kam, benennen Sie den Ersatz ausdruecklich, denn ein nicht installiertes Plugin schlaegt im schlechtesten Moment geschlossen fehl.

Routen und Namensaufloesung folgen dem, der die Konfiguration schreibt

Routen, DNS-Einstellungen und Volltunnel-Verhalten sind in beiden Produkten gepushte Optionen, aber nur eines berechnet sie fuer Sie. In Community OpenVPN schreiben Sie die Push-Direktiven selbst, entscheiden, ob redirect-gateway auf den Server oder den Client gehoert, und bestaetigen, dass Forwarding und NAT auf dem Host existieren. Ein abgeschlossener Handshake sagt Ihnen nichts ueber Forwarding, Adressuebersetzung oder die Routen, die ein Client tatsaechlich erhalten hat.

Verhalten pro Client braucht client-config-dir plus eine Datei, die nach dem Common Name des Client-Zertifikats benannt ist, und ein Standort-Gegenstueck braucht iroute-Eintraege fuer die Praefixe dahinter. Benennen Sie falsch, werden die Optionen ohne Fehler ignoriert. Testen Sie mit einem Nicht-Produktions-Client in seinem eigenen Adresspool und lesen Sie dann die zugewiesene Adresse, die gegebenen Routen und die Resolver-Einstellungen, mit denen er endete.

Sequenzieren Sie den Umstieg so, dass der alte Dienst zurueckkehren kann

Betreiben Sie den neuen Listener auf einem anderen Port oder einer anderen Adresse und lassen Sie den alten weiter Verkehr bedienen, waehrend Sie den Ersatz beweisen. Zwei Daemons auf einem Socket sind kein Rollback-Plan.

Verschieben Sie jeweils eine Gruppe mit eigenen Zertifikaten, eigenem Pool und eigenen Routen, und proben Sie den Rueckweg, statt ihn waehrend eines Vorfalls zu entdecken. Ein Rollback, der nur funktioniert, wenn der neue Dienst zuerst gestoppt wird, ist immer noch ein Rollback, muss aber getestet werden, waehrend nichts brennt.

Listen Sie schliesslich die Funktionen ohne direktes Aequivalent auf und entscheiden Sie das Schicksal jeder schriftlich: Self-Service-Profil-Download, Berechtigungsflags pro Benutzer, die Verwaltungsoberflaeche selbst, Berichte ueber Live-Verbindungen. Sie durch einen dokumentierten manuellen Prozess zu ersetzen, ist eine legitime Antwort. Die Zeile leer zu lassen, nicht.

Die Arbeit ist getan, wenn ein Benutzer, der das alte Portal nie gesehen hat, sich registrieren, verbinden, die beabsichtigte interne Adresse erreichen und sauber widerrufen werden kann. Alles davor ist Vorbereitung.