Cloud NAT – Überblick

Mit Cloud NAT (Network Address Translation) können Google Cloud-VM-Instanzen ohne externe IP-Adressen und private GKE-Cluster (Google Kubernetes Engine) ausgehende Pakete an das Internet senden und entsprechende verarbeitete eingehende Antwortpakete erhalten.

Architektur

Cloud NAT ist ein verteilter, softwarebasierter verwalteter Dienst. Cloud NAT basiert nicht auf Proxy-VMs oder -Appliances. Cloud NAT konfiguriert die Andromeda-Software, die Ihr VPC-Netzwerk (Virtual Private Cloud) unterstützt, um SNAT (Source Network Address Translation) für VMs ohne externe IP-Adressen zu ermöglichen. Cloud NAT bietet auch DNAT (Destination Network Address) für verarbeitete eingehende Antwortpakete.

Traditionelle NAT im Vergleich zu Cloud NAT (zum Vergrößern klicken).
Traditionelle NAT im Vergleich zu Cloud NAT (zum Vergrößern klicken)

Cloud NAT implementiert ausgehende NAT in Verbindung mit statischen Routen in Ihrem VPC-Netzwerk, dessen nächster Hop das Standard-Internetgatewayist. In einer grundlegenden Konfiguration erfüllt eine Standardroute in Ihrem VPC-Netzwerk diese Anforderung.

Cloud NAT implementiert keine unerwünschten eingehenden Verbindungen aus dem Internet. DNAT wird nur für Pakete ausgeführt, die als Antworten auf ausgehende Pakete eingehen.

Vorteile

Cloud NAT bietet folgende Vorteile:

  • Sicherheit

    Sie können die Notwendigkeit der Zuweisung einzelner IP-Adressen für einzelne VMs reduzieren. Je nach Firewallregeln für ausgehenden Traffic können VMs ohne externe IP-Adressen auf Ziele im Internet zugreifen. Möglicherweise haben Sie VMs, die nur Internetzugriff benötigen, um Updates herunterzuladen oder die Bereitstellung abzuschließen.

    Wenn Sie zur Konfiguration eines Cloud NAT-Gateways die manuelle NAT-IP-Adresszuweisung verwenden, können Sie eine Reihe häufig verwendeter externer Quell-IP-Adressen für eine Zielpartei freigeben. Ein Zieldienst lässt beispielsweise nur Verbindungen von bekannten externen IP-Adressen zu.

  • Verfügbarkeit

    Cloud NAT ist ein verteilter, softwarebasierter verwalteter Dienst, der nicht von VMs in Ihrem Projekt oder einem einzelnen physischen Gateway-Gerät abhängt. Sie konfigurieren ein NAT-Gateway auf einem Cloud Router, der die Steuerungsebene für NAT mit von Ihnen angegebenen Konfigurationsparametern bereitstellt. Google Cloud führt Prozesse auf den physischen Maschinen aus, auf denen Ihre Google Cloud-VMs ausgeführt werden, und verwaltet diese.

  • Skalierbarkeit

    Cloud NAT kann so konfiguriert werden, dass die Anzahl der verwendeten NAT-IP-Adressen automatisch skaliert wird. VMs, die zu verwalteten Instanzgruppen gehören, einschließlich Autoscaling, werden unterstützt.

  • Leistung

    Cloud NAT reduziert nicht die Netzwerkbandbreite pro VM. Cloud NAT wird vom softwarebasierten Netzwerk Andromeda von Google implementiert. Weitere Informationen finden Sie in der Dokumentation zu Compute Engine unter Netzwerkbandbreite.

Spezifikationen

Cloud NAT kann so konfiguriert werden, dass dem Internet NAT für Pakete bereitgestellt wird, die gesendet werden über:

  • Die primäre interne IP-Adresse der 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. Wenn eine externe IP-Adresse einer Schnittstelle zugewiesen ist, hat diese immer Vorrang und 1:1-NAT wird ohne Cloud NAT ausgeführt.

  • 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 Cloud 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.

Cloud NAT ermöglicht ausgehende und eingehende Antworten an diese Verbindungen. Jedes Cloud NAT-Gateway führt SNAT (Source Network Address Translation) für ausgehenden Traffic und DNAT (Destination Network Address Translation) für verarbeitete Antwortpakete aus.

Cloud NAT erlaubt keine unerwünschten eingehenden Anfragen aus dem Internet, auch wenn Firewallregeln diese Anfragen andernfalls zulassen würden. Weitere Informationen finden Sie unter Anwendbare RFCs.

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

Routen und Firewallregeln

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

Cloud NAT hat keine Anforderungen an Google Cloud-Firewallregeln. Firewallregeln werden direkt auf die Netzwerkschnittstellen von Compute Engine-VMs angewendet, nicht auf Cloud NAT-Gateways.

Sie müssen keine spezifischen Firewallregeln erstellen, die Verbindungen zu oder von NAT-IP-Adressen zulassen. Wenn ein Cloud NAT-Gateway NAT für die Netzwerkschnittstelle einer VM bereitstellt, werden geltende Firewallregeln für ausgehenden Traffic als Pakete für diese Netzwerkschnittstelle vor der Ausführung von NAT ausgewertet. Firewallregeln für eingehenden Traffic werden ausgewertet, nachdem Pakete von NAT verarbeitet wurden.

Anwendbarkeit des Subnetz-IP-Adressbereichs

Ein Cloud NAT-Gateway kann NAT-Dienste für Pakete bereitstellen, die von der Netzwerkschnittstelle einer VM gesendet werden, sofern der Netzwerkschnittstelle keine externe IP-Adresse zugewiesen ist. Das Cloud NAT-Gateway kann so konfiguriert werden, dass es NAT für die primäre interne IP-Adresse der VM-Netzwerkschnittstelle, Alias-IP-Bereiche oder beides bereitstellt. Für diese Konfiguration wählen Sie die Subnetz-IP-Adressbereiche aus, für die das Gateway gelten soll.

Sie können ein Cloud NAT-Gateway konfigurieren, um NAT für Folgendes bereitzustellen:

  • Primäre und sekundäre IP-Adressbereiche aller Subnetze in der Region. Ein einzelnes Cloud 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 Cloud NAT-Gateway bietet NAT für die primären internen IP-Adressen und Alias-IP-Bereiche aus den primären IP-Adressbereichen der zulässigen VMs, deren Netzwerkschnittstellen ein Subnetz in der Region verwenden. Sie können zusätzliche Cloud NAT-Gateways in der Region erstellen, um NAT für Alias-IP-Bereiche aus den sekundären IP-Adressbereichen der zulässigen VMs bereitzustellen.

  • Benutzerdefinierte IP-Adressbereiche des Subnetzes: Sie können unter Cloud NAT-Kontingente und -Limits so viele Cloud NAT-Gateways wie erforderlich erstellen. Sie entscheiden, welche primären oder sekundären IP-Adressbereiche von jedem Gateway bereitgestellt werden sollen.

Bandbreite

Die Verwendung eines Cloud NAT-Gateways wirkt sich nicht auf die Größe der von einer VM verwendeten ausgehenden oder eingehenden Bandbreite aus. Informationen zu Bandbreitenspezifikationen, die je nach Maschinentyp variieren, finden Sie unter Netzwerkbandbreite in der Compute Engine-Dokumentation.

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 Cloud NAT-Gateway kann nur auf eine einzelne Netzwerkschnittstelle einer VM angewendet werden. Separate Cloud NAT-Gateways können NAT auf derselben VM bereitstellen, wobei jedes Gateway für eine separate Schnittstelle gilt.

  • Wenn eine der Schnittstellen einer VM mit mehreren Netzwerkschnittstellen eine externe IP-Adresse hat, kommt sie für Cloud NAT nicht infrage. Eine der anderen Schnittstellen kann jedoch für NAT infrage kommen, wenn sie keine externe IP-Adresse hat und ein Cloud NAT-Gateway für den entsprechenden Subnetz-IP-Adressbereich konfiguriert wurde.

NAT-IP-Adressen und Ports

Wenn Sie ein Cloud 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. Weitere Informationen zu den einzelnen Methoden finden Sie unter NAT-IP-Adressen.

Sie können die Anzahl der Quellports konfigurieren, die jedes Cloud NAT-Gateway für jede VM reserviert, für die NAT-Dienste bereitgestellt werden sollen. Die VMs, für die NAT bereitgestellt werden soll, richten sich nach den Subnetz-IP-Adressbereichen, die für die Bereitstellung des Gateways konfiguriert sind. Weitere Informationen finden Sie unter Ports und im Verfahren zur Portreservierung.

Anwendbare RFCs

Cloud 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 verwendet das NAT-Gateway die endpunktunabhängige Zuordnung.

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 endpunktabhängig, unabhängig vom Typ der Endpunktzuordnung. 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.

Cloud NAT ist eine Port-eingeschränkte Cone-NAT, wie in RFC 3489 definiert.

NAT-Durchlauf

Wenn die endpunktunabhängige Zuordnung aktiviert ist, ist Cloud 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

Cloud NAT-Gateways verwenden die folgenden Zeitlimits.

Zeitlimit Cloud NAT-Standardeinstellung Konfigurierbar

Zeitlimit bei Inaktivität für UDP-Zuordnung

RFC 4787 REQ-5

30 Sekunden Ja

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

RFC 5382 REQ-5

1.200 Sekunden (20 Minuten) Ja

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

RFC 5382 REQ-5

30 Sekunden

Hinweis: Unabhängig von dem Wert, den Sie für dieses Zeitlimit festgelegt haben, benötigt Cloud NAT möglicherweise weitere 30 Sekunden, bevor ein Tupel aus NAT-Quell-IP-Adresse und Quellport zur Verarbeitung einer neuen Verbindung verwendet werden kann.

Ja

Zeitlimit bei Inaktivität für ICMP-Zuordnung

RFC 5508 REQ-2

30 Sekunden Ja
Verzögerung, bis ein 5-Tupel für eine neue TCP-Verbindung wiederverwendet wird (NAT-Quell-IP-Adresse und Quellport-Tupel kombiniert mit Zieladresse, Zielport und Protokoll) 120 Sekunden (2 Minuten)

Nein

Weitere Informationen finden Sie unter Verzögerung für die Wiederverwendung des TCP-Quellports.

Produktinteraktionen

In den folgenden Abschnitten werden wichtige Interaktionen zwischen Cloud NAT und anderen Google Cloud-Produkten beschrieben.

Interaktionen mit Routen

Ein Cloud NAT-Gateway kann nur Routen verwenden, deren nächster Hop das Standard-Internetgateway ist. Jedes VPC-Netzwerk 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, dass Cloud NAT-Gateways nicht funktionieren:

  • Wenn Sie eine benutzerdefinierte statische Route mit nächsten Hops erstellen, die auf den nächsten Hop einer beliebigen anderen benutzerdefinierten 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 NAT-, Firewall- oder Proxysoftware ausgeführt wird, müssen Sie benutzerdefinierte statische Routen erstellen, um Traffic an diese VMs als nächsten Hop weiterzuleiten. Die VMs des nächsten Hops erfordern externe IP-Adressen. Daher kann Traffic weder von den VMs, die auf den VMs des nächsten Hops basieren, noch von den VMs des nächsten Hops Cloud NAT verwenden.

  • Wenn Sie eine benutzerdefinierte statische Route erstellen, deren nächster Hop ein Cloud VPN-Tunnel ist, verwendet Cloud NAT diese Route nicht. Beispiel: Eine benutzerdefinierte 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 Cloud NAT-Gateways diese Route nicht verwenden. Dies gilt auch für spezifischere Ziele wie 0.0.0.0/1 und 128.0.0.0/1.

  • Wenn ein lokaler Router eine benutzerdefinierte dynamische Route für einen Cloud Router bewirbt, der einen Cloud VPN-Tunnel oder einen Cloud Interconnect-Anhang (VLAN) verwaltet, können Cloud NAT-Gateways diese Route nicht verwenden. Wenn Ihr lokaler Router beispielsweise eine benutzerdefinierte dynamische Route mit dem Ziel 0.0.0.0/0 bewirbt, wird 0.0.0.0/0 an den Cloud VPN-Tunnel oder den Cloud Interconnect-Anhang (VLAN) weitergeleitet. Dies gilt auch für spezifischere Ziele wie 0.0.0.0/1 und 128.0.0.0/1.

Interaktion mit privatem Google-Zugriff

Cloud NAT führt NAT nicht 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 privaten Google-Zugriff für einen Subnetz-IP-Adressbereich, wenn Sie ein Cloud 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 Cloud NAT-Gateway ändert nicht die Funktionsweise des privaten Google-Zugriffs. Weitere Informationen finden Sie unter 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 Cloud NAT-Gateway kann NAT für Knoten und Pods in einem privaten Cluster ausführen, der eine Art VPC-nativer Cluster ist. Das Cloud 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 eines Cloud 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 Cloud 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. Da der kleinste mögliche Pod-IP-Adressbereich 256 IP-Adressen (Subnetzmaske von /24) hat, reserviert das Portreservierungsverfahren von Cloud NAT mindestens 1.024 NAT-Quell-IP-Adressen und Quellports pro Knoten. Informationen zu Pod-IP-Adressbereichen und VPC-nativen Clustern finden Sie unter Sekundärer IP-Adressbereich des Subnetzes für Pods.

Unabhängig von Cloud NAT führt GKE SNAT mit 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 Cloud NAT auch für nicht private Cluster nützlich sein, einschließlich VPC-nativer und routenbasierter 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, nie von Cloud NAT verarbeitet. Pakete, die von Pods in einem nicht privaten Cluster gesendet werden, können jedoch von einem Cloud NAT-Gateway verarbeitet werden, wenn die beiden folgenden Bedingungen zutreffen:

  • Bei VPC-nativen Clustern ist das Cloud 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.

Interaktionen mit Cloud Load Balancing

Externe Load-Balancer und Systemdiagnosesysteme von Google Cloud kommunizieren mithilfe von speziellen Routen 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.

Beispiele

Die folgenden Beispiele veranschaulichen Cloud NAT-Konzepte.

Grundlegende NAT-Konfiguration

Cloud NAT (zum Vergrößern klicken).
Cloud NAT (zum Vergrößern klicken)

In diesem Beispiel:

  • 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 Cloud 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.

GKE-Beispiel

Cloud NAT mit GKE (zum Vergrößern klicken)
Cloud 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 Subnetz 1 als NAT-Kandidaten auswählen. NAT kann nur für container1 oder container2 aktiviert werden.

Weitere Informationen