NAT-Gatewayressource

In diesem Artikel werden die wichtigsten Komponenten einer NAT-Gatewayressource (Network Address Translation) beschrieben, die es ermöglicht, eine hochgradig sichere, skalierbare und robuste ausgehende Konnektivität bereitzustellen. NAT-Gatewayressourcen sind Teil des Azure NAT Gateway-Diensts.

Sie können ein NAT-Gateway in Ihrem Abonnement über unterstützte Clients konfigurieren. Zu diesen Clients gehören das Azure Portal, die Azure CLI, Azure PowerShell, Azure Resource Manager Vorlagen oder geeignete Alternativen.

Azure NAT-Gateway-Bestandseinheiten

Azure NAT Gateway ist in zwei SKUs verfügbar: StandardV2 und Standard.

Diagramm der Standard- und StandardV2-SKUs von Azure NAT Gateway.

Die StandardV2-SKU ist standardmäßig zonenredundant. Es erstreckt sich automatisch über mehrere Verfügbarkeitszonen in einer Region, um eine fortgesetzte ausgehende Konnektivität bereitzustellen, auch wenn eine Zone nicht verfügbar ist.

Die Standard-SKU ist eine zonale Ressource. Sie wird in einer bestimmten Verfügbarkeitszone bereitgestellt und ist innerhalb dieser Zone stabil.

Ein StandardV2 NAT-Gateway unterstützt IPv4- und IPv6-öffentliche IPs, während ein Standard-NAT-Gateway nur öffentliche IPs von IPv4 unterstützt.

Azure NAT Gateway Architektur

Azure NAT Gateway verwendet softwaredefinierte Netzwerke, um als vollständig verwalteter, verteilter Dienst zu arbeiten. Im Entwurf umfasst ein NAT-Gateway mehrere Fehlerdomänen, sodass es mehreren Fehlern standhält, ohne dass der Dienst wirksam wird.

Azure NAT Gateway stellt die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) für private Instanzen innerhalb der zugehörigen Subnetze Ihres Azure virtuellen Netzwerks bereit. Die privaten IPs der virtuellen Computer verwenden SNAT für die statischen öffentlichen IP-Adressen eines NAT-Gateways, um ausgehende Verbindungen mit dem Internet herzustellen. Azure NAT Gateway stellt auch die Zielnetzwerkadressenübersetzung (DNAT) für Antwortpakete nur für ausgehende Verbindungen bereit.

Diagramm einer NAT-Gatewayressource mit virtuellen Computern für ausgehende Verbindungen mit dem Internet.

Wenn ein NAT Gateway in einem Subnetz innerhalb eines Virtual Network konfiguriert ist, wird es zum Standardmäßigen nächsten Hoptyp des Subnetzes für den gesamten ausgehenden Datenverkehr, der an das Internet weitergeleitet wird. Es sind keine zusätzlichen Routingkonfigurationen erforderlich. Ein NAT-Gateway stellt keine unerwünschten eingehenden Verbindungen aus dem Internet bereit. DNAT wird nur für Pakete durchgeführt, die als Antwort auf ein ausgehendes Paket eingehen.

Subnetze

Sie können ein StandardV2- oder Standard-NAT-Gateway an mehrere Subnetze innerhalb eines virtuellen Netzwerks anfügen, um ausgehende Verbindungen mit dem Internet bereitzustellen. Wenn ein NAT-Gateway an ein Subnetz angefügt ist, wird davon ausgegangen, dass die Standardroute zum Internet erfolgt. Das NAT Gateway dient als nächster Hoptyp für den gesamten ausgehenden Datenverkehr, der für das Internet bestimmt ist.

NAT-Gateways haben diese Einschränkungen für Subnetzkonfigurationen:

  • Jedes Subnetz kann nur ein NAT-Gateway zugeordnet haben.

  • Sie können kein NAT-Gateway an Subnetze aus verschiedenen virtuellen Netzwerken anfügen.

  • Sie können kein NAT-Gateway mit einem Gateway-Subnetz verwenden. Ein Gatewaysubnetz ist ein bestimmtes Subnetz für ein VPN-Gateway, das verschlüsselten Datenverkehr zwischen einem virtuellen Azure-Netzwerk und einem lokalen Standort sendet.

Statische öffentliche IP-Adressen

Ein NAT-Gateway kann statischen öffentlichen IP-Adressen oder öffentlichen IP-Präfixen zugeordnet werden. Wenn Sie ein Präfix für öffentliche IP-Adressen zuweisen, wird dieses vollständig verwendet. Sie können ein öffentliches IP-Präfix direkt verwenden oder die öffentlichen IP-Adressen des Präfixes über mehrere NAT-Gatewayressourcen verteilen. Das NAT-Gateway sendet den gesamten Datenverkehr an den Bereich der IP-Adressen des Präfixes.

Diese Bedingungen gelten:

  • Ein STANDARDV2 NAT-Gateway unterstützt bis zu 16 IPv4- und 16 IPv6-IP-Adressen.

  • Sie können kein Standard-NAT-Gateway mit öffentlichen IPv6-IP-Adressen oder Präfixen verwenden. Ein Standard-NAT-Gateway unterstützt bis zu 16 öffentliche IPv4-IP-Adressen.

  • Sie können kein NAT-Gateway mit öffentlichen IP-Adressen für die Standard-SKU verwenden.

Azure NAT Gateway-SKU IPv4 IPv6
StandardV2 Ja, unterstützt öffentliche IPv4-IP-Adressen und Präfixe. Ja, unterstützt öffentliche IPv6-IP-Adressen und Präfixe.
Norm Ja, unterstützt öffentliche IPv4-IP-Adressen und Präfixe. Nein, unterstützt keine öffentlichen IPv6-IP-Adressen und Präfixe.

NAT64

Diagramm des IPv6-Verkehrs zum IPv4-Ziel mit aktiviertem NAT64 auf dem StandardV2 NAT Gateway.

StandardV2 NAT-Gateways unterstützen NAT64, um IPv6-Workloads zu ermöglichen, mit IPv4-only-Internetzielen zu kommunizieren, indem ausgehender IPv6-Verkehr, der für das Well-Known Prefix64:ff9b::/96 bestimmt ist, in IPv4-Verkehr übersetzt wird.

Wie man NAT64 aktiviert

Um NAT64 zu aktivieren, gehe im Azure-Portal zu deiner StandardV2 NAT Gateway-Ressource, gehe zu Konfiguration, setze NAT64 auf Aktiviert und speichere. Legen Sie alternativ die Eigenschaft nat64 für die NAT-Gateway-Ressource über die ARM/REST-API auf Enabled fest. Für PowerShell- und CLI-Unterstützung besuchen Sie az network nat gateway | Microsoft Learn and New-AzNatGateway (Az.Network) | Microsoft Learn.

NAT64 benötigt mindestens eine StandardV2-IPv4-öffentliche IP-Adresse, die für die ausgehende Übersetzung an das NAT-Gateway angeschlossen ist.

DNS64-Anforderung

Hinweis

NAT64 benötigt eine Drittanbieter-DNS64-Lösung, um AAAA-Datensätze für IPv4-only-Ziele zu synthetisieren.

DNS64 synthetisiert AAAA-(IPv6)-Datensätze für Domains, die nur A-(IPv4)-Datensätze besitzen. Ohne DNS64 können IPv6-Clients reine IPv4-Ziele nicht in das bekannte NAT64-Präfix auflösen.

Wie NAT64 funktioniert

  1. Ein Client löst einen Hostnamen über einen DNS64-Resolver. Existiert nur ein A-(IPv4)-Datensatz, synthetisiert der Resolver einen AAAA-Datensatz, indem er die IPv4-Adresse in das 64:ff9b::/96 Präfix einbettet.
  2. Der Client sendet ein IPv6-Paket an die synthetisierte Adresse und behandelt es als normales IPv6-Ziel.
  3. NAT Gateway erkennt das 64:ff9b::/96 Präfix, extrahiert die eingebettete IPv4-Adresse aus den letzten 32 Bit und übersetzt das Paket von IPv6 zu IPv4 mittels SNAT mit seiner konfigurierten öffentlichen IPv4-Adresse.
  4. Die IPv4-Antwort wird zurück in IPv6 übersetzt und an den Client zurückgegeben.

SNAT-Ports

Das SNAT-Portinventar wird von öffentlichen IP-Adressen, öffentlichen IP-Präfixen oder beidem bereitgestellt, die an ein NAT-Gateway angefügt sind. SNAT-Portinventar ist bei Bedarf für alle Instanzen innerhalb eines Subnetzes verfügbar, das an das NAT-Gateway angefügt ist. Es ist keine vorherige Zuteilung von SNAT-Ports pro Instanz erforderlich.

Weitere Informationen zu SNAT-Ports und Azure NAT Gateway finden Sie unter Adressenübersetzung für das Quellnetzwerk (Source Network Address Translation, SNAT) mit Azure NAT Gateway.

Wenn mehrere Subnetze innerhalb eines virtuellen Netzwerks mit derselben NAT-Gatewayressource verbunden sind, wird der SNAT-Portbestand, den das NAT-Gateway bereitstellt, für alle Subnetze freigegeben.

SNAT-Ports dienen als eindeutige Bezeichner, um Verbindungsflüsse voneinander zu unterscheiden. Derselbe SNAT-Port kann für die gleichzeitige Verbindung mit verschiedenen Zielendpunkten verwendet werden.

Verschiedene SNAT-Ports werden verwendet, um Verbindungen mit demselben Zielendpunkt herzustellen, um Verbindungsflüsse voneinander zu unterscheiden. SNAT-Ports, die wiederverwendet werden, um eine Verbindung mit demselben Ziel herzustellen, werden auf einem Wiederverwendungs-Cool-Down-Timer platziert, bevor sie wiederverwendet werden können.

Diagramm: SNAT-Portzuordnung.

Ein einzelnes NAT-Gateway kann um die Anzahl der damit verbundenen öffentlichen IP-Adressen skaliert werden. Jede öffentliche IP-Adresse für ein NAT-Gateway stellt 64.512 SNAT-Ports bereit, um ausgehende Verbindungen herzustellen. Ein NAT-Gateway kann bis zu mehr als 1 Million SNAT-Ports skalieren. TCP und UDP sind separate SNAT-Portinventare und sind nicht mit NAT-Gateways verknüpft.

Verfügbarkeitszonen

Azure NAT Gateway hat zwei SKUs: Standard und StandardV2. Um sicherzustellen, dass Ihre Architektur für Zonenfehler widerstandsfähig ist, stellen Sie ein StandardV2 NAT-Gateway bereit, da es sich um eine zonenredundante Ressource handelt. Wenn eine Verfügbarkeitszone in einer Region ausfällt, fließen neue Verbindungen aus den verbleibenden intakten Zonen.

Diagramm der Bereitstellung mehrerer Zonen eines StandardV2-NAT-Gateways.

Ein Standard-NAT-Gateway ist eine Zonalressource, was bedeutet, dass Sie es aus einzelnen Verfügbarkeitszonen bereitstellen und betreiben können. Wenn die Zone ausfällt, die einem Standard-NAT-Gateway zugeordnet ist, ist die ausgehende Konnektivität der Subnetze betroffen, die dem NAT-Gateway zugeordnet sind.

Weitere Informationen zu Verfügbarkeitszonen und Azure NAT Gateway finden Sie unter Zuverlässigkeit in Azure NAT Gateway.

Diagramm einer einzelzonenbasierten Bereitstellung eines Standard-NAT-Gateways.

Nachdem Sie ein NAT-Gateway bereitgestellt haben, können Sie die Zonenauswahl nicht mehr ändern.

Protokolle

Ein NAT-Gateway interagiert mit IP- und IP-Transportheadern von UDP- und TCP-Flüssen. Ein NAT-Gateway ist für Anwendungsschichtnutzlasten agnostisch. StandardV2 NAT Gateway unterstützt auch ICMP Echo Request und Echo Reply (Ping). Andere ICMP-Nachrichtentypen werden nicht unterstützt.

Hinweis

Azure StandardV2 NAT Gateway unterstützt ausgehende Internet Control Message Protocol (ICMP) Echo Request und Echo Reply (Ping) sowohl für IPv4 als auch für IPv6. Diese Funktion wird standardmäßig bereitgestellt und erfordert keine zusätzliche Konfiguration. Sie können das Ping-Tool (ICMP Echo) verwenden, um ausgehende Konnektivität zu überprüfen und Probleme mit der Reichweite von Arbeitslasten schnell zu diagnostizieren. Schritte zum Überprüfen der Konnektivität finden Sie unter Überprüfen der NAT-Gatewaykonnektivität.

TCP-Zurücksetzung

Ein TCP-Zurücksetzungspaket wird gesendet, wenn ein NAT-Gateway Datenverkehr für einen Verbindungsflow erkennt, der nicht vorhanden ist. Das TCP-Reset-Paket signalisiert dem empfangenden Endpunkt, dass der Verbindungsfluss freigegeben wurde und jede zukünftige Kommunikation über dieselbe TCP-Verbindung fehlschlagen wird. Ein TCP-Reset ist bei einem NAT-Gateway unidirektional.

Der Verbindungsfluss ist möglicherweise nicht vorhanden, wenn:

  • Die Verbindung hat das Leerlauftimeout nach einer Zeit der Inaktivität für den Verbindungsfluss erreicht, und die Verbindung wird im Hintergrund gelöscht.

  • Der Absender, entweder aus dem Azure-Netzwerk oder aus dem öffentlichen Internet, hat nach dem Trennen der Verbindung Daten gesendet.

Das System sendet ein TCP-Reset-Paket nur, wenn es Datenverkehr im verworfenen Verbindungsfluss feststellt. Dieser Vorgang bedeutet, dass ein TCP-Zurücksetzungspaket möglicherweise nicht sofort gesendet wird, nachdem ein Verbindungsfluss abfällt.

Das System sendet ein TCP-Zurücksetzungspaket als Reaktion auf die Erkennung von Datenverkehr in einem nicht vorhandenen Verbindungsfluss, unabhängig davon, ob der Datenverkehr von der Azure Netzwerkseite oder der öffentlichen Internetseite stammt.

TCP-Leerlauftimeout

Ein NAT-Gateway bietet eine konfigurierbare Leerlauftimeout-Spanne von 4 bis 120 Minuten für TCP-Protokolle. Für UDP-Protokolle gilt ein nicht konfigurierbarer Leerlauftimeout von 4 Minuten.

Wenn eine Verbindung inaktiv wird, reserviert das NAT-Gateway den SNAT-Port, bis das Leerlaufzeitlimit der Verbindung abläuft. Da lange Leerlauf-Timeouts die Wahrscheinlichkeit einer Erschöpfung der SNAT-Ports unnötig erhöhen können, empfehlen wir nicht, die Dauer des TCP-Leerlaufzeitlimits über den Standardwert von 4 Minuten hinaus zu erhöhen. Der Leerlauftimer wirkt sich nicht auf einen Flow aus, der sich nie im Leerlauf befindet.

Sie können TCP-Keepalives nutzen, um lange inaktive Verbindungen regelmäßig aufzufrischen und die Erreichbarkeit von Endpunkten zu überprüfen. Weitere Informationen finden Sie in diesen .NET Beispielen. TCP-Keepalives erscheinen an den Endpunkten als doppelte Bestätigungen (ACKs), verursachen nur geringen Overhead und sind für die Anwendungsschicht nicht sichtbar.

UDP-Leerlauftimeouttimer sind nicht konfigurierbar. Sie sollten UDP-Keepalives verwenden, um sicherzustellen, dass die Verbindung nicht das Leerlaufzeitlimit erreicht, und um die Verbindung aufrechtzuerhalten. Im Gegensatz zu TCP-Verbindungen gilt ein UDP-Keepalive, das auf einer Seite der Verbindung aktiviert ist, nur für den Datenfluss in einer Richtung. Sie müssen UDP-Keepalives auf beiden Seiten des Datenflusses aktivieren, um den Datenfluss aufrechtzuerhalten.

Timer

Timer für die Wiederverwendung von Ports

Timer für die Portwiederverwendung bestimmen, wie lange ein Quellport nach dem Schließen einer Verbindung gesperrt bleibt, bevor er vom NAT-Gateway für eine neue Verbindung zum selben Zielendpunkt wiederverwendet werden kann.

Die folgende Tabelle enthält Informationen dazu, wann ein TCP-Port für die Wiederverwendung für denselben Zielendpunkt durch das NAT-Gateway verfügbar wird.

Zeitgeber BESCHREIBUNG Wert
TCP FIN (TCP-Beendigung) Nachdem ein TCP FIN-Paket eine Verbindung geschlossen hat, hält ein 65-Sekunden-Timer den SNAT-Port gedrückt. Der SNAT-Port steht nach Ablauf des Timers zur Wiederverwendung zur Verfügung. 65 Sekunden
TCP RST (TCP-Zurücksetzung) Nachdem ein TCP-RST-Paket (Reset) eine Verbindung geschlossen hat, bleibt der SNAT-Port 16 Sekunden lang gesperrt. Der Port steht nach Ablauf des Timers zur Wiederverwendung zur Verfügung. 16 Sekunden
TCP half open (TCP halb geöffnet) Während des Verbindungsaufbaus, wenn ein Verbindungsendpunkt auf die Bestätigung des anderen Endpunkts wartet, wird ein 30-Sekunden-Timer gestartet. Wird kein Datenverkehr erkannt, wird die Verbindung geschlossen. Nach dem Schließen der Verbindung steht der Quellport für die Wiederverwendung für denselben Zielendpunkt zur Verfügung. 30 Sekunden

Bei UDP-Datenverkehr ist der Port nach dem Schließen einer Verbindung 65 Sekunden lang gesperrt, bevor er zur Wiederverwendung verfügbar ist.

Timer für Leerlauftimeouts

Zeitgeber BESCHREIBUNG Wert
TCP-Leerlauftimeout TCP-Verbindungen können im Leerlauf gehen, wenn keines der Endpunkte Daten für einen längeren Zeitraum überträgt. Sie können einen Timer zwischen 4 Minuten (Standard) und 120 Minuten (2 Stunden) konfigurieren, um eine Leerlaufverbindung zu timen. Durch Datenverkehr im Datenfluss wird der Timer für das Leerlauftimeout zurückgesetzt. Konfigurierbar; 4 Minuten (Standard) bis 120 Minuten
UDP-Leerlauftimeout UDP-Verbindungen können im Leerlauf gehen, wenn Endpunkte Daten für einen längeren Zeitraum nicht übertragen. Timer für UDP-Timeouts betragen vier Minuten und können nicht konfiguriert werden. Durch Datenverkehr im Datenfluss wird der Timer für das Leerlauftimeout zurückgesetzt. Nicht konfigurierbar; 4 Minuten

Hinweis

Diese Zeitgebereinstellungen können sich ändern. Die bereitgestellten Werte können bei der Problembehandlung helfen. Sie sollten sich derzeit nicht auf bestimmte Timer verlassen.

Bandbreite

Jede SKU von Azure NAT Gateway weist Bandbreitenbeschränkungen auf:

  • Ein StandardV2 NAT-Gateway unterstützt bis zu 100 Gbps Gesamtdurchsatz pro NAT-Gateway-Ressource.

  • Ein StandardV2 NAT-Gateway unterstützt bis zu 10 Millionen Pakete pro Sekunde (PPS) pro NAT-Gateway-Ressource. Das PPS-Limit wird über den gesamten vom NAT-Gateway verarbeiteten Verkehr aggregiert, einschließlich ausgehender und eingehender Antwortverkehr.

  • Ein Standard-NAT-Gateway bietet 50 GBit/s Durchsatz, der zwischen ausgehenden und eingehenden Daten (Antwort) aufgeteilt wird. Der Datendurchsatz ist auf 25 GBit/s für ausgehende und 25 GBit/s für eingehende (Antwort)-Daten pro Standard-NAT-Gatewayressource begrenzt.

Leistung

Standard- und StandardV2-NAT-Gateways unterstützen jeweils bis zu 50.000 gleichzeitige Verbindungen pro öffentliche IP-Adresse mit demselben Zielendpunkt über das Internet für TCP- und UDP-Datenverkehr.

Jede kann bis zu 2 Millionen aktive Verbindungen gleichzeitig unterstützen. Die Anzahl der Verbindungen auf einem NAT-Gateway wird basierend auf dem 5-Tupel (Quell-IP-Adresse, Quellport, Ziel-IP-Adresse, Zielport und Protokoll) gezählt. Wenn ein NAT-Gateway mehr als 2 Millionen Verbindungen hat, nimmt die Verfügbarkeit des Datenpfads ab, und neue Verbindungen schlagen fehl.

Ein STANDARDV2 NAT-Gateway kann bis zu 10 Millionen Pakete pro Sekunde verarbeiten. Ein Standard-NAT-Gateway kann bis zu 5 Millionen Pakete pro Sekunde verarbeiten.

Einschränkungen

  • Standard- und Basic-öffentliche IPs sind nicht mit StandardV2 NAT-Gateways kompatibel. Verwenden Sie stattdessen öffentliche StandardV2-IPs.

    Informationen zum Erstellen einer öffentlichen StandardV2-IP finden Sie unter Erstellen einer Azure öffentlichen IP.To create a StandardV2 public IP, see Create an Azure public IP.

  • Grundlegende Lastenausgleichsgeräte sind nicht mit NAT-Gateways kompatibel. Verwenden Sie Standardlastenausgleichsgeräte für Standard- und StandardV2-NAT-Gateways.

    Informationen zum Upgrade eines Load Balancers von Basic auf Standard finden Sie unter Upgrade eines öffentlichen Azure-Load Balancers.

  • Grundlegende öffentliche IPs sind nicht mit Standard-NAT-Gateways kompatibel. Verwenden Sie stattdessen öffentliche Standard-IPs.

    Informationen zum Upgrade einer öffentlichen IP-Adresse von "Basic" auf "Standard" finden Sie unter "Upgrade a Basic public IP address to Standard".

  • Azure StandardV2 NAT-Gateway unterstützt ausgehenden ICMP-Echoanforderungs- und Echoantwortdatenverkehr (Ping) für IPv4- und IPv6-Szenarien. Andere ICMP-Nachrichtentypen werden nicht unterstützt.

  • Ip-Fragmentierung ist für Azure NAT Gateway nicht verfügbar.

  • Azure NAT Gateway unterstützt keine öffentlichen IP-Adressen mit einem Routingkonfigurationstyp des Internets. Eine Liste der Azure Dienste, die die Internetroutingkonfiguration für öffentliche IPs unterstützen, finden Sie unter "Unterstützte Dienste für das Routing über das öffentliche Internet".

  • Azure NAT Gateway unterstützt keine öffentlichen IPs mit aktivierten DDoS-Schutz. Weitere Informationen finden Sie unter DDoS-Einschränkungen.

  • Das Azure NAT-Gateway wird in einer gesicherten vWAN-Architektur (Virtual Hub Network) nicht unterstützt.

  • Sie können ein Standard-NAT-Gateway nicht auf ein StandardV2-NAT-Gateway upgraden. Um zonenresilienz für Architekturen zu erreichen, die natale NAT-Gateways verwenden, müssen Sie ein StandardV2 NAT-Gateway bereitstellen, um das Standard-SKU-NAT-Gateway zu ersetzen.

  • Sie können öffentliche Standard-IPs nicht mit einem StandardV2-NAT-Gateway verwenden. Sie müssen auf neue öffentliche IP-Adressen vom Typ StandardV2 umstellen, um ein StandardV2-NAT-Gateway zu verwenden.

Weitere bekannte Einschränkungen von StandardV2 NAT-Gateways finden Sie unter Azure NAT Gateway SKUs.