AWS Client VPN oder ein VPN auf EC2: ein Betriebshandbuch

Beide Optionen geben Ihrem Team ein Fernzugriffs-VPN, die interessante Frage ist also nicht, welche es gibt, sondern welche Sie betreiben können. Der Unterschied liegt darin, wem der Endpunkt um 3 Uhr nachts gehört und welche Kontrollen Sie erreichen, wenn etwas kaputtgeht. Arbeiten Sie die fünf Schritte unten der Reihe nach ab, denn jeder kann den Vergleich früh beenden. Wer den Inventarschritt überspringt, migriert am Ende zweimal.

Schritt 1: die Anforderung vor der Rechnung schreiben

Sie brauchen fünf Fakten auf einer Seite: wer sich wogegen authentifiziert, welche Client-Plattformen funktionieren müssen, welche privaten Ziele erreichbar sind, welche Verfügbarkeit Sie zugesagt haben und wie der Verkehr tatsächlich aussieht. Ohne diese Angaben wird jede spätere Gegenüberstellung zur Diskussion über eine Funktionsliste.

Seien Sie konkret bei den Zielen. „Zugriff auf die VPC“ bedeutet meist drei verschiedene Dinge: das VPC-CIDR, ein gepeertes Netzwerk und einen lokalen Bereich hinter einem Transit Gateway. Ein verwalteter Endpunkt erreicht alle drei, aber jedes Ziel braucht eine Route und eine Autorisierungsregel, und jedes ist eine eigene Zeile in Ihrer Anforderung.

Schritt 2: auflisten, was bereits läuft

Bevor Sie irgendetwas entwerfen, listen Sie die vorhandenen Endpunkte und jeden auf EC2 gehosteten Server samt seinen Sicherheitsgruppen auf. Diese Aufrufe sind reine Lesezugriffe und sicher von einem Konto mit describe-Berechtigungen auszuführen.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

Lesen Sie die Ausgabe als Karte dessen, was Clients bereits erreichen. Eine fehlende Autorisierungsregel erklärt einen Ausfall, der wie ein Routingproblem aussieht, und ein Endpunkt, der einer einzelnen Subnetz zugeordnet ist, erklärt, warum ein Zonenfehler den gesamten Dienst lahmlegte.

Notieren Sie auch die Sicherheitsgruppen, die an einer selbst betriebenen Instanz hängen. Diese Regeln sind Teil des Zugriffsmodells und das Erste, was still bricht, wenn jemand eine Instanz aus einer Vorlage neu aufbaut.

Schritt 3: die Verantwortlichkeiten aufteilen

Der verwaltete Dienst besitzt die Endpunktflotte, deren Patchversorgung und deren Verfügbarkeit innerhalb der Region. Sie besitzen die Identitätsanmeldung, die Autorisierungsregeln, die Netzwerkpfade hinter dem Endpunkt, die Protokollkonfiguration und die Entscheidung, wie viele Subnetze zugeordnet werden.

Selbstbetrieb kehrt das um. Sie besitzen das Gastbetriebssystem, den VPN-Daemon und seine Konfiguration, Zertifikate und Schlüssel, Sicherungen, Überwachung und Wiederherstellung. Das Sicherheitsmodell von EC2 legt Gast- und Anwendungssicherheit beim Kunden ab, und ein VPN-Server ist ein Gast wie jeder andere.

Schreiben Sie die Aufteilung als Tabelle mit Namen in der rechten Spalte auf. Steht bei der Zertifikatserneuerung kein Name, ist das der Befund, und er wiegt schwerer als der Unterschied pro Stunde.

Schritt 4: gegen eine Arbeitslast vergleichen, die Sie beschreiben können

Kosten folgen der Form, nicht der Größe. Für die verwaltete Option zählen Sie Endpunkt-Zuordnungsstunden, Client-Verbindungsstunden, Transfer sowie die Identitäts- und Protokolldienste, die Sie aktivieren. Für den Selbstbetrieb zählen Sie Rechenleistung, Speicher, Netzwerk, Lizenzen und die Ingenieurszeit, die den Server gepatcht hält. Legen Sie beide Zahlenreihen in ein Blatt mit demselben Zeithorizont. Ein Dreijahresvergleich, der Patchstunden ignoriert, begünstigt immer den Server, den Sie bereits besitzen.

Leistungsvergleiche brauchen dieselbe Disziplin. Eine interaktive Desktop-Sitzung, ein großer Transfer und fünfzig gleichzeitige kleine Anfragen belasten unterschiedliche Teile des Pfades: die CPU für die Verschlüsselung, die Netzwerkfähigkeit der Instanz, den eigenen Stack des Clients und das Ziel. Testen Sie mit repräsentativen Clients und derselben Aufgabe in beiden Designs.

Eine größere Instanz ist kein Beweis, dass ein Transfer schneller wird, und eine erfolgreiche Sitzung ist kein Kapazitätsplan. Behandeln Sie jedes geerbte Instanzfamilien-Gerede als zu prüfende Hypothese, nicht als Einkaufsregel.

Schritt 5: mit einem erprobten Rückrollen umstellen

Betreiben Sie beide Endpunkte für einen festgelegten Zeitraum parallel, verteilen Sie das neue Clientprofil zuerst an eine kleine Gruppe und lassen Sie die Autorisierungsregeln des alten Endpunkts unangetastet, bis die Gruppe das neue Profil für echte Arbeit genutzt hat. Rückrollen ist ein Profilwechsel, kein Neuaufbau, entscheiden Sie also jetzt, wo das alte Profil liegt.

Prüfen Sie in dieser Reihenfolge: die Authentifizierung gelingt, der Client erhält die erwarteten Routen, ein autorisiertes Ziel antwortet, ein nicht autorisiertes Ziel schlägt fehl, und die Protokolle zeigen beide Ereignisse. Scheitert ein Schritt, halten Sie an und beheben Sie diesen Schritt, statt zur nächsten Clientgruppe überzugehen. Schreiben Sie das Ergebnis jeder Prüfung auf, denn eine Umstellung, an die man sich nur als „hat funktioniert“ erinnert, lässt sich einen Monat später nicht mehr debuggen.

Planen Sie nach der Umstellung die langweiligen Prüfungen: Zertifikatsablauf, Anzahl der Zuordnungen, Autorisierungsregeln, die nicht mehr zu einer Gruppe passen, und die Verbindungszahl gegen Ihre Erwartung. Der Administrationsleitfaden für Client VPN ist die Referenz für die Endpunkt-, Authentifizierungs- und Routingteile, die Sie konfiguriert haben.