Cloud NAT – Überblick

Cloud NAT (Netzwerkadressübersetzung) ermöglicht Google Cloud-VM-Instanzen ohne externe IP-Adressen und private Google Kubernetes Engine-Clustern, ausgehende Pakete an das Internet zu senden und entsprechende eingehende Antwortpakete zu empfangen.

Architektur

Cloud NAT ist ein verteilter, softwarebasierter, verwalteter Dienst, der nicht auf Proxy-VMs oder -Appliances basiert. Cloud NAT konfiguriert die Software Andromeda für Ihr VPC-Netzwerk, sodass es auch Quellnetzwerkadressübersetzungen (SNAT) für VMs ohne externe IP-Adressen bereitstellt. Cloud NAT bietet auch eine Zielnetzwerkadressübersetzung für festgelegte eingehende Antwortpakete.

Traditionelles NAT im Vergleich zu Cloud NAT (zum Vergrößern klicken)
Traditionelle NAT im Vergleich zu Cloud NAT (zum Vergrößern klicken)

Cloud NAT implementiert ausgehendes NAT in Verbindung mit statischen Routen in Ihrer VPC, deren nächste Hops Standard-Internet-Gateway sind. In einer grundlegenden Konfiguration erfüllt eine Standardroute in Ihrem VPC-Netzwerk diese Anforderung.

Cloud NAT implementiert keine unerwünschten eingehenden Verbindungen aus dem Internet. DNAT wird nur für Pakete ausgeführt, die als Antworten auf ausgehende Pakete ankommen.

Vorteile

Cloud NAT bietet folgende Vorteile:

  • Sicherheit: Sie können die Anzahl der externen IP-Adressen einzelner VMs reduzieren. Abhängig von den Firewallregeln für ausgehenden Traffic können VMs ohne externe IP-Adressen auf Ziele im Internet zugreifen. Beispiel: Sie haben VMs, die nur einen Internetzugang benötigen, um Updates herunterzuladen oder die Bereitstellung abzuschließen.

    Wenn Sie ein Cloud NAT-Gateway mithilfe der manuellen NAT-IP-Adresszuweisung konfigurieren, können Sie eine Reihe üblicher externer Quell-IP-Adressen für einen Zielpartner problemlos freigeben. Beispielsweise kann ein Zieldienst nur Verbindungen von bekannten externen IP-Adressen zulassen.

  • Verfügbarkeit: Cloud NAT ist ein verteilter, softwarebasierter, verwalteter Dienst, der nicht von VMs in Ihrem Projekt oder einem einzelnen physischen Gateway abhängt. Sie konfigurieren ein NAT-Gateway auf einem Cloud Router, der die Steuerungsebene für NAT mit den von Ihnen angegebenen Konfigurationsparametern bereitstellt. Google Cloud führt Prozesse auf den physischen Maschinen aus, auf denen Ihre Google Cloud-VMs ausgeführt werden, und verwaltet diese.

  • Skalierbarkeit: Cloud NAT kann so konfiguriert werden, dass automatisch die Anzahl der verwendeten NAT-IP-Adressen skaliert wird. VMs, die zu verwalteten Instanzgruppen gehören, einschließlich Autoscaling, werden unterstützt.

  • Leistung: Cloud NAT reduziert nicht die Netzwerkbandbreite pro VM. Cloud NAT funktioniert direkt mit Googles softwaredefiniertem Netzwerk Andromedas.

Spezifikationen

  • Cloud NAT kann so konfiguriert werden, dass NAT für Pakete aus dem Internet bereitgestellt wird:

    • Die primäre interne IP-Adresse der Netzwerkschnittstelle der VM, sofern der Netzwerkschnittstelle keine externe IP-Adresse zugewiesen ist: Wenn der Netzwerkschnittstelle eine externe IP-Adresse zugewiesen ist, führt Google Cloud automatisch 1:1-NAT für Pakete aus, deren Quellen mit der primären internen IP-Adresse der Schnittstelle übereinstimmen, da die Netzwerkschnittstelle die Google Cloud-Anforderungen für den Internetzugang erfüllt. Wenn eine externe IP-Adresse einer Schnittstelle zugewiesen ist, hat das immer Vorrang und 1:1-NAT wird ohne Cloud NAT ausgeführt.

    • Ein Alias-IP-Bereich, der der Netzwerkschnittstelle der VM zugewiesen ist: Auch wenn der Netzwerkschnittstelle eine externe IP-Adresse zugewiesen ist, können Sie ein Cloud NAT-Gateway so konfigurieren, dass NAT für Pakete bereitgestellt wird, deren Quellen von einem Alias-IP-Bereich der Schnittstelle stammen. Wenn eine externe IP-Adresse einer Schnittstelle zugewiesen ist, wird für Alias-IP-Adressen nie 1:1-NAT ausgeführt.

  • Cloud NAT ermöglicht ausgehende und eingehende Antworten auf diese Verbindungen. Jedes Cloud NAT-Gateway führt für ausgehenden Traffic eine Quellnetzwerkadressübersetzung (SNAT) und eine Zielnetzwerkadressübersetzung (DNAT) für Antwortpakete aus.

  • Cloud NAT erlaubt keine unerwünschten eingehenden Anfragen aus dem Internet, auch wenn Firewallregeln diese Anfragen andernfalls zulassen würden. Siehe Anwendbare RFCs für weitere Details.

  • Jedes Cloud NAT-Gateway ist einem einzelnen VPC-Netzwerk, einer Region und einem Cloud Router zugeordnet. Das Cloud NAT-Gateway und der Cloud Router bieten eine Steuerungsebene: Da sie nicht in der Datenebene enthalten sind, werden Pakete nicht durch das Cloud NAT-Gateway oder den Cloud Router geleitet.

Routen und Firewallregeln

Cloud NAT basiert auf benutzerdefinierten statischen Routen, deren nächste Hops das Standard-Internet-Gateway sind. Zur vollständigen Nutzung eines Cloud NAT-Gateways benötigt Ihre VPC eine Standardroute, deren nächster Hop das Standard-Internet-Gateway ist. Weitere Informationen finden Sie unter Routeninteraktionen.

Cloud NAT hat keine Anforderungen an Google Cloud-Firewallregeln. Firewallregeln werden direkt auf die Netzwerkschnittstellen von Compute Engine-VMs und nicht auf Cloud NAT-Gateways angewendet.

Sie müssen keine speziellen Firewallregeln erstellen, die Verbindungen zu oder von NAT-IP-Adressen zulassen. Wenn ein Cloud NAT-Gateway NAT für die Netzwerkschnittstelle einer VM bereitstellt, werden geltende Firewallregeln für ausgehenden Traffic als Pakete dieser Netzwerkschnittstelle vor NAT ausgewertet. Firewallregeln für eingehenden Traffic werden ausgewertet, nachdem Pakete von NAT verarbeitet wurden.

Anwendbarkeit des Subnetz-IP-Adressbereichs

Ein Cloud NAT-Gateway kann NAT-Dienste für Pakete bereitstellen, die von der Netzwerkschnittstelle einer VM gesendet werden, solange dieser Netzwerkschnittstelle keine externe IP-Adresse zugewiesen ist. Das Cloud NAT-Gateway kann so konfiguriert werden, dass NAT für die primäre interne IP-Adresse der VM-Netzwerkschnittstelle, Alias-IP-Bereiche oder beides bereitgestellt wird. Wählen Sie für diese Konfiguration die Subnetz-IP-Adressbereiche aus, auf die das Gateway angewendet werden soll.

Sie können ein Cloud NAT-Gateway so konfigurieren, dass NAT für Folgendes bereitgestellt wird:

  • Primäre und sekundäre IP-Bereiche aller Subnetze in der Region: Ein einzelnes Cloud NAT-Gateway stellt NAT für die primären internen IP-Adressen und alle Alias-IP-Bereiche aktiver VMs bereit, deren Netzwerkschnittstellen ein Subnetz in der Region verwenden. Diese Option verwendet genau ein NAT-Gateway pro Region.

  • Primäre IP-Bereiche aller Subnetze in der Region: Ein einzelnes Cloud NAT-Gateway bietet NAT für die primären internen IP-Adressen und Alias-IP-Bereiche aus den primären IP-Adressbereichen der aktiven VMs, deren Netzwerkschnittstellen ein Subnetz in der Region verwenden. Sie können zusätzliche Cloud NAT-Gateways in der Region erstellen, um NAT für Alias-IP-Bereiche aus den sekundären IP-Adressbereichen des Subnetzes von geeigneten VMs bereitzustellen.

  • Benutzerdefinierte Subnetz-IP-Bereiche: Sie können so viele Cloud NAT-Gateways erstellen wie nötig, vorbehaltlich der Cloud NAT-Kontingente und -Limits. Sie wählen aus, welche primären oder sekundären IP-Bereiche des Subnetzes von jedem Gateway bedient werden sollen.

Bandbreite

Die Verwendung eines Cloud NAT-Gateways ändert nicht die ausgehende oder eingehende Bandbreite, die eine VM nutzen kann. Informationen zu Bandbreitenspezifikationen, die je nach Maschinentyp variieren, finden Sie in der Compute Engine-Dokumentation unter Netzwerkbandbreite.

VMs mit mehreren NICs

Wenn Sie eine VM mit mehreren Netzwerkschnittstellen konfigurieren, muss sich jede Schnittstelle in einem separaten VPC-Netzwerk befinden. Dies hat folgende Konsequenzen:

  • Ein Cloud NAT-Gateway kann nur auf eine einzelne Netzwerkschnittstelle einer VM angewendet werden. Separate Cloud NAT-Gateways können NAT für dieselbe VM bereitstellen, wobei jedes Gateway für eine separate Schnittstelle gilt.

  • Eine Schnittstelle einer VM mit mehreren NICs kann eine externe IP-Adresse haben und somit nicht für Cloud NAT geeignet sein, während eine andere ihrer Schnittstellen für NAT geeignet sein kann, wenn diese Schnittstelle keine externe IP-Adresse hat und Sie ein Cloud NAT-Gateway konfiguriert haben, das auf den entsprechenden Subnetz-IP-Adressbereich angewendet wird.

NAT-IP-Adressen und -Ports

Wenn Sie ein Cloud NAT-Gateway erstellen, können Sie festlegen, dass das Gatewayregionale externe IP-Adressen automatisch zuweist. Alternativ können Sie dem Gateway manuell eine feste Anzahl von regionalen externen IP-Adressen zuweisen. Weitere Informationen zu den einzelnen Methoden finden Sie unter NAT-IP-Adressen.

Sie können die Anzahl der Quellports konfigurieren, die jedes Cloud NAT-Gateway für jede VM reserviert, für die es NAT-Dienste bereitstellen soll. Die VMs, für die NAT bereitgestellt werden soll, werden durch die Subnetz-IP-Adressbereiche bestimmt, für die das Gateway konfiguriert ist. Weitere Informationen finden Sie unter Ports und Verfahren für die Portreservierung.

Anwendbare RFCs

Cloud NAT kann als endpunktunabhängige Zuordnung, endpunktabhängige Filterung NAT nach RFC 5128 und Port-eingeschränktes Cone-NAT nach RFC 3489 eingestuft werden.

Wenn ein Cloud NAT-Gateway beim ausgehenden Traffic für ein von einer VM gesendetes Paket SNAT ausführt, kann es dieselbe Quelladresse und dasselbe Quellport-Tupel einmal pro eindeutigem Ziel (Ziel-IP-Adresse, Zielport und Protokoll) wiederverwenden. Ein Cloud NAT-Gateway führt DNAT nur für eingehende Antwortpakete aus, deren Quell-IP-Adresse und Quellport mit der Ziel-IP-Adresse und dem Zielport eines entsprechenden ausgehenden Anfragepakets übereinstimmen. Weitere Informationen zur Beziehung zwischen Ports und Verbindungen finden Sie unter Ports und Verbindungen und im Beispiel für einen NAT-Ablauf.

NAT-Durchlauf

Da Cloud NAT Endpunkt-unabhängig ist, ist Cloud NAT mit gängigen NAT-Durchlaufprotokollen wie STUN und TURN kompatibel, wenn Sie Ihre eigenen STUN- oder TURN-Server bereitstellen:

  • STUN (Session Traversal Utilities for NAT, RFC 5389) ermöglicht die direkte Kommunikation zwischen VMs hinter NAT, sobald ein Kommunikationskanal eingerichtet wurde.
  • TURN (Traversal Using Relays around NAT, RFC 5766) ermöglicht die Kommunikation zwischen VMs hinter NAT über einen dritten Server, auf dem dieser Server eine externe IP-Adresse hat. Jede VM stellt eine Verbindung zur externen IP-Adresse des Servers her und dieser Server leitet die Kommunikation zwischen den beiden VMs weiter. TURN ist robuster, benötigt jedoch mehr Bandbreite und Ressourcen.

NAT-Zeitlimits

Cloud NAT-Gateways verwenden die folgenden Zeitlimits.

Zeitlimit Cloud NAT-Standardeinstellung Konfigurierbar
Inaktives Zeitlimit für UDP-Zuordnung
RFC 4787 REQ-5
30 Sekunden Ja
Inaktives Zeitlimit für TCP-Verbindungen
RFC 5382 REQ-5
1.200 Sekunden (20 Minuten) Ja
Inaktives Zeitlimit für vorübergehende TCP-Verbindungen
RFC 5382 REQ-5
30 Sekunden Ja
Inaktives Zeitlimit für ICMP-Zuordnung
RFC 5508 REQ-2
30 Sekunden Ja
Verzögerung vor der Wiederverwendung eines 5-Tupels für eine neue TCP-Verbindung
(Tupel der Quelladresse und des Quellports in Kombination mit Zieladresse, Zielport und Protokoll)
120 Sekunden (2 Minuten) Nein
Weitere Informationen finden Sie unter Quellport-Wiederverwendung für TCP-Verbindungen.

Produktinteraktionen

In den folgenden Abschnitten werden wichtige Interaktionen zwischen Cloud NAT und anderen Google Cloud-Produkten erläutert.

Routeninteraktionen

Ein Cloud NAT-Gateway kann nur Routen verwenden, deren nächste Hops das Standard-Internet-Gateway sind. Jedes VPC-Netzwerk beginnt mit einer Standardroute, deren Ziel 0.0.0.0/0 ist und deren nächster Hop das Standard-Internet-Gateway ist. In der Routenübersicht finden Sie wichtige Hintergrundinformationen.

Die folgenden Beispiele zeigen Situationen, die dazu führen können, dass Cloud NAT-Gateways nicht mehr funktionieren:

  • Wenn Sie eine benutzerdefinierte statische Route erstellen, bei der die nächsten Hops auf beliebige andere Art von nächstem Hop für eine benutzerdefinierte statische Route festgelegt sind, werden Pakete mit Ziel-IP-Adressen, die mit dem Ziel der Route übereinstimmen, an diesen nächsten Hop gesendet und nicht an das Standard-Internet-Gateway. Wenn Sie beispielsweise VM-Instanzen verwenden, auf denen NAT-, Firewall- oder Proxy-Software ausgeführt wird, müssen Sie unbedingt benutzerdefinierte statische Routen erstellen, um den Traffic an diese VMs als nächsten Hop weiterzuleiten. Die VMs des nächsten Hops benötigen selbst externe IP-Adressen. Daher kann weder Traffic von den VMs, die auf die VMs des nächsten Hops angewiesen sind, noch die VMs des nächsten Hops selbst Cloud NAT verwenden.

  • Wenn Sie eine benutzerdefinierte statische Route erstellen, deren nächster Hop ein Cloud VPN-Tunnel ist, verwendet Cloud NAT diese Route nicht. Beispielsweise leitet eine benutzerdefinierte statische Route mit dem Ziel 0.0.0.0/0 und dem Cloud VPN-Tunnel als nächstem Hop den Traffic an diesen Tunnel und nicht an das Standard-Internet-Gateway weiter. Daher können Cloud NAT-Gateways diese Route nicht verwenden. Dies gilt auch für spezifischere Ziele wie 0.0.0.0/1 und 128.0.0.0/1.

  • Wenn ein lokaler Router einem Cloud Router, der einen Cloud VPN-Tunnel oder Cloud Interconnect-Anhang (VLAN) verwaltet, eine benutzerdefinierte dynamische Route anbietet, können Cloud NAT-Gateways diese Route nicht verwenden. Wenn Ihr lokaler Router beispielsweise eine benutzerdefinierte dynamische Route mit dem Ziel 0.0.0.0/0 anbietet, wird 0.0.0.0/0 an den Cloud VPN-Tunnel oder den Cloud Interconnect-Anhang (VLAN) weitergeleitet. Dies gilt auch für spezifischere Ziele wie 0.0.0.0/1 und 128.0.0.0/1.

Private Google-Zugriffsinteraktion

Cloud NAT führt NAT nie für Traffic aus, der an die ausgewählten externen IP-Adressen für Google APIs und Google-Dienste gesendet wird. Stattdessen aktiviert Google Cloud automatisch den privaten Google-Zugriff für einen Subnetz-IP-Adressbereich, wenn Sie ein Cloud NAT-Gateway so konfigurieren, dass es auf diesen primären oder sekundären Subnetzbereich angewendet wird. Solange das Gateway NAT für den Bereich eines Subnetzes bereitstellt, gilt der private Google-Zugriff für diesen Bereich und kann nicht manuell deaktiviert werden.

Ein Cloud NAT-Gateway ändert nicht die Funktionsweise von privatem Google-Zugriff. Siehe Privater Google-Zugriff für weitere Informationen.

Freigegebene VPC-Interaktion

Eine freigegebene VPC ermöglicht es mehreren Dienstprojekten in einer Organisation, ein gemeinsames, freigegebenes VPC-Netzwerk in einem Hostprojekt zu verwenden. Um NAT für VMs in Dienstprojekten bereitzustellen, die ein freigegebenes VPC-Netzwerk verwenden, müssen Sie Cloud NAT-Gateways im Hostprojekt erstellen.

VPC-Netzwerk-Peering-Interaktion

Cloud NAT-Gateways sind Subnetz-IP-Adressbereichen in einer einzigen Region und einem einzelnen VPC-Netzwerk zugeordnet. Ein Cloud NAT-Gateway, das in einem VPC-Netzwerk erstellt wurde, kann VMs in anderen VPC-Netzwerken, die über VPC-Netzwerk-Peering verbunden sind, keine NAT bereitstellen, auch wenn sich die VMs in Peering-Netzwerken in derselben Region wie das Gateway befinden.

GKE-Interaktion

Ein Cloud NAT-Gateway kann NAT für Knoten und Pods in einem privaten Cluster durchführen, bei dem es sich um einen VPC-nativen Cluster handelt. Das Cloud NAT-Gateway muss mindestens für die folgenden Subnetz-IP-Adressbereiche für das von Ihrem Cluster verwendete Subnetz konfiguriert sein:

  • primärer IP-Adressbereich des Subnetzes (von Knoten verwendet)
  • sekundärer IP-Adressbereich des Subnetzes, der für Pods im Cluster verwendet wird
  • sekundärer IP-Adressbereich des Subnetzes, der für Dienste im Cluster verwendet wird

Die einfachste Möglichkeit zur Bereitstellung von NAT für einen gesamten privaten Cluster besteht in der Konfiguration eines Cloud NAT-Gateways, das auf alle IP-Adressbereiche des Subnetzwerks des Clusters angewendet wird.

Hintergrundinformationen dazu, wie VPC-native Cluster Subnetz-IP-Adressbereiche verwenden, finden Sie unter IP-Bereiche für VPC-native Cluster.

Wenn ein Cloud NAT-Gateway so konfiguriert ist, dass es NAT für einen privaten Cluster bereitstellt, reserviert es Quelladressen und Quellports für jede Knoten-VM. Diese NAT-Quelladressen und -Quellports können von Pods verwendet werden, da Pod-IP-Adressen als Alias-IP-Bereiche implementiert werden, die jeder Knoten-VM zugewiesen sind. Da der kleinstmögliche Pod-IP-Bereich 256 IP-Adressen umfasst – Subnetzmaske von /24 – reserviert das Cloud NAT-Verfahren für die Portreservierung mindestens 1.024 Quelladressen und Quellports pro Knoten. Weitere Informationen zu Pod-IP-Bereichen und VPC-nativen Clustern finden Sie unter Sekundärer IP-Adressbereich des Subnetzes für Pods.

Unabhängig von Cloud NAT führt GKE SNAT mit Software aus, die auf jedem Knoten ausgeführt wird, wenn Pods Pakete an das Internet senden, es sei denn, Sie haben die IP-Masquerade-Konfiguration geändert. Wenn Sie detaillierte Kontrolle über ausgehenden Traffic von Pods benötigen, können Sie eine Netzwerkrichtlinie verwenden.

Unter bestimmten Umständen kann Cloud NAT auch für nicht private Cluster nützlich sein, einschließlich VPC-nativer und routenbasierter Cluster. Da die Knoten in einem nicht privaten Cluster externe IP-Adressen haben, werden Pakete, die von der primären internen IP-Adresse des Knotens gesendet werden, niemals von Cloud NAT verarbeitet. Pakete, die von Pods in einem nicht privaten Cluster gesendet werden, können jedoch in folgenden Fällen von einem Cloud NAT-Gateway verarbeitet werden:

  • Bei VPC-nativen Clustern ist das Cloud NAT-Gateway so konfiguriert, dass es auf den sekundären IP-Adressbereich für die Pods des Clusters und angewendet wird.
  • Die IP-Masquerade-Konfiguration des Clusters ist nicht so konfiguriert, dass SNAT innerhalb des Clusters für Pakete ausgeführt wird, die von Pods an das Internet gesendet werden.

Cloud Load Balancing-Interaktionen

Externe Google Cloud-Load-Balancer und Systemdiagnose-Systeme kommunizieren mit VMs über spezielle Routen. Back-End-VMs benötigen weder externe IP-Adressen noch verwaltet ein Cloud NAT-Gateway die Kommunikation für Load-Balancer und Systemdiagnosen. Weitere Informationen finden Sie unter Übersicht über Cloud Load Balancing und Übersicht über Systemdiagnosen.

Beispiele

Die folgenden Beispiele veranschaulichen Cloud NAT-Konzepte.

Grundlegende NAT-Konfiguration

Cloud NAT (zum Vergrößern klicken)
Cloud NAT (zum Vergrößern klicken)

In diesem Beispiel:

  • Das Gateway nat-gw-us-east ist für den primären IP-Adressbereich subnet-1 in der Region us-east1 konfiguriert. Eine VM, deren Netzwerkschnittstelle keine externe IP-Adresse hat, kann Traffic über ihre primäre interne IP-Adresse an das Internet senden oder über einen Alias-IP-Bereich aus dem primären IP-Adressbereich von subnet-1, 10.240.0.0/16.

  • Eine VM, deren Netzwerkschnittstelle keine externe IP-Adresse hat und deren primäre interne IP-Adresse sich in subnet-2 befindet, kann nicht auf das Internet zugreifen, da kein Cloud NAT-Gateway für einen IP-Adressbereich dieses Subnetzes gilt.

  • Das Gateway nat-gw-eu ist für den primären IP-Adressbereich subnet-3 in der Region europe-west1 konfiguriert. Eine VM, deren Netzwerkschnittstelle keine externe IP-Adresse hat, kann Traffic über ihre primäre interne IP-Adresse an das Internet senden oder über einen Alias-IP-Bereich aus dem primären IP-Adressbereich von subnet-3, 192.168.1.0/24.

GKE-Beispiel

Cloud NAT mit GKE (zum Vergrößern klicken)
Cloud NAT mit GKE (zum Vergrößern klicken)

Im obigen Beispiel sollen Ihre Container NAT-übersetzt werden. Um NAT für alle Container und den GKE-Knoten zu aktivieren, müssen Sie alle IP-Bereiche des Subnetzes 1 als NAT-Kandidaten auswählen. Es ist nicht möglich, NAT nur auf Container1 oder Container2 anzuwenden.

Weitere Informationen