Problembehandlung: interner Fehler bei der Gateway-Aktivierung - AWS Storage Gateway
Beheben Sie Fehler bei der Aktivierung Ihres Gateways über einen öffentlichen EndpunktBeheben Sie Fehler bei der Aktivierung Ihres Gateways über einen VPC Amazon-EndpunktBeheben Sie Fehler, wenn Sie Ihr Gateway über einen öffentlichen Endpunkt aktivieren und sich dort ein Storage Gateway VPC Gateway-Endpunkt befindet VPC

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.

Problembehandlung: interner Fehler bei der Gateway-Aktivierung

Storage Gateway Gateway-Aktivierungsanforderungen durchlaufen zwei Netzwerkpfade. Eingehende Aktivierungsanfragen, die von einem Client gesendet werden, stellen über Port 80 eine Verbindung zur virtuellen Maschine (VM) oder Amazon Elastic Compute Cloud (AmazonEC2) -Instance des Gateways her. Wenn das Gateway die Aktivierungsanfrage erfolgreich empfängt, kommuniziert das Gateway mit den Storage Gateway Gateway-Endpunkten, um einen Aktivierungsschlüssel zu erhalten. Wenn das Gateway die Storage Gateway Gateway-Endpunkte nicht erreichen kann, antwortet das Gateway dem Client mit einer internen Fehlermeldung.

Verwenden Sie die folgenden Informationen zur Fehlerbehebung, um zu ermitteln, was zu tun ist, wenn Sie beim Versuch, Ihren AWS Storage Gateway zu aktivieren, eine interne Fehlermeldung erhalten.

Anmerkung

  • Stellen Sie sicher, dass Sie neue Gateways mit der neuesten VM-Image-Datei oder Amazon Machine Image (AMI) -Version bereitstellen. Sie erhalten eine interne Fehlermeldung, wenn Sie versuchen, ein Gateway zu aktivieren, das ein AMI veraltetes verwendet.

  • Stellen Sie sicher, dass Sie den richtigen Gateway-Typ auswählen, den Sie bereitstellen möchten, bevor Sie den herunterladenAMI. Die OVA-Dateien AMIs für jeden Gateway-Typ sind unterschiedlich und nicht austauschbar.

Beheben Sie Fehler bei der Aktivierung Ihres Gateways über einen öffentlichen Endpunkt

Um Aktivierungsfehler bei der Aktivierung Ihres Gateways über einen öffentlichen Endpunkt zu beheben, führen Sie die folgenden Prüfungen und Konfigurationen durch.

Überprüfen Sie die erforderlichen Ports

Vergewissern Sie sich bei lokal bereitgestellten Gateways, dass die Ports auf Ihrer lokalen Firewall geöffnet sind. Überprüfen Sie bei Gateways, die auf einer EC2 Amazon-Instance bereitgestellt werden, ob die Ports in der Sicherheitsgruppe der Instance geöffnet sind. Um zu überprüfen, ob die Ports geöffnet sind, führen Sie auf dem öffentlichen Endpunkt von einem Server aus einen Telnet-Befehl aus. Dieser Server muss sich im selben Subnetz wie das Gateway befinden. Mit den folgenden Telnet-Befehlen wird beispielsweise die Verbindung zu Port 443 getestet:

telnet d4kdq0yaxexbo.cloudfront.net 443
telnet storagegateway.region.amazonaws.com 443
telnet dp-1.storagegateway.region.amazonaws.com 443
telnet proxy-app.storagegateway.region.amazonaws.com 443
telnet client-cp.storagegateway.region.amazonaws.com 443
telnet anon-cp.storagegateway.region.amazonaws.com 443

Um zu überprüfen, ob das Gateway selbst den Endpunkt erreichen kann, greifen Sie auf die lokale VM-Konsole des Gateways zu (für lokal bereitgestellte Gateways). Oder Sie können SSH zur Instanz des Gateways wechseln (für Gateways, die bei Amazon bereitgestellt werdenEC2). Führen Sie dann einen Netzwerkverbindungstest durch. Vergewissern Sie sich, dass der Test zurückkehrt[PASSED]. Weitere Informationen finden Sie unter Testen Ihrer Gateway-Verbindung zum Internet.

Anmerkung

Der Standard-Anmeldename für die Gateway-Konsole lautetadmin, und das Standardkennwort istpassword.

Stellen Sie sicher, dass die Firewall-Sicherheit keine Pakete verändert, die vom Gateway an die öffentlichen Endpunkte gesendet werden

SSLInspektionen, Deep Packet Inspections oder andere Formen der Firewall-Sicherheit können die vom Gateway gesendeten Pakete beeinträchtigen. Der SSL Handshake schlägt fehl, wenn das SSL Zertifikat so geändert wird, wie es der Aktivierungsendpunkt erwartet. Um sicherzustellen, dass keine SSL Überprüfung im Gange ist, führen Sie auf dem Hauptaktivierungsendpunkt (anon-cp.storagegateway.region.amazonaws.com) an Port 443 den SSL Befehl Öffnen aus. Sie müssen diesen Befehl von einem Computer aus ausführen, der sich im selben Subnetz wie das Gateway befindet:

$ openssl s_client -connect  anon-cp.storagegateway.region.amazonaws.com:443 -servername anon-cp.storagegateway.region.amazonaws.com
Anmerkung

Ersetzen region mit deinem AWS-Region.

Wenn keine SSL Inspektion im Gange ist, gibt der Befehl eine Antwort zurück, die der folgenden ähnelt:

$ openssl s_client -connect anon-cp.storagegateway.us-east-2.amazonaws.com:443 -servername anon-cp.storagegateway.us-east-2.amazonaws.com
CONNECTED(00000003)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = anon-cp.storagegateway.us-east-2.amazonaws.com
verify return:1
---
Certificate chain
 0 s:/CN=anon-cp.storagegateway.us-east-2.amazonaws.com
   i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
 1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
   i:/C=US/O=Amazon/CN=Amazon Root CA 1
 2 s:/C=US/O=Amazon/CN=Amazon Root CA 1
   i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
 3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
   i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
---

Wenn eine laufende SSL Inspektion stattfindet, zeigt die Antwort eine veränderte Zertifikatskette, die der folgenden ähnelt:

$ openssl s_client -connect  anon-cp.storagegateway.ap-southeast-1.amazonaws.com:443 -servername anon-cp.storagegateway.ap-southeast-1.amazonaws.com
CONNECTED(00000003)
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.ap-southeast-1.amazonaws.com
   i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com
---

Der Aktivierungsendpunkt akzeptiert SSL Handshakes nur, wenn er das SSL Zertifikat erkennt. Das bedeutet, dass der ausgehende Datenverkehr des Gateways zu den Endpunkten von Inspektionen ausgenommen werden muss, die von Firewalls in Ihrem Netzwerk durchgeführt werden. Bei diesen Inspektionen kann es sich um eine SSL Inspektion oder eine Deep Packet Inspection handeln.

Überprüfen Sie die Gateway-Zeitsynchronisierung

Übermäßige Zeitverschiebungen können zu SSL Handshake-Fehlern führen. Bei lokalen Gateways können Sie die lokale VM-Konsole des Gateways verwenden, um die Zeitsynchronisierung Ihres Gateways zu überprüfen. Der Zeitversatz sollte nicht größer als 60 Sekunden sein. Weitere Informationen finden Sie unter .

Die Option System Time Management ist auf Gateways, die auf EC2 Amazon-Instances gehostet werden, nicht verfügbar. Um sicherzustellen, dass EC2 Amazon-Gateways die Zeit ordnungsgemäß synchronisieren können, stellen Sie sicher, dass die EC2 Amazon-Instance über die Ports UDP und TCP 123 eine Verbindung zur folgenden NTP Serverpool-Liste herstellen kann:

  • 0.amazon.pool.ntp.org

  • 1.amazon.pool.ntp.org

  • 2.amazon.pool.ntp.org

  • 3.amazon.pool.ntp.org

Beheben Sie Fehler bei der Aktivierung Ihres Gateways über einen VPC Amazon-Endpunkt

Um Aktivierungsfehler bei der Aktivierung Ihres Gateways über einen Amazon Virtual Private Cloud (AmazonVPC) -Endpunkt zu beheben, führen Sie die folgenden Prüfungen und Konfigurationen durch.

Überprüfen Sie die erforderlichen Ports

Stellen Sie sicher, dass die erforderlichen Ports innerhalb Ihrer lokalen Firewall (für lokal bereitgestellte Gateways) oder Sicherheitsgruppe (für in Amazon bereitgestellte GatewaysEC2) geöffnet sind. Die Ports, die für die Verbindung eines Gateways mit einem Storage Gateway VPC Gateway-Endpunkt erforderlich sind, unterscheiden sich von denen, die für die Verbindung eines Gateways mit öffentlichen Endpunkten erforderlich sind. Die folgenden Ports sind für die Verbindung mit einem Storage Gateway VPC Gateway-Endpunkt erforderlich:

  • TCP443

  • TCP1026

  • TCP1027

  • TCP1028

  • TCP1031

  • TCP2222

Weitere Informationen finden Sie unter Erstellen eines VPC Endpunkts für Storage Gateway.

Überprüfen Sie außerdem die Sicherheitsgruppe, die an Ihren Storage Gateway VPC Gateway-Endpunkt angehängt ist. Die dem Endpunkt zugeordnete Standardsicherheitsgruppe lässt möglicherweise die erforderlichen Ports nicht zu. Erstellen Sie eine neue Sicherheitsgruppe, die Datenverkehr aus dem IP-Adressbereich Ihres Gateways über die erforderlichen Ports zulässt. Fügen Sie dann diese Sicherheitsgruppe dem VPC Endpunkt hinzu.

Anmerkung

Verwenden Sie die VPCAmazon-Konsole, um die Sicherheitsgruppe zu überprüfen, die mit dem VPC Endpunkt verbunden ist. Sehen Sie sich Ihren Storage Gateway VPC Gateway-Endpunkt von der Konsole aus an und wählen Sie dann die Registerkarte Sicherheitsgruppen.

Um zu überprüfen, ob die erforderlichen Ports geöffnet sind, können Sie Telnet-Befehle auf dem Storage Gateway VPC Gateway-Endpunkt ausführen. Sie müssen diese Befehle von einem Server aus ausführen, der sich im selben Subnetz wie das Gateway befindet. Sie können die Tests für den DNS Vornamen ausführen, der keine Availability Zone angibt. Mit den folgenden Telnet-Befehlen werden beispielsweise die erforderlichen Portverbindungen mit dem DNS Namen vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com getestet:

telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 443
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1026
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1027
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1028
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1031
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 2222

Stellen Sie sicher, dass die Firewall-Sicherheit keine Pakete verändert, die vom Gateway an Ihren Storage Gateway VPC Amazon-Endpunkt gesendet werden.

SSLInspektionen, Deep Packet Inspections oder andere Formen der Firewall-Sicherheit können die vom Gateway gesendeten Pakete beeinträchtigen. Der SSL Handshake schlägt fehl, wenn das SSL Zertifikat so geändert wird, wie es der Aktivierungsendpunkt erwartet. Um sicherzustellen, dass keine SSL Inspektion im Gange ist, führen Sie auf Ihrem Storage Gateway VPC Gateway-Endpunkt den SSL Befehl Öffnen aus. Sie müssen diesen Befehl von einem Computer aus ausführen, der sich im selben Subnetz wie das Gateway befindet. Führen Sie den Befehl für jeden erforderlichen Port aus:

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:443 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1026 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1028 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1031 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:2222 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

Wenn keine SSL Überprüfung im Gange ist, gibt der Befehl eine Antwort zurück, die der folgenden ähnelt:

openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = anon-cp.storagegateway.us-east-1.amazonaws.com
verify return:1
---
Certificate chain
 0 s:CN = anon-cp.storagegateway.us-east-1.amazonaws.com
   i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
   i:C = US, O = Amazon, CN = Amazon Root CA 1
 2 s:C = US, O = Amazon, CN = Amazon Root CA 1
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
   i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
---

Wenn eine laufende SSL Inspektion stattfindet, zeigt die Antwort eine veränderte Zertifikatskette, die der folgenden ähnelt:

openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.us-east-1.amazonaws.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.us-east-1.amazonaws.com
   i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com
---

Der Aktivierungsendpunkt akzeptiert SSL Handshakes nur, wenn er das SSL Zertifikat erkennt. Das bedeutet, dass der ausgehende Datenverkehr des Gateways zu Ihrem VPC Endpunkt über die erforderlichen Ports von den Inspektionen Ihrer Netzwerk-Firewalls ausgenommen ist. Bei diesen Inspektionen kann es sich um SSL Inspektionen oder Deep-Packet-Inspektionen handeln.

Überprüfen Sie die Gateway-Zeitsynchronisierung

Übermäßige Zeitverschiebungen können zu SSL Handshake-Fehlern führen. Bei lokalen Gateways können Sie die lokale VM-Konsole des Gateways verwenden, um die Zeitsynchronisierung Ihres Gateways zu überprüfen. Der Zeitversatz sollte nicht größer als 60 Sekunden sein. Weitere Informationen finden Sie unter .

Die Option System Time Management ist auf Gateways, die auf EC2 Amazon-Instances gehostet werden, nicht verfügbar. Um sicherzustellen, dass EC2 Amazon-Gateways die Zeit ordnungsgemäß synchronisieren können, stellen Sie sicher, dass die EC2 Amazon-Instance über die Ports UDP und TCP 123 eine Verbindung zur folgenden NTP Serverpool-Liste herstellen kann:

  • 0.amazon.pool.ntp.org

  • 1.amazon.pool.ntp.org

  • 2.amazon.pool.ntp.org

  • 3.amazon.pool.ntp.org

Suchen Sie nach einem HTTP Proxy und bestätigen Sie die zugehörigen Sicherheitsgruppeneinstellungen

Prüfen Sie vor der Aktivierung, ob Sie einen HTTP Proxy bei Amazon auf der lokalen Gateway-VM als Squid-Proxy auf Port 3128 EC2 konfiguriert haben. Bestätigen Sie in diesem Fall Folgendes:

  • Die an den HTTP Proxy bei Amazon angehängte Sicherheitsgruppe EC2 muss über eine Regel für eingehenden Datenverkehr verfügen. Diese Regel für eingehenden Datenverkehr muss Squid-Proxyverkehr auf Port 3128 von der IP-Adresse der Gateway-VM aus zulassen.

  • Die mit dem EC2 VPC Amazon-Endpunkt verknüpfte Sicherheitsgruppe muss Regeln für eingehenden Datenverkehr haben. Diese Regeln für eingehenden Datenverkehr müssen den Verkehr auf den Ports 1026-1028, 1031, 2222 und 443 von der IP-Adresse des Proxys bei Amazon zulassen. HTTP EC2

Beheben Sie Fehler, wenn Sie Ihr Gateway über einen öffentlichen Endpunkt aktivieren und sich dort ein Storage Gateway VPC Gateway-Endpunkt befindet VPC

Um Fehler bei der Aktivierung Ihres Gateways über einen öffentlichen Endpunkt zu beheben, wenn sich dort ein Amazon Virtual Private Cloud (AmazonVPC) -Endpoint befindetVPC, führen Sie die folgenden Prüfungen und Konfigurationen durch.

Vergewissern Sie sich, dass die Einstellung Private DNS Namen aktivieren auf Ihrem Storage Gateway VPC Gateway-Endpunkt nicht aktiviert ist

Wenn „Privaten DNS Namen aktivieren“ aktiviert ist, können Sie keine Gateways von dort VPC zum öffentlichen Endpunkt aktivieren.

So deaktivieren Sie die Option für private DNS Namen:

  1. Öffnen Sie die VPCAmazon-Konsole.

  2. Wählen Sie im Navigationsbereich Endpunkte aus.

  3. Wählen Sie Ihren Storage Gateway VPC Gateway-Endpunkt.

  4. Wählen Sie Aktionen.

  5. Wählen Sie Private DNS Namen verwalten aus.

  6. Deaktivieren Sie für DNS „Privaten Namen aktivieren“ die Option „Für diesen Endpunkt aktivieren“.

  7. Wählen Sie Private DNS Namen ändern, um die Einstellung zu speichern.