Cloud NAT-Produktinteraktionen

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

Interaktionen mit Routen

Ein Gateway für Public NAT kann nur Routen verwenden, deren next Hop das Standard-Internetgateway ist. Jedes VPC-Netzwerk (Virtual Private Cloud) beginnt mit einer Standardroute, deren Ziel 0.0.0.0/0 und deren next Hop das Standard-Internetgateway ist. Wichtige Hintergrundinformationen finden Sie in der Routenübersicht.

Die folgenden Beispiele veranschaulichen Situationen, die möglicherweise dazu führen, dass diese Gateways nicht funktionieren: Public NAT

  • Wenn Sie eine statische Route mit next Hops erstellen, die auf den next Hop einer anderen benutzerdefinierten statischen Route gesetzt ist, werden Pakete mit Ziel-IP-Adressen, die mit dem Ziel der Route übereinstimmen, an den next Hop statt an das Standard-Internetgateway gesendet. Wenn Sie beispielsweise VM-Instanzen verwenden, auf denen NAT-Gateway-, Firewall- oder Proxysoftware ausgeführt wird, erstellen Sie statische Routen, um Traffic an diese VMs als next Hop weiterzuleiten. Die next-Hop-VMs erfordern externe IP-Adressen. Daher kann Traffic weder von den VMs, die auf den next-Hop-VMs basieren, noch von den next-Hop-VMs selbst über Gateways von Public NAT geleitet werden.

  • Wenn Sie eine benutzerdefinierte statische Route erstellen, deren next Hop ein Cloud VPN-Tunnel ist, verwendet Public NAT diese Route nicht. Beispiel: Eine statische Route mit dem Ziel 0.0.0.0/0 und einem Cloud VPN-Tunnel für den next Hop leitet Traffic an diesen Tunnel und nicht an das Standard-Internetgateway weiter. Daher können Gateways von Public NAT diese Route nicht verwenden. Ebenso können Gateways von Public 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 anbietet, der einen Cloud VPN-Tunnel oder einen VLAN-Anhang verwaltet, können Gateways von Public NAT diese Route nicht verwenden. Wenn Ihr lokaler Router beispielsweise eine dynamische Route mit dem Ziel 0.0.0.0/0 anbietet, wird 0.0.0.0/0 an den Cloud VPN-Tunnel oder den VLAN-Anhang weitergeleitet. Dieses Verhalten gilt auch für spezifischere Ziele wie 0.0.0.0/1 und 128.0.0.0/1.

Für Private NAT werden die folgenden Routen verwendet:

  • Für Network Connectivity Center-Spokes verwendet Private NAT Subnetzrouten und dynamische Routen:
    • Für Traffic zwischen zwei VPC-Spokes, die an einen Network Connectivity Center-Hub angehängt sind, der nur VPC-Spokes enthält, verwendet Private NAT die Subnetzrouten, die von den angehängten VPC-Spokes ausgetauscht werden. Informationen zu VPC-Spokes finden Sie unter VPC-Spokes – Übersicht.
    • 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 von den Hybrid-Spokes über BGP gelernt wurden, sowie die Subnetzrouten, die von den angehängten VPC-Spokes ausgetauscht werden. Informationen zu Hybrid-Spokes finden Sie unter Hybrid-Spokes.
  • Für Hybrid NAT werden bei Private NAT dynamische Routen verwendet, die von Cloud Router über Cloud Interconnect oder Cloud VPN gelernt wurden.

Interaktionen mit privatem Google-Zugriff

Ein Gateway für Public NAT 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 aktiviertGoogle Cloud automatisch den privaten Google-Zugriff für einen Subnetz-IP-Adressbereich, wenn Sie ein Gateway für Public NAT 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 Gateway für Public NAT ä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 gemeinsam genutzten VPCs

Mit einer gemeinsam genutzten 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 gemeinsam genutztes 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 Gateway für Public NAT kann NAT für Knoten und Pods in einem privaten Cluster ausführen, der eine Art VPC-nativer Cluster ist. Das Gateway Public NAT 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 Gateway für Public NAT , das auf alle Subnetz-IP-Adressbereiche des Subnetzes 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 Gateway für Public NAT 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.

In VPC-nativen Clustern der Google Kubernetes Engine (GKE) wird jedem Knoten immer ein Alias-IP-Bereich zugewiesen, 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 an Ports pro VM anfangs pro Knoten zugewiesen. Die Anzahl der zugewiesenen Ports variiert dann 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 von Public NAT führt die Google Kubernetes Engine eine Quellnetzwerkadressübersetzung (Source Network Address Translation, 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-Masquerading-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. Wenn jedoch beide der folgenden Bedingungen zutreffen, können Pakete, die von Pods in einem nicht privaten Cluster gesendet werden, von einem Gateway für Public NAT verarbeitet werden:

  • Bei VPC-nativen Clustern ist das Gateway für Public NAT 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 von Public NAT mit GKE:

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

In diesem Beispiel lassen Sie die Container mit NAT übersetzen. 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 nicht nur für Pod1 oder Pod2 aktiviert werden.

Ein Private NAT-Gateway kann NAT für Knoten und Pods in einem privaten Cluster und in einem nicht privaten Cluster ausführen. Das Private NAT-Gateway wird automatisch auf alle Subnetz-IP-Adressbereiche für das private Subnetz angewendet, das von Ihrem Cluster verwendet wird.

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. Damit Cloud Run ein Cloud NAT-Gateway für Public NAT oder Private NAT verwenden kann, müssen Sie Folgendes konfigurieren:

  • Legen Sie beim Bereitstellen Ihrer Cloud Run-Ressourcen das Flag --vpc-egress fest. 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 mit dem Flag --nat-custom-subnet-ip-ranges an, welche Quellsubnetzbereiche das Gateway verwenden können. Legen Sie den Wert auf die Namen der Subnetze 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 Public NAT darauf, dass der Wert des Flags --min-ports-per-vm 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 benötigt werden.

    • Wenn Sie die manuelle Zuweisung von NAT-IP-Adressen konfigurieren möchten (nur Public 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 ausgehenden Direct VPC-Traffic werden nicht die Namen von Cloud Run-Ressourcen angezeigt.

Interaktionen mit Konnektivitätstests

Mit Konnektivitätstests können Sie die Konnektivität zwischen Netzwerkendpunkten prüfen, für die Cloud NAT-Konfigurationen verwendet werden. Sie können Konnektivitätstests für Netzwerke ausführen, die entweder Public NAT-Gateways oder Private NAT-Gateways oder beides verwenden.

Die NAT-Konfigurationsdetails finden Sie im Bereich Trace für die Konfigurationsanalyse auf der Seite Details des Konnektivitätstests.

Interaktionen mit Cloud Load Balancing

Regionale interne Application Load Balancer und regionale externe Application Load Balancer vonGoogle Cloud kommunizieren mit mehreren regionalen Internet-NEG-Backends (Netzwerk-Endpunktgruppe). Wenn Sie Cloud NAT-Gateways für die regionalen Internet-NEGs konfigurieren, können Sie Ihre eigenen externen IP-Adressbereiche zuweisen, von denen der Traffic von Google Cloud stammen soll. Die Systemdiagnosen und der Datenebenen-Traffic stammen von den NAT-IP-Adressen, die Sie zuweisen.

Andere externe Load Balancer und Systemdiagnosesysteme von Google Cloud 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 weitergegebenen Private Service Connect-Verbindungen

Wenn Sie sowohl Private NAT für Network Connectivity Center als auch weitergegebene 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 verworfen.

  • Damit kein Traffic von sich nicht überschneidenden Subnetzen verloren geht, sollten Sie bei der Konfiguration von Private NAT Folgendes beachten:

    • Geben Sie sich überschneidende Subnetze mit dem Flag --nat-custom-subnet-ip-ranges an.
    • Geben Sie keine sich nicht überschneidenden Subnetze an, die auf weitergegebene Verbindungen zugreifen müssen.
    • Verwenden Sie nicht das Flag --nat-all-subnet-ip-ranges.

Nächste Schritte