Cloud NAT – Überblick

Mit Cloud NAT (Netzwerkadressübersetzung) können bestimmte Ressourcen ohne externe IP-Adressen ausgehende Verbindungen zum Internet herstellen.

Cloud NAT bietet ausgehende Verbindungen für die folgenden Ressourcen:

Architektur

Cloud NAT ist ein verteilter, softwarebasierter verwalteter Dienst. Cloud NAT basiert nicht auf Proxy-VMs oder -Appliances. Cloud NAT konfiguriert die Andromeda-Software, die Ihr VPC-Netzwerk (Virtual Private Cloud) unterstützt, um SNAT (Source Network Address Translation) oder NAT (Network Address Translation) für VMs ohne externe IP-Adressen zu ermöglichen. Cloud NAT bietet auch Destination Network Address Translation (Ziel-NAT oder DNAT) für etablierte eingehende Antwortpakete.

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

Cloud NAT implementiert ausgehende NAT in Verbindung mit statischen Routen in Ihrem VPC-Netzwerk, dessen nächster Hop das Standard-Internetgatewayist. 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 eingehen.

Vorteile

Cloud NAT bietet folgende Vorteile:

  • Sicherheit

    Sie können die Notwendigkeit der Zuweisung einzelner IP-Adressen für einzelne VMs reduzieren. Je nach Firewallregeln für ausgehenden Traffic können VMs ohne externe IP-Adressen auf Ziele im Internet zugreifen. Möglicherweise haben Sie VMs, die nur Internetzugriff benötigen, um Updates herunterzuladen oder die Bereitstellung abzuschließen.

    Wenn Sie zur Konfiguration eines Cloud NAT-Gateways die manuelle NAT-IP-Adresszuweisung verwenden, können Sie eine Reihe häufig verwendeter externer Quell-IP-Adressen für eine Zielpartei freigeben. Ein Zieldienst lässt beispielsweise nur Verbindungen von bekannten externen IP-Adressen zu.

  • Verfügbarkeit

    Cloud NAT ist ein verteilter, softwarebasierter verwalteter Dienst, der nicht von VMs in Ihrem Projekt oder einem einzelnen physischen Gateway-Gerät abhängt. Sie konfigurieren ein NAT-Gateway auf einem Cloud Router, der die Steuerungsebene für NAT mit 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 die Anzahl der verwendeten NAT-IP-Adressen automatisch 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 wird vom softwarebasierten Netzwerk Andromeda von Google implementiert. Weitere Informationen finden Sie in der Dokumentation zu Compute Engine unter Netzwerkbandbreite.

Spezifikationen

Cloud NAT kann so konfiguriert werden, dass dem Internet NAT für Pakete bereitgestellt wird, die gesendet werden über:

  • Die primäre interne IP-Adresse der Compute Engine VM-Schnittstelle, sofern der Netzwerkschnittstelle keine externe IP-Adresse zugewiesen ist. Wenn der Netzwerkschnittstelle eine externe IP-Adresse zugewiesen ist, führt Google Cloud automatisch eine 1:1-NAT für Pakete aus, deren Quellen mit der primären internen IP-Adresse der Schnittstelle übereinstimmen, da die Netzwerkschnittstelle die Anforderungen für den Internetzugriff von Google Cloud 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 konfigurieren, um NAT für Pakete bereitzustellen, deren Quellen aus 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.

  • Bei GKE-Clustern kann Cloud NAT auch dann Dienste bereitstellen, wenn der Cluster unter bestimmten Umständen externe IP-Adressen hat. Weitere Informationen finden Sie unter GKE-Interaktion.

Cloud NAT ermöglicht ausgehende Verbindungen und die eingehenden Antworten auf diese Verbindungen. Jedes Cloud NAT-Gateway führt Quell-NAT bei ausgehendem Traffic und Ziel-NAT für etablierte Antwortpakete aus.

Cloud NAT erlaubt keine unerwünschten eingehenden Anfragen aus dem Internet, auch wenn Firewallregeln diese Anfragen andernfalls zulassen würden. Weitere Informationen finden Sie unter Anwendbare RFCs.

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. Sie sind nicht an der Datenebene beteiligt, sodass Pakete nicht über das Cloud NAT-Gateway oder den Cloud Router geleitet werden.

Routen und Firewallregeln

Cloud NAT basiert auf benutzerdefinierten statischen Routen, deren nächster Hop das Standard-Internetgateway ist. Damit Sie ein Cloud NAT-Gateway vollständig nutzen können, benötigt Ihr VPC-Netzwerk eine Standardroute, deren nächster Hop das Standard-Internetgateway ist. Weitere Informationen finden Sie unter Interaktionen mit Routen.

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

Sie müssen keine spezifischen 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 für diese Netzwerkschnittstelle vor der Ausführung von 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 Compute Engine-VM gesendet werden, sofern der Netzwerkschnittstelle keine externe IP-Adresse zugewiesen ist. Bei GKE-Clustern kann Cloud NAT auch dann Dienste bereitstellen, wenn die Clusterknoten unter bestimmten Umständen externe IP-Adressen haben. Weitere Informationen finden Sie unter GKE-Interaktion.

Das Cloud NAT-Gateway kann so konfiguriert werden, dass es NAT für die primäre interne IP-Adresse der VM-Netzwerkschnittstelle, Alias-IP-Bereiche oder beides bereitstellt. Für diese Konfiguration wählen Sie die Subnetz-IP-Adressbereiche aus, für die das Gateway gelten soll.

Sie können ein Cloud NAT-Gateway konfigurieren, um NAT für Folgendes bereitzustellen:

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

  • Primäre IP-Adressbereiche 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 zulässigen 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 der zulässigen VMs bereitzustellen.

  • Benutzerdefinierte IP-Adressbereiche des Subnetzes: Sie können unter Cloud NAT-Kontingente und -Limits so viele Cloud NAT-Gateways wie erforderlich erstellen. Sie entscheiden, welche primären oder sekundären IP-Adressbereiche von jedem Gateway bereitgestellt werden sollen.

Bandbreite

Die Verwendung eines Cloud NAT-Gateways wirkt sich nicht auf die Größe der von einer VM verwendeten ausgehenden oder eingehenden Bandbreite aus. Informationen zu Bandbreitenspezifikationen, die je nach Maschinentyp variieren, finden Sie unter Netzwerkbandbreite in der Compute Engine-Dokumentation.

VMs mit mehreren Netzwerkschnittstellen

Wenn Sie eine VM mit mehreren Netzwerkschnittstellen konfigurieren, muss sich jede Schnittstelle in einem separaten VPC-Netzwerk befinden. Daher gilt Folgendes:

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

  • Wenn eine der Schnittstellen einer VM mit mehreren Netzwerkschnittstellen eine externe IP-Adresse hat, kommt sie für Cloud NAT nicht infrage. Eine der anderen Schnittstellen kann jedoch für NAT infrage kommen, wenn sie keine externe IP-Adresse hat und ein Cloud NAT-Gateway für den entsprechenden Subnetz-IP-Adressbereich konfiguriert wurde.

NAT-IP-Adressen und Ports

Wenn Sie ein Cloud NAT-Gateway erstellen, können Sie festlegen, dass das Gateway automatisch regionale externe IP-Adressen zuweist. Alternativ können Sie dem Gateway manuell eine feste Anzahl regionaler externer 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 NAT-Dienste bereitgestellt werden sollen. Sie können die statische Portzuweisung konfigurieren, wobei für jede VM dieselbe Anzahl von Ports reserviert ist, oder für die dynamische Portzuweisung, wobei die Anzahl der reservierten Ports zwischen dem von Ihnen angegebenen Mindest- und Höchstwert variieren kann.

Die VMs, für die NAT bereitgestellt werden soll, richten sich nach den Subnetz-IP-Adressbereichen, für deren Bereitstellung das Gateway konfiguriert ist.

Weitere Informationen finden Sie unter Ports und im Verfahren zur Portreservierung.

Anwendbare RFCs

Cloud NAT unterstützt die endpunktunabhängige Zuordnung und die endpunktabhängige Filterung, wie in RFC 5128 definiert. Sie können die endpunktunabhängige Zuordnung aktivieren oder deaktivieren. Standardmäßig ist die endpunktunabhängige Zuordnung deaktiviert, wenn Sie ein NAT-Gateway erstellen.

Endpunktunabhängige Zuordnung bedeutet Folgendes: Wenn eine VM Pakete über ein bestimmtes Paar aus interner IP-Adresse und Port an verschiedene Ziele sendet, ordnet das Gateway alle diese Pakete demselben Paar aus NAT-IP-Adresse und Port zu, unabhängig vom Ziel der Pakete. Weitere Informationen und Auswirkungen auf die endpunktunabhängige Zuordnung finden Sie unter Gleichzeitige Portwiederverwendung und endpunktunabhängige Zuordnung.

Endpunktabhängige Filterung bedeutet, dass Antwortpakete aus dem Internet nur dann eingehen dürfen, wenn sie von einer IP-Adresse und einem Port stammen, an die eine VM bereits Pakete gesendet hat. Die Filterung ist endpunktabhängig, unabhängig vom Typ der Endpunktzuordnung. Dieses Feature ist immer aktiviert und kann vom Nutzer nicht konfiguriert werden.

Weitere Informationen zur Beziehung zwischen Ports und Verbindungen finden Sie unter Ports und Verbindungen sowie im Beispiel für NAT-Ablauf.

Cloud NAT ist eine Port-eingeschränkte Cone-NAT, wie in RFC 3489 definiert.

NAT-Durchlauf

Wenn die endpunktunabhängige Zuordnung aktiviert 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, wenn ein Kommunikationskanal eingerichtet wurde.
  • TURN (Traversal Using Relays around NAT, RFC 5766) ermöglicht die Kommunikation zwischen VMs hinter NAT über einen Drittanbieter-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, verbraucht jedoch mehr Bandbreite und Ressourcen.

NAT-Zeitlimits

Cloud NAT-Gateways verwenden die folgenden Zeitlimits. Sie können die Standardwerte für die Zeitüberschreitung ändern, um die Wiederverwendung von Ports zu verringern oder zu erhöhen. Jeder Zeitlimitwert ist ein Ausgleich zwischen einer effizienten Nutzung von Cloud NAT-Ressourcen und einer möglichen Unterbrechung aktiver Verbindungen, Abläufe oder Sitzungen.

Zeitlimit Beschreibung Cloud NAT-Standardeinstellung Konfigurierbar

Zeitlimit bei Inaktivität für UDP-Zuordnung

RFC 4787 REQ-5

Gibt die Zeit in Sekunden an, nach der UDP-Datenflüsse nicht mehr an Endpunkte gesendet werden müssen, damit die Cloud NAT-Zuordnungen entfernt werden.

Das Zeitlimit bei Inaktivität für UDP-Zuordnung betrifft zwei Endpunkte, die keinen Traffic mehr aneinander senden. Es wirkt sich auch auf Endpunkte aus, die langsamer reagieren oder wenn eine höhere Netzwerklatenz besteht.

Sie können den angegebenen Zeitlimitwert erhöhen, um die Wiederverwendung von Ports zu verringern. Ein höherer Zeitlimitwert bedeutet, dass die Ports für längere Verbindungen beibehalten werden und schützt vor Pausen im Traffic über einen bestimmten UDP-Socket.

30 Sekunden Ja

Zeitlimit bei Inaktivität für hergestellte TCP-Verbindung

RFC 5382 REQ-5

Gibt die Dauer in Sekunden an, für die eine Verbindung inaktiv ist, bevor die Cloud NAT-Zuordnungen entfernt werden.

Das Zeitlimit bei Inaktivität für hergestellte TCP-Verbindungen wirkt sich auf Endpunkte aus, die langsamer reagieren, oder wenn die Netzwerklatenz zunimmt.

Sie können den Zeitlimitwert erhöhen, wenn Sie TCP-Verbindungen öffnen und die Verbindungen lange Zeit ohne Keepalive-Mechanismus offen halten möchten.

1.200 Sekunden (20 Minuten) Ja

Zeitlimit bei Inaktivität für vorübergehende TCP-Verbindung

RFC 5382 REQ-5

Gibt die Zeit in Sekunden an, die TCP-Verbindungen im halboffenen Zustand verbleiben können, bevor die Cloud NAT-Zuordnungen gelöscht werden können.

Das Zeitlimit bei Inaktivität für vorübergehende TCP-Verbindungen wirkt sich auf einen Endpunkt aus, wenn ein externer Endpunkt länger als die angegebene Zeit braucht oder wenn eine höhere Netzwerklatenz besteht. Im Gegensatz zum Zeitlimit bei Inaktivität für hergestellte TCP-Verbindungen wirkt sich das Zeitlimit bei Inaktivität für vorübergehende TCP-Verbindungen nur auf halboffene Verbindungen aus.

30 Sekunden

Hinweis: Unabhängig von dem Wert, den Sie für dieses Zeitlimit festgelegt haben, benötigt Cloud NAT möglicherweise weitere 30 Sekunden, bevor ein Tupel aus Cloud NAT-Quell-IP-Adresse und Quellport zur Verarbeitung einer neuen Verbindung verwendet werden kann.

 Ja

Zeitlimit für TCP-TIME_WAIT

RFC 5382 REQ-5

Gibt die Zeit in Sekunden an, in der eine vollständig geschlossene TCP-Verbindung nach Ablauf der Verbindung in den Cloud NAT-Zuordnungen beibehalten wird.

Das Zeitlimit für TCP-TIME_WAIT schützt Ihre internen Endpunkte vor ungültigen Paketen, die zu einer geschlossenen TCP-Verbindung gehören, die noch einmal gesendet werden.

Sie können den Zeitlimitwert verringern, um die Wiederverwendung von Cloud NAT-Ports zu verbessern, riskieren damit allerdings, noch einmal übertragene Pakete von einer nicht damit zusammenhängenden, zuvor geschlossenen Verbindung zu erhalten.

120 Sekunden

Hinweis: Unabhängig von dem Wert, den Sie für dieses Zeitlimit festgelegt haben, benötigt Cloud NAT möglicherweise weitere 30 Sekunden, bevor ein Tupel aus Cloud NAT-Quell-IP-Adresse und Quellport zur Verarbeitung einer neuen Verbindung verwendet werden kann.

 Ja

Zeitlimit bei Inaktivität für ICMP-Zuordnung

RFC 5508 REQ-2

Gibt die Zeit in Sekunden an, nach der Cloud NAT-Zuordnungen vom Internet Control Message Protocol (ICMP) ohne Trafficflüsse geschlossen werden.

Das Zeitlimit bei Inaktivität für ICMP-Zuordnung wirkt sich auf einen Endpunkt aus, wenn der Endpunkt länger braucht, um zu reagieren als die angegebene Zeit oder wenn eine höhere Netzwerklatenz besteht.

30 Sekunden Ja

Produktinteraktionen

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

Interaktionen mit Routen

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

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

  • Wenn Sie eine benutzerdefinierte statische Route mit nächsten Hops erstellen, die auf den nächsten Hop einer beliebigen anderen benutzerdefinierten statischen Route gesetzt ist, werden Pakete mit Ziel-IP-Adressen, die mit dem Ziel der Route übereinstimmen, an den nächsten Hop statt an das Standard-Internetgateway gesendet. Wenn Sie beispielsweise VM-Instanzen verwenden, auf denen NAT-, Firewall- oder Proxysoftware ausgeführt wird, müssen Sie benutzerdefinierte statische Routen erstellen, um Traffic an diese VMs als nächsten Hop weiterzuleiten. Die VMs des nächsten Hops erfordern externe IP-Adressen. Daher kann Traffic weder von den VMs, die auf den VMs des nächsten Hops basieren, noch von den 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. Beispiel: Eine benutzerdefinierte statische Route mit dem Ziel 0.0.0.0/0 und einem Cloud VPN-Tunnel für den nächsten Hop leitet Traffic an diesen Tunnel und nicht an das Standard-Internetgateway 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 eine benutzerdefinierte dynamische Route für einen Cloud Router bewirbt, der einen Cloud VPN-Tunnel oder einen Cloud Interconnect-Anhang (VLAN) verwaltet, 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 bewirbt, 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.

Interaktion mit privatem Google-Zugriff

Cloud NAT führt NAT nicht 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 konfigurieren, um es auf diesen Subnetzbereich anzuwenden, entweder primär oder sekundär. Solange das Gateway NAT für den Bereich eines Subnetzes bereitstellt, ist der private Google-Zugriff für diesen Bereich gültig und kann nicht manuell deaktiviert werden.

Ein Cloud NAT-Gateway ändert nicht die Funktionsweise des privaten Google-Zugriffs. Weitere Informationen finden Sie unter Privater Google-Zugriff.

Interaktion mit freigegebener VPC

Mit einer freigegebenen VPC können mehrere Dienstprojekte in einer einzelnen Organisation ein gemeinsames VPC-Netzwerk in einem Hostprojekt nutzen. Sie müssen Cloud NAT-Gateways im Hostprojekt erstellen, um NAT für VMs in Dienstprojekten bereitzustellen, die ein freigegebenes VPC-Netzwerk verwenden.

Interaktion mit VPC-Netzwerk-Peering

Cloud NAT-Gateways sind Subnetz-IP-Adressbereichen in einer einzelnen Region und einem einzelnen VPC-Netzwerk zugeordnet. In einem VPC-Netzwerk erstellte Cloud NAT-Gateways können NAT nicht für VMs in anderen VPC-Netzwerken bereitstellen, die über VPC-Netzwerk-Peering verbunden sind, selbst wenn sich die VMs in Peering-Netzwerken in derselben Region wie das Gateway befinden.

Interaktion mit GKE

Ein Cloud NAT-Gateway kann NAT für Knoten und Pods in einem privaten Cluster ausführen, der eine Art VPC-nativer Cluster ist. Das Cloud NAT-Gateway muss so konfiguriert sein, dass es auf mindestens die folgenden Subnetz-IP-Adressbereiche für das Subnetz angewendet wird, das Ihr Cluster verwendet:

  • 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 zur Verwendung von IP-Adressbereichen für VPC-native Cluster finden Sie unter IP-Bereiche für VPC-native Cluster.

Wenn ein Cloud NAT-Gateway zur Bereitstellung von NAT für einen privaten Cluster konfiguriert ist, reserviert es NAT-Quell-IP-Adressen und Quellports für jede Knoten-VM. Diese NAT-Quell-IP-Adressen und Quellports können von Pods verwendet werden, da Pod-IP-Adressen als Alias-IP-Bereiche implementiert werden, die jeder Knoten-VM zugewiesen sind.

VPC-native Cluster von GKE weisen jedem Knoten immer einen Alias-IP-Bereich mit mehr als einer IP-Adresse zu (Netzmaske kleiner als /32).

  • Wenn die statische Portzuweisung konfiguriert ist, reserviert das Portreservierungsverfahren von Cloud NAT mindestens 1.024 Quellports pro Knoten. Wenn der angegebene Wert für die Mindestanzahl von Ports pro VM größer als 1.024 ist, wird dieser Wert verwendet.

  • Wenn die dynamische Portzuweisung konfiguriert ist, wird der angegebene Wert für die Mindestanzahl von Ports pro VM anfangs pro Knoten zugewiesen. Die Anzahl der zugewiesenen Ports variiert danach je nach Bedarf zwischen den angegebenen Werten für minimale und maximale Ports pro VM.

Informationen zu Pod-IP-Adressbereichen 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 des Clusters geändert. Wenn Sie den ausgehenden Traffic von Pods genauer steuern möchten, verwenden Sie eine Netzwerkrichtlinie.

Unter bestimmten Umständen kann Cloud NAT auch für nicht private VPC-native Cluster verwendet werden. 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, nie von Cloud NAT verarbeitet. Pakete, die von Pods in einem nicht privaten Cluster gesendet werden, können jedoch von einem Cloud NAT-Gateway verarbeitet werden, wenn die beiden folgenden Bedingungen zutreffen:

  • 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 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.

Interaktionen mit Cloud Load Balancing

Externe Load-Balancer und Systemdiagnosesysteme von Google Cloud kommunizieren mithilfe von speziellen Routen mit VMs. Back-End-VMs benötigen keine externen IP-Adressen und ein Cloud NAT-Gateway verwaltet nicht die Kommunikation für Load-Balancer und Systemdiagnosen. Weitere Informationen finden Sie unter 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 so konfiguriert, dass es auf den primären IP-Adressbereich von subnet-1 in der Region us-east1 angewendet wird. Eine VM, deren Netzwerkschnittstelle keine externe IP-Adresse hat, kann Traffic über die primäre interne IP-Adresse oder einen Alias-IP-Bereich aus dem primären IP-Adressbereich von subnet-1, 10.240.0.0/16, an das Internet senden.

  • 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 auf einen IP-Adressbereich dieses Subnetzes angewendet wird.

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

GKE-Beispiel

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

In diesem Beispiel übersetzen Sie die Container mit NAT. Um NAT für alle Container und den GKE-Knoten zu aktivieren, müssen Sie alle IP-Adressbereiche von Subnetz 1 als NAT-Kandidaten auswählen. NAT kann nur für container1 oder container2 aktiviert werden.

Nächste Schritte