Cloud NAT-Produktinteraktionen

Auf dieser Seite werden die wichtigen Interaktionen zwischen Cloud NAT und anderen Google Cloud Produkten beschrieben.

Interaktionen mit Routen

Ein Public NAT- Gateway kann nur Routen verwenden, deren nächster Hop das Standard-Internetgateway ist. Jedes VPC-Netzwerk (Virtual Private Cloud) 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, dassPublic NAT-Gateways nicht funktionieren:

• Wenn Sie eine statische Route mit nächsten Hops erstellen, die auf den nächsten Hop einer beliebigen anderen 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 ein NAT-Gateway, eine Firewall oder Proxysoftware ausgeführt wird, erstellen Sie statische Routen, um Traffic an diese VMs als nächsten Hop weiterzuleiten. Die VMs des nächsten Hops erfordern externe IP-Adressen. Daher können weder Traffic von den VMs, die auf den VMs des nächsten Hops basieren, noch von den VMs des nächsten Hops selbstPublic NAT-Gateways verwenden.

• Wenn Sie eine benutzerdefinierte statische Route erstellen, deren nächster Hop ein Cloud VPN-Tunnel ist, verwendetPublic NATdiese Route nicht. Beispiel: Eine 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 Public NAT- Gateways diese Route nicht verwenden. Ebenso können--Gateways mit Public NAT und Cloud NAT keine statischen Routen mit spezifischeren Zielen verwenden, einschließlich 0.0.0.0/1 und 128.0.0.0/1.

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

Private NAT verwendet die folgenden Routen:

• Für Network Connectivity Center-Spokes verwendet Private NAT Subnetzrouten und dynamische Routen:
  • Für Traffic zwischen zwei VPC-Spokes, die mit einem Network Connectivity Center-Hub verbunden sind, der nur VPC-Spokes enthält, verwendet Private NAT die Subnetzrouten, die von den verbundenen VPC-Spokes ausgetauscht werden. Informationen zu VPC-Spokes finden Sie unter VPC-Spokes.
  • Wenn ein Network Connectivity Center-Hub sowohl VPC-Spokes als auch Hybrid-Spokes wie VLAN-Anhänge für Cloud Interconnect, Cloud VPN-Tunnel oder Router-Appliance-VMs enthält, verwendet Private NAT die dynamischen Routen, die die Hybrid-Spokes über BGP gelernt haben, und die Subnetz-Routen, die von den verbundenen VPC-Spokes ausgetauscht werden. Informationen zu Hybrid-Spokes finden Sie unter Hybrid-Spokes.
• Bei Hybrid-NAT verwendet Private NAT dynamische Routen, die von Cloud Router über Cloud Interconnect oder Cloud VPN erlernt wurden.

Interaktionen mit privatem Google-Zugriff

EinPublic NAT-Gateway führt niemals NAT für Traffic aus, der an die ausgewählten externen IP-Adressen für Google APIs und Google-Dienste gesendet wird. Stattdessen wird der private Google-ZugriffGoogle Cloud automatisch für einen Subnetz-IP-Adressbereich aktiviert, wenn Sie einPublic 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 öffentliches NAT- Gateway ändert nicht die Funktionsweise des privaten Google-Zugriffs. Weitere Informationen finden Sie unter Privater Google-Zugriff.

Private NAT-Gateways gelten nicht für den privaten Google-Zugriff.

Interaktionen mit freigegebenen VPCs

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.

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

GKE-Interaktionen

Ein Public NAT- Gateway kann NAT für Knoten und Pods in einem privaten Cluster ausführen, der eine Art VPC-nativer Cluster ist. Das öffentliche 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 einesPublic 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 öffentliches 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.

Native GKE VPC-Cluster weisen jedem Knoten immer einen Alias-IP-Bereich zu, der mehr als eine IP-Adresse enthält (Netzmaske kleiner als /32).

• Wenn die statische Portzuweisung konfiguriert ist, reserviert das Portreservierungsverfahren von Public 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 anfänglich pro Knoten zugewiesen. Die Anzahl der zugewiesenen Ports variiert je nach Bedarf zwischen den angegebenen Werten für die Mindest- und Höchstzahl von 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 vonPublic NATführt die Google Kubernetes Engine eine Quellnetzwerkadressübersetzung (Source NAT oder SNAT) mithilfe von 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 Public NAT auch für nicht private VPC-native Cluster nützlich sein. 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 einemPublic NAT-Gateway verarbeitet werden, wenn die beiden folgenden Bedingungen zutreffen:

• Bei VPC-nativen Clustern ist das Public 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.

Das folgende Beispiel zeigt die Interaktion vonPublic NATmit GKE:

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 Subnet 1 als NAT-Kandidaten auswählen:

• Primärer IP-Adressbereich des Subnetzes: 10.240.0.0/24
• Sekundärer IP-Adressbereich des Subnetzes, der für Pods verwendet wird: 10.0.0.0/16

NAT kann nur für Pod1 oder Pod2 aktiviert werden.

Ein privates NAT-Gateway kann NAT für Knoten und Pods in einem privaten und in einem nicht privaten Cluster ausführen. Das private NAT-Gateway wird automatisch auf alle IP-Adressbereiche des Subnetzwerks angewendet, das Ihr Cluster verwendet.

Interaktionen mit ausgehendem Direct VPC-Traffic

Cloud NAT-Gateways können NAT für Cloud Run-Ressourcen bereitstellen, die mit ausgehendem Direct VPC-Traffic konfiguriert sind. Wenn Sie Cloud Run ein Cloud NAT-Gateway für öffentliches NAT oder privates NAT verwenden lassen möchten, konfigurieren Sie Folgendes:

• Legen Sie das Flag --vpc-egress fest, wenn Sie Ihre Cloud Run-Ressourcen bereitstellen. Wenn Sie Public NAT verwenden möchten, muss der Wert auf all-traffic festgelegt sein.

• Konfigurieren Sie das Cloud NAT-Gateway mit den folgenden Einstellungen:

  • Geben Sie an, welche Quellsubnetzbereiche das Gateway verwenden können, indem Sie das Flag --nat-custom-subnet-ip-ranges festlegen. Legen Sie den Wert auf die Subnetznamen fest, in denen Sie Ihre Cloud Run-Ressourcen bereitstellen.
  • Legen Sie den Wert des Flags --endpoint-types auf ENDPOINT_TYPE_VM fest.

  • Achten Sie bei öffentlicher NAT darauf, dass der Wert des --min-ports-per-vm-Flags auf das Doppelte der Anzahl der Ports festgelegt ist, die für eine einzelne Cloud Run-Instanz erforderlich sind. Bei Private NAT muss dieses Flag auf das Vierfache der Anzahl der Ports festgelegt werden, die pro Cloud Run-Instanz erforderlich sind.

  • Wenn Sie die manuelle Zuweisung von NAT-IP-Adressen konfigurieren möchten (nur öffentliches NAT), weisen Sie Ihrem Gateway eine Anzahl von IP-Adressen zu, die für die Summe der VM-Instanzen und Cloud Run-Instanzen ausreicht, die vom Gateway bereitgestellt werden.

In Cloud NAT-Logs für die direkte Weiterleitung von ausgehendem Traffic an VPC werden keine Namen von Cloud Run-Ressourcen angezeigt.

Interaktionen bei Konnektivitätstests

Mit Konnektivitätstests können Sie die Konnektivität zwischen Netzwerkendpunkten prüfen, die Cloud NAT-Konfigurationen verwenden. Sie können Konnektivitätstests in Netzwerken ausführen, die entweder öffentliche NAT-Gateways oder private NAT-Gateways oder beide verwenden.

Die Details zur NAT-Konfiguration finden Sie auf der Seite Details des Konnektivitätstests im Bereich Trace der Konfigurationsanalyse.

Interaktionen mit Cloud Load Balancing

Google Cloud Regionale interne Application Load Balancer und regionale externe Application Load Balancer kommunizieren mit mehreren regionalen NEG-Back-Ends (Internet Network Endpoint Group). Wenn Sie Cloud NAT-Gateways für die regionalen Internet-NEGs konfigurieren, können Sie Ihre eigenen externen IP-Adressbereiche zuweisen, von denen der Google Cloud Traffic stammen sollte. Die Systemdiagnosen und der Datenebenen-Traffic stammen von den von Ihnen zugewiesenen NAT-IP-Adressen.

Andere Google Cloud externe Load Balancer und Systemdiagnosesysteme kommunizieren mithilfe von speziellen Routingpfaden 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 Systemdiagnosen – Übersicht.

Interaktionen mit weitergeleiteten Private Service Connect-Verbindungen

Wenn Sie sowohl Private NAT für Network Connectivity Center als auch weitergeleitete Private Service Connect-Verbindungen im selben VPC-Spoke verwenden, gilt Folgendes:

• Wenn ein Subnetz mit Private NAT konfiguriert ist, wird Traffic vom Subnetz zu weitergegebenen Private Service Connect-Verbindungen abgelehnt.

• Beachten Sie Folgendes, wenn Sie Private NAT konfigurieren, um Traffic von nicht überlappenden Subnetzen zu vermeiden:

  • Verwenden Sie das Flag --nat-custom-subnet-ip-ranges, um sich überschneidende Subnetze anzugeben.
  • Geben Sie keine nicht überlappenden Subnetze an, die auf propagierte Verbindungen zugreifen müssen.
  • Verwende nicht das Flag --nat-all-subnet-ip-ranges.

Nächste Schritte

• Weitere Informationen zu Cloud NAT-Adressen und -Ports
• Richten Sie ein öffentliches NAT-Gateway ein.
• Konfigurieren Sie Cloud NAT-Regeln.
• Richten Sie ein Private NAT-Gateway ein.