Cloud NAT-Produktinteraktionen

Auf dieser Seite werden die wichtigen Interaktionen zwischen Cloud NAT und andere Google Cloud-Produkte.

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 beispielsweise Sie verwenden VM-Instanzen, auf denen ein NAT-Gateway, eine Firewall oder ein Proxy ausgeführt wird. erstellen Sie statische Routen, um Traffic an diese VMs nächsten Hop. Die VMs des nächsten Hops erfordern externe IP-Adressen. Das heißt: Traffic von den VMs, die auf den Next-Hop-VMs oder den Next-Hop-VMs basieren selbst nicht nutzen können, Öffentliche NAT Gateways.

  • Wenn Sie eine benutzerdefinierte statische Route erstellen, deren nächster Hop ein Cloud VPN ist Tunnel Öffentliche NAT verwendet diese Route nicht. Beispiel: Statische Route mit Ziel 0.0.0.0/0 und einem Cloud-VPN für den nächsten Hop leitet den Traffic an diesen Tunnel weiter, nicht an das Standard-Internetgateway. Daher können Public NAT- Gateways diese Route nicht verwenden. In ähnlicher Weise Öffentliche NAT Gateways können keine statischen Elemente verwenden Routen mit spezifischeren Zielen, einschließlich 0.0.0.0/1 und 128.0.0.0/1.

  • Wenn ein lokaler Router eine dynamische Route Cloud Router, der einen Cloud VPN-Tunnel verwaltet, oder VLAN-Anhang Öffentliche NAT Gateways können 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 ein Subnetz Routen 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 beide VPC-Spokes enthält und Hybrid-Spokes wie VLAN-Anhänge für Cloud Interconnect oder Router-Appliance-VMs, Private NAT verwendet die dynamischen Routen von den Hybrid-Spokes über BGP ermittelt (Vorschau) und Subnetzrouten, die von den angehängten 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

A Öffentliche NAT Gateway führt niemals NAT für Traffic aus, der an die ausgewählte externe IP-Adressen für Google APIs und -Dienste. Stattdessen aktiviert Google Cloud automatisch den privaten 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 privaten Google-Zugriffs. Weitere Informationen finden Sie unter Privater Google-Zugriff.

Private NAT-Gateways gelten nicht für den privaten 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. DasPublic 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 Öffentliche NAT Gateway ist so konfiguriert, dass es NAT für eine private werden NAT-Quell-IP-Adressen und Quellports für jede Knoten-VM reserviert. 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 Google Kubernetes Engine (GKE) weisen immer Knoten einen Alias-IP-Bereich, der mehr als eine IP-Adresse enthält (Netzmaske kleiner als /32).

  • Wenn die statische Portzuweisung gleich konfiguriert, ist die öffentliche NAT Verfahren zur Portreservierung reserviert 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 von Öffentliche NAT , führt die Google Kubernetes Engine das Quellnetzwerk aus Adressübersetzung (NAT oder SNAT) indem er Software nutzt, die auf jedem Knoten ausgeführt wird, wenn Pods Pakete an das Internet senden. es sei denn, Sie haben die IP-Masquerade des Clusters geändert Konfiguration. Bei Bedarf Kontrolle über den ausgehenden Traffic von Pods haben, können Sie ein Netzwerk .

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, Cloud NAT Wenn jedoch die beiden folgenden Bedingungen zutreffen, werden Pakete, die von Pods in einem nicht privaten Cluster können von einem Öffentliche NAT Gateway:

  • 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 Öffentliche NAT mit 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 Cluster und in einem nicht privaten Cluster. Das private NAT-Gateway wird automatisch auf alle IP-Adressbereiche des Subnetzwerks angewendet, das Ihr Cluster verwendet.

Interaktionen mit ausgehendem Direct VPC-Traffic

Öffentliche NAT Gateways können NAT für Cloud Run-Dienste ausführen oder Jobs, die mit Ausgehender VPC-Traffic. 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 für öffentliches NATverwenden können.
  • Legen Sie bei der Zuweisung statischer Ports den Wert von --min-ports-per-vm fest. auf die vierfache Anzahl an Ports gesetzt, Cloud Run-Instanz.
  • Weisen Sie bei manueller NAT-IP-Adresszuweisung eine entsprechende Anzahl von IP-Adressen mit Ihrem Öffentliche NAT Gateway für die Summe der Anzahl der Google Cloud-Instanzen und der Anzahl der Cloud Run-Instanzen, die in Ihrem VPC-Netzwerk.

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, der das Flag --vpc-egress auf private-ranges-only gesetzt ist, sendet der Dienst oder Job Traffic nur an interne IP-Adressen. Sie benötigen keine Öffentliche NAT Gateway zum Weiterleiten von Traffic an interne Ziele.

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 öffentliche NATverwenden:

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

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

  • Cloud NAT-Messwerte für ausgehende Direct VPC-Endpunkte werden nicht exportiert Cloud Monitoring
  • 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 ausgehendem Direct-VPC-Traffic verwenden Endpunkten.

Interaktionen bei Konnektivitätstests

Mit Konnektivitätstests können Sie die Konnektivität zwischen dem Netzwerk prüfen Endpunkte, die Cloud NAT-Konfigurationen verwenden. Sie können Konnektivitätstests ausführen in Netzwerken, die entweder öffentliche NAT-Gateways verwenden oder Private NAT-Gateways oder beides.

Sehen Sie sich die NAT-Konfigurationsdetails im Trace der Konfigurationsanalyse an. auf der Seite Details zum Konnektivitätstest.

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 (Network End Point Group). Durch Konfigurieren von Cloud NAT-Gateways für die regionalen Internet-NEGs können Sie Ihre eigenen externen IP-Adressbereiche zuweisen. woher der Google Cloud-Traffic stammen soll. Die Systemdiagnosen und Traffic auf der Datenebene stammt von den NAT-IP-Adressen, die Sie zuweisen.

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

Nächste Schritte