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.

Interaktion 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 aktiviert Google Cloud automatisch den privater Google-Zugriff für einen Subnetz-IP-Adressbereich, wenn Sie ein Public 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 Public 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. 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 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 VPC-Cluster der Google Kubernetes Engine (GKE) 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 erfüllt sind:

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

Public NAT mit GKE.
Public 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 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

Öffentliches NAT Gateways können NAT für Cloud Run-Dienste oder Jobs ausführen, die mit Direkter VPC-Ausgang konfiguriert sind. Wenn Sie Cloud Run die Verwendung einesPublic NAT-Gateways ermöglichen möchten, konfigurieren Sie IhrPublic NAT-Gateway mit den folgenden Einstellungen:

  • Wenn Sie konfigurieren möchten, welche Subnetze und Subnetz-IP-Adressbereiche, die mit Ihren Cloud Run-Instanzen verknüpft sind, das-Gateway für öffentliche NATverwenden können, geben Sie das Flag --nat-all-subnet-ip-ranges oder --nat-custom-subnet-ip-ranges an:
    • Wenn alle IP-Adressbereiche aller Subnetze in der Region das----nat-all-subnet-ip-ranges-Gateway verwenden sollen, geben Sie das Flag an.
    • Wenn nur bestimmte Subnetze und Subnetz-IP-Adressbereiche das--Gateway verwenden sollen, geben Sie sie mit dem Flag --nat-custom-subnet-ip-ranges an.
  • Legen Sie den Wert des Flags --endpoint-types auf ENDPOINT_TYPE_VM fest. Mit diesem Wert wird sichergestellt, dass nur VMs und VM-Endpunkte für den direkten VPC-Ausgang das--Gateway verwenden können.
  • Legen Sie bei der statischen Portzuweisung den Wert des --min-ports-per-vm-Flags auf das Vierfache der Anzahl der Ports fest, die für eine einzelne Cloud Run-Instanz erforderlich sind.
  • Bei der manuellen Zuweisung von NAT-IP-Adressen weisen Sie IhremPublic NAT-Gateway eine angemessene Anzahl von IP-Adressen zu, die der Summe der Anzahl der Google Cloud-Instanzen und der Anzahl der Cloud Run-Instanzen entspricht, die in Ihrem VPC-Netzwerk bereitgestellt werden.

Wenn Sie ausgehenden Traffic von einem Cloud Run-Dienst oder ‑Job senden möchten, müssen Sie zusätzlich zur Gateway-Konfiguration das --vpc-egress-Flag beim Erstellen des Dienstes oder Jobs auf all-traffic setzen.

Wenn Sie einen Cloud Run-Dienst oder -Job konfiguriert haben, für den das Flag --vpc-egress auf private-ranges-only festgelegt ist, sendet der Dienst oder Job nur Traffic 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, für die das --vpc-egress-Flag auf private-ranges-only festgelegt ist, ein-Gateway für öffentliches NATverwenden:

  • Konfigurieren Sie dasPublic NAT-Gateway mit dem Flag --nat-custom-subnet-ip-ranges.
  • Legen Sie den Wert des --nat-custom-subnet-ip-ranges-Flags auf die Namen der Subnetze fest, in denen Sie Cloud Run-Dienste oder ‑Jobs bereitgestellt haben, wobei das --vpc-egress-Flag 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 Direct VPC-Ausgabeendpunkte werden nicht nach Cloud Monitoring exportiert.
  • Cloud NAT-Logs für Direct VPC-Traffic enthalten nicht den Namen eines Cloud Run-Dienstes, einer Cloud Run-Version oder eines Cloud Run-Jobs.

Sie können keine privaten NAT-Gateways mit Direct VPC-Ausgang-Endpunkten verwenden.

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

Regionale interne Application Load Balancer und regionale externe Application Load Balancer von Google Cloud kommunizieren mit mehreren regionalen NEG-Back-Ends (Regional 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 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 Übersicht über Systemdiagnosen.

Nächste Schritte