Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Private NAT für Spokes des Network Connectivity Centers
Mit Private NAT können Sie ein privates NAT-Gateway erstellen, das in Verbindung mit VPC-Spokes (Network Connectivity Center) für die Network Address Translation (NAT) zwischen den folgenden Netzwerken verwendet wird:
VPC-Netzwerke (Virtual Private Cloud): In diesem Szenario sind die VPC-Netzwerke, die Sie verbinden möchten, als VPC-Spokes mit einem Network Connectivity Center-Hub verbunden.
VPC-Netzwerke und Netzwerke außerhalb von Google Cloud: In diesem Szenario sind ein oder mehrere VPC-Netzwerke als VPC-Spokes an einen Network Connectivity Center-Hub angehängt und über Hybrid-Spokes mit Ihren lokalen Netzwerken oder Netzwerken anderer Cloud-Anbieter verbunden.
Bei Private NAT wird eine NAT-Konfiguration von type=PRIVATE verwendet, damit Netzwerke mit sich überschneidenden IP-Adressbereichen von Subnetzen kommunizieren können. Nur nicht überlappende Subnetze können miteinander verbunden werden.
Sie müssen eine benutzerdefinierte NAT-Regel erstellen, indem Sie auf einen Network Connectivity Center-Hub verweisen.
Die NAT-Regel gibt einen NAT-IP-Adressbereich aus einem Subnetz mit dem Zweck PRIVATE_NAT an, der von Private NAT für die NAT-Ausführung auf Traffic zwischen Ihren verbundenen Netzwerken verwendet wird.
Wenn Sie eine VM-Instanz in einem Subnetzbereich erstellen, für den Private NAT gilt, wird der gesamte ausgehende Traffic von dieser VM-Instanz vom Gateway übersetzt, wenn sich der Ziel-Spoke im selben Network Connectivity Center-Hub wie das Gateway befindet. Private NAT übersetzt Traffic zu Zielspeichen innerhalb derselben Region wie das private NAT-Gateway sowie regionenübergreifend.
Ein privates NAT-Gateway ist Subnetz-IP-Adressbereichen in einer einzelnen Region in einem einzelnen VPC-Netzwerk zugeordnet.
Das bedeutet, dass ein Private NAT-Gateway, das in einem VPC-Netzwerk erstellt wurde, keine NAT-Dienste für VMs in anderen Spokes des Network Connectivity Center-Hubs bereitstellt, auch wenn sich die VMs in derselben Region wie das Gateway befinden.
Traffic zwischen VPC-Netzwerken
Für Traffic zwischen VPC-Netzwerken (VPC-NAT) gelten die folgenden zusätzlichen Spezifikationen:
Wenn Sie Inter-VPC-NAT zwischen zwei VPC-Netzwerken aktivieren möchten, muss jedes VPC-Netzwerk als VPC-Spoke eines Network Connectivity Center-Hubs konfiguriert werden.
Achten Sie darauf, dass sich die IP-Adressbereiche Ihrer VPC-Spokes nicht überschneiden. Weitere Informationen finden Sie unter VPC-Spoke erstellen.
Der mit dem privaten NAT-Gateway verknüpfte Network Connectivity Center-Hub muss mindestens zwei VPC-Spokes haben. Einer der VPC-Spokes ist das VPC-Netzwerk des privaten NAT-Gateways.
Inter-VPC-NAT unterstützt nur NAT zwischen VPC-Spokes (Network Connectivity Center) und nicht zwischen VPC-Netzwerken, die über VPC-Netzwerk-Peering verbunden sind.
Traffic zwischen VPC-Netzwerken und anderen Netzwerken
Für den Traffic zwischen VPC-Netzwerken und Netzwerken außerhalb von Google Cloudgelten die folgenden zusätzlichen Spezifikationen:
Das Quell-VPC-Netzwerk muss als VPC-Spoke eines Network Connectivity Center-Hubs konfiguriert sein.
Ein Hybrid-Spoke muss mit demselben Network Connectivity Center-Hub verbunden sein, um eine Verbindung zwischen dem VPC-Spoke und dem Zielnetzwerk außerhalb von Google Cloudherzustellen. Weitere Informationen finden Sie unter Verbindung zwischen Hybrid-Spokes und VPC-Spokes herstellen.
Informationen zu den Anforderungen für die Verwendung von VPC-Spokes und Hybrid-Spokes im selben Network Connectivity Center-Hub finden Sie unter Routenaustausch mit VPC-Spokes.
Grundlegende Konfiguration und Workflow
Das folgende Diagramm zeigt eine grundlegende Private NAT-Konfiguration für Traffic zwischen zwei VPC-Spokes:
Beispiel für eine inter-VPC-NAT-Übersetzung (zum Vergrößern klicken)
In diesem Beispiel ist Private NAT so eingerichtet:
Das Gateway pvt-nat-gw ist in vpc-a so konfiguriert, dass es auf alle IP-Adressbereiche von subnet-a in der Region us-east1 angewendet wird. Mit den NAT-IP-Bereichen von pvt-nat-gw kann eine VM-Instanz in subnet-a von vpc-a Traffic an eine VM in subnet-b von vpc-b senden, auch wenn sich subnet-a von vpc-a mit subnet-c von vpc-b überschneidet.
Sowohl vpc-a als auch vpc-b sind als Spokes eines Network Connectivity Center-Hubs konfiguriert.
Das pvt-nat-gw-Gateway ist für die NAT zwischen VPC-Netzwerken konfiguriert, die als VPC-Spokes im selben Network Connectivity Center-Hub konfiguriert sind.
Beispielworkflow
Im vorherigen Diagramm muss vm-a mit der internen IP-Adresse 192.168.1.2 in subnet-a von vpc-a ein Update von vm-b mit der internen IP-Adresse 192.168.2.2 in subnet-b von vpc-b herunterladen. Beide VPC-Netzwerke sind mit demselben Network Connectivity Center-Hub wie VPC-Spokes verbunden. Angenommen, vpc-b enthält ein weiteres Subnetz 192.168.1.0/24, das sich mit dem Subnetz in vpc-a überschneidet. Damit subnet-a von vpc-a mit subnet-b von vpc-b kommunizieren kann, müssen Sie in vpc-a ein privates NAT-Gateway (pvt-nat-gw) so konfigurieren:
Privates NAT-Subnetz: Bevor Sie das Private NAT-Gateway konfigurieren, erstellen Sie ein Privates NAT-Subnetz mit dem Zweck PRIVATE_NAT, z. B. 10.1.2.0/29. Achten Sie darauf, dass sich dieses Subnetz nicht mit einem vorhandenen Subnetz in einem der VPC-Spokes überschneidet, die mit demselben Network Connectivity Center-Hub verbunden sind.
Eine NAT-Regel, deren nexthop.hub mit der URL des Network Connectivity Center-Hubs übereinstimmt.
NAT für alle Adressbereiche von subnet-a
In der folgenden Tabelle wird die im vorherigen Beispiel angegebene Netzwerkkonfiguration zusammengefasst:
Netzwerkname
Netzwerkkomponente
IP-Adresse/Adressbereich
Region
vpc-a
subnet-a
192.168.1.0/24
us-east1
vm-a
192.168.1.2
pvt-nat-gw
10.1.2.0/29
vpc-b
subnet-b
192.168.2.0/24
us-west1
vm-b
192.168.2.2
subnet-c
192.168.1.0/24
vm-c
192.168.1.3
Privates NAT für Network Connectivity Center-Spokes folgt dem Portreservierungsverfahren, um die folgenden Tupel aus NAT-Quell-IP-Adresse und Quellport für jede der VMs im Netzwerk zu reservieren. Das private NAT-Gateway reserviert beispielsweise 64 Quellports für vm-a:10.1.2.2:34000 bis 10.1.2.2:34063.
Wenn die VM ein Paket mit dem TCP-Protokoll an den Update-Server 192.168.2.2 auf dem Zielport 80 sendet, geschieht Folgendes:
Die VM sendet ein Anfragepaket mit folgenden Attributen:
Quell-IP-Adresse: 192.168.1.2, die interne IP-Adresse der VM
Quellport: 24000, der sitzungsspezifische Quellport, der vom Betriebssystem der VM ausgewählt wurde
Zieladresse: 192.168.2.2, die IP-Adresse des Update-Servers
Zielport: 80, der Zielport für HTTP-Traffic zum Update-Server
Protokoll: TCP
Das Gateway pvt-nat-gw führt für ausgehenden Traffic eine Quellnetzwerkadressübersetzung (SNAT oder Source NAT) aus und schreibt die NAT-Quell-IP-Adresse und den Quellport des Anfragepakets um:
NAT-Quell-IP-Adresse: 10.1.2.2 von einem der reservierten Tupel aus NAT-Quell-IP-Adresse und Quellport
Quellport: 34022, ein nicht verwendeter Quellport aus einem der reservierten Quellport-Tupel der VM
Zieladresse: 192.168.2.2, unverändert
Zielport: 80, unverändert
Protokoll: TCP, unverändert
Der Update-Server sendet ein Antwortpaket, das mit folgenden Attributen am pvt-nat-gw-Gateway ankommt:
Quell-IP-Adresse: 192.168.2.2, die interne IP-Adresse des Update-Servers
Quellport: 80, die HTTP-Antwort vom Update-Server
Zieladresse: 10.1.2.2, entspricht der ursprünglichen NAT-Quell-IP-Adresse des Anfragepakets
Zielport: 34022, entspricht dem Quellport des Anfragepakets
Protokoll: TCP, unverändert
Das Gateway pvt-nat-gw führt DNAT für das Antwortpaket aus und schreibt die Zieladresse und den Zielport des Antwortpakets um, damit das Paket an die VM gesendet wird, die das Update angefordert hat, mit den folgenden Attributen:
Quell-IP-Adresse: 192.168.2.2, unverändert
Quellport: 80, unverändert
Zieladresse: 192.168.1.2, die interne IP-Adresse der VM
Zielport: 24000, entspricht dem ursprünglichen sitzungsspezifischen Quellport des Anfragepakets
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-19 (UTC)."],[],[],null,["# Private NAT for Network Connectivity Center spokes\n==================================================\n\nPrivate NAT lets you create a Private NAT\ngateway that works in conjunction with Network Connectivity Center\nspokes to perform network address translation (NAT) between the following\nnetworks:\n\n- Virtual Private Cloud (VPC) networks: In this scenario, the VPC networks that you want to connect are attached to a Network Connectivity Center hub as VPC spokes.\n- VPC networks and networks outside of Google Cloud: In this scenario, one or more VPC networks are attached to a Network Connectivity Center hub as VPC spokes and connected to your on-premises or other cloud provider networks through hybrid spokes.\n\nSpecifications\n--------------\n\nIn addition to the [general Private NAT specifications](/nat/docs/private-nat#pvt-nat-specs),\nPrivate NAT for Network Connectivity Center spokes has the following\nspecifications:\n\n- Private NAT uses a NAT configuration of `type=PRIVATE` to let networks with overlapping subnet IP address ranges communicate. However, only non-overlapping subnets can connect to each other.\n- You need to create a custom NAT rule by referencing a Network Connectivity Center hub. The NAT rule specifies a NAT IP address range from a subnet of purpose `PRIVATE_NAT` that Private NAT uses to perform NAT on traffic between your connected networks.\n- When you create a VM instance in a subnet range where the Private NAT applies, all egress traffic from this VM instance is translated by the gateway if the destination spoke is in the same Network Connectivity Center hub as the gateway. Private NAT translates traffic to destination spokes within the same region as the Private NAT gateway as well as across regions.\n- A Private NAT gateway is associated with subnet IP address ranges in a single region in a single VPC network. This means a Private NAT gateway created in one VPC network doesn't provide NAT services to VMs in other spokes of the Network Connectivity Center hub, even if the VMs are in the same region as the gateway.\n\n### Traffic between VPC networks\n\nThe following additional specifications apply for traffic between\nVPC networks (Inter-VPC NAT):\n\n- To enable Inter-VPC NAT between two VPC networks, each VPC network must be configured as a VPC spoke of a Network Connectivity Center hub. You must ensure that there are no overlapping IP address ranges across your VPC spokes. For more information, see [Create a VPC spoke](/network-connectivity/docs/network-connectivity-center/how-to/working-with-hubs-spokes#create-vpc-spoke).\n- The Network Connectivity Center hub associated with the Private NAT gateway must have at least two VPC spokes, where one of the VPC spokes is the VPC network of the Private NAT gateway.\n- Inter-VPC NAT supports NAT between Network Connectivity Center VPC spokes only, and not between VPC networks connected using VPC Network Peering.\n\n### Traffic between VPC networks and other networks\n\nThe following additional specifications apply for traffic between\nVPC networks and networks outside of Google Cloud:\n\n- The source VPC network must be configured as a VPC spoke of a Network Connectivity Center hub.\n- A hybrid spoke must be attached to the same Network Connectivity Center hub to establish connectivity between the VPC spoke and the destination network outside of Google Cloud. For more information, see [Establishing connectivity between hybrid spokes and VPC spokes](/network-connectivity/docs/network-connectivity-center/concepts/dynamic-route-exchange-with-vpc-spokes#connectivity-between-hybrid-and-vpc-spokes).\n\nFor information about the requirements for using VPC spokes and\nhybrid spokes in the same Network Connectivity Center hub, see\n[Route exchange with VPC spokes](/network-connectivity/docs/network-connectivity-center/concepts/dynamic-route-exchange-with-vpc-spokes).\n\nBasic configuration and workflow\n--------------------------------\n\nThe following diagram shows a basic Private NAT configuration\nfor traffic between two VPC spokes:\n[](/static/nat/images/inter-vpc-nat-flow.png) Inter-VPC NAT translation example (click to enlarge).\n\nIn this example, Private NAT is set up as follows:\n\n- The `pvt-nat-gw` gateway is configured in `vpc-a` to apply to all the IP address ranges of `subnet-a` in the `us-east1` region. Using the NAT IP ranges of `pvt-nat-gw`, a virtual machine (VM) instance in `subnet-a` of `vpc-a` can send traffic to a VM in `subnet-b` of `vpc-b`, even though `subnet-a` of `vpc-a` overlaps with `subnet-c` of `vpc-b`.\n- Both `vpc-a` and `vpc-b` are configured as spokes of a Network Connectivity Center hub.\n- The `pvt-nat-gw` gateway is configured to provide NAT between VPC networks that are configured as VPC spokes in the same Network Connectivity Center hub.\n\n### Example workflow\n\nIn the preceding diagram, `vm-a` with the internal IP address `192.168.1.2` in\n`subnet-a` of `vpc-a` needs to download an update from `vm-b` with the internal\nIP address `192.168.2.2` in `subnet-b` of `vpc-b`. Both the VPC\nnetworks are connected to the same Network Connectivity Center hub as VPC\nspokes. Assume that `vpc-b` contains another subnet `192.168.1.0/24` that overlaps\nwith the subnet in `vpc-a`. For `subnet-a` of `vpc-a` to communicate with `subnet-b`\nof `vpc-b`, you need to configure a Private NAT gateway, `pvt-nat-gw`,\nin `vpc-a` as follows:\n\n- Private NAT subnet: Before configuring the Private NAT\n gateway, create a Private NAT subnet of purpose `PRIVATE_NAT`,\n for example, `10.1.2.0/29`. Ensure that this subnet doesn't overlap\n with an existing subnet in any of the VPC spokes attached to the\n same Network Connectivity Center hub.\n\n- A NAT rule whose `nexthop.hub` matches the Network Connectivity Center hub URL.\n\n- NAT for all address ranges of `subnet-a`.\n\nThe following table summarizes the network configuration specified in the preceding\nexample:\n\nPrivate NAT for Network Connectivity Center spokes follows the\n[port reservation procedure](/nat/docs/ports-and-addresses#port-reservation-procedure)\nto reserve the following NAT source IP address\nand source port tuples for each of the VMs in the network. For example, the\nPrivate NAT gateway reserves 64 source ports for `vm-a`:\n`10.1.2.2:34000` through `10.1.2.2:34063`.\n\nWhen the VM uses the TCP protocol to send a packet to the update server\n`192.168.2.2` on destination port `80`, the following occurs:\n\n1. The VM sends a request packet with these attributes:\n\n - Source IP address: `192.168.1.2`, the internal IP address of the VM\n - Source port: `24000`, the ephemeral source port chosen by the VM's operating system\n - Destination address: `192.168.2.2`, the update server's IP address\n - Destination port: `80`, the destination port for HTTP traffic to the update server\n - Protocol: TCP\n2. The `pvt-nat-gw` gateway performs source network address translation (SNAT or\n source NAT) on egress, rewriting the request\n packet's NAT source IP address and source port:\n\n - NAT source IP address: `10.1.2.2`, from one of the VM's reserved NAT source IP address and source port tuples\n - Source port: `34022`, an unused source port from one of the VM's reserved source port tuples\n - Destination address: `192.168.2.2`, unchanged\n - Destination port: `80`, unchanged\n - Protocol: TCP, unchanged\n3. The update server sends a response packet that arrives on the\n `pvt-nat-gw` gateway with these attributes:\n\n - Source IP address: `192.168.2.2`, the update server's internal IP address\n - Source port: `80`, the HTTP response from the update server\n - Destination address: `10.1.2.2`, which matches the original NAT source IP address of the request packet\n - Destination port: `34022`, which matches the source port of the request packet\n - Protocol: TCP, unchanged\n4. The `pvt-nat-gw` gateway performs destination network address translation\n (DNAT) on the response packet, rewriting the response packet's destination address\n and destination port so that the packet is delivered to the VM that requested the update with the following attributes:\n\n - Source IP address: `192.168.2.2`, unchanged\n - Source port: `80`, unchanged\n - Destination address: `192.168.1.2`, the internal IP address of the VM\n - Destination port: `24000`, matching the original ephemeral source port of the request packet\n - Protocol: TCP, unchanged\n\nWhat's next\n-----------\n\n- Set up [Private NAT for Network Connectivity Center spokes](/nat/docs/set-up-private-nat).\n- Learn about [Cloud NAT product interactions](/nat/docs/nat-product-interactions).\n- Learn about [Cloud NAT addresses and ports](/nat/docs/ports-and-addresses).\n- Learn about [Cloud NAT rules](/nat/docs/nat-rules-overview).\n- Troubleshoot [common issues](/nat/docs/troubleshooting)."]]
