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. # AWS Site-to-Site VPN Kunden-Gateway-Geräte Ein *Kunden-Gateway-Gerät* ist eine physische oder Software-Appliance, die Ihnen gehört oder die Sie in Ihrem lokalen Netzwerk verwalten (auf Ihrer Seite einer Site-to-Site VPN-Verbindung). Sie oder Ihr Netzwerkadministrator müssen das Gerät so konfigurieren, dass es mit der Site-to-Site VPN-Verbindung funktioniert. Das folgende Diagramm zeigt Ihr Netzwerk, das Kunden-Gateway-Gerät und die VPN-Verbindung, die zu einem Virtual Private Gateway führt, das Ihrer VPC zugewiesen ist. Die beiden Verbindungen zwischen dem Kunden-Gateway und dem Virtual Private Gateway stellen die Tunnel für die VPN-Verbindung dar. Wenn innerhalb des Geräts ein Geräteausfall auftritt AWS, wechselt Ihre VPN-Verbindung automatisch zum zweiten Tunnel, sodass Ihr Zugriff nicht unterbrochen wird. Führt von Zeit zu Zeit AWS auch routinemäßige Wartungsarbeiten an der VPN-Verbindung durch, wodurch einer der beiden Tunnel Ihrer VPN-Verbindung kurzzeitig deaktiviert werden kann. Weitere Informationen finden Sie unter [AWS Site-to-Site VPN Ersatz von Tunnelendpunkten](endpoint-replacements.md). Konfigurieren Sie Ihr Kunden-Gateway-Gerät daher während der Konfiguration unbedingt auf die Verwendung beider Tunnel. ![\[Grundlegende Übersicht zum Kunden-Gateway\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/cgw-high-level.png) Informationen zu den Schritten zum Einrichten einer VPN-Verbindung finden Sie unter [Fangen Sie an mit AWS Site-to-Site VPN](SetUpVPNConnections.md). Während dieses Vorgangs erstellen Sie eine Kunden-Gateway-Ressource in AWS, die Informationen AWS über Ihr Gerät bereitstellt, z. B. seine öffentlich zugängliche IP-Adresse. Weitere Informationen finden Sie unter [Kunden-Gateway-Optionen für Ihre AWS Site-to-Site VPN Verbindung](cgw-options.md). Die Kunden-Gateway-Ressource in konfiguriert oder erstellt das Kunden-Gateway-Gerät AWS nicht. Sie müssen das Gerät selbst konfigurieren. Hier finden Sie softwarebasierte VPN-Anwendungen:[AWS Marketplace](https://aws.amazon.com/marketplace/search/results/ref=brs_navgno_search_box?searchTerms=vpn). # Anforderungen für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät AWS unterstützt eine Reihe von Site-to-Site VPN-Kunden-Gateway-Geräten, für die wir Konfigurationsdateien zum Herunterladen bereitstellen. Eine Liste der unterstützten Geräte und die Schritte zum Herunterladen der Konfigurationsdateien finden Sie unter[Statische und dynamische Routing-Konfigurationsdateien](example-configuration-files.md). Wenn Sie ein Gerät haben, das nicht in der Liste der unterstützten Geräte aufgeführt ist, werden im folgenden Abschnitt die Anforderungen beschrieben, die das Gerät erfüllen muss, um eine Site-to-Site VPN-Verbindung herzustellen. Die Konfiguration Ihres Kunden-Gateway-Geräts umfasst vier zentrale Elemente. Die folgenden Symbole stellen die einzelnen Teile der Konfiguration dar. | | | | --- |--- | | ![\[Symbol für den Austausch von Internet-Schlüsseln\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/IKE.png) | IKE-Sicherheitszuordnung (Internet Key Exchange). Dies ist für den Austausch von Schlüsseln erforderlich, die zur Einrichtung der IPsec Sicherheitsbeziehung verwendet wurden. | | ![\[Internetprotokoll-Sicherheit\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/IPsec.png) | IPsec Sicherheitsverband. Damit wird die Verschlüsselung, die Authentifizierung usw. des Tunnels abgewickelt. | | ![\[Symbol für die Tunnelschnittstelle\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/Tunnel.png) | Tunnelschnittstelle. Dadurch wird der zum und vom Tunnel gehende Datenverkehr empfangen. | | ![\[Border Gateway Protocol\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/BGP.png) | (Optional) BGP-Peering (Border Gateway Protocol). Bei Geräten, die BGP verwenden, tauscht dies Routen zwischen dem Kunden-Gateway-Gerät und dem Virtual Private Gateway aus. | In der folgenden Tabelle sind die Anforderungen für das Kunden-Gateway-Gerät, der zugehörige RFC (als Referenz) und Kommentare zu den Anforderungen aufgeführt. Jede VPN-Verbindung besteht aus zwei separaten Tunneln. Jeder Tunnel enthält eine IKE-Sicherheitsverbindung, eine IPsec Sicherheitsverbindung und ein BGP-Peering. Sie sind auf ein eindeutiges Sicherheitszuordnungspaar (SA) pro Tunnel (ein eingehender und ein ausgehender) und somit auf insgesamt zwei eindeutige SA-Paare für zwei Tunnel (vier) beschränkt. SAs Einige Geräte verwenden ein richtlinienbasiertes VPN und erstellen bis zu viele SAs ACL-Einträge. Daher müssen Sie möglicherweise Ihre Regeln konsolidieren und dann filtern, damit Sie keinen unerwünschten Datenverkehr zulassen. Standardmäßig wird der VPN-Tunnel bei der Generierung von Datenverkehr gestartet und die IKE-Aushandlung von Ihrer Seite der VPN-Verbindung initiiert wird. Sie können die VPN-Verbindung so konfigurieren, dass die IKE-Verhandlung stattdessen von der AWS Seite der Verbindung aus initiiert wird. Weitere Informationen finden Sie unter [AWS Site-to-Site VPN Optionen zur Tunnelinitiierung](initiate-vpn-tunnels.md). VPN-Endpunkte unterstützen die Erstellung neuer Schlüssel und können kurz vor Ablauf von Phase 1 Neuverhandlungen starten, wenn das Kunden-Gateway-Gerät keinen Neuverhandlungsdatenverkehr gesendet hat. | Anforderung | RFC | Kommentare | | --- | --- | --- | | IKE-Sicherheitszuordnung herstellen ![\[IKE\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/IKE.png) | [RFC 2409](https://datatracker.ietf.org/doc/html/rfc2409) [RFC 7296](https://datatracker.ietf.org/doc/html/rfc7296) | Die IKE-Sicherheitsverbindung wird zunächst zwischen dem virtuellen privaten Gateway und dem Kunden-Gateway-Gerät mithilfe eines vorab gemeinsam genutzten Schlüssels oder eines privaten Zertifikats, das AWS Private Certificate Authority als Authentifikator verwendet wird, hergestellt. Wenn es eingerichtet ist, handelt IKE einen kurzlebigen Schlüssel aus, um zukünftige IKE-Nachrichten zu sichern. Die Parameter müssen vollständig übereinstimmen, einschließlich der Verschlüsselungs- und Authentifizierungsparameter. Wenn Sie in eine VPN-Verbindung herstellen AWS, können Sie für jeden Tunnel Ihren eigenen Pre-Shared Key angeben oder einen für Sie AWS generieren lassen. Alternativ können Sie das private Zertifikat angeben, das für Ihr Kunden-Gateway-Gerät verwendet werden AWS Private Certificate Authority soll. Weitere Informationen zum Konfigurieren von VPN-Tunneln finden Sie unter [Tunneloptionen für Ihre AWS Site-to-Site VPN Verbindung](VPNTunnels.md). Die folgenden Versionen werden unterstützt: IKEv1 und IKEv2. Wir unterstützen den Hauptmodus nur mit IKEv1. Der Site-to-Site VPN-Dienst ist eine routenbasierte Lösung. Wenn Sie eine richtlinienbasierte Konfiguration verwenden, müssen Sie Ihre Konfiguration auf eine einzelne Sicherheitszuordnung beschränken. | | Richten Sie IPsec Sicherheitszuordnungen im Tunnelmodus ein ![\[IPsec\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/IPsec.png) | [RFC 4301](https://datatracker.ietf.org/doc/html/rfc4301) | Mithilfe des kurzlebigen IKE-Schlüssels werden Schlüssel zwischen dem Virtual Private Gateway und dem Kunden-Gateway-Gerät eingerichtet, um eine IPsec Sicherheitsverbindung (SA) zu bilden. Der Datenverkehr zwischen den Gateways wird über diese SA ver- und entschlüsselt. Die kurzlebigen Schlüssel, die zur Verschlüsselung des Datenverkehrs innerhalb der IPsec SA verwendet werden, werden von IKE regelmäßig automatisch rotiert, um die Vertraulichkeit der Kommunikation zu gewährleisten. | | Verwenden der AES 128-Bit- oder AES 256-Bit-Verschlüsselungsfunktion | [RFC 3602](https://datatracker.ietf.org/doc/html/rfc3602) | Die Verschlüsselungsfunktion wird verwendet, um den Datenschutz sowohl für IKE als auch für Sicherheitszuordnungen zu gewährleisten. IPsec | | Verwenden Sie die SHA-1- oder SHA-2 (256)-Hash-Funktion | [RFC 2404](https://datatracker.ietf.org/doc/html/rfc2404) | Diese Hashing-Funktion wird verwendet, um sowohl IKE- als auch IPsec Sicherheitszuordnungen zu authentifizieren. | | Verwenden von Diffie-Hellman Perfect Forward Secrecy. | [RFC 2409](https://datatracker.ietf.org/doc/html/rfc2409) | IKE nutzt Diffie-Hellman zur Etablierung der temporären Schlüssel zur Absicherung der gesamten Kommunikation zwischen Kunden-Gateway-Geräten und Virtual Private Gateways. Folgende Gruppen werden unterstützt: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/CGRequirements.html) | | (Dynamisch geroutete VPN-Verbindungen) Verwenden Sie Dead Peer Detection IPsec | [RFC 3706](https://datatracker.ietf.org/doc/html/rfc3706) | Die Nutzung von Dead Peer Detection ermöglicht den VPN-Geräten die schnelle Erkennung von Netzwerkbedingungen, die verhindern, dass Pakete über das Internet zugestellt werden können. Wenn dies auftritt, löschen die Gateways die Sicherheitsaushandlungen und versuchen, neue Aushandlungen zu erstellen. Während dieses Vorgangs wird, wenn möglich, der alternative IPsec Tunnel verwendet. | | (Dynamisch geroutete VPN-Verbindungen) Binden Sie den Tunnel an die logische Schnittstelle (routenbasiertes VPN) ![\[Tunnel\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/Tunnel.png) | Keine | Ihr Gerät muss in der Lage sein, den IPsec Tunnel an eine logische Schnittstelle zu binden. Die logische Schnittstelle umfasst eine IP-Adresse, die zur Etablierung des BGP-Peerings mit dem Virtual Private Gateway verwendet wird. Die logische Schnittstelle sollte keine zusätzliche Kapselung durchführen (z. B. GRE oder IP in IP). Die Schnittstelle sollte mit einer MTU (Maximum Transmission Unit) von 1399 Byte konfiguriert sein. | | (Dynamisch geroutete VPN-Verbindungen) Richten Sie BGP-Peerings ein ![\[BGP\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/BGP.png) | [RFC 4271](https://datatracker.ietf.org/doc/html/rfc4271) | BGP wird zum Austausch von Routen zwischen dem Kunden-Gateway-Gerät und dem Virtual Private Gateway verwendet. Der gesamte BGP-Verkehr wird verschlüsselt und über die IPsec Security Association übertragen. BGP ist für beide Gateways erforderlich, um die IP-Präfixe auszutauschen, die über die SA erreichbar sind. IPsec | [Eine AWS VPN-Verbindung unterstützt Path MTU Discovery (RFC 1191) nicht.](https://datatracker.ietf.org/doc/html/rfc1191) Wenn sich eine Firewall zwischen Ihrem Kunden-Gateway-Gerät und dem Internet befindet, vgl. [Firewall-Regeln für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](FirewallRules.md). # Bewährte Methoden für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät **Verwenden IKEv2** Wir empfehlen dringend, IKEv2 für Ihre Site-to-Site VPN-Verbindung zu verwenden. IKEv2 ist ein einfacheres, robusteres und sichereres Protokoll als IKEv1. Sie sollten es nur verwenden IKEv1 , wenn Ihr Kunden-Gateway-Gerät dies nicht unterstützt IKEv2. Weitere Informationen zu den Unterschieden zwischen IKEv1 und IKEv2 finden Sie in [Anhang A von RFC7296](https://www.rfc-editor.org/rfc/rfc7296#appendix-A). **Zurücksetzen des "Don't Fragment"-Flags (DF) von Paketen** Einige Pakete verfügen über ein Flag namens "Don't Fragment" (DF). Dieses Flag zeigt an, dass das Paket nicht fragmentiert werden soll. Bei Paketen mit dem Flag generieren die Gateways die ICMP-Nachricht "Path MTU Exceeded". In einigen Fällen verfügen Anwendungen nicht über die entsprechenden Mechanismen zur Verarbeitung dieser ICMP-Nachrichten und reduzieren die in jedem Paket übertragene Datenmenge. Einige VPN-Geräte können das DF-Flag übergehen und Pakete bei Bedarf fragmentieren. Wenn Ihr Kunden-Gateway-Gerät über eine solche Möglichkeit verfügt, sollten Sie diese bei Bedarf nutzen. Siehe .[RFC 791](https://datatracker.ietf.org/doc/html/rfc791) für weitere Details. **Fragmentierung von IP-Paketen vor der Verschlüsselung** Wenn Pakete, an die Sie über Ihre Site-to-Site VPN-Verbindung gesendet werden, die MTU-Größe überschreiten, müssen sie fragmentiert werden. Um Leistungseinbußen zu vermeiden, empfehlen wir Ihnen, Ihr Kunden-Gateway-Gerät so zu konfigurieren, dass die Pakete fragmentiert werden, *bevor* sie verschlüsselt werden. Site-to-Site VPN setzt dann alle fragmentierten Pakete wieder zusammen, bevor es sie an das nächste Ziel weiterleitet, um höhere packet-per-second Datenflüsse durch das AWS Netzwerk zu erreichen. Siehe [RFC 4459](https://datatracker.ietf.org/doc/html/rfc4459) für weitere Details. **Stellen Sie sicher, dass die Paketgröße die MTU für Zielnetzwerke nicht überschreitet** Da Site-to-Site VPN alle fragmentierten Pakete, die von Ihrem Kunden-Gateway-Gerät empfangen wurden, wieder zusammensetzt, bevor sie an das nächste Ziel weitergeleitet werden, sollten Sie bedenken, dass Pakete für Zielnetzwerke, in denen diese Pakete als Nächstes weitergeleitet werden, zu size/MTU berücksichtigen sein können, z. B. über Direct Connect oder mit bestimmten Protokollen, wie Radius. **Passen Sie die MTU- und MSS-Größen entsprechend den verwendeten Algorithmen an** TCP-Pakete sind häufig die häufigste Art von Paketen, die Tunnel IPsec überqueren. Site-to-Site VPN unterstützt eine maximale Übertragungseinheit (MTU) von 1446 Byte und eine entsprechende maximale Segmentgröße (MSS) von 1406 Byte. Verschlüsselungsalgorithmen haben jedoch unterschiedliche Header-Größen und können verhindern, dass diese Maximalwerte erreicht werden können. Um eine optimale Leistung durch Vermeidung von Fragmentierung zu erzielen, empfehlen wir Ihnen, die MTU und MSS speziell auf den verwendeten Algorithmen basierend einzustellen. Verwenden Sie die folgende Tabelle, um Ihre Einstellungen festzulegen, um Fragmentierung MTU/MSS zu vermeiden und eine optimale Leistung zu erzielen: | Verschlüsselungsalgorithmus | Hash-Algorithmus | NAT-Traversierung | MTU | MSS () IPv4 | SMS (IPv6-in-) IPv4 | | --- | --- | --- | --- | --- | --- | | AES-GCM-16 | – | disabled | 1446 | 1406 | 1386 | | AES-GCM-16 | – | aktiviert | 1438 | 1398 | 1378 | | AES-CBC | SHA1/-256 SHA2 | disabled | 1438 | 1398 | 1378 | | AES-CBC | SHA1/-256 SHA2 | aktiviert | 1422 | 1382 | 1362 | | AES-CBC | SHA2-384 | disabled | 1422 | 1382 | 1362 | | AES-CBC | SHA2-384 | aktiviert | 1422 | 1382 | 1362 | | AES-CBC | SHA2-512 | disabled | 1422 | 1382 | 1362 | | AES-CBC | SHA2-512 | aktiviert | 1406 | 1366 | 1346 | **Anmerkung** Die AES-GCM-Algorithmen decken sowohl die Verschlüsselung als auch die Authentifizierung ab, sodass es keine eindeutige Wahl des Authentifizierungsalgorithmus gibt, die sich auf die MTU auswirken würde. **Deaktivieren Sie IKE Unique IDs** Einige Kunden-Gateway-Geräte unterstützen eine Einstellung, die sicherstellt, dass pro Tunnelkonfiguration höchstens eine Phase-1-Sicherheitsverbindung vorhanden ist. Diese Einstellung kann zu inkonsistenten Phase-2-Zuständen zwischen VPN-Peers führen. Wenn Ihr Kunden-Gateway-Gerät diese Einstellung unterstützt, empfehlen wir, sie zu deaktivieren. # Firewall-Regeln für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät Sie benötigen eine statische IP-Adresse, die Sie als Endpunkt für die IPsec Tunnel verwenden können, die Ihr Kunden-Gateway-Gerät mit AWS Site-to-Site VPN Endpunkten verbinden. Wenn zwischen Ihrem Kunden-Gateway-Gerät AWS und Ihrem Kunden-Gateway-Gerät eine Firewall eingerichtet ist, müssen die Regeln in den folgenden Tabellen vorhanden sein, um die IPsec Tunnel einzurichten. Die IP-Adressen für die AWS-Seite werden in der Konfigurationsdatei enthalten sein. **Eingehend (aus dem Internet)** | | | Eingangsregel I1 | | --- | | Quell-IP | Tunnel1 Externe IP | | Ziel-IP | Kunden-Gateway | | Protocol (Protokoll) | UDP | | Quell-Port | 500 | | Zielbereich | 500 | | Eingangsregel I2 | | --- | | Quell-IP | Tunnel2 Externe IP | | Ziel-IP | Kunden-Gateway | | Protocol (Protokoll) | UDP | | Quell-Port | 500 | | Ziel-Port | 500 | | Eingangsregel I3 | | --- | | Quell-IP | Tunnel1 Externe IP | | Ziel-IP | Kunden-Gateway | | Protocol (Protokoll) | IP 50 (ESP) | | Eingangsregel I4 | | --- | | Quell-IP | Tunnel2 Externe IP | | Ziel-IP | Kunden-Gateway | | Protocol (Protokoll) | IP 50 (ESP) | **Ausgehend (in das Internet)** | | | Ausgangsregel O1 | | --- | | Quell-IP | Kunden-Gateway | | Ziel-IP | Tunnel1 Externe IP | | Protocol (Protokoll) | UDP | | Quell-Port | 500 | | Ziel-Port | 500 | | Ausgangsregel O2 | | --- | | Quell-IP | Kunden-Gateway | | Ziel-IP | Tunnel2 Externe IP | | Protocol (Protokoll) | UDP | | Quell-Port | 500 | | Ziel-Port | 500 | | Ausgangsregel O3 | | --- | | Quell-IP | Kunden-Gateway | | Ziel-IP | Tunnel1 Externe IP | | Protocol (Protokoll) | IP 50 (ESP) | | Ausgangsregel O4 | | --- | | Quell-IP | Kunden-Gateway | | Ziel-IP | Tunnel2 Externe IP | | Protocol (Protokoll) | IP 50 (ESP) | Die Regeln I1, I2, O1 und O2 ermöglichen die Übertragung von IKE-Paketen. Die Regeln I3, I4, O3 und O4 ermöglichen die Übertragung von IPsec Paketen, die den verschlüsselten Netzwerkverkehr enthalten. **Anmerkung** Wenn Sie NAT-Traversal (NAT-T) auf Ihrem Gerät verwenden, stellen Sie sicher, dass UDP-Verkehr auf Port 4500 auch zwischen Ihrem Netzwerk und den Endpunkten übertragen werden darf. AWS Site-to-Site VPN Überprüfen Sie, ob Ihr Gerät NAT-T ankündigt. # Statische und dynamische Konfigurationsdateien für ein Kunden-Gateway-Gerät AWS Site-to-Site VPN Nachdem Sie die VPN-Verbindung erstellt haben, haben Sie zusätzlich die Möglichkeit, eine AWS-bereitgestellte Beispielkonfigurationsdatei von der Amazon-VPC-Konsole oder mithilfe der EC2-API herunterzuladen. Weitere Informationen finden Sie unter [Schritt 6: Die Endpunkt-Konfigurationsdatei herunterladen](SetUpVPNConnections.md#vpn-download-config). Sie können auch ZIP-Dateien mit Beispielkonfigurationen speziell für statisches und dynamisches Routing von den jeweiligen Seiten herunterladen. Die AWS mitgelieferte Beispielkonfigurationsdatei enthält spezifische Informationen zu Ihrer VPN-Verbindung, die Sie zur Konfiguration Ihres Kunden-Gateway-Geräts verwenden können. Diese gerätespezifische Konfigurationsdateien sind nur für Geräte verfügbar, die AWS getestet hat. Wenn Ihr spezifisches Kunden-Gateway-Gerät nicht aufgeführt ist, können Sie zunächst eine generische Konfigurationsdatei herunterladen. **Wichtig** Die Konfigurationsdatei dient nur als Beispiel und entspricht möglicherweise nicht vollständig Ihren beabsichtigten Site-to-Site VPN-Verbindungseinstellungen. Sie spezifiziert die Mindestanforderungen für eine Site-to-Site VPN-Verbindung von AES128, SHA1, und Diffie-Hellman-Gruppe 2 in den meisten AWS Regionen und, AES128 SHA2, und Diffie-Hellman-Gruppe 14 in den Regionen. AWS GovCloud Es legt außerdem Pre-Shared-Key für die Authentifizierung fest. Sie müssen die Beispielkonfigurationsdatei ändern, um zusätzliche Sicherheitsalgorithmen, Diffie-Hellman-Gruppen, private Zertifikate und Datenverkehr zu nutzen. IPv6 **Anmerkung** Diese gerätespezifischen Konfigurationsdateien werden nach bestem Wissen und Gewissen von AWS bereitgestellt. Sie wurden zwar von getestet AWS, diese Tests sind jedoch begrenzt. Wenn Sie ein Problem mit den Konfigurationsdateien haben, müssen Sie sich möglicherweise an den jeweiligen Anbieter wenden, um zusätzlichen Support zu erhalten. Die folgende Tabelle enthält eine Liste von Geräten, für die eine Beispielkonfigurationsdatei heruntergeladen werden kann, die aktualisiert wurde, um sie zu unterstützen IKEv2. Wir haben IKEv2 Unterstützung in den Konfigurationsdateien für viele beliebte Kunden-Gateway-Geräte eingeführt und werden im Laufe der Zeit weitere Dateien hinzufügen. Diese Liste wird aktualisiert, wenn weitere Beispielkonfigurationsdateien hinzugefügt werden. | Hersteller | Plattform | Software | | --- | --- | --- | | AXGATE | NF | ALS 3.2\$1 | | AXGIEREN | UTM | ALS 2.1\$1 | | Prüfpunkt | Gaia | R80.10\$1 | | Cisco Meraki | MX-Serie | 15.12\$1 (WebUI) | | Cisco Systems, Inc. | ASA 5500 Serie | ASA 9.7\$1 VTI | | Cisco Systems, Inc. | CSRv AMI | IOS 12.4\$1 | | Fortinet | Serie Fortigate 40\$1 | FortiOS 6.4.4\$1 (GUI) | | Juniper Networks, Inc. | Router der J-Serie | JunOS 9.5\$1 | | Juniper Networks, Inc. | SRX-Router | JunOS 11.0\$1 | | Mikrotik | RouterOS | 6,44,3 | | Palo Alto Networks | PA-Serie | PANOS 7.0\$1 | | SonicWall | NSA, TZ | OS 6.5 | | Sophos | Sophos Firewall | v19\$1 | | Strongswan | Ubuntu 16.04 | Strongswan 5.5.1\$1 | | Yamaha | RTX-Router | Rev.10.01.16\$1 | # Herunterladbare statische Routing-Konfigurationsdateien für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät Um eine Beispielkonfigurationsdatei mit Werten herunterzuladen, die für Ihre Site-to-Site VPN-Verbindungskonfiguration spezifisch sind, verwenden Sie die Amazon VPC-Konsole, die AWS Befehlszeile oder die Amazon EC2 EC2-API. Weitere Informationen finden Sie unter [Schritt 6: Die Endpunkt-Konfigurationsdatei herunterladen](SetUpVPNConnections.md#vpn-download-config). [Sie können auch allgemeine Beispielkonfigurationsdateien für statisches Routing herunterladen, die keine spezifischen Werte für Ihre Site-to-Site VPN-Verbindungskonfiguration enthalten: .zip static-routing-examples](samples/static-routing-examples.zip) Die Dateien verwenden Platzhalterwerte für einige Komponenten. Sie verwenden zum Beispiel: + Beispielwerte für die VPN-Verbindungs-ID, die Kunden-Gateway-ID und die ID des Virtual Private Gateways + Platzhalter für die (externen) AWS Remote-IP-Adressendpunkte (und) *AWS\$1ENDPOINT\$11* *AWS\$1ENDPOINT\$12* + Ein Platzhalter für die IP-Adresse der externen Schnittstelle, die über das Internet routbar ist, auf dem Kunden-Gateway-Gerät () *your-cgw-ip-address* + Ein Platzhalter für den Wert des vorab gemeinsam genutzten Schlüssels () pre-shared-key + Beispielwerte für den Tunnel innerhalb von IP-Adressen. + Beispielwerte für die MTU-Einstellung. **Anmerkung** Die MTU-Einstellungen, die in den Beispielkonfigurationsdateien bereitgestellt werden, sind nur Beispiele. Weitere Informationen zur Einstellung des optimalen MTU-Wertes für Ihre Situation finden Sie unter [Bewährte Methoden für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](cgw-best-practice.md). Die Dateien stellen nicht nur Platzhalterwerte bereit, sondern spezifizieren auch die Mindestanforderungen für eine Site-to-Site VPN-Verbindung von AES128 SHA1, und Diffie-Hellman-Gruppe 2 in den meisten AWS Regionen und, AES128 SHA2, und Diffie-Hellman-Gruppe 14 in den Regionen. AWS GovCloud Sie geben auch Pre-Shared-Key für [authentication (Authentifizierung)](vpn-tunnel-authentication-options.md) an. Sie müssen die Beispielkonfigurationsdatei ändern, um zusätzliche SicherheitsalGORITHmen, Diffie-Hellman-Gruppen, private Zertifikate und Datenverkehr zu nutzen. IPv6 Das folgende Diagramm gibt einen Überblick über die verschiedenen Komponenten, die auf dem Kunden-Gateway-Gerät konfiguriert werden. Es enthält Beispielwerte für die IP-Adressen der Tunnelschnittstelle. ![\[Kunden-Gateway-Gerät mit statischem Routing\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/cgw-static-routing.png) # Konfigurieren Sie statisches Routing für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät Im Folgenden finden Sie einige Beispielverfahren zur Konfiguration eines Kunden-Gateway-Geräts unter Verwendung seiner Benutzeroberfläche (falls verfügbar). ------ #### [ Check Point ] Im Folgenden finden Sie Schritte zur Konfiguration Ihres Kunden-Gateway-Geräts, falls es sich bei Ihrem Gerät um ein Check Point Security Gateway-Gerät mit R77.10 oder höher handelt, das das Gaia-Betriebssystem und Check Point verwendet. SmartDashboard Sie können auch den Artikel [Check Point Security Gateway IPsec VPN to Amazon Web Services VPC](https://support.checkpoint.com/results/sk/sk100726) im Check Point Support Center lesen. **So konfigurieren Sie die Tunnelschnittstelle** Als Erstes müssen Sie die VPN-Tunnel erstellen und die privaten (internen) IP-Adressen des Kunden-Gateways und des Virtual Private Gateways für die einzelnen Tunnel angeben. Wie Sie den ersten Tunnel erstellen, ist im Abschnitt `IPSec Tunnel #1` der Konfigurationsdatei beschrieben. Verwenden Sie zum Erstellen des zweiten Tunnels die Werte im Abschnitt `IPSec Tunnel #2` der Konfigurationsdatei. 1. Öffnen Sie das Gaia-Portal Ihres Check Point-Sicherheits-Gateway-Geräts. 1. Klicken Sie auf **Network Interfaces**, **Add** und **VPN tunnel**. 1. Konfigurieren Sie im Dialogfeld die Einstellungen wie nachfolgend beschrieben und klicken Sie dann auf **OK**: + Geben Sie unter **VPN Tunnel ID** einen eindeutigen Wert, z. B. 1, ein. + Geben Sie unter **Peer** einen eindeutigen Namen für den Tunnel ein, z. B. `AWS_VPC_Tunnel_1` oder `AWS_VPC_Tunnel_2`. + Stellen Sie sicher, dass **Numbered (Nummeriert)** ausgewählt ist, und geben Sie unter **Local Address (Lokale Adresse)** die IP-Adresse für `CGW Tunnel IP` aus der Konfigurationsdatei ein, z. B. `169.254.44.234`. + Geben Sie unter **Remote Address** die IP-Adresse für `VGW Tunnel IP` aus der Konfigurationsdatei ein, z. B. `169.254.44.233`. ![\[Check Point-Dialogfeld "VPN-Tunnel hinzufügen"\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/check-point-create-tunnel.png) 1. Melden Sie sich über SSH bei Ihrem Sicherheits-Gateway an. Wenn Sie nicht die Standard-Shell verwenden, wechseln Sie mit folgendem Befehl zu Clish: `clish` 1. Führen Sie für Tunnel 1 den folgenden Befehl aus: ``` set interface vpnt1 mtu 1436 ``` Führen Sie für Tunnel 2 den folgenden Befehl aus: ``` set interface vpnt2 mtu 1436 ``` 1. Wiederholen Sie diese Schritte, um den zweiten Tunnel zu erstellen. Verwenden Sie dafür die Informationen im Bereich `IPSec Tunnel #2` der Konfigurationsdatei. **So konfigurieren Sie die statischen Routen** In diesem Schritt legen Sie für die einzelnen Tunnel die statische Route zum Subnetz in der VPC fest, damit Sie Datenverkehr über die Tunnelschnittstellen senden können. Der zweite Tunnel dient als Failover, falls der erste Tunnel ausfällt. Falls ein Fehler auftritt, wird die richtlinienbasierte statische Route aus der Routing-Tabelle entfernt und es wird eine zweite Route aktiviert. Außerdem müssen Sie das Check Point-Gateway aktivieren, um einen Ping ans andere Ende des Tunnels zu senden und zu prüfen, ob der Tunnel aktiv ist. 1. **Wählen Sie im Gaia-Portal **IPv4 Static Routes, Add**.** 1. Geben Sie den CIDR-Bereich Ihres Subnetzes an, z. B. `10.28.13.0/24`. 1. Klicken Sie auf **Add Gateway** und **IP Address**. 1. Geben Sie die IP-Adresse für `VGW Tunnel IP` aus der Konfigurationsdatei ein (z. B. `169.254.44.233`) und legen Sie als Priorität "1" fest. 1. Wählen Sie **Ping** aus. 1. Wiederholen Sie die Schritte 3 und 4 für den zweiten Tunnel und verwenden Sie den Wert `VGW Tunnel IP` im Bereich `IPSec Tunnel #2` der Konfigurationsdatei. Legen Sie als Priorität "2" fest. ![\[Check Point-Dialogfeld "Zieladressroute bearbeiten"\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/check-point-static-routes.png) 1. Wählen Sie **Speichern**. Wenn Sie einen Cluster verwenden, wiederholen Sie die vorhergehenden Schritte für die anderen Mitglieder des Clusters. **So definieren Sie ein neues Netzwerkobjekt** In diesem Schritt erstellen Sie ein Netzwerkobjekt für jeden VPN-Tunnel und legen die öffentlichen (externen) IP-Adressen für das Virtual Private Gateway fest. Später fügen Sie diese Netzwerkobjekte als Satelliten-Gateways für Ihre VPN-Community hinzu. Außerdem müssen Sie eine leere Gruppe erstellen, die als Platzhalter für die VPN-Domäne dient. 1. Öffnen Sie den Check Point SmartDashboard. 1. Öffnen Sie für **Groups** das Kontextmenü und klicken Sie auf **Groups** und **Simple Group**. Sie können für alle Netzwerkobjekte dieselbe Gruppe verwenden. 1. Öffnen Sie mit der rechten Maustaste für **Network Objects** das Kontextmenü und wählen Sie **New** und **Interoperable Device** aus. 1. Geben Sie unter **Name** den Namen des Tunnels ein, z. B. `AWS_VPC_Tunnel_1` oder `AWS_VPC_Tunnel_2`. 1. Geben Sie unter **IPv4 Adresse** die externe IP-Adresse des virtuellen privaten Gateways ein, die in der Konfigurationsdatei angegeben ist, `54.84.169.196` z. B. Speichern Sie die Einstellungen und schließen Sie das Dialogfeld. ![\[Check Point-Dialogfeld "Interoperables Gerät"\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/check-point-network-device.png) 1. Öffnen Sie Ihre Gateway-Eigenschaften und wählen Sie im Kategorienbereich **Topologie** aus. SmartDashboard 1. Klicken Sie auf **Get Topology**, um die Schnittstellenkonfiguration abzurufen. 1. Klicken Sie im Bereich **VPN Domain (VPN-Domäne)** auf **Manually defined (Manuell definiert)** und wählen Sie die leere einfache Gruppe aus, die Sie in Schritt 2 erstellt haben. Wählen Sie **OK** aus. **Anmerkung** Sie können eine vorhandene VPN-Domäne, die Sie bereits konfiguriert haben, beibehalten. Stellen Sie jedoch sicher, dass die verwendeten Hosts und Netzwerke von der neuen VPN-Verbindung bedient werden und nicht in dieser VPN-Domäne deklariert werden, insbesondere wenn die VPN-Domäne automatisch abgeleitet wird. 1. Wiederholen Sie diese Schritte, um ein zweites Netzwerkobjekt zu erstellen. Verwenden Sie dafür die Informationen im Bereich `IPSec Tunnel #2` der Konfigurationsdatei. **Anmerkung** Wenn Sie Cluster verwenden, bearbeiten Sie die Topologie und legen Sie die Schnittstellen als Cluster-Schnittstellen fest. Verwenden Sie die IP-Adressen, die in der Konfigurationsdatei angegeben sind. **So erstellen und konfigurieren Sie die VPN-Community, IKE und IPsec Einstellungen** In diesem Schritt erstellen Sie eine VPN-Community in Ihrem Check Point-Gateway, zu dem Sie die Netzwerkobjekte (interoperablen Geräte) für die einzelnen Tunnel hinzufügen. Sie konfigurieren auch den Internet Key Exchange (IKE) und die IPsec Einstellungen. 1. Wählen Sie in Ihren Gateway-Eigenschaften im Kategorienbereich die Option **IPSecVPN** aus. 1. Klicken Sie auf **Communities**, **New** und **Star Community**. 1. Geben Sie einen Namen für die Community ein (z. B. `AWS_VPN_Star`) und klicken Sie im Kategoriebereich auf **Center Gateways**. 1. Klicken Sie auf **Add** und fügen Sie Ihr Gateway bzw. Ihren Cluster der Liste der teilnehmenden Gateways hinzu. 1. Klicken Sie im Kategoriebereich auf **Satellite Gateways (Satelliten-Gateways)** und **Add (Hinzufügen)** und fügen Sie die interoperablen Geräte, die Sie vorher erstellt haben (`AWS_VPC_Tunnel_1` und `AWS_VPC_Tunnel_2`) der Liste der teilnehmenden Gateways hinzu. 1. Klicken Sie im Kategoriebereich auf **Encryption**. Wählen Sie im Abschnitt **Verschlüsselungsmethode** die Option **IKEv1 Nur** aus. Wählen Sie im Bereich **Encryption Suite** **Custom** und **Custom Encryption** aus. 1. Konfigurieren Sie im Dialogfeld die Verschlüsselungseigenschaften wie nachfolgend beschrieben und klicken Sie dann auf **OK**: + Eigenschaften von IKE Security Association (Phase 1): + **Perform key exchange encryption with**: AES-128 + **Perform data integrity with**: SHA-1 + IPsec Eigenschaften von Security Association (Phase 2): + ** IPsec Datenverschlüsselung durchführen mit**: AES-128 + **Perform data integrity with**: SHA-1 1. Klicken Sie im Kategoriebereich auf **Tunnel Management**. Klicken Sie auf **Set Permanent Tunnels** und **On all tunnels in the community**. Wählen Sie im Bereich **VPN Tunnel Sharing** **One VPN tunnel per Gateway pair** aus. 1. Erweitern Sie im Kategoriebereich **Advanced Settings** und klicken Sie auf **Shared Secret**. 1. Wählen Sie den Peer-Namen für den ersten Tunnel aus, klicken Sie auf **Edit (Bearbeiten)** und geben Sie den vorinstallierten Schlüssel aus dem Bereich `IPSec Tunnel #1` der Konfigurationsdatei ein. 1. Wählen Sie den Peer-Namen für den zweiten Tunnel aus, klicken Sie auf **Edit (Bearbeiten)** und geben Sie den vorinstallierten Schlüssel aus dem Bereich `IPSec Tunnel #2` der Konfigurationsdatei ein. ![\[Check Point-Dialogfeld "Gemeinsamer geheimer Schlüssel"\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/check-point-shared-secret.png) 1. Klicken Sie – noch immer in der Kategorie **Advanced Settings (Erweiterte Einstellungen)** – auf **Advanced VPN Properties (Erweiterte VPN-Eigenschaften)**, konfigurieren Sie die Eigenschaften wie nachfolgend beschrieben und klicken Sie abschließend auf **OK**: + IKE (Phase 1): + ** Diffie-Hellman-Gruppe verwenden**: `Group 2` + **Renegotiate IKE security associations every** `480` **minutes** + IPsec (Phase 2): + **Use Perfect Forward Secrecy** auswählen + ** Diffie-Hellman-Gruppe verwenden**: `Group 2` + **Verhandeln Sie IPsec Sicherheitszuordnungen alle** **Sekunden neu `3600`** **So erstellen Sie Firewall-Regeln** In diesem Schritt konfigurieren Sie eine Richtlinie mit Firewall-Regeln und direktionalen Übereinstimmungsregeln, um Kommunikation zwischen der VPC und dem lokalen Netzwerk zu ermöglichen. Dann installieren Sie diese Richtlinie auf Ihrem Gateway. 1. Wählen Sie im SmartDashboard **Global Properties** für Ihr Gateway aus. Erweitern Sie im Kategoriebereich **VPN** und klicken Sie auf **Advanced**. 1. Klicken Sie auf **Enable VPN Directional Match in VPN Column** und speichern Sie die Änderungen. 1. Wählen Sie im die SmartDashboard Option **Firewall** aus und erstellen Sie eine Richtlinie mit den folgenden Regeln: + Erlauben Sie dem VPC-Subnetz, über die erforderlichen Protokolle mit dem lokalen Netzwerk zu kommunizieren. + Erlauben Sie dem lokalen Netzwerk, über die erforderlichen Protokolle mit dem VPC-Subnetz zu kommunizieren. 1. Öffnen Sie das Kontextmenü für die Zelle in der VPN-Spalte und klicken Sie auf **Edit Cell**. 1. Klicken Sie im Dialogfeld **VPN Match Conditions** auf **Match traffic in this direction only**. Klicken Sie jeweils auf **Add** und abschließend auf **OK**, um die folgenden direktionalen Übereinstimmungsregeln zu erstellen: + `internal_clear` > VPN-Community (die VPN-Star-Community, die Sie vorher erstellt haben, z. B. `AWS_VPN_Star`) + VPN-Community > VPN-Community + VPN-Community > `internal_clear` 1. Wählen Sie im die SmartDashboard Option **Richtlinie**, **Installieren** aus. 1. Wählen Sie im Dialogfeld das Gateway aus und klicken Sie auf **OK**, um die Richtlinie zu installieren. **So ändern Sie die Eigenschaft "tunnel\$1keepalive\$1method"** Sie können für Ihren Check Point-Gateway Dead Peer Detection (DPD) verwenden, um Ausfälle bei der IKE-Zuordnung zu identifizieren. Um DPD für einen permanenten Tunnel zu konfigurieren, muss der permanente Tunnel in der AWS VPN-Community konfiguriert werden (siehe Schritt 8). Standardmäßig ist für die Eigenschaft `tunnel_keepalive_method` eines VPN-Gateways der Wert `tunnel_test` festgelegt. Sie müssen diesen Wert zu `dpd` ändern. Für alle VPN-Gateways innerhalb der VPN-Community, einschließlich VPN-Gateways von Drittanbietern, für die Sie DPD-Überwachung aktivieren möchten, muss die Eigenschaft `tunnel_keepalive_method` konfiguriert werden. Es ist nicht möglich, für dasselbe Gateway unterschiedliche Überwachungsmechanismen zu konfigurieren. Sie können die `tunnel_keepalive_method` Eigenschaft mit dem DBedit GUI-Tool aktualisieren. 1. Öffnen Sie den Check Point SmartDashboard und wählen Sie **Security Management Server**, **Domain Management Server**. 1. Klicken Sie auf **File** und **Database Revision Control…** und erstellen Sie einen Versions-Snapshot. 1. Schließen Sie alle SmartConsole Fenster, z. B. SmartView Tracker und SmartView Monitor. SmartDashboard 1. Starten Sie das BDedit GUI-Tool. Weitere Informationen finden Sie im Artikel [Check Point Database Tool](https://support.checkpoint.com/results/sk/sk13009) im Check Point-Supportcenter. 1. Klicken Sie auf **Security Management Server** und **Domain Management Server**. 1. Klicken Sie oben links auf **Table**, **Network Objects** und **network\$1objects**. 1. Wählen Sie oben rechts das entsprechende **Security Gateway**-**Cluster**-Objekt aus. 1. Drücken Sie STRG \$1 F oder verwenden Sie das **Suchmenü**, um nach folgender Zeichenfolge zu suchen: `tunnel_keepalive_method`. 1. Öffnen Sie im unteren Bereich das Kontextmenü für `tunnel_keepalive_method` und klicken Sie auf **Edit… (Bearbeiten...)**. Wählen Sie **dpd** aus. Wählen Sie dann **OK** aus. 1. Wiederholen Sie die Schritte 7 bis 9 für jedes Gateway, das Teil der AWS VPN-Community ist. 1. Klicken Sie auf **File** und **Save All**. 1. Schließen Sie das DBedit GUI-Tool. 1. Öffnen Sie den Check Point SmartDashboard und wählen Sie **Security Management Server**, **Domain Management Server**. 1. Installieren Sie die Richtlinie für das entsprechende **Security Gateway**-**Cluster**-Objekt. Weitere Informationen finden Sie im Artikel [New VPN features in R77.10](https://support.checkpoint.com/results/sk/sk97746) im Check Point-Supportcenter. **So aktivieren Sie TCP MSS Clamping** Mit TCP MSS Clamping können Sie die maximale Segmentgröße von TCP-Paketen reduzieren, um eine Paketfragmentierung zu vermeiden. 1. Öffnen Sie das folgende Verzeichnis: `C:\Program Files (x86)\CheckPoint\SmartConsole\R77.10\PROGRAM\`. 1. Führen Sie die Datei `GuiDBEdit.exe` aus, um das Check Point-Datenbank-Tool zu starten. 1. Wählen Sie **Table**, **Global Properties** und **properties** aus. 1. Klicken Sie für `fw_clamp_tcp_mss` auf **Edit**. Ändern Sie den Wert in `true` und klicken Sie auf **OK**. **So überprüfen Sie den Tunnelstatus** Sie können den Tunnelstatus überprüfen, indem Sie den folgenden Befehl vom Befehlszeilen-Tool aus im Expertenmodus ausführen. ``` vpn tunnelutil ``` Wählen Sie in den angezeigten Optionen **1** aus, um die IKE-Verknüpfungen zu überprüfen, und **2**, um die IPsec Verknüpfungen zu überprüfen. Im Check Point Smart Tracker-Protokoll können Sie auch überprüfen, ob Pakete über diese Verbindung verschlüsselt werden. Dem folgenden Protokoll können Sie beispielsweise entnehmen, dass ein Paket verschlüsselt über Tunnel 1 an die VPC gesendet wurde. ![\[Check Point-Protokolldatei\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/check-point-log.png) ------ #### [ SonicWALL ] Das folgende Verfahren zeigt die Konfiguration von VPN-Tunneln auf dem SonicWALL-Gerät über die SonicOS-Managementschnittstelle. **So konfigurieren Sie die Tunnel** 1. Öffnen Sie die SonicWALL SonicOS-Management-Schnittstelle. 1. Wählen Sie im linken Bereich **VPN**, **Settings** aus. Wählen Sie unter **VPN Policies** **Add...** aus. 1. Geben Sie die folgenden Informationen im VPN-Richtlinienfenster auf der Registerkarte **General ** ein: + **Policy Type (Richtlinientyp)**: Wählel Sie **Tunnel Interface**. + **Authentication Method**: Wählen Sie **IKE using Preshared Secret** aus. + **Name**: Geben Sie einen Namen für die VPN-Richtlinie ein. Wir empfehlen, dass Sie den Namen der VPN-ID aus der Konfigurationsdatei verwenden. + **IPsec Name oder Adresse des primären Gateways**: Geben Sie die IP-Adresse des Virtual Private Gateways ein, wie sie in der Konfigurationsdatei angegeben ist (z. B.`72.21.209.193`). + **IPsec Name oder Adresse des sekundären Gateways**: Behalten Sie den Standardwert bei. + **Shared Secret**: Geben Sie den vorinstallierten Schlüssel aus der Konfigurationsdatei ein. Geben Sie ihn erneut in **Confirm Shared Secret** ein. + **Lokale IKE-ID**: Geben Sie die IPv4 Adresse des Kunden-Gateways (das SonicWALL-Gerät) ein. + **Peer-IKE-ID**: Geben Sie die IPv4 Adresse des virtuellen privaten Gateways ein. 1. Füllen Sie auf der Registerkarte **Network** die folgenden Informationen aus: + Wählen Sie unter **Local Networks** **Any address** aus. Wir empfehlen diese Option, um Verbindungsprobleme aus Ihrem lokalen Netzwerk zu vermeiden. + Wählen Sie unter **Remote Networks** **Choose a destination network from list** aus. Erstellen Sie ein Adressobjekt mit der CIDR Ihrer VPC in AWS. 1. Füllen Sie auf der Registerkarte **Proposals (Vorschläge)** die folgenden Informationen aus. + Führen Sie unter **IKE (Phase 1) Proposal** die folgenden Schritte aus: + **Exchange**: Wählen Sie **Main Mode** aus. + **DH Group**: Geben Sie einen Wert für die Diffie-Hellman-Gruppe ein (z. B. `2`). + **Encryption**: Wählen Sie **AES-128** oder **AES-256** aus. + **Authentifizierung**: Wählen Sie **SHA1**oder **SHA256**. + **Life Time**: Geben Sie `28800` ein. + Führen Sie unter **IKE (Phase 2) Proposal** die folgenden Schritte aus: + **Protocol**: Wählen Sie **ESP** aus. + **Encryption**: Wählen Sie **AES-128** oder **AES-256** aus. + **Authentifizierung**: Wählen Sie **SHA1**oder **SHA256**. + Wählen Sie das Kontrollkästchen **Enable Perfect Forward Secrecy** und die Diffie-Hellman-Gruppe aus. + **Life Time**: Geben Sie `3600` ein. **Wichtig** Wenn Sie Ihr Virtual Private Gateway vor Oktober 2015 erstellt haben, müssen Sie Diffie-Hellman-Gruppe 2, AES-128, und für beide Phasen angeben. SHA1 1. Füllen Sie auf der Registerkarte **Advanced** die folgenden Informationen aus: + Wählen Sie **Enable Keep Alive** aus. + Wählen Sie **Enable Phase2 Dead Peer Detection** aus und geben Sie Folgendes ein: + Geben Sie für **Dead Peer Detection Interval** `60` ein (der Minimalwert für das SonicWALL-Gerät). + Geben Sie in **Failure Trigger Level** `3` ein. + Wählen Sie für **VPN Policy bound to** **Interface X1** aus. Dies ist die Schnittstelle, die normalerweise für öffentliche IP-Adressen vorgesehen ist. 1. Wählen Sie **OK** aus. Auf der Seite **Einstellungen** sollte das Kontrollkästchen **Aktivieren** für den Tunnel standardmäßig aktiviert sein. Der grüne Punkt zeigt an, dass der Tunnel aktiv ist. ------ ## Cisco-Geräte: zusätzliche Informationen Einige Cisco unterstützen ASAs nur Active/Standby den Modus. Wenn Sie diese Cisco verwenden ASAs, können Sie jeweils nur einen aktiven Tunnel haben. Der andere Standby-Tunnel wird aktiv, falls der erste Tunnel nicht verfügbar ist. Diese Redundanz sorgt dafür, dass immer ein Tunnel für die Verbindung zu Ihrer VPC verfügbar ist. Cisco unterstützt ASAs ab Version 9.7.1 und höher den Active/Active Unterstützungsmodus. Wenn Sie diese Cisco verwenden ASAs, können Sie beide Tunnel gleichzeitig aktiv haben. Diese Redundanz sorgt dafür, dass immer ein Tunnel für die Verbindung zu Ihrer VPC verfügbar ist. Für Cisco-Geräte müssen Sie die folgenden Schritte ausführen: + Konfigurieren Sie die Außenschnittstelle. + Stellen Sie sicher, dass die Crypto ISAKMP-Richtliniensequenznummer eindeutig ist. + Stellen Sie sicher, dass die Crypto List-Richtliniensequenznummer eindeutig ist. + Stellen Sie sicher, dass das Crypto IPsec Transform Set und die Crypto ISAKMP Policy Sequence mit allen anderen IPsec Tunneln, die auf dem Gerät konfiguriert sind, harmonieren. + Stellen Sie sicher, dass die SLA-Überwachungsnummer eindeutig ist. + Konfigurieren Sie sämtliche internen Routen, über die Datenverkehr zwischen dem Kunden-Gateway-Gerät und Ihrem On-Premise-Netzwerk gesendet wird. # Herunterladbare dynamische Routing-Konfigurationsdateien für AWS Site-to-Site VPN Kunden-Gateway-Geräte Um eine Beispielkonfigurationsdatei mit Werten herunterzuladen, die für Ihre Site-to-Site VPN-Verbindungskonfiguration spezifisch sind, verwenden Sie die Amazon VPC-Konsole, die AWS Befehlszeile oder die Amazon EC2 EC2-API. Weitere Informationen finden Sie unter [Schritt 6: Die Endpunkt-Konfigurationsdatei herunterladen](SetUpVPNConnections.md#vpn-download-config). [Sie können auch generische Beispielkonfigurationsdateien für dynamisches Routing herunterladen, die keine spezifischen Werte für Ihre Site-to-Site VPN-Verbindungskonfiguration enthalten: .zip dynamic-routing-examples](samples/dynamic-routing-examples.zip) Die Dateien verwenden Platzhalterwerte für einige Komponenten. Sie verwenden zum Beispiel: + Beispielwerte für die VPN-Verbindungs-ID, die Kunden-Gateway-ID und die ID des Virtual Private Gateways + Platzhalter für die (externen) AWS Remote-IP-Adressendpunkte (und) *AWS\$1ENDPOINT\$11* *AWS\$1ENDPOINT\$12* + Ein Platzhalter für die IP-Adresse der externen Schnittstelle, die über das Internet routbar ist, auf dem Kunden-Gateway-Gerät () *your-cgw-ip-address* + Ein Platzhalter für den Wert des vorab gemeinsam genutzten Schlüssels () pre-shared-key + Beispielwerte für den Tunnel innerhalb von IP-Adressen. + Beispielwerte für die MTU-Einstellung. **Anmerkung** Die MTU-Einstellungen, die in den Beispielkonfigurationsdateien bereitgestellt werden, sind nur Beispiele. Weitere Informationen zur Einstellung des optimalen MTU-Wertes für Ihre Situation finden Sie unter [Bewährte Methoden für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](cgw-best-practice.md). Die Dateien stellen nicht nur Platzhalterwerte bereit, sondern spezifizieren auch die Mindestanforderungen für eine Site-to-Site VPN-Verbindung von AES128 SHA1, und Diffie-Hellman-Gruppe 2 in den meisten AWS Regionen und, AES128 SHA2, und Diffie-Hellman-Gruppe 14 in den Regionen. AWS GovCloud Sie geben auch Pre-Shared-Key für [authentication (Authentifizierung)](vpn-tunnel-authentication-options.md) an. Sie müssen die Beispielkonfigurationsdatei ändern, um zusätzliche SicherheitsalGORITHmen, Diffie-Hellman-Gruppen, private Zertifikate und Datenverkehr zu nutzen. IPv6 Das folgende Diagramm gibt einen Überblick über die verschiedenen Komponenten, die auf dem Kunden-Gateway-Gerät konfiguriert werden. Es enthält Beispielwerte für die IP-Adressen der Tunnelschnittstelle. ![\[Kunden-Gateway-Gerät mit dynamischem Routing\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/cgw-bgp.png) # Konfigurieren Sie dynamisches Routing für ein AWS Virtual Private Network Kunden-Gateway-Gerät Im Folgenden finden Sie einige Beispielverfahren zur Konfiguration eines Kunden-Gateway-Geräts unter Verwendung seiner Benutzeroberfläche (falls verfügbar). ------ #### [ Check Point ] Im Folgenden finden Sie Schritte zur Konfiguration eines Check Point Security Gateway-Geräts, auf dem R77.10 oder höher ausgeführt wird, mithilfe des Gaia-Webportals und Check Point. SmartDashboard Sie können auch den [Amazon Web Services (AWS) VPN BGP](https://support.checkpoint.com/results/sk/sk108958)-Artikel über das Check Point Support Center lesen. **So konfigurieren Sie die Tunnelschnittstelle** Als Erstes müssen Sie die VPN-Tunnel erstellen und die privaten (internen) IP-Adressen des Kunden-Gateways und des Virtual Private Gateways für die einzelnen Tunnel angeben. Wie Sie den ersten Tunnel erstellen, ist im Abschnitt `IPSec Tunnel #1` der Konfigurationsdatei beschrieben. Verwenden Sie zum Erstellen des zweiten Tunnels die Werte im Abschnitt `IPSec Tunnel #2` der Konfigurationsdatei. 1. Melden Sie sich über SSH bei Ihrem Sicherheits-Gateway an. Wenn Sie nicht die Standard-Shell verwenden, wechseln Sie mit folgendem Befehl zu Clish: `clish` 1. Stellen Sie die Kunden-Gateway-ASN ein (die ASN, die bei der Erstellung des Kunden-Gateways in angegeben wurde AWS), indem Sie den folgenden Befehl ausführen. ``` set as 65000 ``` 1. Erstellen Sie die Tunnelschnittstelle für den ersten Tunnel anhand der Informationen aus dem Abschnitt `IPSec Tunnel #1` der Konfigurationsdatei. Geben Sie einen eindeutigen Namen für den Tunnel ein, z. B. `AWS_VPC_Tunnel_1`. ``` add vpn tunnel 1 type numbered local 169.254.44.234 remote 169.254.44.233 peer AWS_VPC_Tunnel_1 set interface vpnt1 state on set interface vpnt1 mtu 1436 ``` 1. Wiederholen Sie diese Befehle, um den zweiten Tunnel zu erstellen. Verwenden Sie dafür die Informationen im Bereich `IPSec Tunnel #2` der Konfigurationsdatei. Geben Sie einen eindeutigen Namen für den Tunnel ein, z. B. `AWS_VPC_Tunnel_2`. ``` add vpn tunnel 1 type numbered local 169.254.44.38 remote 169.254.44.37 peer AWS_VPC_Tunnel_2 set interface vpnt2 state on set interface vpnt2 mtu 1436 ``` 1. Legen Sie die ASN des Virtual Private Gateways fest. ``` set bgp external remote-as 7224 on ``` 1. Konfigurieren Sie das BGP für den ersten Tunnel anhand der Informationen im Abschnitt `IPSec Tunnel #1` der Konfigurationsdatei: ``` set bgp external remote-as 7224 peer 169.254.44.233 on set bgp external remote-as 7224 peer 169.254.44.233 holdtime 30 set bgp external remote-as 7224 peer 169.254.44.233 keepalive 10 ``` 1. Konfigurieren Sie das BGP für den zweiten Tunnel anhand der Informationen im Abschnitt `IPSec Tunnel #2` der Konfigurationsdatei: ``` set bgp external remote-as 7224 peer 169.254.44.37 on set bgp external remote-as 7224 peer 169.254.44.37 holdtime 30 set bgp external remote-as 7224 peer 169.254.44.37 keepalive 10 ``` 1. Speichern Sie die Konfiguration. ``` save config ``` **So erstellen Sie eine BGP-Richtlinie** Erstellen Sie als Nächstes eine BGP-Richtlinie, die den Import von Routen erlaubt, die von AWS verbreitet werden. Anschließend konfigurieren Sie Ihr Kunden-Gateway so, dass dessen lokale Routen an AWS gesendet werden. 1. Klicken Sie im Gaia WebUI auf **Advanced Routing** und dann auf **Inbound Route Filters**. Klicken Sie auf **Add** und wählen Sie **Add BGP Policy (Based on AS)** aus. 1. Wählen Sie für **Add BGP Policy (BGP-Richtlinie hinzufügen)** im ersten Feld einen Wert zwischen 512 und 1024 aus und geben Sie im zweiten Feld die ASN des Virtual Private Gateways ein, z. B. `7224`. 1. Wählen Sie **Speichern**. **So kündigen Sie lokale Routen an** In den folgenden Schritten wird die Verteilung von lokalen Schnittstellenrouten beschrieben. Sie können Routen auch von anderen Quellen neu verteilen, z. B. statische Routen oder Routen, die Sie über dynamische Routing-Protokolle erhalten haben. Weitere Informationen finden Sie unter [Gaia Advanced Routing R77 Versions Administration Guide](https://sc1.checkpoint.com/documents/R77/CP_R77_Gaia_Advanced_Routing_WebAdminGuide/html_frameset.htm). 1. Klicken Sie im Gaia WebUI auf **Advanced Routing** und dann auf **Routing Redistribution**. Wählen Sie **Add Redistribution From (Neuverteilung hinzufügen von)** aus. Wählen Sie dann **Interface (Schnittstelle)** aus. 1. Wählen Sie für **To Protocol (Zu Protokoll)** die ASN des Virtual Private Gateways aus, z. B. `7224`. 1. Wählen Sie für **Interface** eine interne Schnittstelle aus. Wählen Sie **Speichern**. **So definieren Sie ein neues Netzwerkobjekt** Dann erstellen Sie ein Netzwerkobjekt für jeden VPN-Tunnel und legen die öffentlichen (externen) IP-Adressen für das Virtual Private Gateway fest. Später fügen Sie diese Netzwerkobjekte als Satelliten-Gateways für Ihre VPN-Community hinzu. Außerdem müssen Sie eine leere Gruppe erstellen, die als Platzhalter für die VPN-Domäne dient. 1. Öffnen Sie den Check Point. SmartDashboard 1. Öffnen Sie für **Groups** das Kontextmenü und klicken Sie auf **Groups** und **Simple Group**. Sie können für alle Netzwerkobjekte dieselbe Gruppe verwenden. 1. Öffnen Sie mit der rechten Maustaste für **Network Objects** das Kontextmenü und wählen Sie **New** und **Interoperable Device** aus. 1. Geben Sie unter **Name** den Namen des Tunnels aus Schritt 1 ein, z. B. `AWS_VPC_Tunnel_1` oder `AWS_VPC_Tunnel_2`. 1. Geben Sie unter **IPv4 Adresse** die externe IP-Adresse des virtuellen privaten Gateways ein, die in der Konfigurationsdatei angegeben ist, `54.84.169.196` z. B. Speichern Sie die Einstellungen und schließen Sie das Dialogfeld. ![\[Check Point-Dialogfeld "Interoperables Gerät"\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/check-point-network-device.png) 1. Wählen Sie im linken Kategoriebereich **Topology** aus. 1. Klicken Sie im Bereich **VPN Domain (VPN-Domäne)** auf **Manually defined (Manuell definiert)** und wählen Sie die leere einfache Gruppe aus, die Sie in Schritt 2 erstellt haben. Wählen Sie **OK** aus. 1. Wiederholen Sie diese Schritte, um ein zweites Netzwerkobjekt zu erstellen. Verwenden Sie dafür die Informationen im Bereich `IPSec Tunnel #2` der Konfigurationsdatei. 1. Rufen Sie das Gateway-Netzwerkobjekt auf, öffnen Sie das Gateway oder Cluster-Objekt und klicken Sie auf **Topology**. 1. Klicken Sie im Bereich **VPN Domain (VPN-Domäne)** auf **Manually defined (Manuell definiert)** und wählen Sie die leere einfache Gruppe aus, die Sie in Schritt 2 erstellt haben. Wählen Sie **OK** aus. **Anmerkung** Sie können eine vorhandene VPN-Domäne, die Sie bereits konfiguriert haben, beibehalten. Stellen Sie jedoch sicher, dass die verwendeten Hosts und Netzwerke von der neuen VPN-Verbindung bedient werden und nicht in dieser VPN-Domäne deklariert werden, insbesondere wenn die VPN-Domäne automatisch abgeleitet wird. **Anmerkung** Wenn Sie Cluster verwenden, bearbeiten Sie die Topologie und legen Sie die Schnittstellen als Cluster-Schnittstellen fest. Verwenden Sie die IP-Adressen, die in der Konfigurationsdatei angegeben sind. **Um die VPN-Community, IKE und IPsec Einstellungen zu erstellen und zu konfigurieren** Dann erstellen Sie eine VPN-Community in Ihrem Check Point-Gateway, zu dem Sie die Netzwerkobjekte (interoperablen Geräte) für die einzelnen Tunnel hinzufügen. Sie konfigurieren auch den Internet Key Exchange (IKE) und die IPsec Einstellungen. 1. Wählen Sie in Ihren Gateway-Eigenschaften im Kategorienbereich die Option **IPSecVPN** aus. 1. Klicken Sie auf **Communities**, **New** und **Star Community**. 1. Geben Sie einen Namen für die Community ein (z. B. `AWS_VPN_Star`) und klicken Sie im Kategoriebereich auf **Center Gateways**. 1. Klicken Sie auf **Add** und fügen Sie Ihr Gateway bzw. Ihren Cluster der Liste der teilnehmenden Gateways hinzu. 1. Klicken Sie im Kategoriebereich auf **Satellite Gateways (Satelliten-Gateways)** und **Add (Hinzufügen)** und fügen Sie die interoperablen Geräte, die Sie vorher erstellt haben (`AWS_VPC_Tunnel_1` und `AWS_VPC_Tunnel_2`) der Liste der teilnehmenden Gateways hinzu. 1. Klicken Sie im Kategoriebereich auf **Encryption**. Wählen Sie im Abschnitt **Verschlüsselungsmethode** die Optionen **IKEv1 für IPv4 und IKEv2 für** aus IPv6. Wählen Sie im Bereich **Encryption Suite** **Custom** und **Custom Encryption** aus. **Anmerkung** Sie müssen **IKEv1 für die IKEv1 Funktionalität die IPv6 Optionen IKEv2 für IPv4 und** für auswählen. 1. Konfigurieren Sie im Dialogfeld die Verschlüsselungseigenschaften wie nachfolgend beschrieben und klicken Sie dann auf **OK**: + Eigenschaften von IKE Security Association (Phase 1): + **Perform key exchange encryption with**: AES-128 + **Perform data integrity with**: SHA-1 + IPsec Eigenschaften von Security Association (Phase 2): + **Führen Sie eine IPsec Datenverschlüsselung durch mit**: AES-128 + **Perform data integrity with**: SHA-1 1. Klicken Sie im Kategoriebereich auf **Tunnel Management**. Klicken Sie auf **Set Permanent Tunnels** und **On all tunnels in the community**. Wählen Sie im Bereich **VPN Tunnel Sharing** **One VPN tunnel per Gateway pair** aus. 1. Erweitern Sie im Kategoriebereich **Advanced Settings** und klicken Sie auf **Shared Secret**. 1. Wählen Sie den Peer-Namen für den ersten Tunnel aus, klicken Sie auf **Edit (Bearbeiten)** und geben Sie den vorinstallierten Schlüssel aus dem Bereich `IPSec Tunnel #1` der Konfigurationsdatei ein. 1. Wählen Sie den Peer-Namen für den zweiten Tunnel aus, klicken Sie auf **Edit (Bearbeiten)** und geben Sie den vorinstallierten Schlüssel aus dem Bereich `IPSec Tunnel #2` der Konfigurationsdatei ein. ![\[Check Point-Dialogfeld "Gemeinsamer geheimer Schlüssel"\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/check-point-shared-secret.png) 1. Klicken Sie – noch immer in der Kategorie **Advanced Settings (Erweiterte Einstellungen)** – auf **Advanced VPN Properties (Erweiterte VPN-Eigenschaften)**, konfigurieren Sie die Eigenschaften wie nachfolgend beschrieben und klicken Sie abschließend auf **OK**: + IKE (Phase 1): + ** Diffie-Hellman-Gruppe verwenden**: `Group 2 (1024 bit)` + **Renegotiate IKE security associations every** `480` **minutes** + IPsec (Phase 2): + **Use Perfect Forward Secrecy** auswählen + ** Diffie-Hellman-Gruppe verwenden**: `Group 2 (1024 bit)` + **Verhandeln Sie IPsec Sicherheitszuordnungen alle** **Sekunden neu `3600`** **So erstellen Sie Firewall-Regeln** Dann konfigurieren Sie eine Richtlinie mit Firewall-Regeln und direktionalen Übereinstimmungsregeln, um Kommunikation zwischen der VPC und dem On-Premise-Netzwerk zu ermöglichen. Dann installieren Sie diese Richtlinie auf Ihrem Gateway. 1. Wählen Sie im SmartDashboard **Global Properties** für Ihr Gateway aus. Erweitern Sie im Kategoriebereich **VPN** und klicken Sie auf **Advanced**. 1. Klicken Sie auf **Enable VPN Directional Match in VPN Column** und anschließend auf **OK**. 1. Wählen Sie im die SmartDashboard Option **Firewall** aus und erstellen Sie eine Richtlinie mit den folgenden Regeln: + Erlauben Sie dem VPC-Subnetz, über die erforderlichen Protokolle mit dem lokalen Netzwerk zu kommunizieren. + Erlauben Sie dem lokalen Netzwerk, über die erforderlichen Protokolle mit dem VPC-Subnetz zu kommunizieren. 1. Öffnen Sie das Kontextmenü für die Zelle in der VPN-Spalte und klicken Sie auf **Edit Cell**. 1. Klicken Sie im Dialogfeld **VPN Match Conditions** auf **Match traffic in this direction only**. Klicken Sie jeweils auf **Add (Hinzufügen)** und abschließend auf **OK**: + `internal_clear` > VPN-Community (die VPN-Star-Community, die Sie vorher erstellt haben, z. B. `AWS_VPN_Star`) + VPN-Community > VPN-Community + VPN-Community > `internal_clear` 1. Wählen Sie im die SmartDashboard Option **Richtlinie**, **Installieren** aus. 1. Wählen Sie im Dialogfeld das Gateway aus und klicken Sie auf **OK**, um die Richtlinie zu installieren. **So ändern Sie die Eigenschaft "tunnel\$1keepalive\$1method"** Sie können für Ihren Check Point-Gateway Dead Peer Detection (DPD) verwenden, um Ausfälle bei der IKE-Zuordnung zu identifizieren. Um DPD für einen permanenten Tunnel zu konfigurieren, muss der permanente Tunnel in der AWS VPN-Community konfiguriert werden. Standardmäßig ist für die Eigenschaft `tunnel_keepalive_method` eines VPN-Gateways der Wert `tunnel_test` festgelegt. Sie müssen diesen Wert zu `dpd` ändern. Für alle VPN-Gateways innerhalb der VPN-Community, einschließlich VPN-Gateways von Drittanbietern, für die Sie DPD-Überwachung aktivieren möchten, muss die Eigenschaft `tunnel_keepalive_method` konfiguriert werden. Es ist nicht möglich, für dasselbe Gateway unterschiedliche Überwachungsmechanismen zu konfigurieren. Sie können die `tunnel_keepalive_method` Eigenschaft mit dem DBedit GUI-Tool aktualisieren. 1. Öffnen Sie den Check Point SmartDashboard und wählen Sie **Security Management Server**, **Domain Management Server**. 1. Klicken Sie auf **File** und **Database Revision Control…** und erstellen Sie einen Versions-Snapshot. 1. Schließen Sie alle SmartConsole Fenster, z. B. SmartView Tracker und SmartView Monitor. SmartDashboard 1. Starten Sie das BDedit GUI-Tool. Weitere Informationen finden Sie im Artikel [Check Point Database Tool](https://support.checkpoint.com/results/sk/sk13009) im Check Point-Supportcenter. 1. Klicken Sie auf **Security Management Server** und **Domain Management Server**. 1. Klicken Sie oben links auf **Table**, **Network Objects** und **network\$1objects**. 1. Wählen Sie oben rechts das entsprechende **Security Gateway**-**Cluster**-Objekt aus. 1. Drücken Sie STRG \$1 F oder verwenden Sie das **Suchmenü**, um nach folgender Zeichenfolge zu suchen: `tunnel_keepalive_method`. 1. Öffnen Sie im unteren Bereich das Kontextmenü für `tunnel_keepalive_method` und klicken Sie auf **Edit…**. Wählen Sie **dpd**, **OK**. 1. Wiederholen Sie die Schritte 7 bis 9 für jedes Gateway, das Teil der AWS VPN-Community ist. 1. Klicken Sie auf **File** und **Save All**. 1. Schließen Sie das DBedit GUI-Tool. 1. Öffnen Sie den Check Point SmartDashboard und wählen Sie **Security Management Server**, **Domain Management Server**. 1. Installieren Sie die Richtlinie für das entsprechende **Security Gateway**-**Cluster**-Objekt. Weitere Informationen finden Sie im Artikel [New VPN features in R77.10](https://support.checkpoint.com/results/sk/sk97746) im Check Point-Supportcenter. **So aktivieren Sie TCP MSS Clamping** Mit TCP MSS Clamping können Sie die maximale Segmentgröße von TCP-Paketen reduzieren, um eine Paketfragmentierung zu vermeiden. 1. Öffnen Sie das folgende Verzeichnis: `C:\Program Files (x86)\CheckPoint\SmartConsole\R77.10\PROGRAM\`. 1. Führen Sie die Datei `GuiDBEdit.exe` aus, um das Check Point-Datenbank-Tool zu starten. 1. Wählen Sie **Table**, **Global Properties** und **properties** aus. 1. Klicken Sie für `fw_clamp_tcp_mss` auf **Edit**. Ändern Sie den Wert in `true` und wählen Sie dann **OK**. **So überprüfen Sie den Tunnelstatus** Sie können den Tunnelstatus überprüfen, indem Sie den folgenden Befehl vom Befehlszeilen-Tool aus im Expertenmodus ausführen. ``` vpn tunnelutil ``` Wählen Sie in den angezeigten Optionen **1** aus, um die IKE-Verknüpfungen zu überprüfen, und **2**, um die IPsec Verknüpfungen zu überprüfen. Im Check Point Smart Tracker-Protokoll können Sie auch überprüfen, ob Pakete über diese Verbindung verschlüsselt werden. Dem folgenden Protokoll können Sie beispielsweise entnehmen, dass ein Paket verschlüsselt über Tunnel 1 an die VPC gesendet wurde. ![\[Check Point-Protokolldatei\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/check-point-log.png) ------ #### [ SonicWALL ] Sie können ein SonicWALL-Gerät über die SonicOS-Verwaltungsoberfläche konfigurieren. Weitere Informationen zur Konfiguration von Tunneln finden Sie unter [Konfigurieren Sie statisches Routing für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](cgw-static-routing-example-interface.md). Sie können das BGP des Geräts nicht mit der Management-Schnittstelle konfigurieren. Verwenden Sie stattdessen die Befehlszeilenanleitungen, die in der oben gezeigten Beispielkonfigurationsdatei unter dem Abschnitt **BGP** genannt sind. ------ ## Cisco-Geräte: zusätzliche Informationen Einige Cisco unterstützen ASAs nur Active/Standby den Modus. Wenn Sie diese Cisco verwenden ASAs, können Sie jeweils nur einen aktiven Tunnel haben. Der andere Standby-Tunnel wird aktiv, falls der erste Tunnel nicht verfügbar ist. Diese Redundanz sorgt dafür, dass immer ein Tunnel für die Verbindung zu Ihrer VPC verfügbar ist. Cisco unterstützt ASAs ab Version 9.7.1 und höher den Active/Active Unterstützungsmodus. Wenn Sie diese Cisco verwenden ASAs, können Sie beide Tunnel gleichzeitig aktiv haben. Diese Redundanz sorgt dafür, dass immer ein Tunnel für die Verbindung zu Ihrer VPC verfügbar ist. Für Cisco-Geräte müssen Sie die folgenden Schritte ausführen: + Konfigurieren Sie die Außenschnittstelle. + Stellen Sie sicher, dass die Crypto ISAKMP-Richtliniensequenznummer eindeutig ist. + Stellen Sie sicher, dass die Crypto List-Richtliniensequenznummer eindeutig ist. + Stellen Sie sicher, dass das Crypto IPsec Transform Set und die Crypto ISAKMP Policy Sequence mit allen anderen IPsec Tunneln, die auf dem Gerät konfiguriert sind, harmonieren. + Stellen Sie sicher, dass die SLA-Überwachungsnummer eindeutig ist. + Konfigurieren Sie sämtliche internen Routen, über die Datenverkehr zwischen dem Kunden-Gateway-Gerät und Ihrem On-Premise-Netzwerk gesendet wird. ## Juniper-Geräte: zusätzliche Informationen Die folgenden Informationen beziehen sich auf die Beispielkonfigurationsdateien für Kunden-Gateway-Geräte der Juniper J-Serie und SRX. + Die externe Schnittstelle wird als *ge-0/0/0.0* bezeichnet. + Die Tunnelschnittstelle IDs wird als *st0.1* und bezeichnet*st0.2*. + Vergewissern Sie sich, dass Sie die Sicherheitszone für die Uplink-Schnittstelle identifizieren (die Konfigurationsinformationen verwenden die standardmäßige "Nicht vertrauenswürdig"-Zone). + Stellen Sie sicher, dass Sie die Sicherheitszone für die interne Schnittstelle identifizieren (die Konfigurationsinformationen verwenden die standardmäßige "Vertrauenswürdig"Zone). # Windows Server als AWS Site-to-Site VPN Kunden-Gatewaygerät konfigurieren Sie können einen Server mit Windows Server als Kunden-Gateway-Gerät für Ihre VPC konfigurieren. Die folgende Anleitung kann unabhängig davon angewendet werden, ob Sie Windows Server auf einer EC2-Instance in einer VPC oder auf Ihrem eigenen Server ausführen. Die folgenden Verfahren gelten für Windows Server 2012 R2 und höher. **Topics** + [Konfigurieren der Windows-Instance](#cgw-device-windows-server-configure-instance) + [Schritt 1: Erstellen einer VPN-Verbindung und Konfigurieren Ihrer VPC](#cgw-device-windows-server-vpn) + [Schritt 2: Herunterladen der Konfigurationsdatei für die VPN-Verbindung](#cgw-device-windows-server-config) + [Schritt 3: Konfigurieren des Windows-Servers](#cgw-device-windows-server-configure) + [Schritt 4: Einrichten des VPN-Tunnels](#cgw-device-windows-server-setup-tunnel) + [Schritt 5: Aktivieren von Dead Gateway Detection](#cgw-device-windows-server-gateway-detection) + [Schritt 6: Testen der VPN-Verbindung](#cgw-device-windows-server-test-connection) ## Konfigurieren der Windows-Instance Wenn Sie Windows Server auf einer EC2-Instance konfigurieren, die Sie von einem Windows-AMI aus gestartet haben, gehen Sie wie folgt vor: + Deaktivieren Sie die source/destination Überprüfung für die Instanz: 1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Wählen Sie Ihre Windows-Instance aus und wählen Sie dann **Actions**, **Networking**, **Change Source/Dest. check**. Wählen Sie **Add** und dann **Save** aus. + Aktualisieren Sie Ihre Adapter-Einstellungen, sodass Sie Datenverkehr von anderen Instances weiterleiten können: 1. Herstellen einer Verbindung mit Ihrer Windows-Instance. Weitere Informationen finden Sie unter [Verbindung zu Ihrer Windows-Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html). 1. Öffnen Sie die Systemsteuerung und starten Sie den Geräte-Manager. 1. Erweitern Sie den Knoten **Network adapters**. 1. Wählen Sie den Netzwerkadapter (je nach Instance-Typ kann dies Amazon Elastic Network Adapter oder Intel 82599 Virtual Function sein) und wählen Sie **Action**, **Properties**. 1. **Deaktivieren Sie auf der Registerkarte **Erweitert** die Eigenschaften **IPv4Checksum Offload**, **TCP Checksum Offload (IPv4)** und **UDP Checksum Offload (IPv4)** und wählen Sie dann OK.** + Weisen Sie Ihrem Konto eine Elastic-IP-Adresse zu und ordnen Sie diese der Instance zu. Weitere Informationen finden Sie unter [Elastische IP-Adressen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) im *Benutzerhandbuch für Amazon EC2*. Notieren Sie sich diese Adresse — Sie benötigen sie, wenn Sie das Kunden-Gateway erstellen. + Stellen Sie sicher, dass die Sicherheitsgruppenregeln der Instanz ausgehenden IPsec Datenverkehr zulassen. Standardmäßig lässt eine Sicherheitsgruppe den gesamten ausgehenden Datenverkehr zu. Wenn die ausgehenden Regeln der Sicherheitsgruppe jedoch gegenüber ihrem ursprünglichen Status geändert wurden, müssen Sie die folgenden benutzerdefinierten Protokollregeln für ausgehenden IPsec Datenverkehr erstellen: IP-Protokoll 50, IP-Protokoll 51 und UDP 500. Beachten Sie beispielsweise den CIDR-Bereich des Netzwerks, in dem sich Ihre Windows-Instance befindet, z. B. `172.31.0.0/16`. ## Schritt 1: Erstellen einer VPN-Verbindung und Konfigurieren Ihrer VPC Um eine VPN-Verbindung von Ihrer VPC aus zu erstellen, gehen Sie folgendermaßen vor: 1. Erstellen Sie ein Virtual Private Gateway und weisen Sie es Ihrer VPC zu. Weitere Informationen finden Sie unter [Erstellen eines Virtual Private Gateways](SetUpVPNConnections.md#vpn-create-vpg). 1. Erstellen Sie eine VPN-Verbindung und ein neues Kunden-Gateway. Geben Sie für das Kunden-Gateway die öffentliche IP-Adresse Ihres Windows-Servers an. Wählen Sie für die VPN-Verbindung statisches Routing aus. Geben Sie dann den CIDR-Bereich für Ihr Netzwerk ein, in dem sich der Windows-Server befindet, z. B. `172.31.0.0/16`. Weitere Informationen finden Sie unter [Schritt 5: Eine VPN-Verbindung erstellen](SetUpVPNConnections.md#vpn-create-vpn-connection). Nachdem Sie die VPN-Verbindung erstellt haben, konfigurieren Sie die VPC so, dass die Kommunikation über die VPN-Verbindung ermöglicht wird. **Konfigurieren Ihrer VPC** + Erstellen Sie ein privates Subnetz in der VPC (sofern nicht schon vorhanden), mit dem Sie Instances starten können, die mit dem Windows Server kommunizieren sollen. Weitere Informationen finden Sie unter [Erstellen eines Subnetzes in Ihrer VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#AddaSubnet). **Anmerkung** Ein privates Subnetz ist ein Subnetz ohne Weiterleitung an das Internet-Gateway. Das Routing für dieses Subnetz wird unter dem nächsten Punkt beschrieben. + Aktualisieren der Routing-Tabellen für die VPN-Verbindung: + Fügen Sie der Routing-Tabelle Ihres privaten Subnetzes eine Route mit dem Virtual Private Gateway als Ziel und dem Netzwerk des Windows-Servers (CIDR-Bereich) als Zielbereich hinzu. Weitere Informationen finden Sie unter [Hinzufügen und Entfernen von Routen aus einer Routing-Tabelle](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes) im *Amazon VPC-Benutzerhandbuch*. + Aktivieren Sie die Routing-Verbreitung für das Virtual Private Gateway. Weitere Informationen finden Sie unter [(Virtual Private Gateway) Aktivieren Sie die Routenverbreitung in Ihrer Routing-Tabelle](SetUpVPNConnections.md#vpn-configure-routing). + Erstellen Sie eine Sicherheitsgruppe für Ihre Instances, die die Kommunikation zwischen Ihrer VPC und Ihrem Netzwerk ermöglicht: + Fügen Sie Regeln hinzu, die eingehenden RDP- bzw. SSH-Zugriff von Ihrem Netzwerk zulassen. So können Sie von Ihrem Netzwerk aus eine Verbindung zu Instances in Ihrer VPC herstellen. Wenn Sie z. B. möchten, dass Computer in Ihrem Netzwerk Zugriff auf die Linux-Instances in Ihrer VPC haben, erstellen Sie eine Eingangsregel mit einem SSH-Typ und stellen Sie die Quelle auf den CIDR-Bereich Ihres Netzwerks ein, z. B. `172.31.0.0/16`. Weitere Informationen finden Sie unter [Sicherheitsgruppenregeln für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) im *Amazon VPC-Benutzerhandbuch*. + Fügen Sie eine Regel hinzu, die eingehenden ICMP-Zugriff von Ihrem Netzwerk zulässt. So können Sie Ihre VPN-Verbindung testen, indem Sie von Ihrem Windows-Server aus einen Ping an eine Instance in der VPC senden. ## Schritt 2: Herunterladen der Konfigurationsdatei für die VPN-Verbindung Sie können mithilfe der Amazon VPC-Konsole eine Windows-Server-Konfigurationsdatei für die VPN-Verbindung herunterladen. **So laden Sie die Konfigurationsdatei herunter** 1. Öffnen Sie die Amazon-VPC-Konsole unter [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Wählen Sie im Navigationsbereich **Site-to-Site VPN Connections** aus. 1. Wählen Sie erst Ihre VPN-Verbindung und dann **Download Configuration (Konfiguration herunterladen)** aus. 1. Wählen Sie als Anbieter **Microsoft**, als Plattform **Windows Server** und als Software **2012 R2** aus. Wählen Sie **Herunterladen** aus. Sie können die Datei öffnen oder speichern. Die Konfigurationsdatei enthält einen Abschnitt mit Informationen, der dem folgenden Beispiel ähnelt. Diese Informationen werden zweimal angezeigt, einmal für jeden Tunnel. ``` vgw-1a2b3c4d Tunnel1 -------------------------------------------------------------------- Local Tunnel Endpoint:       203.0.113.1 Remote Tunnel Endpoint:      203.83.222.237 Endpoint 1:                  [Your_Static_Route_IP_Prefix] Endpoint 2:                  [Your_VPC_CIDR_Block] Preshared key:               xCjNLsLoCmKsakwcdoR9yX6GsEXAMPLE ``` `Local Tunnel Endpoint` Die IP-Adresse, die Sie für das Kunden-Gateway angegeben haben, als Sie die VPN-Verbindung erstellt haben. `Remote Tunnel Endpoint` Eine von zwei IP-Adressen für das Virtual Private Gateway, das die VPN-Verbindung auf der AWS Seite der Verbindung beendet. `Endpoint 1` Das IP-Präfix, das Sie beim Erstellen der VPN-Verbindung als statische Route konfiguriert haben. Dabei handelt es sich um die IP-Adressen in Ihrem Netzwerk, die über die VPN-Verbindung auf die VPC zugreifen können. `Endpoint 2` Der IP-Adressbereich (CIDR-Block) der VPC, die mit dem Virtual Private Gateway verknüpft ist (z. B. 10.0.0.0/16) `Preshared key` Der vorab gemeinsam genutzte Schlüssel, der zum Herstellen der IPsec VPN-Verbindung zwischen und `Local Tunnel Endpoint` verwendet wird. `Remote Tunnel Endpoint` Wir empfehlen Ihnen, beide Tunnel als Teil der VPN-Verbindung zu konfigurieren. Jeder Tunnel ist mit einem separaten Site-to-Site VPN-Konzentrator auf der Amazon-Seite der VPN-Verbindung verbunden. Es ist zwar jeweils nur ein Tunnel aktiv, aber der zweite Tunnel baut sich automatisch auf, wenn der erste Tunnel ausfällt. Redundante Tunnel gewährleisten eine kontinuierliche Verfügbarkeit im Falle eines Geräteausfalls. Da nur ein Tunnel gleichzeitig verfügbar ist, wird auf der Amazon VPC-Konsole angezeigt, dass ein Tunnel inaktiv ist. Dies ist jedoch Absicht und bedarf keiner Handlung Ihrerseits. Wenn zwei Tunnel konfiguriert sind und innerhalb weniger Minuten ein Geräteausfall auftritt AWS, wird Ihre VPN-Verbindung automatisch auf den zweiten Tunnel des Virtual Private Gateways umgestellt. Konfigurieren Sie beim Konfigurieren Ihres Kunden-Gateway-Geräts unbedingt beide Tunnel. **Anmerkung** AWS Führt von Zeit zu Zeit routinemäßige Wartungsarbeiten am Virtual Private Gateway durch. Durch diese Wartungsarbeiten kann es vorkommen, dass ein oder beide Tunnel der VPN-Verbindung kurzzeitig deaktiviert werden. Ihre VPN-Verbindung schaltet automatisch auf den zweiten Tunnel, während diese Wartungen durchgeführt werden. Zusätzliche Informationen zu Internet Key Exchange (IKE) und IPsec Security Associations (SA) finden Sie in der heruntergeladenen Konfigurationsdatei. ``` MainModeSecMethods: DHGroup2-AES128-SHA1 MainModeKeyLifetime: 480min,0sess QuickModeSecMethods: ESP:SHA1-AES128+60min+100000kb QuickModePFS: DHGroup2 ``` `MainModeSecMethods` Die Verschlüsselungs- und Authentifizierungsalgorithmen für die IKE-SA. Dies sind die empfohlenen Einstellungen für die VPN-Verbindung und die Standardeinstellungen für Windows IPsec Server-VPN-Verbindungen. `MainModeKeyLifetime` Die Lebensdauer des IKE-SA-Schlüssels.  Dies ist die empfohlene Einstellung für die VPN-Verbindung und die Standardeinstellung für Windows IPsec Server-VPN-Verbindungen. `QuickModeSecMethods` Die Verschlüsselungs- und Authentifizierungsalgorithmen für die IPsec SA. Dies sind die empfohlenen Einstellungen für die VPN-Verbindung und die Standardeinstellungen für Windows IPsec Server-VPN-Verbindungen. `QuickModePFS` Wir empfehlen Ihnen, Master Key Perfect Forward Secrecy (PFS) für Ihre Sitzungen zu verwenden. IPsec ## Schritt 3: Konfigurieren des Windows-Servers Bevor Sie den VPN-Tunnel einrichten, müssen Sie Routing- und RAS-Dienste auf Windows Server installieren und konfigurieren. Dadurch können Benutzer auf die Ressourcen in Ihrem Netzwerk zugreifen. **So installieren Sie Routing- und Remotezugriff-Services** 1. Melden Sie sich bei Ihrem Windows Server an. 1. Navigieren Sie zum Menü **Start** und wählen Sie **Server-Manager** aus. 1. Installation der Routing- und Remotezugriff-Services: 1. Wählen Sie im Menü **Verwalten** die Option **Rollen und Features hinzufügen** aus. 1. Überprüfen Sie auf der Seite **Bevor Sie beginnen**, ob Ihr Server alle Voraussetzungen erfüllt, und klicken Sie dann auf **Weiter**. 1. Wählen Sie erst **Rollenbasierte oder featurebasierte Installation** und dann **Weiter** aus. 1. Wählen Sie erst die Option **Einen Server aus dem Serverpool auswählen**, dann den Windows-Server und anschließend **Weiter** aus. 1. Wählen Sie **Netzwerkrichtlinien- und Zugriffsdienste** aus der Liste aus. Wählen Sie im daraufhin angezeigten Dialogfeld **Features hinzufügen** aus, um die für diese Rolle erforderlichen Funktionen zu bestätigen. 1. Wählen Sie in derselben Liste **Remote Access (Remotezugriff)** und dann **Next (Weiter)** aus. 1. Wählen Sie auf der Seite **Features auswählen** die Option **Weiter** aus. 1. Wählen Sie auf der Seite **Netzwerkrichtlinien- und Zugriffsdienste** **Weiter** aus. 1. Wählen Sie auf der Seite **Remotezugriff** die Option **Weiter** aus. Wählen Sie DirectAccess auf der nächsten Seite **VPN (**RAS) aus. Wählen Sie im angezeigten Dialogfeld die Option **Features hinzufügen** aus, um die für diesen Rollenservice erforderlichen Funktionen zu bestätigen. Wählen Sie in derselben Liste **Routing** und anschließend **Weiter** aus. 1. Klicken Sie auf der Seite **Rolle 'Webserver' (IIS)** auf **Weiter**. Belassen Sie die Standardauswahl und wählen Sie **Weiter** aus. 1. Wählen Sie **Installieren** aus. Nach abgeschlossener Installation wählen Sie **Schließen** aus. **So konfigurieren und aktivieren Sie den Routing- und Remotezugriff-Server** 1. Wählen Sie auf dem Dashboard **Benachrichtigungen** (das Flag-Symbol) aus. Es sollte eine Aufgabe angezeigt werden, mit der Sie die Konfiguration nach der Bereitstellung abschließen können. Wählen Sie den Link **Assistent für erste Schritte öffnen** aus. 1. Wählen Sie **Nur VPN bereitstellen** aus. 1. Wählen Sie im Dialogfenster **Routing and Remote Access (Routing und Remotezugriff(** den Servernamen, dann **Action (Aktion)** und anschließend **Configure and Enable Routing und Remote Access (Routing und RAS konfigurieren und aktivieren)** aus. 1. Wählen Sie auf der ersten Seite des **Setup-Assistent für den Routing- und RAS-Server** die Option **Weiter** aus. 1. Wählen Sie auf der Seite **Configuration (Konfiguration)** erst die Option **Custom Configuration (Benutzerdefinierte Konfiguration)** und anschließend **Next (Weiter)** aus. 1. Wählen Sie **LAN routing (LAN-Routing)**, **Next (Weiter)** und **Finish (Fertig stellen)** aus. 1. Wenn das Dialogfeld **Routing und Remotezugriff** Sie dazu auffordert, wählen Sie **Dienst starten** aus. ## Schritt 4: Einrichten des VPN-Tunnels Sie können den VPN-Tunnel konfigurieren, indem Sie die in der heruntergeladenen Konfigurationsdatei enthaltenen Netsh-Skripte ausführen oder die Windows Server-Benutzeroberfläche verwenden. **Wichtig** Wir empfehlen Ihnen, Master Key Perfect Forward Secrecy (PFS) für Ihre Sitzungen zu verwenden. IPsec Wenn Sie das Netsh-Skript ausführen möchten, enthält es einen Parameter zur Aktivierung von PFS (). `qmpfs=dhgroup2` Sie können PFS nicht über die Windows-Benutzeroberfläche aktivieren, sondern müssen es über die Befehlszeile aktivieren. **Topics** + [Option 1: Ausführen des Netsh-Skripts](#cgw-device-windows-server-run-netsh) + [Option 2: Verwenden der Windows-Server-Benutzeroberfläche](#cgw-device-windows-server-ui) ### Option 1: Ausführen des Netsh-Skripts Kopieren Sie das Netsh-Skript aus der heruntergeladenen Konfigurationsdatei und ersetzen Sie die Variablen. Nachfolgend sehen Sie ein Beispielskript. ``` netsh advfirewall consec add rule Name="vgw-1a2b3c4d Tunnel 1" ^ Enable=Yes Profile=any Type=Static Mode=Tunnel ^ LocalTunnelEndpoint=Windows_Server_Private_IP_address ^ RemoteTunnelEndpoint=203.83.222.236 Endpoint1=Your_Static_Route_IP_Prefix ^ Endpoint2=Your_VPC_CIDR_Block Protocol=Any Action=RequireInClearOut ^ Auth1=ComputerPSK Auth1PSK=xCjNLsLoCmKsakwcdoR9yX6GsEXAMPLE ^ QMSecMethods=ESP:SHA1-AES128+60min+100000kb ^ ExemptIPsecProtectedConnections=No ApplyAuthz=No QMPFS=dhgroup2 ``` **Name**: Sie können den empfohlenen Namen (`vgw-1a2b3c4d Tunnel 1)` durch einen beliebigen Namen ersetzen. **LocalTunnelEndpoint**: Geben Sie die private IP-Adresse des Windows Servers in Ihrem Netzwerk ein. **Endpoint1**: Der CIDR-Block Ihres Netzwerks, in dem sich der Windows-Server befindet, beispielsweise `172.31.0.0/16`. Umgeben Sie diesen Wert mit doppelten Anführungszeichen ("). **Endpoint2**: Der CIDR-Block Ihrer VPC oder eines Subnetzes der VPC, beispielsweise `10.0.0.0/16`. Umgeben Sie diesen Wert mit doppelten Anführungszeichen ("). Führen Sie das aktualisierte Skript in einem Befehlszeilenfenster auf dem Windows-Server aus. (Mit ^ können Sie umgebrochenen Text in der Eingabeaufforderung kopieren und einfügen.) Wiederholen Sie diese Vorgehensweise mit dem zweiten Netsh-Skript aus der Konfigurationsdatei, um den zweiten VPN-Tunnel einzurichten. Wenn Sie fertig sind, rufen Sie [Konfigurieren der Windows-Firewall](#cgw-device-windows-server-firewall) auf. *Weitere Informationen zu den Netsh-Parametern finden Sie unter [Netsh AdvFirewall Consec-Befehle](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd736198(v=ws.10)?redirectedfrom=MSDN#BKMK_2_set) in der Microsoft-Bibliothek. TechNet* ### Option 2: Verwenden der Windows-Server-Benutzeroberfläche Sie können den VPN-Tunnel auch über die Windows-Server-Benutzeroberfläche einrichten. **Wichtig** Sie können über die Windows-Server-Benutzeroberfläche keinen PFS-fähigen (Perfect Forward Secrecy) Master Key aktivieren. Sie müssen PFS über die Befehlszeile aktivieren, wie in [Master Key Perfect Forward Secrecy aktivieren](#cgw-device-windows-server-enable-pfs) beschrieben. **Topics** + [Konfigurieren einer Sicherheitsregel für einen VPN-Tunnel](#cgw-device-windows-server-security-rule) + [Überprüfen der Tunnelkonfiguration](#cgw-device-windows-server-confirm-tunnel) + [Master Key Perfect Forward Secrecy aktivieren](#cgw-device-windows-server-enable-pfs) + [Konfigurieren der Windows-Firewall](#cgw-device-windows-server-firewall) #### Konfigurieren einer Sicherheitsregel für einen VPN-Tunnel In diesem Abschnitt konfigurieren Sie eine Sicherheitsregel auf Ihrem Windows-Server, um einen VPN-Tunnel zu erstellen. **So konfigurieren Sie eine Sicherheitsregel für einen VPN-Tunnel** 1. Öffnen Sie den Server-Manager, wählen Sie **Tools** und dann **Windows Defender Firewall with Advanced Security (Windows-Firewall mit erweiterter Sicherheit)** aus. 1. Wählen Sie erst **Verbindungssicherheitsregeln**, dann **Aktion** und anschließend **Neue Regel** aus. 1. Wählen Sie im **Assistent für neue Verbindungssicherheitsregeln** auf der Seite **Regeltyp** erst **Tunnel** und anschließend **Weiter** aus. 1. Wählen Sie auf der Seite **Tunneltype** unter **Welche Art von Tunnel möchten Sie erstellen?** die Option **Benutzerdefinierte Konfiguration** aus. **Lassen Sie unter **Möchten Sie IPsec -geschützte Verbindungen von diesem Tunnel** ausnehmen, den Standardwert aktiviert (Nein). Senden Sie den gesamten Netzwerkverkehr, der dieser Verbindungssicherheitsregel entspricht, durch den Tunnel**, und klicken Sie dann auf **Weiter**. 1. Wählen Sie auf der Seite „**Anforderungen**“ die Option **Authentifizierung für eingehende Verbindungen erforderlich aus. Richten Sie keine Tunnel für ausgehende Verbindungen** **ein und wählen Sie dann Weiter.** 1. Wählen Sie auf der Seite **Tunnel Endpoints (Tunnelendpunkte)** unter **Which computers are in Endpoint 1 (Welche Computer befinden sich im Endpunkt 1)** die Option **Add (Hinzufügen)** aus. Geben Sie den CIDR-Bereich Ihres Netzwerks (nach Ihrem Windows Server-Kunden-Gateway) ein, z. B. `172.31.0.0/16`, und wählen Sie dann **OK** aus. Der Bereich kann die IP-Adresse Ihres Kunden-Gateway-Geräts beinhalten. 1. Wählen Sie unter **Was ist der lokale Tunnelendpunkt (am nächsten zu Computer in Endpunkt 1)** die Option **Bearbeiten** aus. Geben Sie in das **IPv4 Adressfeld** die private IP-Adresse Ihres Windows Servers ein, und wählen Sie dann **OK**. 1. Wählen Sie unter **Was ist der Remotetunnelendpunkt (am nächsten zu Computern in Endpunkt 2)?** die Option **Bearbeiten** aus. Geben Sie in das **IPv4 Adressfeld** die IP-Adresse des virtuellen privaten Gateways für Tunnel 1 aus der Konfigurationsdatei ein (siehe`Remote Tunnel Endpoint`), und wählen Sie dann **OK**. **Wichtig** Wenn Sie diesen Vorgang für Tunnel 2 wiederholen, wählen Sie für Tunnel 2 den korrekten Endpunkt aus. 1. Wählen Sie unter **Welche Computer befinden sich im Endpunkt 2?** die Option **Hinzufügen** aus. Geben Sie in das Feld **Diese IP-Adresse oder Subnetzfeld** den CIDR-Block Ihrer VPC ein und wählen Sie dann **OK** aus. **Wichtig** Blättern Sie im Dialogfeld nach unten bis zu **Welche Computer befinden sich im Endpunkt 2?**. Wählen Sie erst dann **Weiter** aus, wenn Sie diesen Schritt abgeschlossen haben, da Sie sonst keine Verbindung zum Server herstellen können. ![\[Assistent für neue Verbindungssicherheitsregeln: Tunnelendpunkte\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/tunnelendpoints_complete_win2012.png) 1. Bestätigen Sie, dass sämtliche Einstellungen korrekt sind und wählen Sie dann **Next (Weiter)** aus. 1. Wählen Sie auf der Seite **Authentication Method (Authentifizierungsmethode)** **Advanced (Erweitert)** und dann die Option **Customize (Anpassen)**. 1. Wählen Sie unter **Erste Authentifizierungsmethoden** die Option **Hinzufügen** aus. 1. Wählen Sie **Preshared key (Vorinstallierter Schlüssel)** aus, geben Sie den Wert des vorinstallierten Schlüssels aus der Konfigurationsdatei ein und wählen Sie **OK** aus. **Wichtig** Wenn Sie diesen Vorgang für Tunnel 2 wiederholen, achten Sie darauf, dass Sie für Tunnel 2 den korrekten vorinstallierten Schlüssel auswählen. 1. Achten Sie darauf, dass die Option **Erste Authentifizierung ist optional** nicht ausgewählt ist und wählen Sie **OK** aus. 1. Wählen Sie **Weiter** aus. 1. Aktivieren Sie auf der Seite **Profile (Profil)** die drei Kontrollkästchen **Domain (Domäne)**, **Private (Privat)** und **Public (Öffentlich)**. Wählen Sie **Weiter** aus. 1. Geben Sie auf der Seite **Name** einen Namen für Ihre Verbindungsregel ein, z. B. `VPN to Tunnel 1` und wählen Sie dann **Fertig stellen** aus. Wiederholen Sie das vorhergehende Verfahren und geben Sie die Daten für Tunnel 2 aus Ihrer Konfigurationsdatei an. Wenn Sie fertig sind, sind beide Tunnel für Ihre VPN-Verbindung konfiguriert. #### Überprüfen der Tunnelkonfiguration **So überprüfen Sie die Tunnelkonfiguration** 1. Öffnen Sie den Server-Manager, wählen Sie zuerst **Tools**, dann **Windows-Firewall mit erweiterter Sicherheit** und anschließend **Verbindungssicherheitsregeln** aus. 1. Überprüfen Sie für beide Tunnel Folgendes: + Für **Aktiviert** ist `Yes` ausgewählt. + **Endpunkt 1** entspricht dem CIDR-Block für Ihr Netzwerk. + **Endpunkt 2** entspricht dem CIDR-Block Ihrer VPC. + Für **Authentication mode (Authentifizierungsmodus)** ist `Require inbound and clear outbound` ausgewählt. + Für **Authentifizierungsmethode** ist `Custom` ausgewählt. + Für **Endpunkt 1-Port** ist `Any` ausgewählt. + Für **Endpunkt 2-Port** ist `Any` ausgewählt. + Für **Protokoll** ist `Any` ausgewählt. 1. Wählen Sie die erste Regel und dann **Eigenschaften** aus. 1. Wählen Sie auf der Registerkarte **Authentication (Authentifizierung)** unter **Method (Methode)** die Option **Customize (Anpassen)** aus. Vergewissern Sie sich, dass **First authentication methods (Erste Authentifizierungsmethoden)** den korrekten Pre-Shared-Key aus Ihrer Konfigurationsdatei für den Tunnel enthält, und wählen Sie dann **OK** aus. 1. Überprüfen Sie auf der Registerkarte **Erweitert**, ob die drei Optionen **Domäne**, **Privat** und **Öffentlich** ausgewählt sind. 1. **Wählen Sie unter **IPsec Tunneling die** Option Anpassen aus.** Überprüfen Sie die folgenden IPsec Tunneleinstellungen, und wählen Sie dann OK und erneut ****OK****, um das Dialogfeld zu schließen. + ** IPsec Tunneling verwenden** ist ausgewählt. + **Lokaler Tunnelendpunkt (am nächsten zu Endpunkt 1)** enthält die IP-Adresse Ihres Windows-Servers. Wenn es sich bei Ihrem Kunden-Gateway-Gerät um eine EC2-Instance handelt, ist dies die private IP-Adresse der Instance. + **Remotetunnelendpunkt (am nächsten zu Endpunkt 2)** enthält die IP-Adresse des Virtual Private Gateways für diesen Tunnel. 1. Öffnen Sie die Eigenschaften für Ihren zweiten Tunnel. Wiederholen Sie für diesen Tunnel die Schritte 4 bis 7. #### Master Key Perfect Forward Secrecy aktivieren Sie können einen PFS-fähigen (Perfect Forward Secrecy) Master Key über die Befehlszeile aktivieren. Sie können diese Funktion nicht über die Benutzerschnittstelle aktivieren. **Aktivieren eines PFS-fähigen (Perfect Forward Secrecy) Master Keys** 1. Öffnen Sie auf Ihrem Windows-Server ein neues Befehlszeilenfenster. 1. Geben Sie den folgenden Befehl ein und ersetzen Sie `rule_name` durch den Namen, den Sie der ersten Verbindungsregel gegeben haben. ``` netsh advfirewall consec set rule name="rule_name" new QMPFS=dhgroup2 QMSecMethods=ESP:SHA1-AES128+60min+100000kb ``` 1. Wiederholen Sie Schritt zwei für den zweiten Tunnel und ersetzen Sie dieses Mal `rule_name` durch den Namen, den Sie der zweiten Verbindungsregel gegeben haben. #### Konfigurieren der Windows-Firewall Nachdem Sie Ihre Sicherheitsregeln auf Ihrem Server eingerichtet haben, konfigurieren Sie einige IPsec Grundeinstellungen für die Verwendung mit dem Virtual Private Gateway. **So konfigurieren Sie die Windows-Firewall** 1. Öffnen Sie den Server-Manager, wählen Sie **Tools** aus, dann **Windows Defender Firewall mit erweiterter Sicherheit** und anschließend **Eigenschaften**. 1. Stellen Sie auf der Registerkarte **IPsec Einstellungen** unter **IPsecAusnahmen** sicher, dass **ICMP ausschließen von** auf **Nein (Standard) gesetzt IPsec** ist. **Stellen Sie sicher, dass die **IPsec Tunnelautorisierung auf Keine gesetzt** ist.** 1. Wählen Sie unter **IPsec Standardeinstellungen** die Option **Anpassen** aus. 1. Wählen Sie unter **Schlüsselaustausch (Hauptmodus)** die Option **Erweitert** aus und dann **Anpassen**. 1. Bestätigen Sie unter **Customize Advanced Key Exchange Settings (Erweiterte Schlüsselaustauscheinstellungen anpassen)** unter **Security methods (Sicherheitsmethoden)**, dass diese Standardwerte für den ersten Eintrag verwendet werden. + Integrität: SHA-1 + Verschlüsselung: AES-CBC 128 + Schlüsselaustauschalgorithmus: Diffie-Hellman Gruppe 2 + Überprüfen Sie unter **Schlüsselgültigkeitsdauer**, ob für **Minuten** `480` und für **Sitzungen** `0` ausgewählt ist. Diese Einstellungen entsprechen den folgenden Einträgen in der Konfigurationsdatei. ``` MainModeSecMethods: DHGroup2-AES128-SHA1,DHGroup2-3DES-SHA1 MainModeKeyLifetime: 480min,0sec ``` 1. Wählen Sie unter **Schlüsselaustauschoptionen** **Diffie-Hellman für verstärkte Sicherheit verwenden** aus und anschließend **OK**. 1. Wählen Sie unter **Datenschutz (Schnellmodus)** **Erweitert** aus und dann **Anpassen**. 1. Wählen Sie **Verschlüsselung für alle Verbindungssicherheitsregeln erforderlich, die diese Einstellungen verwenden** aus. 1. Übernehmen Sie unter **Datenintegritäts- und Verschlüsselungsalgorithmen** die Standardwerte: + Protokoll: ESP + Integrität: SHA-1 + Verschlüsselung: AES-CBC 128 + Gültigkeitsdauer: 60 Minuten Diese Werte entsprechen dem folgenden Eintrag in der Konfigurationsdatei. ``` QuickModeSecMethods: ESP:SHA1-AES128+60min+100000kb ``` 1. Wählen Sie **OK**, um zum Dialogfeld „**IPsec Einstellungen anpassen**“ zurückzukehren, und klicken Sie erneut **auf OK**, um die Konfiguration zu speichern. ## Schritt 5: Aktivieren von Dead Gateway Detection Konfigurieren Sie als Nächstes TCP, sodass erkannt wird, wenn ein Gateway nicht mehr verfügbar ist. Dafür müssen Sie diesen Registrierungsschlüssel ändern: `HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters`. Tun Sie dies erst, wenn Sie die vorherigen Schritte abgeschlossen haben. Nach dem Ändern des Registrierungsschlüssels müssen Sie den Server neu starten. **So aktivieren Sie Dead Gateway Detection** 1. Starten Sie auf Ihrem Windows Server die Befehlszeile oder eine PowerShell Sitzung und geben Sie **regedit** ein, um den Registrierungseditor zu starten. 1. ****Erweitern Sie **HKEY\$1LOCAL\$1MACHINE**, erweitern Sie **SYSTEM**, erweitern Sie, erweitern Sie **Dienste **CurrentControlSet****, erweitern Sie Tcpip und erweitern Sie dann Parameter.**** 1. Wählen Sie aus dem Menü **Bearbeiten** die Option **Neu** und anschließend **DWORD-Wert (32-Bit)**. 1. Geben Sie den Namen **EnableDeadGWDetect** ein. 1. ****Wählen Sie und wählen Sie Bearbeiten, Ändern. **EnableDeadGWDetect****** 1. Geben Sie unter **Value data** **1** ein und wählen Sie dann **OK** aus. 1. Schließen Sie den Registrierungseditor und starten Sie den Server neu. Weitere Informationen finden Sie [EnableDeadGWDetect](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc960464(v=technet.10)?redirectedfrom=MSDN)in der * TechNetMicrosoft-Bibliothek*. ## Schritt 6: Testen der VPN-Verbindung Um die korrekte Funktionsweise der VPN-Verbindung zu testen, starten Sie eine Instance in Ihrer VPC und stellen Sie sicher, dass diese über keine Internetverbindung verfügt. Senden Sie nach dem Starten der Instance von Ihrem Windows-Server aus einen Ping an die private IP-Adresse der Instance. Der VPN-Tunnel wird aufgebaut, wenn Datenverkehr vom Kunden-Gateway-Gerät generiert wird. Daher initiiert der Ping-Befehl auch die VPN-Verbindung. Schritte zum Testen der VPN-Verbindung finden Sie unter [Eine AWS Site-to-Site VPN Verbindung testen](HowToTestEndToEnd_Linux.md). Wenn der Befehl `ping` fehlschlägt, gehen Sie wie folgt vor: + Stellen Sie sicher, dass die Sicherheitsgruppenregeln so konfiguriert sind, dass ICMP-Datenverkehr zur Instance in Ihrer VPC zulässig ist. Wenn es sich bei Ihrem Windows Server um eine EC2-Instance handelt, stellen Sie sicher, dass die Regeln der Sicherheitsgruppe für ausgehenden Datenverkehr zulassen IPsec . Weitere Informationen finden Sie unter [Konfigurieren der Windows-Instance](#cgw-device-windows-server-configure-instance). + Stellen Sie sicher, dass das Betriebssystem der Instance, an die Sie den Ping senden, so konfiguriert ist, dass eine Antwort auf ICMP-Datenverkehr gesendet wird. Wir empfehlen Ihnen, eines der Amazon Linux-Betriebssysteme zu verwenden AMIs. + Wenn es sich bei der Instance, die Sie pingen, um eine Windows-Instance handelt, stellen Sie eine Verbindung zu der Instance her und aktivieren Sie Inbound ICMPv4 auf der Windows-Firewall. + Stellen Sie sicher, dass die Routing-Tabellen für Ihre VPC oder Ihr Subnetz korrekt konfiguriert sind. Weitere Informationen finden Sie unter [Schritt 1: Erstellen einer VPN-Verbindung und Konfigurieren Ihrer VPC](#cgw-device-windows-server-vpn). + Wenn es sich bei Ihrem Kunden-Gateway-Gerät um eine EC2-Instance handelt, stellen Sie sicher, dass Sie die Suche nach der Instance source/destination deaktiviert haben. Weitere Informationen finden Sie unter [Konfigurieren der Windows-Instance](#cgw-device-windows-server-configure-instance). Wählen Sie in der Amazon-VPC-Konsole auf der Seite **VPN Connections** die VPN-Verbindung aus. Der erste Tunnel hat den Zustand UP. Der zweite Tunnel muss konfiguriert sein, wird jedoch nur dann aktiv, wenn der erste Tunnel ausfällt. Es kann einige Momente dauern, die verschlüsselten Tunnel zu aktivieren. # Fehlerbehebung AWS Site-to-Site VPN beim Kunden-Gateway-Gerät Bei der Behebung von Problemen mit Ihrem Kunden-Gateway-Gerät ist ein strukturierter Ansatz wichtig. Die ersten beiden Themen in diesem Abschnitt enthalten allgemeine Flussdiagramme zur Behebung von Problemen, wenn ein für dynamisches Routing konfiguriertes Gerät (BGP aktiviert) bzw. ein für statisches Routing konfiguriertes Gerät (ohne BGP aktiviert) verwendet wird. Im Anschluss an diese Themen finden Sie gerätespezifische Anleitungen zur Fehlerbehebung für Kunden-Gateway-Geräte von Cisco, Juniper und Yamaha. Zusätzlich zu den Themen in diesem Abschnitt [AWS Site-to-Site VPN Logs](monitoring-logs.md) kann die Aktivierung bei der Fehlerbehebung und Behebung von VPN-Verbindungsproblemen sehr hilfreich sein. Allgemeine Testanweisungen finden Sie auch unter[Eine AWS Site-to-Site VPN Verbindung testen](HowToTestEndToEnd_Linux.md). **Topics** + [Gerät mit BGP](Generic_Troubleshooting.md) + [Gerät ohne BGP](Generic_Troubleshooting_noBGP.md) + [Cisco ASA](Cisco_ASA_Troubleshooting.md) + [Cisco IOS](Cisco_Troubleshooting.md) + [Cisco IOS ohne BGP](Cisco_Troubleshooting_NoBGP.md) + [Juniper JunOS](Juniper_Troubleshooting.md) + [Juniper ScreenOS](Juniper_ScreenOs_Troubleshooting.md) + [Yamaha](Yamaha_Troubleshooting.md) **Weitere Ressourcen** + [Amazon VPC-Forum](https://repost.aws/tags/TATGuEiYydTVCPMhSnXFN6gA/amazon-vpc) # Beheben Sie AWS Site-to-Site VPN Verbindungsprobleme bei der Verwendung des Border Gateway Protocol Die nachfolgende Abbildung und Tabelle enthalten allgemeine Anweisungen zur Fehlersuche bei Kunden-Gateway-Geräten ohne Border Gateway Protocol (BGP). Wir empfehlen Ihnen auch, die Debug-Funktionen Ihres Geräts zu aktivieren. Weitere Informationen erhalten Sie vom Anbieter Ihres Gateway-Geräts. ![\[Flussdiagramm zur Fehlerbehebung bei einem herkömmlichen Kunden-Gateway-Gerät\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-diagram.png) | | | | --- |--- | | IKE | Überprüfen Sie, ob eine IKE Sicherheitsaushandlung vorhanden ist. Für den Austausch von Schlüsseln, die zur Einrichtung der Sicherheitsverbindung verwendet werden, ist eine IPsec IKE-Sicherheitsverbindung erforderlich. Wenn keine IKE Security Association vorhanden ist, überprüfen Sie Ihre IKE-Konfigurationseinstellungen. Sie müssen die Verschlüsselung, Authentifizierung, Perfect Forward Secrecy und Modusparameter entsprechend der Konfigurationsdatei konfigurieren. Wenn eine IKE-Sicherheitsverbindung vorhanden ist, fahren Sie mit 'IPsec' fort. | | IPsec | Ermitteln Sie, ob eine IPsec Sicherheitsverbindung (SA) vorhanden ist. Eine IPsec SA ist der Tunnel selbst. Fragen Sie Ihr Kunden-Gateway-Gerät ab, um festzustellen, ob eine IPsec SA aktiv ist. Stellen Sie sicher, dass Sie die in der Konfigurationsdatei aufgeführten Parameter für Verschlüsselung, Authentifizierung, Perfect Forward Secrecy und Modus konfigurieren. Wenn keine IPsec SA vorhanden ist, überprüfen Sie Ihre IPsec Konfiguration. Wenn eine IPsec SA vorhanden ist, fahren Sie mit „Tunnel“ fort. | | Tunnel | Stellen Sie sicher, dass die erforderlichen Firewall-Regeln eingerichtet sind. Eine Liste der Regeln finden Sie unter [Firewall-Regeln für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](FirewallRules.md). Wenn die Regeln korrekt eingerichtet sind, fahren Sie fort. Stellen Sie fest, ob eine IP-Konnektivität durch den Tunnel besteht. Jede Seite des Tunnels hat eine IP-Adresse, wie in der Konfigurationsdatei angegeben. Die IP-Adresse des Virtual Private Gateways ist die Adresse des BGP-Nachbarn. Senden Sie von Ihrem Kunden-Gateway-Gerät aus einen Ping an diese Adresse, um zu überprüfen, ob IP-Datenverkehr korrekt verschlüsselt und entschlüsselt wird. Sollte dies fehlschlagen, überprüfen Sie die Konfiguration der Tunnelschnittstelle, um sicherzustellen, dass die korrekte IP-Adresse konfiguriert ist. Wenn der Ping erfolgreich war, fahren Sie mit "BGP" fort. | | BGP | Bestimmen Sie, ob die BGP-Peering-Sitzung aktiv ist. Gehen Sie für jeden Tunnel wie folgt vor: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/Generic_Troubleshooting.html) Wenn die Tunnel einen anderen Zustand aufweisen, überprüfen Sie die BGP-Konfiguration. Wenn BGP Peering korrekt eingerichtet wurde, Sie ein Präfix empfangen und auch eines senden, ist der Tunnel korrekt konfiguriert. Stellen Sie sicher, dass beide Tunnel diesen Zustand aufweisen. | # Beheben Sie AWS Site-to-Site VPN Verbindungsprobleme ohne Border Gateway Protocol Die nachfolgende Abbildung und Tabelle enthalten allgemeine Anweisungen zur Fehlersuche bei Kunden-Gateway-Geräten ohne Border Gateway Protocol (BGP). Wir empfehlen Ihnen auch, die Debug-Funktionen Ihres Geräts zu aktivieren. Weitere Informationen erhalten Sie vom Anbieter Ihres Gateway-Geräts. ![\[Flussdiagramm für die Fehlersuche bei generischen Kunden-Gateway-Geräten\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-nobgp-diagram.png) | | | | --- |--- | | IKE | Überprüfen Sie, ob eine IKE Sicherheitsaushandlung vorhanden ist. Für den Austausch von Schlüsseln, die zur Einrichtung der Sicherheitsverbindung verwendet werden, ist eine IPsec IKE-Sicherheitsverbindung erforderlich. Wenn keine IKE Security Association vorhanden ist, überprüfen Sie Ihre IKE-Konfigurationseinstellungen. Sie müssen die Verschlüsselung, Authentifizierung, Perfect Forward Secrecy und Modusparameter entsprechend der Konfigurationsdatei konfigurieren. Wenn eine IKE-Sicherheitsverbindung vorhanden ist, fahren Sie mit 'IPsec' fort. | | IPsec | Ermitteln Sie, ob eine IPsec Sicherheitsverbindung (SA) vorhanden ist. Eine IPsec SA ist der Tunnel selbst. Fragen Sie Ihr Kunden-Gateway-Gerät ab, um festzustellen, ob eine IPsec SA aktiv ist. Stellen Sie sicher, dass Sie die in der Konfigurationsdatei aufgeführten Parameter für Verschlüsselung, Authentifizierung, Perfect Forward Secrecy und Modus konfigurieren. Wenn keine IPsec SA vorhanden ist, überprüfen Sie Ihre IPsec Konfiguration. Wenn eine IPsec SA vorhanden ist, fahren Sie mit „Tunnel“ fort. | | Tunnel | Stellen Sie sicher, dass die erforderlichen Firewall-Regeln eingerichtet sind. Eine Liste der Regeln finden Sie unter [Firewall-Regeln für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](FirewallRules.md). Wenn die Regeln korrekt eingerichtet sind, fahren Sie fort. Stellen Sie fest, ob eine IP-Konnektivität durch den Tunnel besteht. Jede Seite des Tunnels hat eine IP-Adresse, wie in der Konfigurationsdatei angegeben. Die IP-Adresse des Virtual Private Gateways ist die Adresse des BGP-Nachbarn. Senden Sie von Ihrem Kunden-Gateway-Gerät aus einen Ping an diese Adresse, um zu überprüfen, ob IP-Datenverkehr korrekt verschlüsselt und entschlüsselt wird. Sollte dies fehlschlagen, überprüfen Sie die Konfiguration der Tunnelschnittstelle, um sicherzustellen, dass die korrekte IP-Adresse konfiguriert ist. Wenn der Ping erfolgreich ist, fahren Sie mit "Statische Routen" fort. | | Statische Routen | Gehen Sie für jeden Tunnel wie folgt vor: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/Generic_Troubleshooting_noBGP.html) Wenn die Tunnel einen anderen Zustand aufweisen, überprüfen Sie die Gerätekonfiguration. Stellen Sie sicher, dass beide Tunnel diesen Zustand aufweisen. | # Beheben Sie die AWS Site-to-Site VPN Konnektivität mit einem Cisco ASA-Kunden-Gateway-Gerät Wenn Sie Probleme mit der Konnektivität eines Cisco Kunden-Gateway-Geräts beheben, sollten Sie IKE IPsec, und Routing in Betracht ziehen. Sie können zwar in beliebiger Reihenfolge nach Fehlern in diesen drei Bereichen suchen, wir empfehlen jedoch, mit IKE (am Ende des Netzwerk-Stacks) zu beginnen und sich hochzuarbeiten. **Wichtig** Einige Cisco unterstützen ASAs nur Active/Standby den Modus. Wenn Sie diese Cisco verwenden ASAs, können Sie jeweils nur einen aktiven Tunnel haben. Der andere Standby-Tunnel wird nur dann aktiv, wenn der erste Tunnel nicht verfügbar ist. Der Standby-Tunnel kann in Protokolldateien folgende Fehlermeldung verursachen: `Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside`. Diese können Sie ignorieren. ## IKE Verwenden Sie den folgenden -Befehl. Die Antwort zeigt ein Kunden-Gateway-Gerät mit korrekt konfiguriertem IKE. ``` ciscoasa# show crypto isakmp sa ``` ``` Active SA: 2 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 2 1 IKE Peer: AWS_ENDPOINT_1 Type : L2L Role : initiator Rekey : no State : MM_ACTIVE ``` Es sollte mindestens eine Zeile mit einem `src`-Wert für das in den Tunneln angegebene Remote-Gateway angezeigt werden. Der `state`-Wert sollte `MM_ACTIVE` und `status` sollte `ACTIVE` lauten. Wenn kein Eintrag vorhanden ist oder ein anderer Zustand angezeigt wird, ist IKE nicht korrekt konfiguriert. Wenn Sie weitere Informationen zur Fehlersuche benötigen, führen Sie die folgenden Befehle aus, um Protokollmeldungen mit Diagnoseinformationen zu aktivieren. ``` router# term mon router# debug crypto isakmp ``` Wenn Sie Debugging deaktivieren möchten, führen Sie den folgenden Befehl aus. ``` router# no debug crypto isakmp ``` ## IPsec Verwenden Sie den folgenden -Befehl. In der Antwort wird ein Kunden-Gateway-Gerät angezeigt, das korrekt IPsec konfiguriert ist. ``` ciscoasa# show crypto ipsec sa ``` ``` interface: outside Crypto map tag: VPN_crypto_map_name, seq num: 2, local addr: 172.25.50.101 access-list integ-ppe-loopback extended permit ip any vpc_subnet subnet_mask local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) remote ident (addr/mask/prot/port): (vpc_subnet/subnet_mask/0/0) current_peer: integ-ppe1 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 172.25.50.101, remote crypto endpt.: AWS_ENDPOINT_1 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: 6D9F8D3B current inbound spi : 48B456A6 inbound esp sas: spi: 0x48B456A6 (1219778214) transform: esp-aes esp-sha-hmac no compression in use settings ={L2L, Tunnel, PFS Group 2, } slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1 sa timing: remaining key lifetime (kB/sec): (4374000/3593) IV size: 16 bytes replay detection support: Y Anti replay bitmap: 0x00000000 0x00000001 outbound esp sas: spi: 0x6D9F8D3B (1839172923) transform: esp-aes esp-sha-hmac no compression in use settings ={L2L, Tunnel, PFS Group 2, } slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1 sa timing: remaining key lifetime (kB/sec): (4374000/3593) IV size: 16 bytes replay detection support: Y Anti replay bitmap: 0x00000000 0x00000001 ``` Sie sollten für jede Tunnelschnittstelle sowohl `inbound esp sas` als auch `outbound esp sas` sehen. Dabei wird vorausgesetzt, dass eine SA aufgeführt ist (z. B.`spi: 0x48B456A6`) und dass diese korrekt konfiguriert IPsec ist. In Cisco ASA wird der IPsec erst angezeigt, nachdem interessanter Datenverkehr (Datenverkehr, der verschlüsselt werden sollte) gesendet wurde. Um stets IPsec aktiv zu bleiben, empfehlen wir die Konfiguration eines SLA-Monitors. Der SLA-Monitor sendet weiterhin interessanten Datenverkehr, wobei der IPsec Benutzer aktiv bleibt. Sie können auch den folgenden Ping-Befehl verwenden, um Sie zu zwingen, mit der Verhandlung IPsec zu beginnen und dann nach oben zu gehen. ``` ping ec2_instance_ip_address ``` ``` Pinging ec2_instance_ip_address with 32 bytes of data: Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128 Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128 Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128 Ping statistics for 10.0.0.4: Packets: Sent = 3, Received = 3, Lost = 0 (0% loss), Approximate round trip times in milliseconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms ``` Aktivieren Sie zur weiteren Problembehebung mit dem folgenden Befehl Debugging. ``` router# debug crypto ipsec ``` Wenn Sie Debugging deaktivieren möchten, führen Sie den folgenden Befehl aus. ``` router# no debug crypto ipsec ``` ## Routing Senden Sie einen Ping ans andere Ende des Tunnels. Wenn das funktioniert, IPsec sollten Sie etabliert sein. Wenn das nicht funktioniert, überprüfen Sie Ihre Zugriffslisten und lesen Sie den vorherigen IPsec Abschnitt. Wenn Sie nicht in der Lage sind, Ihre Instances zu erreichen, überprüfen Sie die folgenden Informationen. 1. Stellen Sie sicher, dass die Zugriffsliste so konfiguriert ist, dass der Crypto-Map zugeordneter Datenverkehr zugelassen wird. Führen Sie dazu den folgenden Befehl aus. ``` ciscoasa# show run crypto ``` ``` crypto ipsec transform-set transform-amzn esp-aes esp-sha-hmac crypto map VPN_crypto_map_name 1 match address access-list-name crypto map VPN_crypto_map_name 1 set pfs crypto map VPN_crypto_map_name 1 set peer AWS_ENDPOINT_1 AWS_ENDPOINT_2 crypto map VPN_crypto_map_name 1 set transform-set transform-amzn crypto map VPN_crypto_map_name 1 set security-association lifetime seconds 3600 ``` 1. Überprüfen Sie die Zugriffsliste mit dem folgenden Befehl. ``` ciscoasa# show run access-list access-list-name ``` ``` access-list access-list-name extended permit ip any vpc_subnet subnet_mask ``` 1. Vergewissern Sie sich, dass die Zugriffsliste korrekt ist. Die folgende Beispielzugriffsliste erlaubt den gesamten internen Datenverkehr zum VPC-Subnetz 10.0.0.0/16. ``` access-list access-list-name extended permit ip any 10.0.0.0 255.255.0.0 ``` 1. Führen Sie eine Traceroute vom Cisco ASA-Gerät aus, um zu sehen, ob sie die Amazon-Router erreicht (z. B.*AWS\$1ENDPOINT\$11*/). *AWS\$1ENDPOINT\$12* Ist dies der Fall, überprüfen Sie nun die statischen Routen, die Sie in der Amazon VPC-Konsole hinzugefügt haben, sowie die Sicherheitsgruppen der betroffenen Instances. 1. Fahren Sie mit der Fehlersuche in der Konfiguration fort. ## Lassen Sie die Tunnelschnittstelle abprallen Wenn der Tunnel in Betrieb zu sein scheint, der Verkehr aber nicht richtig fließt, können Verbindungsprobleme häufig durch Bouncing (Deaktivierung und erneutes Aktivieren) der Tunnelschnittstelle behoben werden. So schalten Sie die Tunnelschnittstelle auf einer Cisco ASA ab: 1. Führen Sie Folgendes aus: ``` ciscoasa# conf t ciscoasa(config)# interface tunnel X (where X is your tunnel ID) ciscoasa(config-if)# shutdown ciscoasa(config-if)# no shutdown ciscoasa(config-if)# end ``` Alternativ können Sie einen einzeiligen Befehl verwenden: ``` ciscoasa# conf t ; interface tunnel X ; shutdown ; no shutdown ; end ``` 1. Überprüfen Sie nach dem Abrufen der Schnittstelle, ob die VPN-Verbindung wieder hergestellt wurde und ob der Datenverkehr jetzt korrekt fließt. # Beheben Sie die AWS Site-to-Site VPN Konnektivität mit einem Cisco IOS-Kunden-Gateway-Gerät Wenn Sie Probleme mit der Konnektivität eines Cisco Kunden-Gateway-Geräts beheben, sollten Sie vier Dinge berücksichtigen: IKE IPsec, Tunnel und BGP. Sie können zwar in beliebiger Reihenfolge nach Fehlern in diesen drei Bereichen suchen, wir empfehlen jedoch, mit IKE (am Ende des Netzwerk-Stacks) zu beginnen und sich hochzuarbeiten. ## IKE Verwenden Sie den folgenden -Befehl. Die Antwort zeigt ein Kunden-Gateway-Gerät mit korrekt konfiguriertem IKE. ``` router# show crypto isakmp sa ``` ``` IPv4 Crypto ISAKMP SA dst src state conn-id slot status 192.168.37.160 72.21.209.193 QM_IDLE 2001 0 ACTIVE 192.168.37.160 72.21.209.225 QM_IDLE 2002 0 ACTIVE ``` Es sollte mindestens eine Zeile mit einem `src`-Wert für das in den Tunneln angegebene Remote-Gateway angezeigt werden. Der `state` sollte `QM_IDLE` und der `status` sollte `ACTIVE` lauten. Wenn kein Eintrag vorhanden ist oder ein anderer Zustand angezeigt wird, ist IKE nicht korrekt konfiguriert. Wenn Sie weitere Informationen zur Fehlersuche benötigen, führen Sie die folgenden Befehle aus, um Protokollmeldungen mit Diagnoseinformationen zu aktivieren. ``` router# term mon router# debug crypto isakmp ``` Wenn Sie Debugging deaktivieren möchten, führen Sie den folgenden Befehl aus. ``` router# no debug crypto isakmp ``` ## IPsec Verwenden Sie den folgenden -Befehl. In der Antwort wird ein Kunden-Gateway-Gerät angezeigt, das korrekt IPsec konfiguriert ist. ``` router# show crypto ipsec sa ``` ``` interface: Tunnel1 Crypto map tag: Tunnel1-head-0, local addr 192.168.37.160 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer 72.21.209.225 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149 #pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.225 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0 current outbound spi: 0xB8357C22(3090512930) inbound esp sas: spi: 0x6ADB173(112046451) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0 sa timing: remaining key lifetime (k/sec): (4467148/3189) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xB8357C22(3090512930) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0 sa timing: remaining key lifetime (k/sec): (4467148/3189) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE outbound ah sas: outbound pcp sas: interface: Tunnel2 Crypto map tag: Tunnel2-head-0, local addr 174.78.144.73 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer 72.21.209.193 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26 #pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.193 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0 current outbound spi: 0xF59A3FF6(4120526838) inbound esp sas: spi: 0xB6720137(3060924727) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0 sa timing: remaining key lifetime (k/sec): (4387273/3492) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xF59A3FF6(4120526838) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0 sa timing: remaining key lifetime (k/sec): (4387273/3492) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE outbound ah sas: outbound pcp sas: ``` Sie sollten für jede Tunnelschnittstelle sowohl `inbound esp sas` als auch `outbound esp sas` sehen. Angenommen`spi: 0xF95D2F3C`, eine SA ist aufgeführt (zum Beispiel) und `ACTIVE` diese `Status` IPsec ist korrekt konfiguriert. Aktivieren Sie zur weiteren Problembehebung mit dem folgenden Befehl Debugging. ``` router# debug crypto ipsec ``` Wenn Sie Debugging deaktivieren möchten, führen Sie den folgenden Befehl aus. ``` router# no debug crypto ipsec ``` ## Tunnel Überprüfen Sie zunächst, ob die benötigten Firewall-Regeln konfiguriert sind. Weitere Informationen finden Sie unter [Firewall-Regeln für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](FirewallRules.md). Wenn die Firewall-Regeln korrekt eingerichtet sind, können Sie mithilfe des folgenden Befehls mit der Fehlersuche fortfahren. ``` router# show interfaces tun1 ``` ``` Tunnel1 is up, line protocol is up Hardware is Tunnel Internet address is 169.254.255.2/30 MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 2/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 174.78.144.73, destination 72.21.209.225 Tunnel protocol/transport IPSEC/IP Tunnel TTL 255 Tunnel transport MTU 1427 bytes Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps) Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0") Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 1000 bits/sec, 1 packets/sec 407 packets input, 30010 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles ``` Stellen Sie sicher, dass das `line protocol` eingerichtet ist. Überprüfen Sie, ob die Quell-IP-Adresse, die Quellschnittstelle und der Zielbereich des Tunnels mit der Tunnelkonfiguration für die externe IP-Adresse des Kunden-Gateway-Geräts, die Schnittstelle und die externe IP-Adresse des Virtual Private Gateways übereinstimmen. Stellen Sie sicher, dass `Tunnel protection via IPSec` aktiviert ist. Führen Sie den Befehl für beiden Tunnelschnittstellen aus. Um etwaige Probleme zu beheben, prüfen Sie die Konfiguration sowie die physischen Verbindungen zum Kunden-Gateway-Gerät. Führen Sie auch den folgenden Befehl aus und ersetzen Sie dabei `169.254.255.1` durch die interne IP-Adresse des Virtual Private Gateways. ``` router# ping 169.254.255.1 df-bit size 1410 ``` ``` Type escape sequence to abort. Sending 5, 1410-byte ICMP Echos to 169.254.255.1, timeout is 2 seconds: Packet sent with the DF bit set !!!!! ``` Es sollten fünf Ausrufezeichen angezeigt werden. Fahren Sie mit der Fehlersuche in der Konfiguration fort. ## BGP Verwenden Sie den folgenden -Befehl. ``` router# show ip bgp summary ``` ``` BGP router identifier 192.168.37.160, local AS number 65000 BGP table version is 8, main routing table version 8 2 network entries using 312 bytes of memory 2 path entries using 136 bytes of memory 3/1 BGP path/bestpath attribute entries using 444 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory BGP using 948 total bytes of memory BGP activity 4/1 prefixes, 4/1 paths, scan interval 15 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 169.254.255.1 4 7224 363 323 8 0 0 00:54:21 1 169.254.255.5 4 7224 364 323 8 0 0 00:00:24 1 ``` Hier sollten beide Nachbarn aufgeführt sein. Für jeden davon sollte der `State/PfxRcd`-Wert `1` betragen. Wenn BGP-Peering aktiviert ist, überprüfen Sie, ob Ihr Kunden-Gateway-Gerät die Standardroute (0.0.0.0/0) an die VPC sendet. ``` router# show bgp all neighbors 169.254.255.1 advertised-routes ``` ``` For address family: IPv4 Unicast BGP table version is 3, local router ID is 174.78.144.73 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path *> 10.120.0.0/16 169.254.255.1 100 0 7224 i Total number of prefixes 1 ``` Stellen Sie außerdem sicher, dass Sie das Präfix Ihrer VPC vom Virtual Private Gateway empfangen. ``` router# show ip route bgp ``` ``` 10.0.0.0/16 is subnetted, 1 subnets B 10.255.0.0 [20/0] via 169.254.255.1, 00:00:20 ``` Fahren Sie mit der Fehlersuche in der Konfiguration fort. # Beheben Sie die AWS Site-to-Site VPN Konnektivität mit einem Cisco IOS-Kunden-Gateway-Gerät ohne Border Gateway Protocol Wenn Sie Probleme mit der Konnektivität eines Cisco Kunden-Gateway-Geräts beheben, sollten Sie drei Dinge berücksichtigen: IKE und Tunnel. IPsec Sie können zwar in beliebiger Reihenfolge nach Fehlern in diesen drei Bereichen suchen, wir empfehlen jedoch, mit IKE (am Ende des Netzwerk-Stacks) zu beginnen und sich hochzuarbeiten. ## IKE Verwenden Sie den folgenden -Befehl. Die Antwort zeigt ein Kunden-Gateway-Gerät mit korrekt konfiguriertem IKE. ``` router# show crypto isakmp sa ``` ``` IPv4 Crypto ISAKMP SA dst src state conn-id slot status 174.78.144.73 205.251.233.121 QM_IDLE 2001 0 ACTIVE 174.78.144.73 205.251.233.122 QM_IDLE 2002 0 ACTIVE ``` Es sollte mindestens eine Zeile mit einem `src`-Wert für das in den Tunneln angegebene Remote-Gateway angezeigt werden. Der `state` sollte `QM_IDLE` und der `status` sollte `ACTIVE` lauten. Wenn kein Eintrag vorhanden ist oder ein anderer Zustand angezeigt wird, ist IKE nicht korrekt konfiguriert. Wenn Sie weitere Informationen zur Fehlersuche benötigen, führen Sie die folgenden Befehle aus, um Protokollmeldungen mit Diagnoseinformationen zu aktivieren. ``` router# term mon router# debug crypto isakmp ``` Wenn Sie Debugging deaktivieren möchten, führen Sie den folgenden Befehl aus. ``` router# no debug crypto isakmp ``` ## IPsec Verwenden Sie den folgenden -Befehl. Die Antwort zeigt, dass ein Kunden-Gateway-Gerät korrekt IPsec konfiguriert ist. ``` router# show crypto ipsec sa ``` ``` interface: Tunnel1 Crypto map tag: Tunnel1-head-0, local addr 174.78.144.73 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer 72.21.209.225 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149 #pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.121 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0 current outbound spi: 0xB8357C22(3090512930) inbound esp sas: spi: 0x6ADB173(112046451) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0 sa timing: remaining key lifetime (k/sec): (4467148/3189) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xB8357C22(3090512930) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0 sa timing: remaining key lifetime (k/sec): (4467148/3189) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE outbound ah sas: outbound pcp sas: interface: Tunnel2 Crypto map tag: Tunnel2-head-0, local addr 205.251.233.122 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer 72.21.209.193 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26 #pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.122 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0 current outbound spi: 0xF59A3FF6(4120526838) inbound esp sas: spi: 0xB6720137(3060924727) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0 sa timing: remaining key lifetime (k/sec): (4387273/3492) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xF59A3FF6(4120526838) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0 sa timing: remaining key lifetime (k/sec): (4387273/3492) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE outbound ah sas: outbound pcp sas: ``` Sie sollten für jede Tunnelschnittstelle sowohl eine eingehende `esp sas` als auch eine ausgehende `esp sas` sehen. Dabei wird vorausgesetzt, dass eine SA aufgeführt ist (z. B.`spi: 0x48B456A6`), dass der Status lautet `ACTIVE` und dass diese korrekt konfiguriert IPsec ist. Aktivieren Sie zur weiteren Problembehebung mit dem folgenden Befehl Debugging. ``` router# debug crypto ipsec ``` Wenn Sie Debugging deaktivieren möchten, führen Sie den folgenden Befehl aus. ``` router# no debug crypto ipsec ``` ## Tunnel Überprüfen Sie zunächst, ob die benötigten Firewall-Regeln konfiguriert sind. Weitere Informationen finden Sie unter [Firewall-Regeln für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](FirewallRules.md). Wenn die Firewall-Regeln korrekt eingerichtet sind, können Sie mithilfe des folgenden Befehls mit der Fehlersuche fortfahren. ``` router# show interfaces tun1 ``` ``` Tunnel1 is up, line protocol is up Hardware is Tunnel Internet address is 169.254.249.18/30 MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 2/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 174.78.144.73, destination 205.251.233.121 Tunnel protocol/transport IPSEC/IP Tunnel TTL 255 Tunnel transport MTU 1427 bytes Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps) Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0") Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 1000 bits/sec, 1 packets/sec 407 packets input, 30010 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles ``` Stellen Sie sicher, dass das Leitungsprotokoll eingerichtet ist. Überprüfen Sie, ob die Quell-IP-Adresse, die Quellschnittstelle und der Zielbereich des Tunnels mit der Tunnelkonfiguration für die externe IP-Adresse des Kunden-Gateway-Geräts, die Schnittstelle und die externe IP-Adresse des Virtual Private Gateways übereinstimmen. Stellen Sie sicher, dass `Tunnel protection through IPSec` aktiviert ist. Führen Sie den Befehl für beiden Tunnelschnittstellen aus. Um etwaige Probleme zu beheben, prüfen Sie die Konfiguration sowie die physischen Verbindungen zum Kunden-Gateway-Gerät. Sie können auch den folgenden Befehl ausführen; ersetzen Sie dabei `169.254.249.18` durch die interne IP-Adresse des Virtual Private Gateways. ``` router# ping 169.254.249.18 df-bit size 1410 ``` ``` Type escape sequence to abort. Sending 5, 1410-byte ICMP Echos to 169.254.249.18, timeout is 2 seconds: Packet sent with the DF bit set !!!!! ``` Es sollten fünf Ausrufezeichen angezeigt werden. ### Routing Führen Sie den folgenden Befehl aus, um die statische Routing-Tabelle anzuzeigen. ``` router# sh ip route static ``` ``` 1.0.0.0/8 is variably subnetted S 10.0.0.0/16 is directly connected, Tunnel1 is directly connected, Tunnel2 ``` Die statische Route sollte für VPC CIDR durch beide Tunnel vorhanden sein. Wenn sie nicht vorhanden ist, fügen Sie die statischen Routen wie folgt hinzu. ``` router# ip route 10.0.0.0 255.255.0.0 Tunnel1 track 100 router# ip route 10.0.0.0 255.255.0.0 Tunnel2 track 200 ``` ### Überprüfen der SLA-Überwachung ``` router# show ip sla statistics 100 ``` ``` IPSLAs Latest Operation Statistics IPSLA operation id: 100 Latest RTT: 128 milliseconds Latest operation start time: *18:08:02.155 UTC Wed Jul 15 2012 Latest operation return code: OK Number of successes: 3 Number of failures: 0 Operation time to live: Forever ``` ``` router# show ip sla statistics 200 ``` ``` IPSLAs Latest Operation Statistics IPSLA operation id: 200 Latest RTT: 128 milliseconds Latest operation start time: *18:08:02.155 UTC Wed Jul 15 2012 Latest operation return code: OK Number of successes: 3 Number of failures: 0 Operation time to live: Forever ``` Der Wert für `Number of successes` gibt an, ob der SLA-Monitor erfolgreich eingerichtet wurde. Fahren Sie mit der Fehlersuche in der Konfiguration fort. # Fehlerbehebung bei der AWS Site-to-Site VPN Konnektivität mit einem Juniper JunOS-Kunden-Gateway-Gerät Wenn Sie Probleme mit der Konnektivität eines Kunden-Gateway-Geräts von Juniper beheben, sollten Sie vier Dinge berücksichtigen: IKE IPsec, Tunnel und BGP. Sie können zwar in beliebiger Reihenfolge nach Fehlern in diesen drei Bereichen suchen, wir empfehlen jedoch, mit IKE (am Ende des Netzwerk-Stacks) zu beginnen und sich hochzuarbeiten. ## IKE Verwenden Sie den folgenden -Befehl. Die Antwort zeigt ein Kunden-Gateway-Gerät mit korrekt konfiguriertem IKE. ``` user@router> show security ike security-associations ``` ``` Index Remote Address State Initiator cookie Responder cookie Mode 4 72.21.209.225 UP c4cd953602568b74 0d6d194993328b02 Main 3 72.21.209.193 UP b8c8fb7dc68d9173 ca7cb0abaedeb4bb Main ``` Es sollte mindestens eine Zeile mit einer Remote-Adresse des in den Tunneln angegebenen Remote-Gateways angezeigt werden. Der `State` sollte `UP` sein. Wenn kein Eintrag vorhanden ist oder ein anderer Zustand (z. B. `DOWN`) angezeigt wird, ist IKE nicht korrekt konfiguriert. Wenn Sie weitere Informationen zur Fehlersuche benötigen, aktivieren Sie die IKE-Trace-Optionen (wie in den Beispielkonfigurationsinformationen empfohlen). Führen Sie dann den folgenden Befehl aus, um verschiedene Debugging-Meldungen auf dem Bildschirm auszugeben. ``` user@router> monitor start kmd ``` Mit dem folgenden Befehl können Sie die gesamte Protokolldatei von einem externen Host abrufen. ``` scp username@router.hostname:/var/log/kmd ``` ## IPsec Verwenden Sie den folgenden -Befehl. In der Antwort wird ein Kunden-Gateway-Gerät angezeigt, das korrekt IPsec konfiguriert ist. ``` user@router> show security ipsec security-associations ``` ``` Total active tunnels: 2 ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys <131073 72.21.209.225 500 ESP:aes-128/sha1 df27aae4 326/ unlim - 0 >131073 72.21.209.225 500 ESP:aes-128/sha1 5de29aa1 326/ unlim - 0 <131074 72.21.209.193 500 ESP:aes-128/sha1 dd16c453 300/ unlim - 0 >131074 72.21.209.193 500 ESP:aes-128/sha1 c1e0eb29 300/ unlim - 0 ``` Sie sollten mindestens zwei Zeilen pro Gateway-Adresse (entsprechend dem Remote-Gateway) sehen. Beachten Sie die Einfügezeichen am Beginn jeder Zeile (< >), die die Richtung des Datenverkehrs für den jeweiligen Eintrag angeben. Für die Ausgabe gibt es eigene Zeilen für eingehenden Datenverkehr ("<", Datenverkehr vom Virtual Private Gateway zu diesem Kunden-Gateway) und ausgehenden Datenverkehr (">"). Wenn Sie weitere Informationen zur Fehlersuche benötigen, aktivieren Sie die IKE-Trace-Optionen (weitere Informationen finden Sie im vorherigen Abschnitt zu IKE). ## Tunnel Überprüfen Sie zunächst noch einmal, ob die benötigten Firewall-Regeln konfiguriert sind. Eine Liste der Regeln finden Sie unter [Firewall-Regeln für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](FirewallRules.md). Wenn die Firewall-Regeln korrekt eingerichtet sind, können Sie mithilfe des folgenden Befehls mit der Fehlersuche fortfahren. ``` user@router> show interfaces st0.1 ``` ``` Logical interface st0.1 (Index 70) (SNMP ifIndex 126) Flags: Point-To-Point SNMP-Traps Encapsulation: Secure-Tunnel Input packets : 8719 Output packets: 41841 Security: Zone: Trust Allowed host-inbound traffic : bgp ping ssh traceroute Protocol inet, MTU: 9192 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 169.254.255.0/30, Local: 169.254.255.2 ``` Stellen Sie sicher, dass `Security: Zone` korrekt konfiguriert ist und die Adresse `Local` mit der internen Adresse des Kunden-Gateway-Geräte-Tunnels übereinstimmt. Führen Sie nun den folgenden Befehl aus und ersetzen Sie dabei `169.254.255.1` durch die interne IP-Adresse des Virtual Private Gateways. Ihre Ergebnisse sollten etwa wie folgt aussehen. ``` user@router> ping 169.254.255.1 size 1382 do-not-fragment ``` ``` PING 169.254.255.1 (169.254.255.1): 1410 data bytes 64 bytes from 169.254.255.1: icmp_seq=0 ttl=64 time=71.080 ms 64 bytes from 169.254.255.1: icmp_seq=1 ttl=64 time=70.585 ms ``` Fahren Sie mit der Fehlersuche in der Konfiguration fort. ## BGP Führen Sie den folgenden Befehl aus. ``` user@router> show bgp summary ``` ``` Groups: 1 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 2 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 169.254.255.1 7224 9 10 0 0 1:00 1/1/1/0 0/0/0/0 169.254.255.5 7224 8 9 0 0 56 0/1/1/0 0/0/0/0 ``` Führen Sie zur weiteren Fehlersuche den folgenden Befehl aus; ersetzen Sie dabei `169.254.255.1` durch die interne IP-Adresse des Virtual Private Gateways. ``` user@router> show bgp neighbor 169.254.255.1 ``` ``` Peer: 169.254.255.1+179 AS 7224 Local: 169.254.255.2+57175 AS 65000 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ EXPORT-DEFAULT ] Options: Holdtime: 30 Preference: 170 Local AS: 65000 Local System AS: 0 Number of flaps: 0 Peer ID: 169.254.255.1 Local ID: 10.50.0.10 Active Holdtime: 30 Keepalive Interval: 10 Peer index: 0 BFD: disabled, down Local Interface: st0.1 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 7224) Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 1 Received prefixes: 1 Accepted prefixes: 1 Suppressed due to damping: 0 Advertised prefixes: 1 Last traffic (seconds): Received 4 Sent 8 Checked 4 Input messages: Total 24 Updates 2 Refreshes 0 Octets 505 Output messages: Total 26 Updates 1 Refreshes 0 Octets 582 Output Queue[0]: 0 ``` Hier sollten `Received prefixes` und `Advertised prefixes` beide mit "1" aufgelistet sein. Diese Werte befinden sich im Abschnitt `Table inet.0`. Wenn `State` nicht `Established` ist, finden Sie unter `Last State` und `Last Error` detaillierte Informationen zur Fehlerbehebung. Wenn BGP-Peering aktiviert ist, überprüfen Sie, ob Ihr Kunden-Gateway-Gerät die Standardroute (0.0.0.0/0) an die VPC sendet. ``` user@router> show route advertising-protocol bgp 169.254.255.1 ``` ``` inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 Self I ``` Stellen Sie außerdem sicher, dass Sie das Präfix Ihrer VPC vom Virtual Private Gateway empfangen. ``` user@router> show route receive-protocol bgp 169.254.255.1 ``` ``` inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.110.0.0/16 169.254.255.1 100 7224 I ``` # Fehlerbehebung bei der AWS Site-to-Site VPN Konnektivität mit einem Juniper ScreenOS-Kunden-Gateway-Gerät Wenn Sie Probleme mit der Konnektivität eines auf Juniper ScreenOS basierenden Kunden-Gateway-Geräts beheben, sollten Sie vier Dinge berücksichtigen: IKE IPsec, Tunnel und BGP. Sie können zwar in beliebiger Reihenfolge nach Fehlern in diesen drei Bereichen suchen, wir empfehlen jedoch, mit IKE (am Ende des Netzwerk-Stacks) zu beginnen und sich hochzuarbeiten. ## IKE und IPsec Verwenden Sie den folgenden -Befehl. Die Antwort zeigt ein Kunden-Gateway-Gerät mit korrekt konfiguriertem IKE. ``` ssg5-serial-> get sa ``` ``` total configured sa: 2 HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys 00000002< 72.21.209.225 500 esp:a128/sha1 80041ca4 3385 unlim A/- -1 0 00000002> 72.21.209.225 500 esp:a128/sha1 8cdd274a 3385 unlim A/- -1 0 00000001< 72.21.209.193 500 esp:a128/sha1 ecf0bec7 3580 unlim A/- -1 0 00000001> 72.21.209.193 500 esp:a128/sha1 14bf7894 3580 unlim A/- -1 0 ``` Es sollte mindestens eine Zeile mit einer Remote-Adresse des in den Tunneln angegebenen Remote-Gateways angezeigt werden. Der Wert `Sta` sollte `A/-` sein und unter `SPI` sollte eine andere hexadezimale Zahl als `00000000` angezeigt werden. Wenn die Einträge davon abweichen, ist IKE nicht korrekt konfiguriert. Wenn Sie weitere Informationen zur Fehlersuche benötigen, aktivieren Sie die IKE-Trace-Optionen (wie in den Beispielkonfigurationsinformationen empfohlen). ## Tunnel Überprüfen Sie zunächst noch einmal, ob die benötigten Firewall-Regeln konfiguriert sind. Eine Liste der Regeln finden Sie unter [Firewall-Regeln für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](FirewallRules.md). Wenn die Firewall-Regeln korrekt eingerichtet sind, können Sie mithilfe des folgenden Befehls mit der Fehlersuche fortfahren. ``` ssg5-serial-> get interface tunnel.1 ``` ``` Interface tunnel.1: description tunnel.1 number 20, if_info 1768, if_index 1, mode route link ready vsys Root, zone Trust, vr trust-vr admin mtu 1500, operating mtu 1500, default mtu 1500 *ip 169.254.255.2/30 *manage ip 169.254.255.2 route-deny disable bound vpn: IPSEC-1 Next-Hop Tunnel Binding table Flag Status Next-Hop(IP) tunnel-id VPN pmtu-v4 disabled ping disabled, telnet disabled, SSH disabled, SNMP disabled web disabled, ident-reset disabled, SSL disabled OSPF disabled BGP enabled RIP disabled RIPng disabled mtrace disabled PIM: not configured IGMP not configured NHRP disabled bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps] configured ingress mbw 0kbps, current bw 0kbps total allocated gbw 0kbps ``` Stellen Sie sicher, dass `link:ready` angezeigt wird und die `IP`-Adresse mit der internen Adresse des Kunden-Gateway-Geräte-Tunnels übereinstimmt. Führen Sie nun den folgenden Befehl aus und ersetzen Sie dabei `169.254.255.1` durch die interne IP-Adresse des Virtual Private Gateways. Ihre Ergebnisse sollten etwa wie folgt aussehen. ``` ssg5-serial-> ping 169.254.255.1 ``` ``` Type escape sequence to abort Sending 5, 100-byte ICMP Echos to 169.254.255.1, timeout is 1 seconds !!!!! Success Rate is 100 percent (5/5), round-trip time min/avg/max=32/32/33 ms ``` Fahren Sie mit der Fehlersuche in der Konfiguration fort. ## BGP Führen Sie den folgenden Befehl aus. ``` ssg5-serial-> get vrouter trust-vr protocol bgp neighbor ``` ``` Peer AS Remote IP Local IP Wt Status State ConnID Up/Down -------------------------------------------------------------------------------- 7224 169.254.255.1 169.254.255.2 100 Enabled ESTABLISH 10 00:01:01 7224 169.254.255.5 169.254.255.6 100 Enabled ESTABLISH 11 00:00:59 ``` Der Status der beiden BGP-Peers sollte `ESTABLISH` sein, was bedeutet, dass die BGP-Verbindung zum Virtual Private Gateway aktiv ist. Führen Sie zur weiteren Fehlersuche den folgenden Befehl aus; ersetzen Sie dabei `169.254.255.1` durch die interne IP-Adresse des Virtual Private Gateways. ``` ssg5-serial-> get vr trust-vr prot bgp neigh 169.254.255.1 ``` ``` peer: 169.254.255.1, remote AS: 7224, admin status: enable type: EBGP, multihop: 0(disable), MED: node default(0) connection state: ESTABLISH, connection id: 18 retry interval: node default(120s), cur retry time 15s configured hold time: node default(90s), configured keepalive: node default(30s) configured adv-interval: default(30s) designated local IP: n/a local IP address/port: 169.254.255.2/13946, remote IP address/port: 169.254.255.1/179 router ID of peer: 169.254.255.1, remote AS: 7224 negotiated hold time: 30s, negotiated keepalive interval: 10s route map in name: , route map out name: weight: 100 (default) self as next hop: disable send default route to peer: disable ignore default route from peer: disable send community path attribute: no reflector client: no Neighbor Capabilities: Route refresh: advertised and received Address family IPv4 Unicast: advertised and received force reconnect is disable total messages to peer: 106, from peer: 106 update messages to peer: 6, from peer: 4 Tx queue length 0, Tx queue HWM: 1 route-refresh messages to peer: 0, from peer: 0 last reset 00:05:33 ago, due to BGP send Notification(Hold Timer Expired)(code 4 : subcode 0) number of total successful connections: 4 connected: 2 minutes 6 seconds Elapsed time since last update: 2 minutes 6 seconds ``` Wenn BGP-Peering aktiviert ist, überprüfen Sie, ob Ihr Kunden-Gateway-Gerät die Standardroute (0.0.0.0/0) an die VPC sendet. Dieser Befehl ist ab ScreenOS 6.2.0 anwendbar. ``` ssg5-serial-> get vr trust-vr protocol bgp rib neighbor 169.254.255.1 advertised ``` ``` i: IBGP route, e: EBGP route, >: best route, *: valid route Prefix Nexthop Wt Pref Med Orig AS-Path -------------------------------------------------------------------------------------- >i 0.0.0.0/0 0.0.0.0 32768 100 0 IGP Total IPv4 routes advertised: 1 ``` Stellen Sie außerdem sicher, dass Sie das Präfix Ihrer VPC vom Virtual Private Gateway empfangen. Dieser Befehl ist ab ScreenOS 6.2.0 anwendbar. ``` ssg5-serial-> get vr trust-vr protocol bgp rib neighbor 169.254.255.1 received ``` ``` i: IBGP route, e: EBGP route, >: best route, *: valid route Prefix Nexthop Wt Pref Med Orig AS-Path -------------------------------------------------------------------------------------- >e* 10.0.0.0/16 169.254.255.1 100 100 100 IGP 7224 Total IPv4 routes received: 1 ``` # Beheben Sie Probleme mit der AWS Site-to-Site VPN Konnektivität mit einem Yamaha-Kunden-Gateway-Gerät Wenn Sie Probleme mit der Konnektivität eines Yamaha-Kunden-Gateway-Geräts beheben, sollten Sie vier Dinge berücksichtigen: IKE IPsec, Tunnel und BGP. Sie können zwar in beliebiger Reihenfolge nach Fehlern in diesen drei Bereichen suchen, wir empfehlen jedoch, mit IKE (am Ende des Netzwerk-Stacks) zu beginnen und sich hochzuarbeiten. **Anmerkung** Die Einstellung für `proxy ID`, die in Phase 2 von IKE verwendet wurde, ist im Yamaha-Router standardmäßig deaktiviert. Dies kann zu Problemen bei der Verbindung mit dem Site-to-Site VPN führen. Wenn der auf Ihrem Router nicht konfiguriert `proxy ID` ist, sehen Sie sich bitte die AWS mitgelieferte Beispielkonfigurationsdatei an, damit Yamaha sie richtig einstellt. ## IKE Führen Sie den folgenden Befehl aus. Die Antwort zeigt ein Kunden-Gateway-Gerät mit korrekt konfiguriertem IKE. ``` # show ipsec sa gateway 1 ``` ``` sgw flags local-id remote-id # of sa -------------------------------------------------------------------------- 1 U K YOUR_LOCAL_NETWORK_ADDRESS 72.21.209.225 i:2 s:1 r:1 ``` Es sollte eine Zeile mit dem Wert `remote-id` für die in den Tunneln angegebene Remote-Gateway angezeigt werden. Sie können alle Sicherheitszuordnungen (SAs) auflisten, indem Sie die Tunnelnummer weglassen. Wenn Sie weitere Informationen zur Fehlersuche benötigen, führen Sie die folgenden Befehle aus, um Protokollmeldungen auf DEBUG-Ebene mit Diagnoseinformationen zu aktivieren. ``` # syslog debug on # ipsec ike log message-info payload-info key-info ``` Um die protokollierten Elemente zu löschen, führen Sie den folgenden Befehl aus. ``` # no ipsec ike log # no syslog debug on ``` ## IPsec Führen Sie den folgenden Befehl aus. In der Antwort wird ein Kunden-Gateway-Gerät angezeigt, das korrekt IPsec konfiguriert ist. ``` # show ipsec sa gateway 1 detail ``` ``` SA[1] Duration: 10675s Local ID: YOUR_LOCAL_NETWORK_ADDRESS Remote ID: 72.21.209.225 Protocol: IKE Algorithm: AES-CBC, SHA-1, MODP 1024bit SPI: 6b ce fd 8a d5 30 9b 02 0c f3 87 52 4a 87 6e 77 Key: ** ** ** ** ** (confidential) ** ** ** ** ** ---------------------------------------------------- SA[2] Duration: 1719s Local ID: YOUR_LOCAL_NETWORK_ADDRESS Remote ID: 72.21.209.225 Direction: send Protocol: ESP (Mode: tunnel) Algorithm: AES-CBC (for Auth.: HMAC-SHA) SPI: a6 67 47 47 Key: ** ** ** ** ** (confidential) ** ** ** ** ** ---------------------------------------------------- SA[3] Duration: 1719s Local ID: YOUR_LOCAL_NETWORK_ADDRESS Remote ID: 72.21.209.225 Direction: receive Protocol: ESP (Mode: tunnel) Algorithm: AES-CBC (for Auth.: HMAC-SHA) SPI: 6b 98 69 2b Key: ** ** ** ** ** (confidential) ** ** ** ** ** ---------------------------------------------------- SA[4] Duration: 10681s Local ID: YOUR_LOCAL_NETWORK_ADDRESS Remote ID: 72.21.209.225 Protocol: IKE Algorithm: AES-CBC, SHA-1, MODP 1024bit SPI: e8 45 55 38 90 45 3f 67 a8 74 ca 71 ba bb 75 ee Key: ** ** ** ** ** (confidential) ** ** ** ** ** ---------------------------------------------------- ``` Sie sollten für jede Tunnelschnittstelle sowohl `receive sas` als auch `send sas` sehen. Aktivieren Sie zur weiteren Problembehebung mit dem folgenden Befehl Debugging. ``` # syslog debug on # ipsec ike log message-info payload-info key-info ``` Wenn Sie Debugging deaktivieren möchten, führen Sie den folgenden Befehl aus. ``` # no ipsec ike log # no syslog debug on ``` ## Tunnel Überprüfen Sie zunächst, ob die benötigten Firewall-Regeln konfiguriert sind. Eine Liste der Regeln finden Sie unter [Firewall-Regeln für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](FirewallRules.md). Wenn die Firewall-Regeln korrekt eingerichtet sind, können Sie mithilfe des folgenden Befehls mit der Fehlersuche fortfahren. ``` # show status tunnel 1 ``` ``` TUNNEL[1]: Description: Interface type: IPsec Current status is Online. from 2011/08/15 18:19:45. 5 hours 7 minutes 58 seconds connection. Received: (IPv4) 3933 packets [244941 octets] (IPv6) 0 packet [0 octet] Transmitted: (IPv4) 3933 packets [241407 octets] (IPv6) 0 packet [0 octet] ``` Stellen Sie sicher, dass der `current status` Wert online ist und das auch so `Interface type` ist IPsec. Führen Sie den Befehl für beide Tunnelschnittstellen aus. Fehler, die hier auftreten, können Sie in der Konfiguration beheben. ## BGP Führen Sie den folgenden Befehl aus. ``` # show status bgp neighbor ``` ``` BGP neighbor is 169.254.255.1, remote AS 7224, local AS 65000, external link BGP version 0, remote router ID 0.0.0.0 BGP state = Active Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds Received 0 messages, 0 notifications, 0 in queue Sent 0 messages, 0 notifications, 0 in queue Connection established 0; dropped 0 Last reset never Local host: unspecified Foreign host: 169.254.255.1, Foreign port: 0 BGP neighbor is 169.254.255.5, remote AS 7224, local AS 65000, external link BGP version 0, remote router ID 0.0.0.0 BGP state = Active Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds Received 0 messages, 0 notifications, 0 in queue Sent 0 messages, 0 notifications, 0 in queue Connection established 0; dropped 0 Last reset never Local host: unspecified Foreign host: 169.254.255.5, Foreign port: ``` Hier sollten beide Nachbarn aufgeführt sein. Für jeden davon sollte der `BGP state`-Wert `Active` betragen. Wenn BGP-Peering aktiviert ist, überprüfen Sie, ob Ihr Kunden-Gateway-Gerät die Standardroute (0.0.0.0/0) an die VPC sendet. ``` # show status bgp neighbor 169.254.255.1 advertised-routes ``` ``` Total routes: 1 *: valid route Network Next Hop Metric LocPrf Path * default 0.0.0.0 0 IGP ``` Stellen Sie außerdem sicher, dass Sie das Präfix Ihrer VPC vom Virtual Private Gateway empfangen. ``` # show ip route ``` ``` Destination Gateway Interface Kind Additional Info. default ***.***.***.*** LAN3(DHCP) static 10.0.0.0/16 169.254.255.1 TUNNEL[1] BGP path=10124 ``` # Integration von AWS Site-to-Site VPN und Eero AWS Site-to-Site VPN hat mit [eero](http://eero.com) zusammengearbeitet, um es Unternehmen einfach und bequem zu machen, mit nur wenigen Klicks eine sichere Konnektivität zwischen ihren Remote-Standorten und AWS herzustellen. Diese Lösung nutzt die WiFi Access Points und Netzwerk-Gateways von eero, um lokale Konnektivität bereitzustellen. Mit den Gateway-Appliances und dem Site-to-Site VPN von eero können Kunden mit nur wenigen Klicks automatisch VPN-Konnektivität herstellen, um auf ihre in AWS gehosteten Anwendungen wie Zahlungsgateways für Kassensysteme zuzugreifen. Dies macht es für Kunden einfach und schneller, ihre Konnektivität an entfernten Standorten auf Hunderte von Standorten zu skalieren, und macht die Notwendigkeit eines Technikers vor Ort mit Netzwerkkenntnissen zur Einrichtung der Konnektivität überflüssig. Diese Lösung eignet sich für verteilte Unternehmen mit bis zu 500 Außenstellen, wobei jedes Büro bis zu 100 Benutzer hat. Weitere Informationen zu dieser Integration, einschließlich einer ausführlichen Anleitung zur Einrichtung, finden Sie in der [eero-Dokumentation](https://support.eero.com/hc/en-us/articles/42827838351899-AWS-Account-and-VPN-Configuration). **Anmerkung** Im Rahmen dieser Integration wurden keine Änderungen an der Funktionalität von AWS Site-to-Site VPN vorgenommen. **Überlegungen**: + Nur für VPN-Verbindungen verfügbar, die an ein Transit Gateway oder an Cloud WAN angeschlossen sind. Wird nicht für Virtual Private Gateway-Anhänge unterstützt. + 5-Gbit/s-Tunnel werden nicht unterstützt. + Site-to-Site VPN Concentrator wird nicht unterstützt. + Site-to-Site [VPN-Kontingente](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-limits.html) ändern sich mit dieser Integration nicht.