Öffentliche NAT

Mit der öffentlichen NAT können Ihre Google Cloud-VM-Instanzen ohne öffentliche IP-Adressen über einen Satz gemeinsamer öffentlicher IP-Adressen mit dem Internet kommunizieren. Cloud NAT verwendet ein öffentliches NAT-Gateway, das jeder VM, die das Gateway verwendet, eine Gruppe externer IP-Adressen und Quellports zuweist, um ausgehende Verbindungen zum Internet herzustellen.

Grundlegende Konfiguration und Workflows der öffentlichen NAT

Das folgende Diagramm zeigt eine grundlegende Konfiguration für öffentliche NAT:

Beispiel für eine öffentliche NAT-Übersetzung.
Beispiel für eine öffentliche NAT-Übersetzung (zum Vergrößern klicken)

In diesem Fall gilt Folgendes:

  • Das Gateway nat-gw-us-east ist so konfiguriert, dass es auf den primären IP-Adressbereich von subnet-1 in der Region us-east1 angewendet wird. Eine VM, deren Netzwerkschnittstelle keine externe IP-Adresse hat, kann Traffic über die primäre interne IP-Adresse oder einen Alias-IP-Bereich aus dem primären IP-Adressbereich von subnet-1, 10.240.0.0/16, an das Internet senden.

  • Eine VM, deren Netzwerkschnittstelle keine externe IP-Adresse hat und deren primäre interne IP-Adresse sich in subnet-2 befindet, kann nicht auf das Internet zugreifen, da kein öffentliches NAT-Gateway auf einen IP-Adressbereich dieses Subnetzes angewendet wird.

  • Das Gateway nat-gw-eu ist so konfiguriert, dass es auf den primären IP-Adressbereich von subnet-3 in der Region europe-west1 angewendet wird. Eine VM, deren Netzwerkschnittstelle keine externe IP-Adresse hat, kann Traffic über die primäre interne IP-Adresse oder einen Alias-IP-Bereich aus dem primären IP-Adressbereich von subnet-3, 192.168.1.0/24, an das Internet senden.

Beispiel für einen öffentlichen NAT-Workflow

Im vorherigen Diagramm muss eine VM mit der primären internen IP-Adresse 10.240.0.4 ohne externe IP-Adresse ein Update von der externen IP-Adresse 203.0.113.1 herunterladen. Im Diagramm ist das nat-gw-us-east-Gateway so konfiguriert:

  • Mindestanzahl an Ports pro Instanz: 64
  • Manuell zwei NAT-IP-Adressen (Network Address Translation): 192.0.2.50 und 192.0.2.60
  • Bereitgestellte NAT für den primären IP-Adressbereich von subnet-1

Öffentliche NAT folgt dem Verfahren zur Portreservierung, um die folgenden Semikolons für NAT-Quell-IP-Adressen und Quellports für jede der VMs im Netzwerk zu reservieren. Das öffentliche NAT-Gateway reserviert beispielsweise 64 Quellports für die VM mit der internen IP-Adresse 10.240.0.4. Die NAT-IP-Adresse 192.0.2.50 hat 64 nicht reservierte Ports. Deshalb reserviert das Gateway die folgenden 64 Tupel aus NAT-Quell-IP-Adresse und Quellport für diese VM:

  • 192.0.2.50:34000 bis 192.0.2.50:34063

Wenn die VM ein Paket mit dem TCP-Protokoll an den Update-Server 203.0.113.1 auf dem Zielport 80 sendet, geschieht Folgendes:

  • Die VM sendet ein Anfragepaket mit folgenden Attributen:

    • Quell-IP-Adresse: 10.240.0.4, die primäre interne IP-Adresse der VM
    • Quellport: 24000, der sitzungsspezifische Quellport, der vom Betriebssystem der VM ausgewählt wurde
    • Zieladresse: 203.0.113.1, die externe IP-Adresse des Update-Servers
    • Zielport: 80, der Zielport für HTTP-Traffic zum Update-Server
    • Protokoll: TCP

  • Das nat-gw-us-east-Gateway führt eine SNAT (Source Network Address Translation) für ausgehenden Traffic durch. Dabei werden die NAT-Quell-IP-Adresse und der Quellport des Anfragepakets neu geschrieben. Das geänderte Paket wird an das Internet gesendet, wenn das VPC-Netzwerk (Virtual Private Cloud) eine Route für das Ziel 203.0.113.1 hat, dessen nächster Hop das Standard-Internetgateway ist. Eine Standardroute erfüllt diese Anforderung in der Regel.

    • NAT-Quell-IP-Adresse: 192.0.2.50 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: 203.0.113.1, unverändert
    • Zielport: 80, unverändert
    • Protokoll: TCP, unverändert

  • Wenn der Update-Server ein Antwortpaket sendet, kommt dieses Paket mit folgenden Attributen am nat-gw-us-east Gateway an:

    • Quell-IP-Adresse: 203.0.113.1, die externe IP-Adresse des Update-Servers
    • Quellport: 80, die HTTP-Antwort vom Update-Server
    • Zieladresse: 192.0.2.50, entspricht der ursprünglichen NAT-Quell-IP-Adresse des Anfragepakets
    • Zielport: 34022, entspricht dem Quellport des Anfragepakets
    • Protokoll: TCP, unverändert

  • Das Gateway nat-gw-us-east 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:

    • Quell-IP-Adresse: 203.0.113.1, unverändert
    • Quellport: 80, unverändert
    • Zieladresse: 10.240.0.4, die primäre interne IP-Adresse der VM
    • Zielport: 24000, entspricht dem ursprünglichen sitzungsspezifischen Quellport des Anfragepakets
    • Protokoll: TCP, unverändert

Spezifikationen

Allgemeine Spezifikationen

Sie können ein öffentliches NAT-Gateway so konfigurieren, dass NAT für die folgenden Pakete im Internet bereitgestellt wird:

  • Die primäre interne IP-Adresse der Compute Engine VM-Schnittstelle, sofern der Netzwerkschnittstelle keine externe IP-Adresse zugewiesen ist. Wenn der Netzwerkschnittstelle eine externe IP-Adresse zugewiesen ist, führt Google Cloud automatisch eine 1:1-NAT für Pakete aus, deren Quellen mit der primären internen IP-Adresse der Schnittstelle übereinstimmen, da die Netzwerkschnittstelle die Anforderungen für den Internetzugriff von Google Cloud erfüllt. Das Vorhandensein einer externen IP-Adresse auf einer Schnittstelle hat immer Vorrang und führt immer 1:1-NAT ohne öffentliche NAT aus.

  • Ein Alias-IP-Bereich, der der Netzwerkschnittstelle der VM zugewiesen ist. Auch wenn der Netzwerkschnittstelle eine externe IP-Adresse zugewiesen ist, können Sie ein öffentliches NAT-Gateway konfigurieren, um NAT für Pakete bereitzustellen, deren Quellen aus einem Alias-IP-Bereich der Schnittstelle stammen. Wenn eine externe IP-Adresse einer Schnittstelle zugewiesen ist, wird für Alias-IP-Adressen nie 1:1-NAT ausgeführt.

  • Für Google Kubernetes Engine-Cluster (GKE) kann die öffentliche NAT unter bestimmten Umständen einen Dienst bereitstellen, auch wenn der Cluster externe IP-Adressen hat. Weitere Informationen finden Sie unter GKE-Interaktion.

Die öffentliche NAT lässt ausgehende Verbindungen und die eingehenden Antworten auf diese Verbindungen zu. Jedes öffentliche NAT-Gateway führt eine Quell-NAT bei ausgehendem Traffic und eine Ziel-NAT für eingerichtete Antwortpakete aus.

Die öffentliche NAT lässt keine unerwünschten eingehenden Anfragen aus dem Internet zu, auch wenn sie durch Firewallregeln sonst zugelassen würden. Weitere Informationen finden Sie unter Anwendbare RFCs.

Jedes öffentliche NAT-Gateway ist einem einzelnen VPC-Netzwerk, einer Region und einem Cloud Router zugeordnet. Das öffentliche NAT-Gateway und der Cloud Router stellen eine Steuerungsebene bereit. Sie sind nicht an der Datenebene beteiligt, sodass Pakete nicht über das öffentliche NAT-Gateway oder Cloud Router geleitet werden.

Routen und Firewallregeln

Die öffentliche NAT basiert auf benutzerdefinierten statischen Routen, deren nächster Hop das Standard-Internetgateway ist. Damit Sie ein öffentliches NAT-Gateway vollständig nutzen können, benötigt Ihr Virtual Private Cloud-Netzwerk eine Standardroute, deren nächster Hop das Standard-Internetgateway ist. Weitere Informationen finden Sie unter Interaktionen mit Routen.

Öffentliche NAT hat keine Cloud Firewallregel-Anforderungen. Firewallregeln werden direkt auf die Netzwerkschnittstellen von Compute Engine-VMs angewendet, nicht auf öffentliche NAT-Gateways.

Sie müssen keine speziellen Firewallregeln erstellen, die Verbindungen zu oder von NAT-IP-Adressen zulassen. Wenn ein öffentliches NAT-Gateway NAT für die Netzwerkschnittstelle einer VM bereitstellt, werden geltende Firewallregeln für ausgehenden Traffic als Pakete für diese Netzwerkschnittstelle vor NAT ausgewertet. Firewallregeln für eingehenden Traffic werden nach der Verarbeitung von Paketen durch NAT ausgewertet.

Anwendbarkeit des Subnetz-IP-Adressbereichs

Sie können das öffentliche NAT-Gateway so konfigurieren, dass NAT für die primäre interne IP-Adresse der VM-Netzwerkschnittstelle, Alias-IP-Bereiche oder beides bereitgestellt wird. Für diese Konfiguration wählen Sie die Subnetz-IP-Adressbereiche aus, für die das Gateway gelten soll.

Sie können ein öffentliches NAT-Gateway so konfigurieren, dass es NAT für Folgendes bereitstellt:

  • Primäre und sekundäre IP-Adressbereiche aller Subnetze in der Region. Ein einzelnes öffentliches NAT-Gateway bietet NAT für die primären internen IP-Adressen und alle Alias-IP-Bereiche berechtigter VMs, deren Netzwerkschnittstellen ein Subnetz in der Region verwenden. Diese Option verwendet genau ein NAT-Gateway pro Region.

  • Primäre IP-Adressbereiche aller Subnetze in der Region. Ein einzelnes öffentliches NAT-Gateway bietet NAT für die primären internen IP-Adressen und Alias-IP-Bereiche aus den primären Subnetz-IP-Adressbereichen kompatibler VMs, deren Netzwerkschnittstellen ein Subnetz in der Region verwenden. Sie können zusätzliche öffentliche NAT-Gateways in der Region erstellen, um NAT für Alias-IP-Bereiche aus sekundären Subnetz-IP-Adressbereichen kompatibler VMs bereitzustellen.

  • Benutzerdefinierte Subnetzliste. Ein einzelnes öffentliches NAT-Gateway bietet NAT für die primären internen IP-Adressen und alle Alias-IP-Bereiche berechtigter VMs, deren Netzwerkschnittstellen ein Subnetz aus einer Liste von bestimmten Subnetzen verwenden.

  • Benutzerdefinierte IP-Adressbereiche des Subnetzes: Sie können so viele öffentliche NAT-Gateways erstellen, wie Sie benötigen. Dabei gelten Kontingente und Limits für öffentliche NAT. Sie wählen aus, welche primären oder sekundären IP-Adressbereiche von jedem Gateway bereitgestellt werden sollen.

Bandbreite

Die Verwendung eines öffentlichen NAT-Gateways ändert nicht die Menge der ausgehenden oder eingehenden Bandbreite, die eine VM verwenden kann. Informationen zu Bandbreitenspezifikationen, die je nach Maschinentyp variieren, finden Sie in der Compute Engine-Dokumentation unter Netzwerkbandbreite.

VMs mit mehreren Netzwerkschnittstellen

Wenn Sie eine VM mit mehreren Netzwerkschnittstellen konfigurieren, muss sich jede Schnittstelle in einem separaten VPC-Netzwerk befinden. Daher gilt Folgendes:

  • Ein öffentliches NAT-Gateway kann nur auf eine einzelne Netzwerkschnittstelle einer VM angewendet werden. Separate öffentliche NAT-Gateways können NAT an dieselbe VM bereitstellen, wobei jedes Gateway auf eine separate Schnittstelle angewendet wird.
  • Eine Schnittstelle auf einer VM mit mehreren Netzwerkschnittstellen kann eine externe IP-Adresse haben, sodass diese Schnittstelle nicht für die öffentliche NAT infrage kommt. Eine andere Schnittstelle kann hingegen keine NAT haben, wenn diese Schnittstelle keine externe IP-Adresse hat und Sie ein öffentliches NAT-Gateway für den entsprechenden Subnetz-IP-Adressbereich konfiguriert haben.

NAT-IP-Adressen und -Ports

Wenn Sie ein öffentliches NAT-Gateway erstellen, können Sie festlegen, dass das Gateway automatisch regionale externe IP-Adressen zuweist. Alternativ können Sie dem Gateway manuell eine feste Anzahl regionaler externer IP-Adressen zuweisen.

Beachten Sie für ein öffentliches NAT-Gateway mit automatischer NAT-IP-Adresszuweisung Folgendes:

  • Sie können die Netzwerkdienststufen (Premium-Stufe- oder Standardstufe) auswählen, von denen das öffentliche NAT-Gateway die IP-Adressen zuweist.

  • Wenn Sie die Stufe für ein öffentliches NAT-Gateway ändern, das automatisch NAT-IP-Adressen zugewiesen hat, gibt Google Cloud alle zugewiesenen IP-Adressen für dieses Gateway frei und deaktiviert alle Portzuweisungen.

    Es werden automatisch neue IP-Adressen der neu ausgewählten Stufe zugewiesen und allen Endpunkten werden neue Portzuweisungen zugewiesen.

Für ein bestimmtes öffentliches NAT-Gateway können Sie unter bestimmten Bedingungen auch manuell IP-Adressen aus der Premium- oder Standardstufe oder aus beiden zuweisen.

Weitere Informationen zur NAT-IP-Adresszuweisung finden Sie unter Öffentliche NAT-IP-Adressen.

Sie können die Anzahl der Quellports konfigurieren, die jedes öffentliche NAT-Gateway auf jeder VM reserviert, für die es NAT-Dienste bereitstellen soll. Sie können die statische Portzuweisung konfigurieren, wobei für jede VM die gleiche Anzahl von Ports reserviert ist, oder die dynamische Portzuweisung, bei der die Anzahl der reservierten Ports zwischen den von Ihnen angegebenen Mindest- und Höchstzahlen variieren kann.

Die VMs, für die NAT bereitgestellt werden soll, werden durch die Subnetz-IP-Adressbereiche bestimmt, die das Gateway für die Bereitstellung konfiguriert.

Weitere Informationen zu Ports finden Sie unter Ports.

Anwendbare RFCs

Die öffentliche NAT unterstützt die endpunktunabhängige Zuordnung und die endpunktabhängige Filterung wie in RFC 5128 definiert. Sie können die endpunktunabhängige Zuordnung aktivieren oder deaktivieren. Standardmäßig ist die endpunktunabhängige Zuordnung deaktiviert, wenn Sie ein NAT-Gateway erstellen.

Endpunktunabhängige Zuordnung bedeutet Folgendes: Wenn eine VM Pakete über ein bestimmtes Paar aus interner IP-Adresse und Port an verschiedene Ziele sendet, ordnet das Gateway alle diese Pakete demselben Paar aus NAT-IP-Adresse und Port zu, unabhängig vom Ziel der Pakete. Weitere Informationen und Auswirkungen auf die endpunktunabhängige Zuordnung finden Sie unter Gleichzeitige Portwiederverwendung und endpunktunabhängige Zuordnung.

Endpunktabhängige Filterung bedeutet, dass Antwortpakete aus dem Internet nur dann eingehen dürfen, wenn sie von einer IP-Adresse und einem Port stammen, an die eine VM bereits Pakete gesendet hat. Die Filterung ist unabhängig vom Endpunktzuordnungstyp. Dieses Feature ist immer aktiviert und kann vom Nutzer nicht konfiguriert werden.

Weitere Informationen zur Beziehung zwischen Ports und Verbindungen finden Sie unter Ports und Verbindungen sowie im Beispiel für NAT-Ablauf.

Die öffentliche NAT ist eine Port-eingeschränkte kegelförmige NAT gemäß der Definition in RFC 3489.

NAT-Durchlauf

Wenn die endpunktunabhängige Zuordnung aktiviert ist, ist die öffentliche NAT mit gängigen NAT-Durchlaufprotokollen wie STUN und TURN kompatibel, wenn Sie Ihre eigenen STUN- oder TURN-Server bereitstellen:

  • STUN (Session Traversal Utilities for NAT, RFC 5389) ermöglicht die direkte Kommunikation zwischen VMs hinter NAT, wenn ein Kommunikationskanal eingerichtet wurde.
  • TURN (Traversal Using Relays around NAT, RFC 5766) ermöglicht die Kommunikation zwischen VMs hinter NAT über einen Drittanbieter-Server, auf dem dieser Server eine externe IP-Adresse hat. Jede VM stellt eine Verbindung zur externen IP-Adresse des Servers her und dieser Server leitet die Kommunikation zwischen den beiden VMs weiter. TURN ist robuster, verbraucht jedoch mehr Bandbreite und Ressourcen.

NAT-Zeitlimits

Öffentliche NAT-Gateways verwenden die folgenden Zeitlimits. Sie können die Standardwerte für Zeitlimits ändern, um die Häufigkeit, mit der Ports wiederverwendet werden, zu verringern oder zu erhöhen. Jeder Zeitüberschreitungswert ist ein Gleichgewicht zwischen einer effizienten Nutzung öffentlicher NAT-Ressourcen und einer möglichen Unterbrechung aktiver Verbindungen, Abläufe oder Sitzungen.

Zeitlimit Beschreibung Standardmäßige NAT-Standardeinstellung Konfigurierbar

Zeitlimit bei Inaktivität für UDP-Zuordnung

RFC 4787 REQ-5

Gibt die Zeit in Sekunden an, nach der kein UDP-Datenverkehr mehr an Endpunkte gesendet werden muss, damit die öffentlichen NAT-Zuordnungen entfernt werden.

Das Zeitlimit bei Inaktivität für die UDP-Zuordnung wirkt sich auf zwei Endpunkte aus, die keinen Traffic mehr aneinander senden. Sie wirkt sich auch auf Endpunkte aus, deren Reaktionszeit länger ist oder die die Netzwerklatenz erhöhen.

Sie können den angegebenen Wert für die Zeitüberschreitung erhöhen, um die Häufigkeit zu reduzieren, mit der Ports wiederverwendet werden können. Ein größerer Zeitüberschreitungswert bedeutet, dass die Ports für längere Verbindungen gehalten werden und auch vor Traffic-Pausen über einen bestimmten UDP-Socket geschützt sind.

30 Sekunden Ja

Zeitlimit bei Inaktivität für hergestellte TCP-Verbindung

RFC 5382 REQ-5

Gibt die Zeit in Sekunden an, die eine Verbindung inaktiv ist, bevor die öffentlichen NAT-Zuordnungen entfernt werden.

Das Zeitlimit für inaktive eingerichtete TCP-Verbindungen wirkt sich auf Endpunkte aus, deren Reaktionszeit länger ist oder die die Netzwerklatenz erhöhen.

Sie können den Wert für die Zeitüberschreitung erhöhen, wenn Sie TCP-Verbindungen öffnen und die Verbindungen für einen längeren Zeitraum ohne Keepalive-Mechanismus geöffnet lassen möchten.

1.200 Sekunden (20 Minuten) Ja

Zeitlimit bei Inaktivität für vorübergehende TCP-Verbindung

RFC 5382 REQ-5

Gibt die Zeit in Sekunden an, die TCP-Verbindungen im halboffenen Zustand bleiben können, bevor die öffentlichen NAT-Zuordnungen gelöscht werden.

Das Zeitlimit für inaktive temporäre TCP-Verbindungen wirkt sich auf einen Endpunkt aus, wenn ein externer Endpunkt länger als die angegebene Zeit dauert oder die Netzwerklatenz zunimmt. Im Gegensatz zum Zeitlimit für inaktive eingerichtete TCP-Verbindungen wirkt sich das Zeitlimit bei Inaktivität für temporäre Verbindungen nur auf halboffene Verbindungen aus.

30 Sekunden

Hinweis:Unabhängig vom Wert, den Sie für dieses Zeitlimit festlegen, kann die öffentliche NAT bis zu weiteren 30 Sekunden benötigen, bevor ein Semikolon aus der öffentlichen NAT-Quell-IP-Adresse und dem Quellport für die Verarbeitung einer neuen Verbindung verwendet werden kann.

 Ja

Zeitlimit für TCP-TIME_WAIT

RFC 5382 REQ-5

Gibt die Zeit in Sekunden an, die eine vollständig geschlossene TCP-Verbindung in den öffentlichen NAT-Zuordnungen beibehalten wird, nachdem die Verbindung abgelaufen ist.

Das TCP-TIME_WAIT-Zeitlimit schützt Ihre internen Endpunkte vor ungültigen Paketen, die zu einer geschlossenen TCP-Verbindung gehören, die noch einmal übertragen werden.

Sie können den Wert für die Zeitüberschreitung verringern, um die Wiederverwendung von öffentlichen NAT-Ports zu verbessern. Kosten dafür sind möglicherweise das Empfangen von neu übertragenen Paketen von einer nicht verbundenen, zuvor geschlossenen Verbindung.

120 Sekunden

Hinweis:Unabhängig vom Wert, den Sie für dieses Zeitlimit festlegen, kann die öffentliche NAT bis zu weiteren 30 Sekunden benötigen, bevor ein Semikolon aus der öffentlichen NAT-Quell-IP-Adresse und dem Quellport für die Verarbeitung einer neuen Verbindung verwendet werden kann.

 Ja

Zeitlimit bei Inaktivität für ICMP-Zuordnung

RFC 5508 REQ-2

Gibt die Zeit in Sekunden an, nach der öffentliche NAT-Zuordnungen (Internet Control Message Protocol) ohne Trafficflüsse geschlossen werden.

Das Zeitlimit für die Inaktivitätszuordnung von ICMP wirkt sich auf einen Endpunkt aus, wenn der Endpunkt länger auf die angegebene Zeit braucht oder die Netzwerklatenz zunimmt.

30 Sekunden Ja

Nächste Schritte