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.
Im Folgenden finden Sie Beispiele für Anwendungsfälle für öffentliche und private NAT-Gateways.
Szenarien
Zugriff auf das Internet von einem privaten Subnetz
Sie können ein öffentliches NAT-Gateway verwenden, um es Instances in einem privaten Subnetz zu ermöglichen, ausgehenden Datenverkehr an das Internet zu senden, ohne dass das Internet Verbindungen zu den Instances herstellen kann.
Ü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 Availability Zone B enthält das öffentliche Subnetz ein NAT-Gateway, und die Instances im privaten Subnetz können über eine Route zum NAT-Gateway im öffentlichen Subnetz das Internet 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 NAT-Gateways ordnet das Internet-Gateway dann die private IPv4 Adresse des öffentlichen NAT-Gateways der Elastic IP-Adresse zu, die dem NAT-Gateway zugeordnet ist. Beim Senden von Antwortdatenverkehr an die Instances übersetzt das NAT-Gateway die Adresse zurück in die ursprüngliche IP-Adresse.
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 Resilienz verbessern, indem Sie in jeder Availability Zone ein NAT-Gateway erstellen, das Ressourcen enthält, für die ein Internetzugang erforderlich ist. Ein Beispieldiagramm finden Sie unter Beispiel: VPC mit Servern in privaten Subnetzen und NAT.
Routing
Die folgende Routing-Tabelle ist dem öffentlichen Subnetz in Availability Zone A zugeordnet. Der erste Eintrag ist die lokale Route; dieser Eintrag ermöglicht es den Instances im Subnetz mit anderen Instances in der VPC über private IP-Adressen zu kommunizieren. 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 |
Die folgende Routing-Tabelle ist dem privaten Subnetz in Availability Zone A zugeordnet. Der Eintrag ist die lokale Route, die es den Instances im Subnetz ermöglicht, mit anderen Instances in der VPC mit privaten IP-Adressen zu kommunizieren. Die Instances in diesem Subnetz haben keinen Zugriff auf das Internet.
| Bestimmungsort | Ziel |
|---|---|
VPC CIDR |
local |
Die folgende Routing-Tabelle ist dem öffentlichen Subnetz in Availability Zone B zugeordnet. Der erste Eintrag ist die lokale Route; dieser Eintrag ermöglicht es den Instances im Subnetz mit anderen Instances in der VPC über private IP-Adressen zu kommunizieren. Der zweite Eintrag sendet den übrigen Datenverkehr des Subnetzes zum 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 |
Die folgende Routing-Tabelle ist dem privaten Subnetz in Availability Zone B zugeordnet. Der erste Eintrag ist die lokale Route; dieser Eintrag ermöglicht es den Instances im Subnetz durch private IP-Adressen mit anderen Instances in der VPC zu kommunizieren. Der zweite Eintrag sendet den übrigen Subnetz-Verkehr zum NAT-Gateway.
| Bestimmungsort | Ziel |
|---|---|
VPC CIDR |
Lokal |
| 0.0.0.0/0 | nat-gateway-id |
Weitere Informationen finden Sie unter Ändern der Routing-Tabelle eines Subnetzes.
Testen des öffentlichen NAT-Gateways
Nachdem Sie ein NAT-Gateway erstellt und die Routing-Tabellen aktualisiert haben, können Sie von einer Instance in Ihrem privaten Subnetz aus einen Ping an Remote-Adressen im Internet senden, um die Verbindung zum Internet zu testen. 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 testen, ob Internetdatenverkehr ü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
tracerouteauf einer Linux-Instance in Ihrem privaten Subnetz aus. Die Ausgabe enthält die private IP-Adresse des NAT-Gateways in einem der Hops (in der Regel der erste Hop). -
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.
-
Starten Sie eine Instance in Ihrem öffentlichen Subnetz (diese dient als Bastion Host). Wählen Sie im Startassistenten ein Amazon Linux-AMI aus und weisen Sie der Instance eine öffentliche IP-Adresse zu. Die Sicherheitsgruppenregeln müssen eingehenden SSH-Datenverkehr im IP-Adressbereich Ihres lokalen Netzwerks sowie ausgehenden SSH-Datenverkehr im IP-Adressbereich Ihres privaten Subnetzes zulassen (für Testzwecke können Sie sowohl für ein- als auch ausgehenden SSH-Datenverkehr auch
0.0.0.0/0verwenden). -
Starten Sie eine Instance in Ihrem privaten Subnetz. Wählen Sie im Startassistenten ein Amazon Linux-AMI aus. Weisen Sie der Instance keine öffentliche IP-Adresse zu. Die Sicherheitsgruppenregeln müssen eingehenden SSH-Datenverkehr von der privaten IP-Adresse der Instance zulassen, die Sie im öffentlichen Subnetz gestartet haben, sowie den gesamten ausgehenden ICMP-Datenverkehr. Sie müssen dasselbe Schlüsselpaar auswählen, mit dem Sie die Instance im öffentlichen Subnetz gestartet haben.
-
Konfigurieren Sie das SSH-Agent-Forwarding auf Ihrem lokalen Computer und stellen Sie eine Verbindung zum Bastion Host im öffentlichen Subnetz her. Weitere Informationen finden Sie unter So konfigurieren Sie SSH-Agent-Forwarding für Linux oder macOS oder So konfigurieren Sie die Weiterleitung des SSH-Agenten für Windows.
-
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 SSH-Agent-Forwarding für Linux oder macOS
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.pemVerwenden Sie für macOS den folgenden Befehl.
ssh-add -K mykeypair.pemVerbinden Sie sich mit der Option
-Amit der Instance im öffentlichen Subnetz, um SSH-Agent-Forwarding zu aktivieren, und verwenden Sie die öffentliche Adresse der Instance, wie im nachfolgenden Beispiel gezeigt.ssh -A ec2-user@54.0.0.123
So konfigurieren Sie die Weiterleitung des SSH-Agenten für Windows
Sie können den in Windows verfügbaren OpenSSH-Client verwenden oder Ihren bevorzugten SSH-Client (z. B. PuTTY) installieren.
Installieren Sie OpenSSH für Windows wie im folgenden Artikel beschrieben: Erste Schritte mit OpenSSH für Windows
So testen Sie die Internetverbindung
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Überprüfen Sie auf der eigenen Instance, ob Sie eine Verbindung mit dem Internet herstellen können. Senden Sie dazu den Befehl
pingan eine ICMP-fähige Website.ping ietf.orgPING 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
pingabzubrechen. Falls der Befehlpingfehlschlägt, lesen Sie hier weiter: Instances haben keinen Zugriff auf das Internet..(Optional) Beenden Sie Ihre Instances, wenn Sie sie nicht mehr benötigen. Weitere Informationen finden Sie im EC2 Amazon-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 Instance eine separate IP-Adresse von dem bereits aufgeführten IP-Adressbereich zuzuweisen, können Sie Datenverkehr von dem Subnetz, das für das On-Premises-Netzwerk vorgesehen ist, über ein privates NAT-Gateway mit einer IP-Adresse aus dem bereits aufgeführten IP-Adressbereich leiten.
Übersicht
Das folgende Diagramm zeigt, wie Instances über auf lokale Ressourcen zugreifen können. AWS VPN Der Datenverkehr von den Instances wird über die VPN-Verbindung an ein Virtual Private Gateway, an das Kunden-Gateway und dann an das Ziel im On-Premises-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.
Die folgende Abbildung zeigt die Hauptkomponenten der Konfiguration für dieses Szenario. Die VPC verfügt über ihren ursprünglichen IP-Adressbereich plus den zulässigen IP-Adressbereich. Die VPC verfügt über ein Subnetz aus dem zulässigen IP-Adressbereich mit einem privaten NAT-Gateway. Der Datenverkehr von den Instances, die für das On-Premises-Netzwerk bestimmt sind, wird an das NAT-Gateway gesendet, bevor er an die VPN-Verbindung weitergeleitet wird. Das On-Premises-Netzwerk empfängt den Datenverkehr von den Instances mit der Quell-IP-Adresse des NAT-Gateways, die aus dem zulässigen IP-Adressbereich stammt.
Ressourcen
Erstellen oder aktualisieren Sie Ressourcen wie folgt:
-
Ordnen Sie den zulässigen IP-Adressbereich mit der VPC zu.
-
Erstellen Sie aus dem zulässigen IP-Adressbereich ein Subnetz in der VPC.
-
Erstellen Sie im neuen Subnetz ein privates NAT-Gateway.
-
Aktualisieren Sie die Routing-Tabelle für das Subnetz mit den Instances, um den für das On-Premises-Netzwerk bestimmten Datenverkehr an das NAT-Gateway zu senden. Fügen Sie eine Route zur Routing-Tabelle für das Subnetz mit dem privaten NAT-Gateway hinzu, das Datenverkehr für das On-Premises-Netzwerk an das Virtual Private Gateway sendet.
Routing
Die folgende Routing-Tabelle ist dem ersten Subnetz zugeordnet. Für jeden VPC CIDR gibt es eine lokale Route. Lokale Routen ermöglichen es Ressourcen im Subnetz, mit anderen Ressourcen in der VPC über private IP-Adressen zu kommunizieren. Der dritte Eintrag sendet den für das On-Premises-Netzwerk bestimmten Datenverkehr an das private NAT-Gateway.
| 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 VPC CIDR gibt es eine lokale Route. Lokale Routen ermöglichen es Ressourcen im Subnetz, mit anderen Ressourcen in der VPC über private IP-Adressen zu kommunizieren. 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 sie sich überschneidende CIDR-Bereiche haben. Angenommen, die Instances in VPC A müssen auf die Dienste zugreifen, die von den Instances in VPC B bereitgestellt werden.
Übersicht
Die folgende Abbildung zeigt die Hauptkomponenten der Konfiguration für dieses Szenario. Zunächst bestimmt Ihr IP-Managementteam, 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.
Jede VPC hat ihren ursprünglichen IP-Adressbereich, der nicht routbar ist, sowie den routbaren IP-Adressbereich, den ihr vom IP-Managementteam zugewiesen wurde. VPC A verfügt über ein Subnetz aus seinem routbaren Bereich mit einem privaten NAT-Gateway. Das private NAT-Gateway erhält seine IP-Adresse aus seinem Subnetz. VPC B verfügt über 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, die für die Instances im nicht routbaren Subnetz von VPC B bestimmt ist, wird über das private NAT-Gateway gesendet und dann an das Transit-Gateway weitergeleitet. 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 NAT-Gateways. Daher verwendet der Antwortverkehr vom Load Balancer die Adresse des privaten NAT-Gateways als Ziel. Der Antwortverkehr wird an das Transit-Gateway gesendet und dann an das private NAT-Gateway weitergeleitet, welches das Ziel in die Instance im nicht routbaren Subnetz von VPC A übersetzt.
Ressourcen
Erstellen oder aktualisieren Sie Ressourcen wie folgt:
-
Ordnen Sie die zugewiesenen routbaren IP-Adressbereiche den jeweiligen Bereichen zu. VPCs
-
Erstellen Sie ein Subnetz in VPC A aus seinem routfähigen IP-Adressbereich und erstellen Sie in diesem neuen Subnetz ein privates NAT-Gateway.
-
Erstellen Sie ein Subnetz in VPC B aus seinem routfähigen IP-Adressbereich und erstellen Sie in diesem neuen Subnetz einen Application Load Balancer. Registrieren Sie die Instances im nicht routbaren Subnetz bei der Zielgruppe für den Load Balancer.
-
Erstellen Sie ein Transit-Gateway, um eine Verbindung herzustellen. VPCs Stellen Sie sicher, dass Sie die Routing-Verbreitung deaktivieren. Wenn Sie jede VPC an das Transit-Gateway anfügen, verwenden Sie den routbaren Adressbereich der VPC.
-
Aktualisieren Sie die Routing-Tabelle des nicht routbaren Subnetzes in VPC A, um den gesamten Datenverkehr, der für den routbaren Adressbereich von VPC B bestimmt ist, an das private NAT-Gateway zu senden. Aktualisieren Sie die Routing-Tabelle des routbaren Subnetzes in VPC A, um den gesamten Datenverkehr, der für den routbaren Adressbereich von VPC B bestimmt ist, an das Transit-Gateway zu senden.
-
Aktualisieren Sie die Routing-Tabelle des routbaren Subnetzes in VPC B, um den gesamten Datenverkehr, der für den routbaren Adressbereich von VPC A bestimmt ist, an das Transit-Gateway zu senden.
Routing
Dies ist die Routing-Tabelle für das nicht routbare Subnetz in VPC A:
| Bestimmungsort | Ziel |
|---|---|
10.0.0.0/16 |
local |
100.64.1.0/24 |
local |
100.64.2.0/24 |
nat-gateway-id |
Dies ist die Routing-Tabelle für das routbare Subnetz in VPC A:
| Bestimmungsort | Ziel |
|---|---|
10.0.0.0/16 |
local |
100.64.1.0/24 |
local |
100.64.2.0/24 |
transit-gateway-id |
Dies ist die Routing-Tabelle für das nicht routbare Subnetz in VPC B:
| Bestimmungsort | Ziel |
|---|---|
10.0.0.0/16 |
local |
100.64.2.0/24 |
local |
Dies ist die Routing-Tabelle für das routbare Subnetz in VPC B:
| 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 |
