Cloud NAT-Produktinteraktionen

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

Interaktionen mit Routen

A Öffentliche NAT Gateway kann nur Routen verwenden, deren nächster Hop der Standard-Internetgateway. Jedes VPC-Netzwerk (Virtual Private Cloud) beginnt mit einem Standardnetzwerk Route mit dem Ziel 0.0.0.0/0, deren nächster Hop die Standardeinstellung ist Internetgateways. Wichtige Hintergrundinformationen finden Sie in der Routenübersicht.

Die folgenden Beispiele veranschaulichen Situationen, Öffentliche NAT funktionsgefährdende Gateways:

  • Wenn Sie eine benutzerdefinierte statische Route erstellen und für die nächsten Hops eine andere Art von nächster Hop der benutzerdefinierten statischen Route, dann Pakete mit Ziel-IP-Adressen, die mit dem Ziel der Route übereinstimmen, statt zum Standard-Internetgateway. Wenn beispielsweise Sie verwenden VM-Instanzen, auf denen ein NAT-Gateway, eine Firewall oder ein Proxy ausgeführt wird. erstellen Sie benutzerdefinierte statische Routen, um Traffic an diese VMs weiterzuleiten, 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: Eine benutzerdefinierte 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. Dementsprechend wird Öffentliche NAT Gateways können diese Route. In ähnlicher Weise Öffentliche NAT Gateways können keine benutzerdefinierte statische Konfiguration verwenden Routen mit spezifischeren Zielen, einschließlich 0.0.0.0/1 und 128.0.0.0/1.

  • Wenn ein lokaler Router eine benutzerdefinierte 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 z. B. bewirbt eine benutzerdefinierte dynamische Route mit dem Ziel 0.0.0.0/0, 0.0.0.0/0 wird an den Cloud VPN-Tunnel weitergeleitet oder VLAN-Anhang. Dieses Verhalten gilt auch für spezifischere Ziele, einschließlich 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: <ph type="x-smartling-placeholder">
      </ph>
    • Für Traffic zwischen zwei VPC-Spokes, die an einen Network Connectivity Center-Hub, der nur VPC-Spokes enthält, Private NAT verwendet die Subnetzrouten die durch die angehängten VPC-Spokes ausgetauscht werden. Weitere Informationen zu VPC-Spokes, siehe VPC-Spokes – Übersicht
    • 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.
  • Für Hybrid-NAT (Vorabversion) Private NAT verwendet dynamische Routen, die von Cloud Router über Cloud Interconnect oder Cloud VPN.

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 Google Cloud aktiviert automatisch den privater Google-Zugriff für einen Subnetz-IP-Adressbereich, wenn Sie eine Öffentliche NAT Gateway zum Anwenden auf diesen Subnetzbereich, entweder primäre oder sekundäre. 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.

A Öffentliche NAT ändert sich nicht die Art und Weise, Privater Google-Zugriff funktioniert. Weitere Informationen finden Sie unter Privater Google-Zugriff:

Private NAT-Gateways gelten nicht für 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. A Ein in einem VPC-Netzwerk erstelltes Cloud NAT-Gateway kann nicht stellen Sie NAT für VMs in anderen VPC-Netzwerken bereit, die über mit VPC-Netzwerk-Peering auch wenn sich die VMs in Peering-Netzwerken in derselben Region wie das Gateway befinden.

Interaktion mit GKE

A Öffentliche NAT Gateway NAT für Knoten und Pods in einem privater Cluster eine Art VPC-nativer Cluster. Die Öffentliche NAT Gateway muss für die Anwendung auf mindestens die folgenden Subnetz-IP-Adressbereiche konfiguriert sein für das Subnetz, das der 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, NAT für einen gesamten privaten Cluster bereitzustellen, ist die Konfiguration eine Öffentliche NAT Gateway, das auf alle Subnetz-IP-Adressbereiche angewendet werden soll des Clusters des Clusters ab.

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 gleich wird der angegebene Wert für die Mindestanzahl von Ports pro VM anfänglich pro Knoten zugewiesen wird. Die Anzahl der zugewiesenen Ports variiert anschließend zwischen den angegebenen Werten für minimale und maximale Anzahl von Ports pro VM, basierend auf Nachfrage.

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 Sie Software nutzen, 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 Öffentliche NAT können auch für nicht private VPC-native Cluster. 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:

  • Für VPC-native Cluster Öffentliche NAT Gateway ist die für den sekundären IP-Adressbereich für die Pods des Clusters konfiguriert sind.

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

<ph type="x-smartling-placeholder">
</ph> Öffentliche NAT mit GKE
. Öffentliche NAT mit GKE (zum Vergrößern klicken)

In diesem Beispiel sollen die Container NAT-Übersetzungen sein. NAT aktivieren für alle Container und den GKE-Knoten müssen Sie alle IP-Adressbereiche von Subnet 1 als NAT-Kandidat:

  • 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 privates NAT-Gateway kann NAT für Knoten und Pods in einem privaten Cluster und in einem nicht privaten Cluster. Die Das private NAT-Gateway wird automatisch angewendet an alle Subnetz-IP-Adressbereiche für das private Subnetz, das der 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. So aktivieren Sie Cloud Run für die Verwendung eines Öffentliche NAT Gateway konfigurieren, Öffentliche NAT . Gateway mit den folgenden Einstellungen:

  • Um zu konfigurieren, welche Subnetze und Subnetz-IP-Adressbereiche mit Ihrem Cloud Run-Instanzen können die Öffentliche NAT Gateway 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 die Methode Öffentliche NAT Gateway, geben Sie die --nat-all-subnet-ip-ranges an melden.
    • Damit nur bestimmte Subnetze und Subnetz-IP-Adressbereiche die Methode Öffentliche NAT Gateway, geben Sie sie mit dem --nat-custom-subnet-ip-ranges.
  • Legen Sie den Wert des Flags --endpoint-types auf ENDPOINT_TYPE_VM fest. Dieser Wert sorgt dafür, dass nur VMs und VM-Endpunkte für ausgehenden Direct VPC-Traffic die Öffentliche NAT Gateway.
  • 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.

Zusätzlich zur Gateway-Konfiguration ist zum Senden von ausgehendem Traffic von einem Cloud Run-Gerät ein zusätzliches Dienst oder Job zu tun haben, müssen Sie das Flag --vpc-egress auf all-traffic setzen, wenn Sie Erstellen Sie den Dienst oder Job.

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.

Um zu verhindern, dass Cloud Run-Dienste oder -Jobs, die --vpc-egress private-ranges-only für die Verwendung eines Öffentliche NAT Gateway:

  • Konfigurieren Sie die Öffentliche NAT Gateway mit dem Flag --nat-custom-subnet-ip-ranges.
  • Legen Sie für den Wert des Flags --nat-custom-subnet-ip-ranges die Subnetznamen fest, wobei Sie haben Cloud Run-Dienste oder -Jobs mit dem Flag --vpc-egress bereitgestellt. auf all-traffic festgelegt.

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
  • In Cloud NAT-Logs für ausgehenden Direct VPC-Traffic wird nicht der Name eines Cloud Run-Dienst, -Überarbeitung oder -Job.

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

Interaktionen mit 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 und/oder Private NAT-Gateways.

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 von Google Cloud und regionale externe Application Load Balancer mit mehreren NEG-Back-Ends (regionale NEG-Back-Ends) kommunizieren 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 Routen. Back-End-VMs erfordern keine externen IP-Adressen und ein Cloud NAT-Gateway für Load-Balancer und Systemdiagnosen. Weitere Informationen finden Sie unter Cloud Load Balancing und Übersicht über Systemdiagnosen.

Nächste Schritte