Fehlerbehebung bei AWS Client VPN - AWS Client VPN

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Fehlerbehebung bei AWS Client VPN

Das folgende Thema kann Ihnen bei der Behebung von Problemen helfen, die mit einem Client VPN-Endpunkt auftreten könnten.

Weitere Informationen zur Fehlerbehebung bei OpenVPN-basierter Software, mit der Clients eine Verbindung zu einem Client VPN herstellen, finden Sie unter Fehlerbehebung bei Ihrer Client-VPN-Verbindung im Benutzerhandbuch zu AWS Client VPN .

DNS-Name des Client-VPN-Endpunkts konnte nicht aufgelöst werden

Problem

Ich kann den DNS-Namen des Client-VPN-Endpunkts nicht auflösen.

Ursache

Die Client-VPN-Endpunktkonfigurationsdatei enthält einen Parameter mit dem Namen remote-random-hostname. Dieser Parameter zwingt den Client, dem DNS-Namen eine zufällige Zeichenfolge voranzustellen, um das DNS-Caching zu verhindern. Einige Clients erkennen diesen Parameter nicht und stellen daher dem DNS-Namen nicht die erforderliche zufällige Zeichenfolge voran.

Lösung

Öffnen Sie die Client-VPN-Endpunktkonfigurationsdatei mit Ihrem bevorzugten Texteditor. Suchen Sie die Zeile, die den Client VPN-Endpunkt-DNS-Namen angibt. Stellen Sie ihm eine zufällige Zeichenfolge voran. Das Format lautet zufällige_zeichenfolge.angezeigter_DNS_name. Zum Beispiel:

  • Ursprünglicher DNS-Name: cvpn-endpoint-0102bc4c2eEXAMPLE.clientvpn.us-west-2.amazonaws.com

  • Geänderter DNS-Name: asdfa.cvpn-endpoint-0102bc4c2eEXAMPLE.clientvpn.us-west-2.amazonaws.com

Der Datenverkehr wird nicht zwischen Subnetzen aufgeteilt.

Problem

Ich versuche, den Netzwerkdatenverkehr zwischen zwei Subnetze aufzuteilen. Privater Datenverkehr sollte durch ein privates Subnetz geroutet werden, während Internet-Datenverkehr durch ein öffentliches Subnetz geroutet werden sollte. Es wird nur eine Route verwendet, obwohl ich beide Routen in die Client-VPN-Endpunkt-Routing-Tabelle aufgenommen habe.

Ursache

Sie können einem Client-VPN-Endpunkt mehrere Subnetze zuweisen, aber Sie können nur ein Subnetz pro Availability Zone zuweisen. Der Zweck der mehrfachen Subnetz-Zuordnung ist die Bereitstellung von Hochverfügbarkeits- und Availability Zone-Redundanz für Clients. Mit dem Client-VPN können Sie den Datenverkehr jedoch nicht selektiv zwischen den Subnetze aufteilen, die dem Client-VPN-Endpunkt zugeordnet sind.

Clients stellen eine Verbindung zu einem Client-VPN-Endpunkt basierend auf dem DNS-Round-Robin-Algorithmus her. Das bedeutet, dass ihr Datenverkehr durch jedes der zugehörigen Subnetze geroutet werden kann, wenn sie eine Verbindung herstellen. Daher kann es zu Verbindungsproblemen kommen, wenn sie in einem zugehörigen Subnetz landen, das nicht über die erforderlichen Routingeinträge verfügt.

Angenommen, Sie konfigurieren beispielsweise die folgenden Subnetz-Zuordnungen und Routen:

  • Subnetzzuordnungen

    • Zuordnung 1: Subnetz-A (us-ost-1a)

    • Zuordnung 2: Subnetz-B (us-ost-1b)

  • Routen

    • Route 1: 10.0.0.0/16 geroutet zu Subnetz-A

    • Route 2: 172.31.0.0/16 geroutet zu Subnetz-B

In diesem Beispiel können Clients, die beim Verbindungsaufbau in Subnetz-A landen, nicht auf Route 2 zugreifen, während Clients, die beim Verbindungsaufbau in Subnetz-B landen, nicht auf Route 1 zugreifen können.

Lösung

Vergewissern Sie sich, dass der Client-VPN-Endpunkt dieselben Routeneinträge mit Zielen für jedes zugehörige Netzwerk hat. Dadurch wird sichergestellt, dass Clients Zugriff auf alle Routen haben, unabhängig vom Subnetz, durch das ihr Datenverkehr geroutet wird.

Autorisierungsregeln für Active Directory-Gruppen, die nicht wie erwartet funktionieren

Problem

Ich habe Autorisierungsregeln für meine Active Directory-Gruppen konfiguriert, aber sie funktionieren nicht wie erwartet. Ich habe eine Autorisierungsregel für 0.0.0.0/0 hinzugefügt, um den Datenverkehr für alle Netzwerke zu autorisieren, aber für bestimmte Ziel-CIDRs schlägt der Datenverkehr immer noch fehl.

Ursache

Autorisierungsregeln werden für Netzwerk-CIDRs festgelegt. Autorisierungsregeln müssen Active Directory-Gruppen Zugriff auf bestimmte Netzwerk-CIDRs gewähren. Autorisierungsregelnn für 0.0.0.0/0 werden als Sonderfall behandelt und daher als letzte ausgewertet, unabhängig von der Reihenfolge, in der die Autorisierungsregelnn erstellt werden.

Angenommen, Sie erstellen drei Autorisierungsregeln in der folgenden Reihenfolge:

  • Regel 1: Zugriff Gruppe 1 auf 10.1.0.0/16

  • Regel 2: Zugriff Gruppe 1 auf 0.0.0.0/0

  • Regel 3: Zugriff Gruppe 2 auf 0.0.0.0/0

  • Regel 4: Zugriff Gruppe 3 auf 0.0.0.0/0

  • Regel 5: Zugriff Gruppe 2 auf 172.131.0.0/16

In diesem Beispiel werden Regel 2, Regel 3 und Regel 4 zuletzt ausgewertet. Gruppe 1 hat nur Zugriff auf 10.1.0.0/16. Gruppe 2 hat nur Zugriff auf 172.131.0.0/16. Gruppe 3 hat keinen Zugriff auf 10.1.0.0/16 oder 172.131.0.0/16, aber sie hat Zugriff auf alle anderen Netzwerke. Wenn Sie Regel 1 und 5 entfernen, haben alle drei Gruppen Zugriff auf alle Netzwerke.

Client VPN verwendet bei der Auswertung von Autorisierungsregeln das längste übereinstimmende Präfix. Weitere Details finden Sie in unter Routenpriorität im Benutzerhandbuch zu Amazon VPC.

Lösung

Vergewissern Sie sich, dass Sie Autorisierungsregeln erstellen, die Active Directory-Gruppen explizit Zugriff auf bestimmte Netzwerk-CIDRs gewähren. Wenn Sie eine Autorisierungsregel für 0.0.0.0/0 hinzufügen, denken Sie daran, dass diese zuletzt ausgewertet wird und dass vorherige Autorisierungsregeln die Netzwerke, auf die sie Zugriff gewährt, einschränken können.

Clients können nicht auf eine Peered-VPC, Amazon S3 oder das Internet zugreifen.

Problem

Ich habe meine Client-VPN-Endpunkt-Routen korrekt konfiguriert, aber meine Clients können nicht auf eine Peer-VPC, Amazon S3 oder das Internet zugreifen.

Lösung

Das folgende Flussdiagramm enthält die Schritte zur Diagnose von Internet-, Peer-VPC- und Amazon S3-Verbindungsproblemen.

Schritte zur Fehlerbehebung bei Client-VPN
  1. Für den Zugriff auf das Internet fügen Sie eine Autorisierungsregel für 0.0.0.0/0 hinzu.

    Für den Zugriff auf eine Peer-VPC fügen Sie der VPC eine Autorisierungsregel für den IPv4-CIDR-Bereich hinzu.

    Geben Sie für den Zugriff auf S3 die IP-Adresse des Amazon S3-Endpunkts an.

  2. Prüfen Sie, ob Sie in der Lage sind, den DNS-Namen aufzulösen.

    Wenn Sie den DNS-Namen nicht auflösen können, vergewissern Sie sich, dass Sie die DNS-Server für den Client-VPN-Endpunkt angegeben haben. Wenn Sie Ihren eigenen DNS-Server verwalten, geben Sie seine IP-Adresse an. Vergewissern Sie sich, dass der DNS-Server von der VPC aus zugänglich ist.

    Wenn Sie sich nicht sicher sind, welche IP-Adresse für die DNS-Server angegeben werden soll, geben Sie den VPC-DNS-Resolver unter der IP-Adresse „.2“ in Ihrer VPC an.

  3. Überprüfen Sie für Internetzugang, ob Sie eine öffentliche IP-Adresse oder eine öffentliche Website wie amazon.com pingen können. Wenn Sie keine Antwort erhalten, stellen Sie sicher, dass die Routing-Tabelle für die zugehörigen Subnetze eine Standardroute hat, die entweder auf ein Internet-Gateway oder ein NAT-Gateway verweist. Wenn die Route vorhanden ist, vergewissern Sie sich, dass das zugeordnete Subnetz nicht über Netzwerkzugriffskontrolllistenregeln verfügt, die den ein- und ausgehenden Datenverkehr blockieren.

    Wenn Sie eine Peer-VPC nicht erreichen können, überprüfen Sie, ob die Routing-Tabelle des zugehörigen Subnetze einen Routeneintrag für die Peer-VPC enthält.

    Wenn Sie Amazon S3 nicht erreichen können, überprüfen Sie, ob die Routing-Tabelle des zugehörigen Subnetzes einen Routeneintrag für den Gateway-VPC-Endpunkt enthält.

  4. Prüfen Sie, ob Sie mit einem Payload von mehr als 1400 Bytes eine öffentliche IP-Adresse anpingen können. Verwenden Sie einen der folgenden Befehle:

    • Windows

      C:\> ping 8.8.8.8 -l 1480 -f
    • Linux

      $ ping -s 1480 8.8.8.8 -M do

    Wenn Sie eine IP-Adresse mit einer Nutzlast von mehr als 1400 Bytes nicht per Ping erreichen können, öffnen Sie die .ovpn-Konfigurationsdatei für den Client-VPN-Endpunkt mit Ihrem bevorzugten Texteditor und fügen Sie Folgendes hinzu.

    mssfix 1328

Der Zugriff auf eine Peer-VPC, Amazon S3 oder das Internet erfolgt nur mit Unterbrechungen.

Problem

Ich habe zeitweilige Verbindungsprobleme, wenn ich eine Verbindung mit einer Peer-VPC, Amazon S3 oder dem Internet herstelle, aber der Zugriff auf das entsprechende Subnetz ist davon nicht betroffen. Ich muss die Verbindung trennen und wiederherstellen, um die Verbindungsprobleme zu lösen.

Ursache

Clients stellen eine Verbindung zu einem Client-VPN-Endpunkt basierend auf dem DNS-Round-Robin-Algorithmus her. Das bedeutet, dass ihr Datenverkehr durch jedes der zugehörigen Subnetze geroutet werden kann, wenn sie eine Verbindung herstellen. Daher kann es zu Verbindungsproblemen kommen, wenn sie in einem zugehörigen Subnetz landen, das nicht über die erforderlichen Routingeinträge verfügt.

Lösung

Vergewissern Sie sich, dass der Client-VPN-Endpunkt dieselben Routeneinträge mit Zielen für jedes zugehörige Netzwerk hat. Dadurch wird sichergestellt, dass Clients Zugriff auf alle Routen haben, unabhängig vom zugehörigen Subnetz, durch das ihr Datenverkehr geroutet wird.

Angenommen, Ihr Client-VPN-Endpunkt hat drei zugeordnete Subnetze (Subnetz A, B und C), und Sie möchten Ihren Clients den Internetzugriff ermöglichen. Dazu müssen Sie drei 0.0.0.0/0-Routen hinzufügen - eine, die auf jedes zugehörige Subnetz verweist:

  • Route 1: 0.0.0.0/0 für Subnetz A

  • Route 2: 0.0.0.0/0 für Subnetz B

  • Route 3: 0.0.0.0/0 für Subnetz C

Client-Software gibt TLS-Fehler zurück

Problem

Früher konnte ich meine Clients erfolgreich mit dem Client-VPN verbinden, aber jetzt gibt der OpenVPN-basierte Client einen der folgenden Fehler zurück, wenn er versucht, eine Verbindung herzustellen:

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) TLS Error: TLS handshake failed
Connection failed because of a TLS handshake error. Contact your IT administrator.
Mögliche Ursache 1

Wenn Sie die gegenseitige Authentifizierung verwenden und eine Client-Zertifikat-Widerrufsliste importiert haben, ist die Client-Zertifikat-Widerrufsliste möglicherweise abgelaufen. Während der Authentifizierungsphase prüft der Client-VPN-Endpunkt das Client-Zertifikat anhand der von Ihnen importierten Client-Zertifikat-Widerrufsliste. Wenn die Widerrufsliste für Client-Zertifikate abgelaufen ist, können Sie keine Verbindung mit dem Client-VPN-Endpunkt herstellen.

Lösung 1

Überprüfen Sie das Ablaufdatum Ihrer Client-Zertifikat-Widerrufsliste mit dem OpenSSL-Tool.

$ openssl crl -in path_to_crl_pem_file -noout -nextupdate

Die Ausgabe zeigt das Ablaufdatum und die Uhrzeit an. Wenn die Widerrufsliste für Client-Zertifikate abgelaufen ist, müssen Sie eine neue Liste erstellen und sie für den Client-VPN-Endpunkt importieren. Weitere Informationen finden Sie unter Client-Zertifikatsperrlisten.

Mögliche Ursache 2

Das für den Client-VPN-Endpunkt verwendete Serverzertifikat ist abgelaufen.

Lösung 2

Überprüfen Sie den Status Ihres Serverzertifikats in der AWS Certificate Manager Konsole oder mithilfe der AWS CLI. Wenn das Serverzertifikat abgelaufen ist, erstellen Sie ein neues Zertifikat und laden Sie es auf ACM hoch. Ausführliche Schritte zum Generieren der Server- und Client-Zertifikate und Schlüssel unter Verwendung des OpenVPN-Dienstprogramms easy-rsa sowie zu deren Import in ACM finden Sie unter Gegenseitige Authentifizierung.

Alternativ könnte ein Problem mit der OpenVPN-basierten Software bestehen, die der Client zur Verbindung mit dem Client-VPN verwendet. Weitere Informationen zur Fehlerbehebung bei OpenVPN-basierter Software finden Sie unter Fehlerbehebung für Ihre Client-VPN-Verbindung im Benutzerhandbuch zu AWS Client VPN .

Client-Software gibt Fehler zum Benutzernamen und Passwort zurück (Active Directory-Authentifizierung)

Problem

Ich verwende die Active Directory-Authentifizierung für meinen Client-VPN-Endpunkt und konnte meine Clients früher erfolgreich mit dem Client-VPN verbinden. Jetzt erhalten die Clients jedoch Fehler zu ungültigen Benutzernamen und Passwörtern.

Mögliche Ursachen

Wenn Sie die Active Directory-Authentifizierung verwenden und Multi-Factor Authentication (MFA) aktiviert haben, nachdem Sie die Client-Konfigurationsdatei verteilt haben, enthält die Datei nicht die erforderlichen Informationen, um Benutzer zur Eingabe ihres MFA-Codes aufzufordern. Die Benutzer werden aufgefordert, nur ihren Benutzernamen und ihr Passwort einzugeben, und die Authentifizierung schlägt fehl.

Lösung

Laden Sie eine neue Client-Konfigurationsdatei herunter und verteilen Sie sie an Ihre Clients. Vergewissern Sie sich, dass die neue Datei die folgende Zeile enthält.

static-challenge "Enter MFA code " 1

Weitere Informationen finden Sie unter Exportieren und Konfigurieren der Client-Konfigurationsdatei. Testen Sie die MFA-Konfiguration für Ihr Active Directory, ohne den Client-VPN-Endpunkt zu verwenden, um zu überprüfen, ob MFA wie erwartet funktioniert.

Client-Software gibt Fehler bei Benutzernamen und Passwörtern zurück (Verbundauthentifizierung)

Problem

Der Versuch, sich mit einem Benutzernamen und einem Passwort mit Verbundauthentifizierung anzumelden und die Fehlermeldung „Die empfangenen Anmeldeinformationen waren falsch“ zu erhalten. Wenden Sie sich an Ihren IT-Administrator.“

Ursache

Dieser Fehler kann dadurch verursacht werden, dass nicht mindestens ein Attribut in der SAML-Antwort vom IdP enthalten ist.

Lösung

Stellen Sie sicher, dass mindestens ein Attribut in der SAML-Antwort des IdP enthalten ist. Weitere Informationen finden Sie unter Konfigurationsressourcen für SAML-basierte IdPs.

Clients können keine Verbindung herstellen (gegenseitige Authentifizierung)

Problem

Ich verwende die gegenseitige Authentifizierung für meinen Client-VPN-Endpunkt. Clients erhalten bei fehlgeschlagenen TLS-Schlüsselaushandlungen und Zeitüberschreitungsfehler Fehler.

Mögliche Ursachen

Die Konfigurationsdatei, die den Clients zur Verfügung gestellt wurde, enthält nicht das Client-Zertifikat und den privaten Schlüssel des Clients, oder das Zertifikat und der Schlüssel sind falsch.

Lösung

Stellen Sie sicher, dass die Konfigurationsdatei das richtige Client-Zertifikat und den richtigen Schlüssel enthält. Korrigieren Sie gegebenenfalls die Konfigurationsdatei und verteilen Sie sie erneut an Ihre Clients. Weitere Informationen finden Sie unter Exportieren und Konfigurieren der Client-Konfigurationsdatei.

Client gibt einen Fehler zurück, der besagt, dass die Anmeldeinformationen die maximale Größe überschreiten (Verbundauthentifizierung)

Problem

Ich verwende die Verbundauthentifizierung für meinen Client-VPN-Endpunkt. Wenn Clients ihren Benutzernamen und ihr Passwort im Browserfenster des SAML-basierten Identitätsanbieters (IdP) eingeben, wird ein Fehler angezeigt, dass die Anmeldeinformationen die maximal unterstützte Größe überschreiten.

Ursache

Die vom IdP zurückgegebene SAML-Antwort überschreitet die maximal unterstützte Größe. Weitere Informationen finden Sie unter Anforderungen und Überlegungen für die SAML-basierte Verbundauthentifizierung.

Lösung

Versuchen Sie, die Anzahl der Gruppen zu reduzieren, zu denen der Benutzer im IdP gehört, und versuchen Sie erneut, eine Verbindung herzustellen.

Client öffnet den Browser nicht (Verbundauthentifizierung)

Problem

Ich verwende die Verbundauthentifizierung für meinen Client-VPN-Endpunkt. Wenn Clients versuchen, eine Verbindung mit dem Endpunkt herzustellen, öffnet die Client-Software kein Browserfenster, sondern zeigt stattdessen ein Pop-up-Fenster für Benutzername und Passwort an.

Ursache

Die Konfigurationsdatei, die den Clients zur Verfügung gestellt wurde, enthält das auth-federate-Flag nicht.

Lösung

Exportieren Sie die neueste Konfigurationsdatei , importieren Sie sie in den von AWS bereitgestellten Client und versuchen Sie erneut, eine Verbindung herzustellen.

Client gibt einen Fehler zurück, der besagt, dass keine Ports verfügbar sind (Verbundauthentifizierung)

Problem

Ich verwende die Verbundauthentifizierung für meinen Client-VPN-Endpunkt. Wenn Clients versuchen, eine Verbindung mit dem Endpunkt herzustellen, gibt die Client-Software den folgenden Fehler zurück:

The authentication flow could not be initiated. There are no available ports.
Ursache

Der AWS von bereitgestellte Client erfordert die Verwendung von TCP-Port 35001, um die Authentifizierung abzuschließen. Weitere Informationen finden Sie unter Anforderungen und Überlegungen für die SAML-basierte Verbundauthentifizierung.

Lösung

Vergewissern Sie sich, dass das Client-Gerät den TCP-Port 35001 nicht blockiert oder für einen anderen Prozess verwendet.

VPN-Verbindung aufgrund von IP-Nichtübereinstimmung beendet

Problem

Die VPN-Verbindung wurde beendet und die Client-Software gibt den folgenden Fehler zurück: "The VPN connection is being terminated due to a discrepancy between the IP address of the connected server and the expected VPN server IP. Please contact your network administrator for assistance in resolving this issue."

Ursache

Der AWS von bereitgestellte Client erfordert, dass die IP-Adresse, mit der er verbunden ist, mit der IP des VPN-Servers übereinstimmt, der den Client-VPN-Endpunkt unterstützt. Weitere Informationen finden Sie unter Regeln und bewährte Methoden von AWS Client VPN.

Lösung

Stellen Sie sicher, dass zwischen dem von AWS bereitgestellten Client und dem Client-VPN-Endpunkt kein DNS-Proxy vorhanden ist.

Weiterleiten von Datenverkehr an LAN funktioniert nicht wie erwartet

Problem

Der Versuch, den Datenverkehr nicht wie erwartet an das lokale Netzwerk (LAN) weiterzuleiten, wenn sich die LAN-IP-Adressbereiche nicht innerhalb der folgenden privaten Standard-IP-Adressbereiche befinden: 10.0.0.0/8, 172.16.0.0/12192.168.0.0/16, oder 169.254.0.0/16.

Ursache

Wenn festgestellt wird, dass der Client-LAN-Adressbereich außerhalb des oben genannten Standardbereichs liegt, überträgt der Client-VPN-Endpunkt automatisch die OpenVPN-Richtlinie „redirect-gateway block-local“ an den Client und erzwingt den gesamten LAN-Datenverkehr in das VPN. Weitere Informationen finden Sie unter Regeln und bewährte Methoden von AWS Client VPN.

Lösung

Wenn Sie während VPN-Verbindungen LAN-Zugriff benötigen, wird empfohlen, die oben aufgeführten herkömmlichen Adressbereiche für Ihr LAN zu verwenden.

Überprüfen des Bandbreitenlimits für einen Client-VPN-Endpunkt

Problem

Ich muss das Bandbreitenlimit für einen Client-VPN-Endpunkt überprüfen.

Ursache

Der Durchsatz hängt von mehreren Faktoren ab, z. B. von der Kapazität Ihrer Verbindung von Ihrem Standort aus und der Netzwerklatenz zwischen Ihrer Client-VPN-Desktop-Anwendung auf Ihrem Computer und dem VPC-Endpunkt. Es gibt auch ein Bandbreitenlimit von 10 Mbit/s pro Benutzerverbindung.

Lösung

Führen Sie die folgenden Befehle aus, um die Bandbreite zu überprüfen.

sudo iperf3 -s -V

Auf dem Client:

sudo iperf -c server IP address -p port -w 512k -P 60