EC2 Windows: VPN-Client, VPN-Server oder AWS-Gateway?
Eine Windows-EC2-Instanz kann VPN-Software ausführen, aber ein Client, ein selbst verwalteter Server und ein AWS-Gateway sind verschiedene Rollen mit verschiedenen Eigentümern.
Ein Team braucht VPN-Konnektivität für eine App auf einer Windows-EC2-Instanz, findet kompatible Client-Software, installiert sie und fragt dann, warum der Rest des VPC sie nicht nutzen kann. Die Installation hat funktioniert; die Rolle wurde nie entschieden. Software, die innerhalb eines Gasts läuft, kann ein Client sein, der einem fremden Netzwerk beitritt, ein Server, der andere Clients annimmt, oder keines der von AWS verwalteten VPN-Produkte, und jede Rolle hinterlässt andere Arbeit bei Ihnen.
Das Symptom ist meist die falsche Rolle
Das übliche Symptom ist ein funktionierender Tunnel, der das falsche Problem löst. Ein Client in der VM gibt dieser VM einen ausgehenden Pfad; er gibt Ihrem Laptop, Ihrem Büro oder einem anderen Subnetz keinen Weg hinein. Ein Server in der VM gibt anderen einen Weg hinein, aber jetzt besitzen Sie den Listener, die Authentifizierung und die Weiterleitung.
Verwaltete Dienste verlagern den Dienstbetrieb zu AWS und lassen das Design bei Ihnen. Site-to-Site VPN verbindet Netzwerke über ein Kundengateway und ein AWS-Gateway, und Client VPN gibt entfernten Geräten einen verwalteten Endpunkt. In beiden Fällen sind die Routen, die Autorisierungsregeln und die Identitätsquelle Ihre Konfiguration, und keines der Produkte installiert einen Allzweck-Client in einem Windows-Gast.
Vier Formen sind möglich, und die Tabelle trennt sie danach, was sich womit verbindet und wer die Betriebslast trägt.
| Role | What connects | Who owns the VPN software |
|---|---|---|
| Client in the Windows VM | This VM dials out into someone else's network | You, plus the software vendor |
| Server in the Windows VM | Inbound clients and sites attach to this VM | You, end to end |
| AWS Site-to-Site VPN | Two networks meet through a customer gateway and an AWS gateway | AWS operates the tunnels; you own the peer and route design |
| AWS Client VPN | User devices attach to an endpoint AWS operates | AWS operates it; you own the access rules |
Lesen Sie die Zeile statt den Produktnamen: dieselbe Windows-Instanz kann in zwei verschiedenen Zeilen stehen, je nachdem, welche Software darin läuft.
Client in der VM: die VM tritt einem Netzwerk bei
Ein ausgehender Client muss den Windows-Build, die Architektur und die Treiberanforderungen prüfen lassen, bevor irgendetwas installiert wird. Der Client ändert Routen und DNS auf der Instanz, was bereits laufende Dienste beeinflussen kann, einschließlich des Pfads, den Sie für die Fernadministration nutzen. Notieren Sie den Adapternamen und die Interface-Metrik, die der Client setzt, denn das neue Interface kann Vorrang vor dem bestehenden bekommen. Wenn die Instanz über einen Session Manager statt über SSH oder RDP verwaltet wird, bestätigen Sie, dass dieser Pfad nach dem Verbinden des Clients noch funktioniert.
Entscheiden Sie, welchen Verkehr der Client tragen soll, bevor Sie ihn aktivieren. Ein voller Tunnel kann die Verwaltungssitzung einfangen und Sie aussperren, und ein geteilter Tunnel kann die Instanz das private Netzwerk erreichen lassen, während ihr übriger Verkehr einen anderen Ausgang nimmt. Testen Sie mit einem zweiten verfügbaren Verwaltungspfad und notieren Sie die Routen, die der Client installiert, damit eine spätere Änderung erklärbar ist.
Server in der VM: andere Clients treten ihm bei
Bei einem selbst verwalteten Server besitzen Sie den Listener, das Zertifikat- oder Schlüsselmaterial, die Benutzerdatenbank und die Weiterleitungsregeln. Wenn der Server Verkehr für andere Clients weiterleitet, wird die Instanz zum Router, und das erfordert Weiterleitung auf Gast-Ebene plus Änderungen an Routen und Sicherheitsgruppen auf AWS-Ebene.
Prüfen Sie den Listener aus dem Gast und erneut aus einem anderen Subnetz, dann prüfen Sie einen Host, für den die Instanz weiterleitet. Ein gesunder lokaler Dienst beweist nichts über den weitergeleiteten Pfad, also halten Sie beide Ergebnisse im Änderungsvermerk fest.
Verwaltete Gateways behalten den Dienst, nicht Ihr Zugriffsdesign
AWS Site-to-Site VPN dokumentiert die Tunnelrollen von Kundengateway und AWS-Gateway, und der Kauf dieser Verbindung ersetzt nicht jedes Fernzugriffsdesign. Client VPN dokumentiert einen verwalteten Endpunkt mit Client-Personas, während die Autorisierungsregeln und Zielrouten Ihre bleiben. AWS hält den Endpunkt und seine Zertifikate am Laufen; wer welche Anwendung erreichen darf, ist weiterhin eine Autorisierungsregel, die Sie schreiben und pflegen.
Wählen Sie zwischen den Produkten auf fünf Achsen: welche Rolle jedes spielt, welche Protokolle es akzeptiert, welche Identitätsquelle es erwartet, wie Verkehr weitergeleitet wird und wie Verfügbarkeit bereitgestellt wird. Ignorieren Sie jede einzelne Durchsatzzahl aus einem Forumsbeitrag, denn die veröffentlichte Kapazität ändert sich mit dem Dienst. Und gehen Sie nicht davon aus, dass ein verwaltetes Tunnelpaar das Verhalten eines beliebigen Gastclients ändert.
Wählen Sie die Rolle vor dem Produkt
Schreiben Sie einen Satz, der die Richtung benennt: diese VM tritt einem Netzwerk bei, diese VM nimmt Clients an, oder ein AWS-Gateway verbindet definierte Netzwerke.
Dieser Satz entscheidet die Produktauswahl, den Eigentümer der Software und die Fehlerbilder, die Sie debuggen werden. Wenn die Anforderung ist, dass entfernte Benutzer eine Anwendung erreichen, ist ein in der VM der Anwendung installierter Client die falsche Form. Wenn die Anforderung ist, dass eine VM ein Partnernetzwerk erreicht, ist ein verwaltetes Site-to-Site-Gateway mehr Maschinerie, als die Aufgabe braucht. Beide Antworten sind legitim; nur eine passt zu dem Satz, den Sie geschrieben haben.