Cloud NAT-Produktinteraktionen

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

Interaktionen mit Routen

Ein öffentliches 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, in denen öffentliche NAT-Gateways möglicherweise nicht mehr funktionieren:

  • Wenn Sie eine benutzerdefinierte statische Route erstellen, bei der die nächsten Hops auf einen beliebigen nächsten Hop der benutzerdefinierten statischen Route festgelegt sind, werden Pakete mit Ziel-IP-Adressen, die mit dem Ziel der Route übereinstimmen, an diesen nächsten Hop und nicht an das Standard-Internetgateway gesendet. Wenn Sie beispielsweise VM-Instanzen verwenden, auf denen ein NAT-Gateway, eine Firewall oder eine Proxy-Software ausgeführt wird, erstellen Sie benutzerdefinierte statische Routen, um den Traffic als nächsten Hop an diese VMs zu leiten. Die VMs des nächsten Hops erfordern externe IP-Adressen. Daher kann Traffic von den VMs, die auf den VMs des nächsten Hops basieren, oder von den VMs des nächsten Hops selbst keine öffentlichen NAT-Gateways verwenden.

  • Wenn Sie eine benutzerdefinierte statische Route erstellen, deren nächster Hop ein Cloud VPN-Tunnel ist, verwendet die öffentliche 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 öffentliche NAT-Gateways diese Route nicht verwenden. Ebenso können öffentliche NAT-Gateways keine benutzerdefinierten statischen Routen mit spezifischeren Zielen wie 0.0.0.0/1 und 128.0.0.0/1 verwenden.

  • Wenn ein lokaler Router eine benutzerdefinierte dynamische Route für einen Cloud Router anbietet, der einen Cloud VPN-Tunnel oder einen VLAN-Anhang verwaltet, können öffentliche 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 VLAN-Anhang weitergeleitet. Dieses Verhalten 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 Inter-VPC-NAT verwendet private NAT nur Subnetzrouten, die von zwei VPC-Spokes des Network Connectivity Center ausgetauscht werden, die an einen Network Connectivity Center-Hub angehängt sind. Weitere Informationen zu VPC-Spokes in Network Connectivity Center finden Sie unter VPC-Spokes – Übersicht.
  • Für Hybrid-NAT (Vorabversion) verwendet private NAT die von Cloud Router über Cloud VPN erlernten dynamischen Routen.

Interaktion mit privatem Google-Zugriff

Ein öffentliches NAT-Gateway 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 privater Google-Zugriff für einen Subnetz-IP-Adressbereich, wenn Sie ein öffentliches NAT-Gateway so konfigurieren, dass es auf diesen Subnetzbereich (primär oder sekundär) angewendet wird. 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 privater Google-Zugriff. Weitere Informationen finden Sie unter Privater Google-Zugriff.

Private NAT-Gateways gelten nicht für den 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. Ein in einem VPC-Netzwerk erstelltes Cloud NAT-Gateway kann NAT nicht für VMs in anderen VPC-Netzwerken bereitstellen, die über VPC-Netzwerk-Peering oder VPC-Spokes des Network Connectivity Center verbunden sind, selbst wenn sich die VMs in Peering-Netzwerken in derselben Region wie das Gateway befinden.

Interaktion mit GKE

Ein öffentliches 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 von Ihrem Cluster verwendete Subnetz angewendet wird:

  • 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, NAT für einen gesamten privaten Cluster bereitzustellen, besteht darin, ein öffentliches NAT-Gateway zu konfigurieren, 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 ö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.

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

  • Wenn die statische Portzuweisung konfiguriert ist, reserviert das Portreservierungsverfahren für öffentliche 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 anfangs der angegebene Wert für die Mindestanzahl von Ports pro VM pro Knoten zugewiesen. Die Anzahl der zugewiesenen Ports variiert anschließend je nach Bedarf zwischen den angegebenen Werten für die Mindest- und die 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 öffentlicher NAT führt Google Kubernetes Engine eine Quellnetzwerkadressübersetzung (Quell-NAT oder SNAT) durch. Dazu wird Software verwendet, 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 die öffentliche 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 Ihr öffentlicher Cluster jedoch statische externe IP-Adressen verwenden soll, die von einem öffentlichen NAT-Gateway bereitgestellt werden, gehen Sie so vor:

  • Konfigurieren Sie das öffentliche NAT-Gateway so, dass es nur für den sekundären IP-Adressbereich der Pod-Objekte des Clusters gilt.
  • Konfigurieren Sie Ihren Cluster so, dass die Standard-SNAT deaktiviert wird, damit GKE die IP-Adressen für die Quell-Pod-Objekte der Pakete behält, die an das Internet gesendet werden.
  • Konfigurieren Sie Ihren IP-Masquerade-Agent. Geben Sie dazu geeignete CIDRs als Ziele ohne Maskierung an, sodass der Agent die IP-Adressen für die Quell-Pod-Objekte der Pakete behält, die an die Ziele ohne Maskierung gesendet werden.

Das folgende Beispiel zeigt eine typische Interaktion zwischen öffentlicher NAT und GKE:

Öffentliche NAT mit GKE
Öffentliche NAT mit GKE (zum Vergrößern klicken).

In diesem Beispiel sollen Ihre Container durch NAT übersetzt werden. Wenn Sie NAT für alle Container und den GKE-Knoten aktivieren möchten, 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
  • Für Pods verwendeter sekundärer IP-Adressbereich des Subnetzes: 10.0.0.0/16

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

Ein privates NAT-Gateway kann NAT für Knoten und Pods in einem privaten Cluster und einem nicht privaten Cluster ausführen. Das private NAT-Gateway gilt automatisch auf alle Subnetz-IP-Adressbereiche des privaten Subnetzes, das der Cluster verwendet.

Interaktionen mit direktem VPC-Traffic

Öffentliche NAT-Gateways können NAT für Cloud Run-Dienste oder Jobs ausführen, die mit direktem ausgehendem VPC-Traffic konfiguriert sind. Konfigurieren Sie das öffentliche NAT-Gateway mit den folgenden Einstellungen, damit die Instanzen für ausgehenden direkten VPC-Traffic ein öffentliches NAT-Gateway verwenden können:

  • Geben Sie das Flag --nat-all-subnet-ip-ranges an, damit alle IP-Adressbereiche aller Subnetze in der Region das öffentliche NAT-Gateway verwenden können.
  • Legen Sie für das Flag --endpoint-types den Wert ENDPOINT_TYPE_VM fest. Durch diesen Wert wird sichergestellt, dass nur VMs (einschließlich VMs für ausgehenden Direct VPC-Traffic) das öffentliche NAT-Gateway verwenden können.
  • Legen Sie bei einer statischen Portzuweisung den Wert des Flags --min-ports-per-vm auf die vierfache Anzahl der Ports fest, die für eine einzelne Cloud Run-Instanz erforderlich sind.
  • Weisen Sie Ihrem öffentlichen NAT-Gateway bei manueller NAT-IP-Adresszuweisung eine angemessene Anzahl von IP-Adressen zu, um die Gesamtzahl der Google Cloud-Instanzen und die Anzahl der Instanzen für ausgehenden direkten VPC-Traffic zu berücksichtigen, die Sie in Ihrem VPC-Netzwerk bereitgestellt haben.

Zusätzlich zur Gateway-Konfiguration müssen Sie zum Senden von ausgehendem Traffic von einem Cloud Run-Dienst oder -Job das Flag --vpc-egress auf all-traffic festlegen, wenn Sie den Dienst oder Job erstellen.

Wenn Sie einen Cloud Run-Dienst oder -Job konfiguriert haben, bei dem das Flag --vpc-egress auf private-ranges-only gesetzt ist, sendet der Dienst oder Job Traffic nur an interne IP-Adressen. Sie benötigen kein öffentliches NAT-Gateway, um Traffic an interne Ziele weiterzuleiten.

So verhindern Sie, dass Cloud Run-Dienste oder -Jobs, bei denen das Flag --vpc-egress auf private-ranges-only gesetzt ist, ein öffentliches NAT-Gateway verwenden:

  • Konfigurieren Sie das öffentliche NAT-Gateway mit dem Flag --nat-custom-subnet-ip-ranges.
  • Legen Sie den Wert des Flags --nat-custom-subnet-ip-ranges auf die Namen der Subnetze fest, in denen Sie Cloud Run-Dienste oder -Jobs bereitgestellt haben, wobei das Flag --vpc-egress auf all-traffic gesetzt ist.

Die folgenden Einschränkungen gelten für Cloud Run-Dienste und Jobs, die öffentliche NAT-Gateways verwenden:

  • Cloud NAT-Messwerte für Endpunkte für ausgehenden Direct VPC-Traffic werden nicht nach Cloud Monitoring exportiert.
  • In Cloud NAT-Logs für direkten ausgehenden VPC-Traffic wird nicht der Name eines Cloud Run-Dienstes, einer -Version oder eines Cloud Run-Jobs angezeigt.

Private NAT-Gateways können nicht mit Instanzen für ausgehenden Direct VPC-Traffic verwendet werden.

Interaktionen von 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 für Netzwerke ausführen, die entweder öffentliche NAT-Gateways oder private NAT-Gateways oder beides verwenden.

Sie können die NAT-Konfigurationsdetails im Bereich Trace der Konfigurationsanalyse auf der Seite Details zum Konnektivitätstest ansehen.

Interaktionen mit Cloud Load Balancing

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

Andere externe Load-Balancer und Systemdiagnosesysteme von Google Cloud kommunizieren mit VMs über spezielle Routen. Back-End-VMs benötigen keine externen IP-Adressen und ein Cloud NAT-Gateway verwaltet keine Kommunikation für Load-Balancer und Systemdiagnosen. Weitere Informationen finden Sie unter Cloud Load Balancing und Übersicht über Systemdiagnosen.

Nächste Schritte