Freigeben über

Behandeln von Problemen bei der Azure NAT Gateway-Konnektivität

  • Artikel

In diesem Artikel erhalten Sie Anleitungen zur Problembehandlung und zum Auflösen gängiger Probleme mit ausgehender Konnektivität mit Ihrem NAT-Gateway. Außerdem finden Sie in diesem Artikel bewährte Methoden, um Anwendungen für die effiziente Verwendung ausgehender Verbindungen zu entwerfen.

Rückgang der Datenpfadverfügbarkeit auf dem NAT-Gateway mit Verbindungsfehlern

Szenario

Sie beobachten einen Rückgang der Datenpfadverfügbarkeit des NAT-Gateways, der mit Verbindungsfehlern einhergeht.

Mögliche Ursachen

  • Portausschöpfung bei Quellnetzwerkadresseübersetzung (Source Network Address Translation, SNAT).

  • Grenzwerte für gleichzeitige SNAT-Verbindungen.

  • Verbindungstimeouts.

Problembehandlungsschritte

Mögliche Lösungen für SNAT-Portausschöpfung oder Erreichen der Grenzwerte für gleichzeitige Verbindungen

  • Fügen Sie Ihrem NAT-Gateway öffentliche IP-Adressen bis zu maximal 16 hinzu, um Ihre ausgehende Konnektivität zu skalieren. Jede öffentliche IP-Adresse bietet 64 512 SNAT-Ports und unterstützt bis zu 50 000 gleichzeitige Verbindungen pro eindeutigem Zielendpunkt für das NAT-Gateway.

  • Verteilen Sie Ihre Anwendungsumgebung auf mehrere Subnetze, und stellen Sie für jedes Subnetz eine NAT-Gatewayressource bereit.

  • Geben Sie den SNAT-Portbestand frei, indem Sie den Zeitgeber für das TCP-Leerlauftimeout auf einen niedrigeren Wert setzen. Der Timer für das TCP-Leerlauftimeout kann nicht auf einen Wert unter 4 Minuten festgelegt werden.

  • Erwägen Sie die Nutzung asynchroner Abrufmuster, um Verbindungsressourcen für andere Vorgänge freizugeben.

  • Stellen Sie Verbindungen mit Azure PaaS-Diensten über den Azure-Backbone mithilfe von Private Link her. Eine private Verbindung gibt SNAT-Ports für ausgehende Verbindungen mit dem Internet frei.

  • Sollte das Ergebnis Ihrer Untersuchung nicht eindeutig sein, erstellen Sie eine Supportanfrage zurweiteren Problembehandlung.

Hinweis

Es ist wichtig, zu verstehen, warum es zur SNAT-Portausschöpfung kommt. Stellen Sie sicher, dass Sie die richtigen Muster für skalierbare und zuverlässige Szenarien verwenden. Das Hinzufügen von weiteren SNAT-Ports, ohne dass Ihnen die Ursache des Bedarfs bekannt ist, sollte nur im Notfall erfolgen. Wenn Sie nicht verstehen, warum es bei Ihnen zu einer hohen Auslastung beim SNAT-Portbestand kommt, führt die Erweiterung auf eine größere Zahl von SNAT-Ports durch das Hinzufügen von weiteren IP-Adressen nur dazu, dass sich dieser Überlastungsfehler bei der weiteren Skalierung Ihrer Anwendung fortsetzt. Es kann sein, dass hierdurch andere Ineffizienzen und Antimuster verdeckt werden. Weitere Informationen finden Sie unter Bewährte Methoden für die effiziente Verwendung ausgehender Verbindungen.

Mögliche Lösungen für TCP-Verbindungstimeouts

Verwenden Sie TCP-Keepalives oder Anwendungsebene-Keepalives, um inaktive Flows zu aktualisieren und den Zeitgeber für das Leerlauftimeout zurückzusetzen. Beispiele finden Sie unter .NET-Beispiele.

TCP-Keep-Alives müssen nur von einer Seite einer Verbindung aktiviert werden, damit eine Verbindung von beiden Seiten erhalten bleibt. Wenn ein TCP-Keepalive von einer Seite einer Verbindung gesendet wird, sendet die andere Seite automatisch ein Bestätigungspaket (Acknowledge, ACK). Der Timer für das Leerlauftimeout wird dann auf beiden Seiten der Verbindung zurückgesetzt.

Hinweis

Das Heraufsetzen des TCP-Leerlauftimeouts ist das letzte Mittel, und löst die Grundursache des Problems möglicherweise nicht auf. Ein langes Timeout kann zu Verzögerungen führen und unnötige Fehler bei niedrigen Raten verursachen, wenn das Timeout abläuft.

Mögliche Lösungen für UDP (User Datagram Protocol)-Verbindungstimeouts

Zeitgeber für UDP-Leerlauftimeouts sind auf 4 Minuten festgelegt und nicht konfigurierbar. Aktivieren Sie UDP-Keepalives für beide Richtungen in einem Verbindungsflow, um lange Verbindungen aufrechtzuerhalten. Wenn ein UDP-Keepalive aktiviert wird, ist er nur für eine Richtung in einer Verbindung aktiv. Die Verbindung kann weiterhin in den Leerlauf wechseln und auf der anderen Seite einer Verbindung ein Timeout verursachen. Um zu verhindern, dass für eine UDP-Verbindung ein Leerlauftimeout eintritt, sollten UDP-Keep-Alives für beide Richtungen in einem Verbindungsfluss aktiviert werden.

Keep-Alives auf Anwendungsebene können ebenfalls verwendet werden, um eine Aktualisierung von Datenflüssen im Leerlauf durchzuführen und den Leerlauftimeout zurückzusetzen. Überprüfen Sie auf der Serverseite, welche Optionen es für anwendungsspezifische Keepalives gibt.

Rückgang der Datenpfadverfügbarkeit auf dem NAT-Gateway, aber keine Verbindungsfehler

Szenario

Die Datenpfadverfügbarkeit eines NAT-Gateways geht zurück, aber es werden keine fehlgeschlagenen Verbindungen beobachtet.

Mögliche Ursache

Vorübergehender Rückgang der Datenpfadverfügbarkeit, verursacht durch Rauschen im Datenpfad.

Schritte zur Problembehandlung

Wenn Sie einen Rückgang der Datenpfadverfügbarkeit ohne Auswirkungen auf Ihre ausgehende Konnektivität feststellen, kann es daran liegen, dass das NAT-Gateway vorübergehendes Rauschen im Datenpfad aufnimmt.

Richten Sie eine Warnung für den Rückgang der Datenpfadverfügbarkeit ein, oder verwenden Sie Azure Resource Health, um auf NAT Gateway-Integritätsereignisse hinzuweisen.

Keine ausgehende Konnektivität mit dem Internet

Szenario

Sie beobachten keine ausgehende Verbindung auf Ihrem NAT-Gateway.

Mögliche Ursachen

  • Fehlkonfiguration des NAT-Gateways.

  • Der Internetdatenverkehr wird vom NAT-Gateway weggeleitet und durch einen Tunnel zu einem virtuellen Gerät oder zu einem lokalen Ziel mit einem VPN oder ExpressRoute gezwungen.

  • Regeln für die Netzwerksicherheitsgruppe (Network Security Group, NSG) werden konfiguriert, die den Internetdatenverkehr blockieren.

  • Die Verfügbarkeit von NAT-Gatewaydatenpfaden ist beeinträchtigt.

  • Domain Name System (DNS)-Fehlkonfiguration.

Schritte zur Problembehandlung

  • Überprüfen Sie, ob das NAT-Gateway mit mindestens einer öffentlichen IP-Adresse oder einem Präfix konfiguriert und an ein Subnetz angefügt ist. Das NAT-Gateway ist erst betriebsbereit, wenn eine öffentliche IP-Adresse und ein Subnetz angefügt sind. Weitere Informationen finden Sie unter Konfigurationsgrundlagen für das NAT-Gateway.

  • Überprüfen Sie die Routingtabelle des an das NAT-Gateway angefügten Subnetzes. Jeder 0.0.0.0/0-Datenverkehr, der durch einen Tunnel zu einem virtuellen Netzwerkgerät (Network Virtual Appliance, NVA), ExpressRoute oder VPN Gateway gezwungen wird, hat Vorrang vor dem NAT-Gateway. Weitere Informationen finden Sie unter Auswahl einer Route durch Azure.

  • Überprüfen Sie, ob auf Ihrer VM NSG-Regeln für die Netzwerkschnittstelle konfiguriert sind, die den Internetzugriff blockiert.

  • Überprüfen Sie, ob sich die Datenpfadverfügbarkeit des NAT-Gateways in einem beeinträchtigten Zustand befindet. Lesen Sie Anleitung zur Problembehandlung bei Verbindungsfehlern, wenn sich das NAT-Gateway in einem beeinträchtigten Zustand befindet.

  • Überprüfen Sie Ihre DNS-Einstellungen, wenn DNS nicht ordnungsgemäß aufgelöst wird.

Mögliche Lösungen für Verlust der ausgehenden Konnektivität

  • Fügen Sie eine öffentliche IP-Adresse oder ein Präfix an das NAT-Gateway an. Stellen Sie außerdem sicher, dass das NAT-Gateway an Subnetze aus demselben virtuellen Netzwerk angefügt ist. Überprüfen Sie, ob das NAT-Gateway eine ausgehende Verbindung herstellen kann.

  • Berücksichtigen Sie ihre Anforderungen für das Datenverkehrsrouting sorgfältig, bevor Sie Änderungen an Datenverkehrsrouten für Ihr virtuelles Netzwerk vornehmen. Benutzerdefinierte Routen (User Defined Routes, UDRs), die 0.0.0.0/0-Datenverkehr an ein virtuelles Gerät oder ein virtuelles Netzwerkgateway senden, setzen das NAT-Gateway außer Kraft. Weitere Informationen dazu, wie sich benutzerdefinierte Routen auf das Routing von Netzwerkdatenverkehr auswirken, finden Sie unter benutzerdefinierte Routen.

    Informationen zu Optionen zum Aktualisieren Ihrer Datenverkehrsrouten in der Routingtabelle Ihres Subnetzes finden Sie unter:

  • Aktualisieren Sie NSG-Sicherheitsregeln, die den Internetzugriff für ihre VMs blockieren. Weitere Informationen finden Sie unter Verwalten von Netzwerksicherheitsgruppen.

  • DNS lässt sich aus vielen Gründen nicht richtig auflösen. Lesen Sie den Leitfaden zur DNS-Problembehandlung, um zu untersuchen, warum die DNS-Auflösung fehlschlägt.

Die öffentliche IP-Adresse des NAT-Gateways wird nicht zum Herstellen einer ausgehenden Verbindung verwendet

Szenario

Das NAT-Gateway wird in Ihrem virtuellen Azure-Netzwerk bereitgestellt, aber unerwartete IP-Adressen werden für ausgehende Verbindungen verwendet.

Mögliche Ursachen

  • Fehlkonfiguration des NAT-Gateways.

  • Aktive Verbindung mit einer anderen ausgehenden Azure-Konnektivitätsmethode, z. B. Azure-Lastenausgleich oder öffentliche IP-Adressen auf Instanzebene auf VMs. Aktive Verbindungsflows verwenden weiterhin die vorherige öffentliche IP-Adresse, die beim Herstellen der Verbindung zugewiesen wurde. Wenn das NAT-Gateway bereitgestellt wird, beginnen neue Verbindungen sofort mit der Verwendung des NAT-Gateways.

  • Private IP-Adressen werden verwendet, um über Dienstendpunkte oder Private Link eine Verbindung mit Azure-Diensten herzustellen.

  • Verbindungen mit Speicherkonten stammen aus derselben Region wie die VM, von dem aus Sie eine Verbindung herstellen.

  • Der Internetdatenverkehr wird vom NAT-Gateway weggeleitet und durch einen Tunnel zu einer NVA oder Firewall gezwungen.

Informationen zur Problembehandlung

  • Überprüfen Sie, dass Ihrem NAT-Gateway mindestens eine öffentliche IP-Adresse oder ein Präfix und mindestens ein Subnetz zugeordnet ist.

  • Überprüfen Sie, ob eine vorherige ausgehende Verbindungsmethode, z. B. ein öffentlicher Lastenausgleich, nach der Bereitstellung des NAT-Gateways immer noch aktiv ist.

  • Überprüfen Sie, ob Verbindungen, die zu anderen Azure-Diensten hergestellt werden, von einer privaten IP-Adresse in Ihrem virtuellen Azure-Netzwerk stammen.

  • Überprüfen Sie, ob Private Link oder Dienstendpunkte für die Verbindung mit anderen Azure-Diensten aktiviert sind.

  • Stellen Sie sicher, dass sich Ihre VM in derselben Region wie der Azure-Speicher befindet, wenn eine Speicherverbindung hergestellt wird.

  • Überprüfen Sie, ob die für Verbindungen verwendete öffentliche IP-Adresse von einem anderen Azure-Dienst in Ihrem virtuellen Azure-Netzwerk stammt, z. B. einem virtuellen Netzwerkgerät (Network Virtual Appliance, NVA).

Mögliche Lösungen für öffentliche IP-Adressen des NAT-Gateways, die nicht für ausgehende Verbindungen verwendet werden

  • Fügen Sie eine öffentliche IP-Adresse oder ein Präfix an das NAT-Gateway an. Stellen Sie sicher, dass das NAT-Gateway an Subnetze aus demselben virtuellen Netzwerk angefügt ist. Überprüfen Sie, ob das NAT-Gateway eine ausgehende Verbindung herstellen kann.

  • Testen und Beheben Sie Probleme mit VMs, die alte SNAT-IP-Adressen aus einer anderen Methode für ausgehende Verbindungen beibehalten, indem Sie:

    • Stellen Sie sicher, dass Sie eine neue Verbindung hergestellt haben und dass vorhandene Verbindungen nicht im Betriebssystem wiederverwendet werden, oder dass der Browser die Verbindungen zwischenspeichert. Wenn Sie z. B. curl in PowerShell verwenden, stellen Sie sicher, dass Sie den Parameter -DisableKeepalive angeben, um eine neue Verbindung zu erzwingen. Wenn Sie einen Browser verwenden, können die Verbindungen auch gepoolt werden.

    • Es ist nicht erforderlich, eine VM in einem Subnetz neu zu starten, das für die Verwendung von NAT Gateway konfiguriert ist. Wenn allerdings ein virtueller Computer neu gestartet wird, wird der Verbindungsstatus geleert. Wenn der Verbindungsstatus geleert wird, beginnen alle Verbindungen mit der Verwendung der IP-Adresse oder -Adressen der NAT-Gateway-Ressource. Dieses Verhalten ist ein Nebeneffekt des VM-Neustarts und kein Hinweis darauf, dass ein Neustart erforderlich ist.

    • Sollte das Ergebnis Ihrer Untersuchung nicht eindeutig sein, erstellen Sie eine Supportanfrage zurweiteren Problembehandlung.

  • Benutzerdefinierte Routen, die 0.0.0.0/0-Datenverkehr an eine NVA leiten, haben Vorrang vor dem NAT-Gateway für das Routing des Datenverkehrs an das Internet. Damit das NAT-Gateway Datenverkehr an das Internet statt an die NVA weiterleitet, entfernen Sie die benutzerdefinierte Route für den 0.0.0.0/0-Datenverkehr, der durch das virtuelle Gerät geht. Der 0.0.0.0/0-Datenverkehr wird stattdessen weiterhin die Standardroute zum Internet verwenden, und das NAT-Gateway wird stattdessen verwendet.

Wichtig

Bevor Sie Änderungen am Datenverkehrsrouting vornehmen, sollten Sie die Routing-Anforderungen Ihrer Cloud-Architektur sorgfältig prüfen.

  • Dienste, die in derselben Region wie ein Azure-Speicherkonto bereitgestellt werden, verwenden für die Kommunikation private Azure-IP-Adressen. Sie können den Zugriff auf bestimmte Azure-Dienste nicht anhand ihres öffentlichen ausgehenden IP-Adressbereichs einschränken. Weitere Informationen finden Sie unter Einschränkungen für IP-Netzwerkregeln.
  • Private Link und Dienstendpunkte verwenden die privaten IP-Adressen von VM-Instanzen in Ihrem virtuellen Netzwerk, um eine Verbindung mit diesen Azure-Plattformdiensten herzustellen, anstatt die öffentlichen IP-Adresse des NAT-Gateways zu verwenden. Verwenden Sie Private Link, um eine Verbindung mit anderen Azure-Diensten über das Azure-Backbone anstatt über das Internet mit dem NAT-Gateway herzustellen.

Hinweis

Private Link ist die empfohlene Option für Dienstendpunkte für den privaten Zugriff auf in Azure gehostete Dienste.

Verbindungsfehler am Ziel im öffentlichen Internet

Szenario

Nat-Gatewayverbindungen zu Internetzielen schlagen fehl oder erfahren ein Timeout.

Mögliche Ursachen

  • Firewall oder andere Komponenten zur Verwaltung des Datenverkehrs am Ziel

  • Zielseitige API-Ratenbegrenzung

  • Gegenmaßnahmen für volumetrische DDoS-Angriffe oder Traffic-Shaping auf der Transportebene

  • Der Zielendpunkt antwortet mit fragmentierten Paketen.

Informationen zur Problembehandlung

  • Überprüfen Sie zum Vergleich die Konnektivität mit einem Endpunkt in der gleichen Region oder an einem anderen Ort.

  • Führen Sie die Paketerfassung von Quell- und Zielseiten aus.

  • Sehen Sie sich die Paketanzahl an der Quelle und am Ziel (sofern verfügbar) an, um die Anzahl von Verbindungsversuchen zu ermitteln.

  • Sehen Sie sich die verworfenen Pakete an, um zu ermitteln, wie viele Pakete vom NAT-Gateway verworfen wurden.

  • Analysieren Sie die Pakete. TCP-Pakete mit fragmentierten IP-Protokollpaketen deuten auf die IP-Fragmentierung hin. Das NAT-Gateway unterstützt keine IP-Fragmentierung, sodass Verbindungen mit fragmentierten Paketen fehlschlagen.

  • Stellen Sie sicher, dass die öffentliche IP-Adresse des NAT-Gateways bei Partnerzielen mit Firewalls oder anderen Datenverkehrsverwaltungskomponenten als zulässig aufgeführt ist.

Mögliche Lösungen für Verbindungsfehler am Internetziel

  • Überprüfen Sie, ob die öffentliche IP-Adresse des NAT-Gateways am Ziel erlaubt ist.

  • Untersuchen Sie im Falle von Tests für hohes Volumen oder hohe Transaktionsraten, ob weniger Fehler auftreten, wenn Sie die Rate verringern.

  • Wenn das Reduzieren der Verbindungsrate das Auftreten von Fehlern verringert, überprüfen Sie, ob das Ziel seine API-Ratengrenzwerte oder andere Einschränkungen erreicht hat.

Verbindungsfehler beim FTP-Server für den aktiven oder passiven Modus

Szenario

Bei Verwendung des NAT-Gateways mit aktivem oder passivem FTP-Modus sehen Sie Verbindungsfehler auf einem FTP-Server.

Mögliche Ursachen

  • Der aktive FTP-Modus ist aktiviert.

  • Der passive FTP-Modus ist aktiviert, und das NAT-Gateway verwendet mehr als eine öffentliche IP-Adresse.

Mögliche Lösung für den aktiven FTP-Modus

FTP verwendet zwei separate Kanäle zwischen einem Client und einem Server, die Befehls- und Datenkanäle. Jeder Kanal kommuniziert über separate TCP-Verbindungen, eine zum Senden der Befehle und die andere zum Übertragen von Daten.

Im aktiven FTP-Modus richtet der Client den Befehlskanal ein, und der Server richtet den Datenkanal ein.

Das NAT-Gateway ist nicht mit dem aktiven FTP-Modus kompatibel. Aktives FTP verwendet einen PORT-Befehl vom FTP-Client, der dem FTP-Server mitteilt, welche IP-Adresse und welcher Port für den Server auf dem Datenkanal verwendet werden soll, um eine Verbindung mit dem Client herzustellen. Der PORT-Befehl verwendet die private Adresse des Client, die nicht geändert werden kann. Clientseitiger Datenverkehr wird vom NAT-Gateway für die internetbasierte Kommunikation SNATed, sodass der PORT-Befehl vom FTP-Server als ungültig angesehen wird.

Eine alternative Lösung für den aktiven FTP-Modus ist stattdessen die Verwendung des passiven FTP-Modus. Um jedoch das NAT-Gateway im passiven FTP-Modus zu verwenden, müssen einige Überlegungen angestellt werden.

Mögliche Lösung für passiven FTP-Modus

Im passiven FTP-Modus stellt der Client Verbindungen sowohl auf dem Befehls- als auch auf dem Datenkanal her. Der Client fordert an, dass der Server auf einem Port antworte, anstatt zu versuchen, eine Verbindung zurück zum Client herzustellen.

Ausgehendes passives FTP funktioniert nicht bei einem NAT-Gateway mit mehreren öffentlichen IP-Adressen, abhängig von der Konfiguration Ihres FTP-Servers. Wenn NATGateway mit mehreren öffentlichen IP-Adressen ausgehenden Datenverkehr sendet, wird nach dem Zufallsprinzip eine der öffentlichen IP-Adressen als Quell-IP-Adresse ausgewählt. FTP funktioniert nicht, wenn für Daten- und Steuerungskanäle unterschiedliche Quell-IP-Adressen verwendet werden, abhängig von der Konfiguration Ihres FTP-Servers.

Um mögliche Fehler bei der passiven FTP-Verbindung zu verhindern, führen Sie die folgenden Schritte aus:

  1. Überprüfen Sie, ob Ihr NAT-Gateway an eine einzelne öffentliche IP-Adresse gebunden ist und nicht an mehrere IP-Adressen oder ein Präfix.

  2. Stellen Sie sicher, dass der passive Portbereich Ihres NAT-Gateways alle Firewalls am Zielendpunkt durchlaufen darf.

Hinweis

Durch die Verringerung der Anzahl öffentlicher IP-Adressen auf Ihrem NAT-Gateway wird der SNAT-Portbestand reduziert, das für das Erstellen ausgehender Verbindungen verfügbar ist, und kann das Risiko einer SNAT-Portausschöpfung erhöhen. Berücksichtigen Sie die Anforderungen Ihrer SNAT-Konnektivität, bevor Sie öffentliche IP-Adressen vom NAT-Gateway entfernen. Es wird nicht empfohlen, die FTP-Servereinstellungen so zu ändern, dass der Datenverkehr auf Steuerungs- und Datenebene von verschiedenen Quell-IP-Adressen akzeptiert wird.

Ausgehende Verbindungen an Port 25 sind blockiert

Szenario

Ausgehende Verbindungen mit dem NAT-Gateway am Port 25 für SMTP (Simple Mail Transfer Protocol)-Datenverkehr können nicht hergestellt werden.

Ursache

Die Azure-Plattform blockiert ausgehende SMTP-Verbindungen an TCP-Port 25 für bereitgestellte virtuelle Computer. Durch diesen Block werden die Sicherheit für Microsoft-Partner und -Kunden verbessert, die Azure-Plattform von Microsoft geschützt und branchenübliche Standards eingehalten.

Verwenden Sie einen authentifizierten SMTP-Relaydienst, um E-Mails von Azure-VMs oder aus Azure App Service zu senden. Weitere Informationen finden Sie unter Behandeln von Problemen mit ausgehender SMTP-Konnektivität.

Weitere Anleitung zur Problembehandlung

Zusätzliche Netzwerkerfassungen

Wenn Ihre Untersuchung nicht eindeutig ist, öffnen Sie einen Supportfall zur weiteren Problembehandlung, und sammeln Sie die folgenden Informationen für eine schnelle Lösung. Wählen Sie eine einzelne VM in Ihrem mit einem NAT-Gateway konfigurierten Subnetz aus, und führen Sie die folgenden Tests aus:

  • Testen Sie die Testport-Antwort mit ps ping von einer der Backend-VMs innerhalb des virtuellen Netzwerks und zeichnen Sie die Ergebnisse auf (Beispiel: ps ping 10.0.0.4:3389).

  • Wenn bei diesen Pingtests keine Antwort empfangen wird, führen Sie beim Ausführen von „PsPing“ eine gleichzeitige netsh-Ablaufverfolgung auf der Back-End-VM und der Test-VM des virtuellen Netzwerks aus, und beenden Sie dann die netsh-Ablaufverfolgung.

Bewährte Methoden für ausgehende Konnektivität

Azure überwacht und betreibt seine Infrastruktur mit großer Sorgfalt. Trotzdem kann es auf bereitgestellten Anwendungen zu vorübergehenden Fehlern kommen, und es gibt keine Garantie für verlustfreie Übertragungen. Das NAT-Gateway ist die bevorzugte Option zum Einrichten einer äußerst zuverlässigen und resilienten ausgehenden Konnektivität aus Azure-Bereitstellungen. Informationen zur Optimierung der Anwendungsverbindungseffizienz finden Sie in der Anleitung weiter unten im Artikel.

Verbindungspooling verwenden

Indem Sie Ihre Verbindungen im Pool zusammenfassen, vermeiden Sie das Öffnen neuer Netzwerkverbindungen für Aufrufe derselben Adresse und desselben Ports. Sie können in Ihrer Anwendung ein Verbindungspoolingschema implementieren, bei dem Anforderungen intern auf einen festen Satz von Verbindungen verteilt und wenn möglich wiederverwendet werden. Bei diesem Setup wird die Anzahl der verwendeten SNAT-Ports eingeschränkt und eine vorhersagbare Umgebung erstellt. Das Verbindungspooling trägt dazu bei, Latenz und Ressourcenauslastung zu verringern und die Leistung Ihrer Anwendungen letztendlich zu verbessern.

Weitere Informationen zum Pooling von HTTP-Verbindungen finden Sie unter Pool-HTTP-Verbindungen mit HttpClientFactory.

Wiederverwenden von Verbindungen

Anstatt einzelne, unteilbare TCP-Verbindungen für jede Anforderung zu generieren, konfigurieren Sie Ihre Anwendung so, dass Verbindungen wiederverwendet werden. Die Wiederverwendung von Verbindungen führt zu leistungsfähigeren TCP-Transaktionen und ist insbesondere für Protokolle wie HTTP/1.1 relevant, beim dem Verbindungen standardmäßig wiederverwendet werden. Diese Wiederverwendung gilt für andere Protokolle, die HTTP als Transport verwenden, z. B. REST.

Verwenden Sie weniger aggressive Wiederholungslogik

Wenn SNAT-Ports ausgelastet sind oder Anwendungsfehler auftreten, führen aggressive oder Brute-Force-Wiederholungsversuche ohne Verzögerungs- und Backofflogik zu zeitweiliger oder sogar anhaltender Auslastung. Sie können den Bedarf an SNAT-Ports durch Verwendung einer weniger aggressiven Wiederholungslogik reduzieren.

Je nach konfiguriertem Leerlauftimeout haben Verbindungen bei zu aggressiven Wiederholungsversuchen nicht genügend Zeit, um SNAT-Ports für die Wiederverwendung zu schließen und freizugeben.

Zusätzliche Anleitung und Beispiele finden Sie unter Wiederholungsmuster.

Verwenden von Keep-Alives zum Zurücksetzen des Leerlauftimeouts für ausgehende Verbindungen

Weitere Informationen zu Keepalives finden Sie unter TCP-Leerlauftimeout.

Nach Möglichkeit sollte Private Link verwendet werden, um eine direkte Verbindung zwischen Ihren virtuellen Netzwerken und Azure Platform-Diensten herzustellen und so die Nachfrage nach SNAT-Ports zu reduzieren. Das Verringern der Nachfrage nach SNAT-Ports kann dazu beitragen, das Risiko einer SNAT-Porterschöpfung zu verringern.

Informationen zum Erstellen eines Private Link finden Sie in den folgenden Schnellstartanleitungen:

Nächste Schritte

Wir sind stets bestrebt, die Erfahrungen unserer Kunden zu verbessern. Wenn NAT Gateway-Probleme auftreten, die in diesem Artikel nicht behandelt oder behoben werden, senden Sie Feedback über GitHub unten auf dieser Seite.

Weitere Informationen zum NAT-Gateway finden Sie unter: