NATAnwendungsfälle für Gateways - Amazon Virtual Private Cloud
Zugriff auf das Internet von einem privaten SubnetzZugriff auf Ihr Netzwerk mit bereits aufgeführten IP-AdressenAktivieren Sie die Kommunikation zwischen sich überschneidenden Netzwerken

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.

NATAnwendungsfälle für Gateways

Im Folgenden finden Sie Beispiele für Anwendungsfälle für öffentliche und private NAT Gateways.

Zugriff auf das Internet von einem privaten Subnetz

Sie können ein öffentliches NAT Gateway verwenden, um Instances in einem privaten Subnetz die Möglichkeit zu geben, ausgehenden Datenverkehr ins Internet zu senden und gleichzeitig zu verhindern, dass das Internet Verbindungen zu den Instances herstellt.

Übersicht

Das folgende Diagramm veranschaulicht diesen Anwendungsfall. Es gibt zwei Availability Zones, mit zwei Subnetzen in jeder Availability Zone. Die Routing-Tabelle für jedes Subnetz bestimmt, wie der Datenverkehr weitergeleitet wird. In Availability Zone A können die Instances im öffentlichen Subnetz über eine Route zum Internet-Gateway ins Internet gelangen, während die Instances im privaten Subnetz keine Route zum Internet haben. In der Availability Zone B enthält das öffentliche Subnetz ein NAT Gateway, und die Instances im privaten Subnetz können das Internet über eine Route zum NAT Gateway im öffentlichen Subnetz erreichen. Sowohl private als auch öffentliche NAT Gateways ordnen die private IPv4 Quelladresse der Instances der privaten IPv4 Adresse des privaten NAT Gateways zu. Im Fall eines öffentlichen Gateways ordnet das NAT Internet-Gateway dann die private IPv4 Adresse des öffentlichen Gateways der Elastic IP-Adresse zu, die dem NAT Gateway zugeordnet ist. NAT Beim Senden von Antwortdatenverkehr an die Instances, unabhängig davon, ob es sich um ein öffentliches oder ein privates NAT NAT Gateway handelt, übersetzt das Gateway die Adresse zurück in die ursprüngliche Quell-IP-Adresse.

A VPC mit öffentlichen und privaten Subnetzen, einem NAT Gateway und einem Internet-Gateway.

Beachten Sie, dass Sie, wenn die Instances im privaten Subnetz in Availability Zone A auch das Internet erreichen müssen, eine Route von diesem Subnetz zum NAT Gateway in Availability Zone B erstellen können. Alternativ können Sie die Ausfallsicherheit verbessern, indem Sie in jeder Availability Zone, die Ressourcen enthält, für die Internetzugang erforderlich ist, ein NAT Gateway einrichten. Ein Beispieldiagramm finden Sie unter Beispiel: VPC mit Servern in privaten Subnetzen und NAT.

Routing

Im Folgenden finden Sie die Routing-Tabelle, die dem öffentlichen Subnetz in Availability Zone A zugeordnet ist. Der erste Eintrag ist die lokale Route. Sie ermöglicht es den Instances im Subnetz, mit anderen Instances zu kommunizieren, die private IP-Adressen VPC verwenden. Der zweite Eintrag sendet den übrigen Datenverkehr des Subnetzes zum Internet-Gateway, wodurch die Instances im Subnetz auf das Internet zugreifen können.

Bestimmungsort Ziel
VPC CIDR Lokal
0.0.0.0/0 internet-gateway-id

Im Folgenden finden Sie die Routing-Tabelle, die dem privaten Subnetz in Availability Zone A zugeordnet ist. Der Eintrag ist die lokale Route, über die die Instances im Subnetz mit anderen Instances kommunizieren können, die private IP-Adressen VPC verwenden. Die Instances in diesem Subnetz haben keinen Zugriff auf das Internet.

Bestimmungsort Ziel
VPC CIDR local

Im Folgenden finden Sie die Routing-Tabelle, die dem öffentlichen Subnetz in Availability Zone B zugeordnet ist. Der erste Eintrag ist die lokale Route, über die die Instances im Subnetz mit anderen Instances kommunizieren können, die private IP-Adressen VPC verwenden. Der zweite Eintrag sendet den gesamten anderen Subnetzverkehr an das Internet-Gateway, wodurch das NAT Gateway im Subnetz auf das Internet zugreifen kann.

Bestimmungsort Ziel
VPC CIDR Lokal
0.0.0.0/0 internet-gateway-id

Im Folgenden finden Sie die Routing-Tabelle, die dem privaten Subnetz in Availability Zone B zugeordnet ist. Der erste Eintrag ist die lokale Route. Sie ermöglicht es den Instances im Subnetz, mit anderen Instances zu kommunizieren, die private IP-Adressen VPC verwenden. Der zweite Eintrag sendet den gesamten anderen Subnetzverkehr an das Gateway. NAT

Bestimmungsort Ziel
VPC CIDR Lokal
0.0.0.0/0 nat-gateway-id

Weitere Informationen finden Sie unter Ändern Sie eine Subnetz-Routentabelle.

Testen Sie das öffentliche Gateway NAT

Nachdem Sie Ihr NAT Gateway erstellt und Ihre Routing-Tabellen aktualisiert haben, können Sie Remoteadressen im Internet von einer Instance in Ihrem privaten Subnetz aus pingen, um zu testen, ob sie eine Verbindung zum Internet herstellen kann. Ein Beispiel für diese Vorgehensweise finden Sie unter Testen Sie die Internetverbindung.

Wenn Sie eine Verbindung zum Internet herstellen können, können Sie auch testen, ob der Internetverkehr über das NAT Gateway geleitet wird:

  • Sie können die Route, die der Datenverkehr von einer Instance zu Ihrem privaten Subnetz nimmt, nachvollziehen. Führen Sie dazu den Befehl traceroute auf einer Linux-Instance in Ihrem privaten Subnetz aus. In der Ausgabe sollten Sie die private IP-Adresse des NAT Gateways in einem der Hops (normalerweise der erste Hop) sehen.

  • Verwenden Sie eine Drittanbieter-Website oder ein Drittanbieter-Tool, um die Quell-IP-Adresse anzuzeigen, wenn Sie sich von einer Instance in Ihrem privaten Subnetz mit dem NAT-Gateway verbinden. Die Quell-IP-Adresse sollte die elastische IP-Adresse des NAT Gateways sein.

Sollten diese Tests fehlschlagen, finden Sie weitere Informationen unter Problembehandlung bei NAT-Gateways.

Testen Sie die Internetverbindung

Das folgende Beispiel veranschaulicht, wie Sie überprüfen, ob eine Instance in einem privaten Subnetz eine Verbindung zum Internet herstellen kann.

  1. Starten Sie eine Instance in Ihrem öffentlichen Subnetz (diese dient als Bastion Host). Stellen Sie im Startassistenten sicher, dass Sie ein Amazon Linux AMI auswählen und Ihrer Instance eine öffentliche IP-Adresse zuweisen. Stellen Sie sicher, dass Ihre Sicherheitsgruppenregeln eingehenden SSH Datenverkehr aus dem IP-Adressbereich Ihres lokalen Netzwerks und ausgehenden SSH Datenverkehr in den IP-Adressbereich Ihres privaten Subnetzes zulassen (Sie können diesen Test auch sowohl 0.0.0.0/0 für eingehenden als auch für ausgehenden SSH Datenverkehr verwenden).

  2. Starten Sie eine Instance in Ihrem privaten Subnetz. Stellen Sie im Startassistenten sicher, dass Sie ein Amazon Linux auswählenAMI. Weisen Sie der Instance keine öffentliche IP-Adresse zu. Stellen Sie sicher, dass Ihre Sicherheitsgruppenregeln eingehenden SSH Datenverkehr von der privaten IP-Adresse Ihrer Instance, die Sie im öffentlichen Subnetz gestartet haben, sowie den gesamten ausgehenden ICMP Datenverkehr zulassen. Sie müssen dasselbe Schlüsselpaar auswählen, mit dem Sie die Instance im öffentlichen Subnetz gestartet haben.

  3. Konfigurieren Sie die SSH Agentenweiterleitung auf Ihrem lokalen Computer und stellen Sie eine Verbindung zu Ihrem Bastion-Host im öffentlichen Subnetz her. Weitere Informationen finden Sie unter So konfigurieren Sie die SSH Agentenweiterleitung für Linux oder macOS oder Um die SSH Agentenweiterleitung für Windows zu konfigurieren.

  4. Verbinden Sie sich vom Bastion Host aus mit der Instance im privaten Subnetz und testen Sie die Internetverbindung von der Instance im privaten Subnetz aus. Weitere Informationen finden Sie unter So testen Sie die Internetverbindung.

So konfigurieren Sie die SSH Agentenweiterleitung für Linux oder macOS

  1. Fügen Sie dem Authentifizierungsagenten von Ihrem lokalen Computer aus Ihren privaten Schlüssel hinzu.

    Verwenden Sie für Linux den folgenden Befehl.

    ssh-add -c mykeypair.pem

    Verwenden Sie für macOS den folgenden Befehl.

    ssh-add -K mykeypair.pem

  2. Stellen Sie mithilfe der -A Option zur Aktivierung der SSH Agentenweiterleitung eine Connect zu Ihrer Instance im öffentlichen Subnetz her und verwenden Sie die öffentliche Adresse der Instance, wie im folgenden Beispiel gezeigt.

    ssh -A ec2-user@54.0.0.123
Um die SSH Agentenweiterleitung für Windows zu konfigurieren

Sie können den in Windows verfügbaren SSH Open-Client verwenden oder Ihren bevorzugten SSH Client (z. B. PuTTY) installieren.

OpenSSH

Installieren Sie Open SSH for Windows wie in diesem Artikel beschrieben: Erste Schritte mit Open SSH for Windows. Fügen Sie anschließend Ihren Schlüssel zum Authentifizierungsagenten hinzu. Weitere Informationen finden Sie unter Schlüsselbasierte Authentifizierung in Open SSH for Windows.

PuTTY

  1. Laden Sie Pageant von der TTYPu-Downloadseite herunter und installieren Sie es, falls es nicht bereits installiert ist.

  2. Konvertieren Sie Ihren privaten Schlüssel ins PPK-Format. Weitere Informationen finden Sie unter Konvertieren Ihres privaten Schlüssels mit P uTTYgen im EC2Amazon-Benutzerhandbuch.

  3. Starten Sie Pageant, klicken Sie mit der rechten Maustaste auf das Pageant-Symbol in der Taskleiste (das Symbol ist möglicherweise ausgeblendet) und klicken Sie auf Add Key. Wählen Sie die .ppk-Datei, die Sie erstellt haben, geben Sie gegebenenfalls das Passwort ein, und wählen Sie Open (Öffnen).

  4. Starten Sie eine TTY Pu-Sitzung und stellen Sie über deren öffentliche IP-Adresse eine Verbindung zu Ihrer Instance im öffentlichen Subnetz her. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit Ihrer Linux-Instance. Wählen Sie in der Kategorie Auth die Option Allow agent forwarding aus und lassen Sie das Feld Private key file for authentication frei.
So testen Sie die Internetverbindung

  1. Verbinden Sie sich von der Instance im öffentlichen Subnetz aus mit der Instance im privaten Subnetz unter Verwendung von deren privater IP-Adresse, wie im nachfolgenden Beispiel gezeigt.

    ssh ec2-user@10.0.1.123

  2. Testen Sie von Ihrer privaten Instance aus, ob Sie eine Verbindung zum Internet herstellen können, indem Sie den ping Befehl für eine Website ausführen, die ICMP aktiviert wurde.

    ping ietf.org
    PING ietf.org (4.31.198.44) 56(84) bytes of data.
64 bytes from mail.ietf.org (4.31.198.44): icmp_seq=1 ttl=47 time=86.0 ms
64 bytes from mail.ietf.org (4.31.198.44): icmp_seq=2 ttl=47 time=75.6 ms
...

    Drücken Sie auf der Tastatur Strg + C, um den Befehl ping abzubrechen. Falls der Befehl ping fehlschlägt, lesen Sie hier weiter: Instances haben keinen Zugriff auf das Internet..

  3. (Optional) Beenden Sie Ihre Instances, wenn Sie sie nicht mehr benötigen. Weitere Informationen finden Sie im EC2Amazon-Benutzerhandbuch unter Ihre Instance beenden.

Zugriff auf Ihr Netzwerk mit bereits aufgeführten IP-Adressen

Sie können ein privates NAT Gateway verwenden, um die Kommunikation von Ihrem Netzwerk VPCs zu Ihrem lokalen Netzwerk mithilfe eines Pools von Adressen auf der Zulassungsliste zu ermöglichen. Anstatt jeder Instanz eine separate IP-Adresse aus dem IP-Adressbereich auf der Zulassungsliste zuzuweisen, können Sie den Datenverkehr aus dem Subnetz, das für das lokale Netzwerk bestimmt ist, über ein privates NAT Gateway mit einer IP-Adresse aus dem IP-Adressbereich der Zulassungsliste weiterleiten.

Übersicht

Das folgende Diagramm zeigt, wie Instanzen über auf lokale Ressourcen zugreifen können. AWS VPN Der Datenverkehr von den Instances wird an ein virtuelles privates Gateway, über die VPN Verbindung zum Kunden-Gateway und dann zum Ziel im lokalen Netzwerk weitergeleitet. Angenommen, das Ziel lässt Datenverkehr nur aus einem bestimmten IP-Adressbereich wie 100.64.1.0/28 zu. Dies würde verhindern, dass der Datenverkehr von diesen Instances das On-Premises-Netzwerk erreicht.

Zugriff auf ein lokales Netzwerk über eine Verbindung. AWS VPN

Die folgende Abbildung zeigt die Hauptkomponenten der Konfiguration für dieses Szenario. Der VPC hat seinen ursprünglichen IP-Adressbereich plus den zulässigen IP-Adressbereich. Der VPC hat ein Subnetz aus dem zulässigen IP-Adressbereich mit einem privaten NAT Gateway. Der Datenverkehr von den Instances, der für das lokale Netzwerk bestimmt ist, wird an das NAT Gateway gesendet, bevor er an die Verbindung weitergeleitet wird. VPN Das lokale Netzwerk empfängt den Datenverkehr von den Instanzen mit der Quell-IP-Adresse des NAT Gateways, die aus dem zulässigen IP-Adressbereich stammt.

VPCSubnetz-Verkehr, der über ein privates Gateway geleitet wird NAT

Ressourcen

Erstellen oder aktualisieren Sie Ressourcen wie folgt:

  • Ordnen Sie den zulässigen IP-Adressbereich dem zu. VPC

  • Erstellen Sie ein Subnetz im VPC zulässigen IP-Adressbereich.

  • Erstellen Sie ein privates NAT Gateway im neuen Subnetz.

  • Aktualisieren Sie die Routing-Tabelle für das Subnetz mit den Instanzen, um den für das lokale Netzwerk bestimmten Datenverkehr an das Gateway zu senden. NAT Fügen Sie der Routentabelle für das Subnetz mit dem privaten NAT Gateway, das den für das lokale Netzwerk bestimmten Datenverkehr an das virtuelle private Gateway sendet, eine Route hinzu.

Routing

Die folgende Routing-Tabelle ist dem ersten Subnetz zugeordnet. Für jedes gibt es eine lokale Route. VPC CIDR Lokale Routen ermöglichen es Ressourcen im Subnetz, mit anderen Ressourcen zu kommunizieren, die private IP-Adressen VPC verwenden. Der dritte Eintrag leitet den für das lokale Netzwerk bestimmten Datenverkehr an das private Gateway weiter. NAT

Bestimmungsort Ziel
10.0.0.0/16 local
100.64.1.0/24 local
192.168.0.0/16 nat-gateway-id

Die folgende Routing-Tabelle ist dem zweiten Subnetz zugeordnet. Für jeden gibt es eine lokale Route. VPC CIDR Lokale Routen ermöglichen es Ressourcen im Subnetz, mit anderen Ressourcen zu kommunizieren, die private IP-Adressen VPC verwenden. Der dritte Eintrag sendet Datenverkehr, der für das On-Premises-Netzwerk vorgesehen ist, an das Virtual Private Gateway.

Bestimmungsort Ziel
10.0.0.0/16 local
100.64.1.0/24 local
192.168.0.0/16 vgw-id

Aktivieren Sie die Kommunikation zwischen sich überschneidenden Netzwerken

Sie können ein privates NAT Gateway verwenden, um die Kommunikation zwischen Netzwerken zu ermöglichen, auch wenn sich deren Bereiche überschneiden. CIDR Nehmen wir zum Beispiel an, dass die Instanzen in VPC A auf die Dienste zugreifen müssen, die von den Instanzen in VPC B bereitgestellt werden.

Zwei VPCs mit überlappenden CIDR Bereichen.

Übersicht

Die folgende Abbildung zeigt die Hauptkomponenten der Konfiguration für dieses Szenario. Zunächst bestimmt Ihr IP-Management-Team, welche Adressbereiche sich überschneiden können (nicht routbare Adressbereiche) und welche nicht (routbare Adressbereiche). Das IP-Management-Team weist auf Anfrage Adressbereiche vom Pool routierbarer Adressbereiche bis hin zu Projekten zu.

Jeder VPC hat seinen ursprünglichen IP-Adressbereich, der nicht routbar ist, sowie den routbaren IP-Adressbereich, der ihm vom IP-Verwaltungsteam zugewiesen wurde. VPCA hat ein Subnetz aus seinem routingfähigen Bereich mit einem privaten Gateway. NAT Das private NAT Gateway bezieht seine IP-Adresse aus seinem Subnetz. VPCB hat ein Subnetz aus seinem routbaren Bereich mit einem Application Load Balancer. Der Application Load Balancer erhält seine IP-Adressen aus seinen Subnetzen.

Der Datenverkehr von einer Instance im nicht routbaren Subnetz von VPC A, der für die Instances im nicht routbaren Subnetz von VPC B bestimmt ist, wird über das private Gateway und dann an das Transit-Gateway weitergeleitet. NAT Das Transit-Gateway sendet den Datenverkehr an den Application Load Balancer, der den Datenverkehr an eine der Ziel-Instances im nicht routbaren Subnetz von VPC B weiterleitet. Der Datenverkehr vom Transit-Gateway zum Application Load Balancer hat die Quell-IP-Adresse des privaten Gateways. NAT Daher verwendet der Antwortdatenverkehr vom Load Balancer die Adresse des privaten Gateways als Ziel. NAT Der Antwortverkehr wird an das Transit-Gateway gesendet und dann an das private NAT Gateway weitergeleitet, das das Ziel in die Instance im nicht routbaren Subnetz von A übersetzt. VPC

VPCmit privatem NAT Gateway und Transit-Gateway für die Kommunikation mit Überlappung VPC CIDR

Ressourcen

Erstellen oder aktualisieren Sie Ressourcen wie folgt:

  • Ordnen Sie die zugewiesenen routbaren IP-Adressbereiche ihren jeweiligen zu. VPCs

  • Erstellen Sie ein Subnetz in VPC A aus seinem routingfähigen IP-Adressbereich und erstellen Sie ein privates NAT Gateway in diesem neuen Subnetz.

  • Erstellen Sie ein Subnetz in VPC B aus seinem routbaren IP-Adressbereich und erstellen Sie einen Application Load Balancer in diesem neuen Subnetz. Registrieren Sie die Instances im nicht routbaren Subnetz bei der Zielgruppe für den Load Balancer.

  • Erstellen Sie ein Transit-Gateway, um die Verbindung herzustellen. VPCs Stellen Sie sicher, dass Sie die Routing-Verbreitung deaktivieren. Wenn Sie jedes VPC an das Transit-Gateway anschließen, verwenden Sie den routingfähigen Adressbereich von. VPC

  • Aktualisieren Sie die Routentabelle des nicht routbaren Subnetzes in VPC A, um den gesamten Datenverkehr, der für den routingfähigen Adressbereich von VPC B bestimmt ist, an das private Gateway zu senden. NAT Aktualisieren Sie die Routentabelle des routbaren Subnetzes in VPC A, um den gesamten Datenverkehr, der für den routingfähigen Adressbereich von B bestimmt ist, an das Transit-Gateway zu senden. VPC

  • Aktualisieren Sie die Routentabelle des routbaren Subnetzes in VPC B, um den gesamten Datenverkehr, der für den routingfähigen Adressbereich von A bestimmt ist, an das Transit-Gateway zu senden. VPC

Routing

Im Folgenden finden Sie die Routentabelle für das nicht routbare Subnetz in A. VPC

Bestimmungsort Ziel
10.0.0.0/16 local
100.64.1.0/24 local
100.64.2.0/24 nat-gateway-id

Im Folgenden finden Sie die Routing-Tabelle für das routbare Subnetz in A. VPC

Bestimmungsort Ziel
10.0.0.0/16 local
100.64.1.0/24 local
100.64.2.0/24 transit-gateway-id

Im Folgenden finden Sie die Routing-Tabelle für das nicht routbare Subnetz in B. VPC

Bestimmungsort Ziel
10.0.0.0/16 local
100.64.2.0/24 local

Im Folgenden finden Sie die Routing-Tabelle für das routbare Subnetz in B. VPC

Bestimmungsort Ziel
10.0.0.0/16 local
100.64.2.0/24 local
100.64.1.0/24 transit-gateway-id

Es folgt ein Beispiel für die Routing-Tabelle des Transit-Gateways.

CIDR Attachment Routing-Typ
100.64.1.0/24 Attachment for VPC A Statisch
100.64.2.0/24 Attachment for VPC B Statisch