Partager via

Résoudre les problèmes de connectivité avec Azure NAT Gateway

  • Article

Cet article fournit des conseils pour résoudre les problèmes de connectivité sortante courants associés à votre passerelle NAT. Cet article fournit également les meilleures pratiques sur la façon de concevoir des applications pour utiliser efficacement les connexions sortantes.

Baisse de la disponibilité du chemin de données sur la passerelle NAT avec des échecs de connexion

Scénario

Vous constatez une baisse de la disponibilité du chemin de données de la passerelle NAT qui coïncide avec les échecs de connexion.

Causes possibles

  • Épuisement du port de traduction d’adresses réseau source (SNAT).

  • Limites de connexion SNAT simultanées.

  • Expiration de connexion.

Étapes de résolution des problèmes

Solutions possibles aux ports SNAT épuisés ou aux limites de connexion simultanées atteintes

  • Ajoutez des adresses IP publiques à votre passerelle NAT jusqu’à un total de 16 pour mettre à l’échelle votre connectivité sortante. Chaque adresse IP publique fournit 64 512 ports SNAT et prend en charge jusqu’à 50 000 connexions simultanées par point de terminaison de destination unique pour la passerelle NAT.

  • Distribuez votre environnement d’application sur plusieurs sous-réseaux et fournissez une ressource de passerelle NAT pour chaque sous-réseau.

  • Libérez l’inventaire des ports SNAT en définissant le minuteur de délai d’inactivité TCP sur une valeur inférieure. Le minuteur du délai d’inactivité TCP ne peut pas être défini sur une valeur inférieure à 4 minutes.

  • Utilisez des modèles d’interrogation asynchrones pour libérer des ressources de connexion pour les autres opérations.

  • Établissez des connexions aux services PaaS Azure via le réseau principal Azure à l’aide de Private Link. La liaison privée libère des ports SNAT pour les connexions sortantes vers Internet.

  • Si votre enquête n’aboutit pas, ouvrez un cas de support pour obtenir une assistance supplémentaire pour la résolution du problème.

Remarque

Il est important de comprendre la raison pour laquelle les ports SNAT sont épuisés. Veillez à utiliser les modèles appropriés pour des scénarios évolutifs et fiables. L’ajout de ports SNAT supplémentaires à un scénario sans comprendre la cause de la demande doit être envisagé en dernier recours. Si vous ne comprenez pas pourquoi votre scénario applique une charge sur l’inventaire des ports SNAT, le fait d’ajouter des ports SNAT supplémentaires en ajoutant plus d’adresses IP ne fera que retarder le même échec dû à l’épuisement quand votre application est mise à l’échelle. Vous masquez peut-être d’autres manques d’efficacité et anti-modèles. Pour en savoir plus, consultez Bonnes pratiques pour une utilisation efficace des connexions sortantes.

Solutions possibles aux délais d’expiration de connexion TCP

Utilisez des keepalives TCP ou des keepalives de la couche application pour actualiser les flux inactifs et réinitialiser le délai d’inactivité. Pour obtenir des exemples, consultez Exemples .NET.

Les keepalives TCP doivent uniquement être activées à partir d’un côté d’une connexion afin de maintenir la connexion des deux côtés. Lorsqu’un keepalive TCP est envoyé d’un côté d’une connexion, l’autre côté envoie automatiquement un paquet d’acquittement (ACK). Le minuteur de délai d’inactivité est ensuite réinitialisé des deux côtés de la connexion.

Remarque

L’augmentation du délai d’inactivité TCP est un dernier recours, et peut ne pas résoudre la cause racine du problème. Un délai d’expiration long peut provoquer des retards et des défaillances inutiles à faible débit lorsque le délai d’expiration expire.

Solutions possibles aux délais d’expiration de connexion UDP (User Datagram Protocol)

Les minuteurs de délai d’inactivité UDP sont définis sur 4 minutes et ne peuvent pas être configurés. Activez les keepalives UDP pour les deux directions d’un flux de connexion afin de conserver des connexions longues. Lorsqu’un keepalive UDP est activé, il est uniquement actif pour une direction dans une connexion. La connexion peut toujours rester inactive et expirer de l’autre côté d’une connexion. Pour empêcher une connexion UDP de dépasser le délai d’inactivité, les keepalives UDP doivent être activés pour les deux directions dans un flux de connexion.

Les keepalives de la couche application peuvent également être utilisés pour actualiser les flux inactifs et réinitialiser le délai d’inactivité. Examinez le côté serveur à la recherche d’options de conservations de connexion active spécifiques aux applications.

Baisse de la disponibilité du chemin de données sur la passerelle NAT, mais aucune défaillance de connexion

Scénario

La disponibilité du chemin de données de la passerelle NAT diminue, mais aucune connexion ayant échoué n’est observée.

Cause possible

Baisse temporaire de la disponibilité du chemin de données causée par le bruit dans le chemin de données.

Étapes de dépannage

Si vous remarquez une baisse de la disponibilité du chemin de données qui n’a aucun effet sur votre connectivité sortante, cela peut être dû au fait que la passerelle NAT récupère le bruit temporaire dans le chemin de données.

Configurez une alerte pour les baisses de disponibilité du chemin de données ou utilisez Azure Resource Health pour être alerté des événements d’intégrité de la passerelle NAT.

Aucune connectivité sortante à Internet

Scénario

Vous n’observez aucune connectivité sortante sur votre passerelle NAT.

Causes possibles

  • Configuration incorrecte de la passerelle NAT.

  • Le trafic Internet est redirigé en dehors de la passerelle NAT et forcé vers une appliance virtuelle ou vers une destination locale avec un VPN ou ExpressRoute.

  • Les règles de groupe de sécurité réseau (NSG) sont configurées pour bloquer le trafic Internet.

  • La disponibilité du chemin de données de la passerelle NAT est détériorée.

  • Configuration incorrecte du DNS (Domain Name System).

Étapes de dépannage

  • Vérifiez que la passerelle NAT est configurée avec au moins une adresse IP publique ou un préfixe et est attachée à un sous-réseau. Tant qu’une adresse IP publique et un sous-réseau ne sont pas attachés, la passerelle NAT n’est pas opérationnelle. Pour plus d’informations, consultez Informations de base sur la configuration de la passerelle NAT.

  • Vérifiez la table de routage du sous-réseau attaché à la passerelle NAT. Tout trafic 0.0.0.0/0 forcé vers une appliance virtuelle réseau (NVA), vers ExpressRoute ou vers une passerelle VPN prend la priorité sur la passerelle NAT. Pour plus d’informations, consultez Comment Azure choisit un itinéraire.

  • Vérifiez si des règles NSG, qui bloquent l’accès à Internet, sont configurées pour l’interface réseau sur votre machine virtuelle.

  • Vérifiez si la disponibilité du chemin de données de la passerelle NAT se trouve dans un état détérioré. Reportez-vous aux conseils de résolution des problèmes de défaillance de connexion si la passerelle NAT se trouve dans un état détérioré.

  • Vérifiez vos paramètres DNS s’il ne se résout pas correctement.

Solutions possibles à la perte de connectivité sortante

L’adresse IP publique de la passerelle NAT n’est pas utilisée pour la connexion sortante.

Scénario

La passerelle NAT est déployée dans votre réseau virtuel Azure, mais des adresses IP inattendues sont utilisées pour les connexions sortantes.

Causes possibles

  • Configuration incorrecte de la passerelle NAT.

  • Connexion active avec une autre méthode de connectivité sortante Azure, telle qu’Azure Load Balancer ou des adresses IP publiques au niveau de l’instance sur des machines virtuelles. Les flux de connexion actifs continuent d’utiliser l’adresse IP publique précédente affectée lors de l’établissement de la connexion. Lorsque la passerelle NAT est déployée, les nouvelles connexions commencent immédiatement à l’utiliser.

  • Les adresses IP privées sont utilisées pour se connecter aux services Azure par le biais de points de terminaison de service ou de Private Link.

  • Les connexions aux comptes de stockage proviennent de la même région que la machine virtuelle à partir de laquelle vous établissez une connexion.

  • Le trafic Internet est redirigé en dehors de la passerelle NAT et forcé vers une appliance virtuelle réseau ou un pare-feu.

Comment résoudre les problèmes

  • Vérifiez que votre passerelle NAT dispose d’au moins une adresse IP publique ou un préfixe associé et d’au moins un sous-réseau.

  • Vérifiez si une méthode de connectivité sortante précédente, telle qu’un équilibreur de charge public, est toujours active après le déploiement de la passerelle NAT.

  • Vérifiez si les connexions établies auprès d’autres services Azure proviennent d’une adresse IP privée dans votre réseau virtuel Azure.

  • Vérifiez si Private Link ou des points de terminaison de service sont activés pour la connexion à d’autres services Azure.

  • Vérifiez que votre machine virtuelle se trouve dans la même région que le stockage Azure lorsque vous établissez une connexion de stockage.

  • Vérifiez si l’adresse IP publique utilisée pour les connexions provient d’un autre service Azure au sein de votre réseau virtuel Azure, par exemple une appliance virtuelle réseau (NVA).

Solutions possibles à la non utilisation de l’adresse IP publique de la passerelle NAT pour les connexions sortantes

  • Attachez une adresse IP publique ou un préfixe à la passerelle NAT. Vérifiez que la passerelle NAT est attachée aux sous-réseaux à partir du même réseau virtuel. Vérifiez que la passerelle NAT dispose d’une connexion sortante.

  • Testez et résolvez les problèmes associés aux machines virtuelles qui conservent d’anciennes adresses IP SNAT à partir d’une autre méthode de connectivité sortante en :

    • Vérifiant que vous établissez une nouvelle connexion, et que les connexions existantes ne sont pas réutilisées dans le système d’exploitation ou que le navigateur met en cache les connexions. Par exemple, lorsque vous utilisez curl dans PowerShell, veillez à spécifier le paramètre -DisableKeepalive pour forcer une nouvelle connexion. Si vous utilisez un navigateur, les connexions peuvent également être mises en pool.

    • Il n’est pas nécessaire de redémarrer une machine virtuelle dans un sous-réseau configuré sur une passerelle NAT. Cependant, si la machine est redémarrée, l’état de la connexion est vidé. Lorsque l’état de la connexion est vidé, toutes les connexions commencent à utilisent la ou les adresses IP de la ressource de passerelle NAT. Ce comportement est un effet secondaire du redémarrage de la machine virtuelle et non un signe indiquant qu’un redémarrage est nécessaire.

    • Si votre enquête n’aboutit pas, ouvrez un cas de support pour obtenir une assistance supplémentaire pour la résolution du problème.

  • Les itinéraires personnalisés qui dirigent le trafic 0.0.0.0/0 vers une appliance virtuelle réseau ont la priorité sur la passerelle NAT pour le routage du trafic vers Internet. Pour que le trafic de la passerelle NAT soit acheminé vers Internet au lieu de l’appliance virtuelle réseau, supprimez l’itinéraire personnalisé pour le trafic 0.0.0.0/0 vers l’appliance virtuelle. Le trafic 0.0.0.0/0 reprend à l’aide de l’itinéraire par défaut vers Internet, et la passerelle NAT est utilisée à la place.

Important

Avant de modifier la façon dont le trafic est acheminé, prenez soigneusement en compte les exigences de routage de votre architecture cloud.

  • Les services déployés dans la même région qu’un compte de stockage Azure utilisent des adresses IP Azure privées pour la communication. Vous ne pouvez pas restreindre l’accès à des services Azure spécifiques en fonction de leur plage d’adresses IP sortantes publiques. Pour plus d’informations, consultez les Restrictions pour les règles de réseau IP.
  • Private Link et les points de terminaison de service utilisent les adresses IP privées des instances de machine virtuelle de votre réseau virtuel pour se connecter aux services de la plateforme Azure au lieu de l’adresse IP publique de la passerelle NAT. Utilisez Private Link pour vous connecter à d’autres services Azure via le réseau principal Azure au lieu d’Internet avec la passerelle NAT.

Remarque

Private Link est l’option recommandée sur les points de terminaison de service pour l’accès privé aux services hébergés Azure.

Échecs de connexion côté destination Internet publique

Scénario

Les connexions de passerelle NAT aux destinations Internet échouent ou expirent.

Causes possibles

  • Pare-feu ou autres composants de gestion du trafic côté destination.

  • Limitation du débit d’API imposée côté destination

  • Atténuations DDoS volumétriques ou mise en forme du trafic de la couche transport

  • Le point de terminaison de destination répond avec des paquets fragmentés.

Comment résoudre les problèmes

  • Vérifiez la connectivité à un point de terminaison dans la même région et dans une région différente à des fins de comparaison.

  • Effectuez la capture de paquets des côtés source et de destination.

  • Examinez le nombre de paquets côté source et destination (le cas échéant) pour déterminer le nombre de tentatives de connexion effectués.

  • Examinez les paquets supprimés pour savoir combien ont été supprimés par la passerelle NAT.

  • Analysez les paquets. Les paquets TCP avec des paquets de protocole IP fragmentés indiquent la fragmentation des adresses IP. La passerelle NAT ne prend pas en charge la fragmentation des adresses IP ; de ce fait, les connexions avec des paquets fragmentés échouent.

  • Vérifiez que l’adresse IP publique de la passerelle NAT est répertoriée comme autorisée au niveau des destinations partenaires avec des pare-feu ou d’autres composants de gestion du trafic.

Solutions possibles pour les échecs de connexion au niveau de la destination Internet

  • Vérifiez que l’adresse IP publique de la passerelle NAT est répertoriée comme autorisée au niveau de la destination.

  • Si vous effectuez des tests de taux de transactions ou de volume élevé, vérifiez si la réduction du taux réduit l’occurrence des défaillances.

  • Si la réduction du taux de connexions diminue l’occurrence des défaillances, vérifiez si la destination a atteint ses limites de débit d’API ou d’autres contraintes.

Échecs de connexion sur le serveur FTP en mode actif ou passif

Scénario

Vous voyez des échecs de connexion sur un serveur FTP lors de l’utilisation de la passerelle NAT avec le mode FTP actif ou passif.

Causes possibles

  • Le mode FTP actif est activé.

  • Le mode FTP passif est activé et la passerelle NAT utilise plusieurs adresses IP publiques.

Solution possible au mode FTP actif

Le protocole FTP utilise deux canaux distincts entre un client et un serveur, les canaux de commandes et de données. Chaque canal communique sur des connexions TCP distinctes, l’une pour envoyer les commandes et l’autre pour transférer les données.

En mode FTP actif, le client établit le canal de commandes et le serveur établit le canal de données.

La passerelle NAT n’est pas compatible avec le mode FTP actif. Le protocole FTP actif utilise une commande PORT du client FTP qui indique au serveur FTP l’adresse IP et le port que le serveur doit utiliser sur le canal de données pour se reconnecter au client. La commande PORT utilise l’adresse privée du client qui ne peut pas être modifiée. Le trafic côté client est traduit au format SNAT par la passerelle NAT pour la communication basée sur Internet de sorte que la commande PORT est considérée comme non valide par le serveur FTP.

Une solution alternative au mode FTP actif consiste à utiliser le mode FTP passif à la place. Toutefois, pour utiliser la passerelle NAT en mode FTP passif, il convient de prendre en compte certaines considérations.

Solution possible au mode FTP passif

En mode FTP passif, le client établit des connexions sur les canaux de commandes et de données. Le client demande que le serveur réponde sur un port au lieu d’établir une reconnexion au client.

Le protocole FTP passif sortant ne fonctionne pas pour une passerelle NAT ayant plusieurs adresses IP publiques ; cela dépend de la configuration de votre serveur FTP. Lorsqu’une passerelle NAT possédant plusieurs adresses IP publiques envoie du trafic vers l’extérieur, elle sélectionne de manière aléatoire l’une de ses adresses IP publiques comme adresse IP source. Le protocole FTP échoue lorsque les canaux de données et de contrôle utilisent des adresses IP sources différentes ; cela dépend de la configuration de votre serveur FTP.

Pour éviter d’éventuels échecs de connexion FTP passive, veillez à effectuer les étapes suivantes :

  1. Vérifiez que votre passerelle NAT est attachée à une seule adresse IP publique plutôt qu’à plusieurs adresses IP ou un préfixe.

  2. Assurez-vous que la plage de ports passive de votre passerelle NAT est autorisée à passer tous les pare-feu au niveau du point de terminaison de destination.

Remarque

Le fait de réduire la quantité d’adresses IP publiques sur votre passerelle NAT réduit l’inventaire des ports SNAT disponible pour établir des connexions sortantes et peut augmenter le risque d’épuisement des ports SNAT. Prenez en compte vos besoins en matière de connectivité SNAT avant de supprimer les adresses IP publiques de la passerelle NAT. Il n’est pas recommandé de modifier les paramètres du serveur FTP pour accepter le trafic de contrôle et de plan de données provenant de différentes adresses IP sources.

Les connexions sortantes sur le port 25 sont bloquées.

Scénario

Impossible de connecter le trafic sortant à la passerelle NAT sur le port 25 pour le protocole SMTP (Simple Mail Transfer Protocol).

Cause

La plateforme Azure bloque les connexions SMTP sortantes sur le port TCP 25 pour les machines virtuelles déployées. Ce blocage vise à garantir une meilleure sécurité pour les partenaires et clients Microsoft, de protéger la plateforme Azure de Microsoft et de se conformer aux normes du secteur.

Utilisez un service de relais SMTP authentifié pour envoyer des e-mails à partir de machines virtuelles Azure ou d’Azure App Service. Pour plus d’informations, consultez Résoudre les problèmes de connectivité SMTP sortante.

Instructions supplémentaires pour la résolution des problèmes

Captures réseau supplémentaires

Si votre investigation n’est pas concluante, ouvrez un cas de support pour la résolution et collectez les informations suivantes pour accélérer le processus. Choisissez une seule machine virtuelle dans votre sous-réseau configuré avec la passerelle NAT et effectuez les tests suivants :

  • Testez la réponse du port de la sonde à l’aide de ps ping à partir d’une des machines virtuelles back-end dans le réseau virtuel et enregistrez les résultats (exemple : ps ping 10.0.0.4:3389).

  • Si aucune réponse n’est reçue dans ces tests Ping, exécutez une trace netsh simultanée sur la machine virtuelle back-end et la machine virtuelle test du réseau virtuel tout en exécutant PsPing, puis arrêtez la trace netsh.

Meilleures pratiques en matière de connectivité sortante

Azure supervise et exécute son infrastructure avec beaucoup de soin. Toutefois, des échecs temporaires peuvent tout de même se produire à partir des applications déployées, et il n’y a aucune garantie de transmission sans perte. La passerelle NAT est l’option préférée pour établir une connectivité sortante hautement fiable et résiliente à partir de déploiements Azure. Pour optimiser l’efficacité de la connexion d’application, reportez-vous aux instructions ci-après dans l’article.

Utiliser le regroupement de connexions

En regroupant vos connexions, vous n’avez pas besoin d’ouvrir de nouvelles connexions réseau pour les appels vers les mêmes adresse et port. Vous pouvez implémenter un schéma de regroupement de connexions dans votre application, dans lequel les demandes sont distribuées en interne sur un ensemble fixe de connexions et réutilisées quand cela est possible. Ce schéma limite le nombre de ports SNAT utilisés et crée un environnement prévisible. Le regroupement de connexions permet de réduire la latence et l’utilisation des ressources, et d’améliorer les performances de vos applications.

Pour en savoir plus sur le regroupement des connexions HTTP, consultez Regrouper des connexions HTTP avec HttpClientFactory.

Réutiliser les connexions

Au lieu de générer des connexions TCP atomiques individuelles pour chaque demande, configurez votre application pour réutiliser les connexions. La réutilisation des connexions se traduit par des transactions TCP plus performantes et est particulièrement pertinente pour les protocoles comme HTTP/1.1, où la réutilisation des connexions est la valeur par défaut. Cette réutilisation s’applique à d’autres protocoles qui utilisent HTTP comme transport, tel que REST.

Utiliser une logique de nouvelle tentative moins agressive

Quand les ports SNAT sont épuisés ou que des applications échouent, des tentatives de reconnexion agressives ou par force brute sans logique de réduction ou d’interruption ne font que générer ou accentuer le problème. Vous pouvez réduire la demande de ports SNAT en utilisant une logique de nouvelle tentative moins agressive.

Selon le délai d’inactivité configuré, si les nouvelles tentatives sont trop agressives, les connexions n’ont pas suffisamment de temps pour fermer et libérer des ports SNAT en vue de leur réutilisation.

Pour d’autres exemples ou instructions, consultez Modèle de nouvelle tentative.

Utiliser des conservations de connexion active pour réinitialiser le délai d’inactivité en sortie

Pour plus d’informations sur les keepalives, consultez Délai d’inactivité TCP.

Quand cela est possible, vous devez utiliser Private Link pour connecter directement vos réseaux virtuels aux services de la plateforme Azure afin de réduire la demande sur les ports SNAT. La réduction de la demande sur les ports SNAT peut contribuer à réduire le risque d’épuisement du port SNAT.

Pour créer un Private Link, reportez-vous aux guides de démarrage rapide suivants pour commencer :

Étapes suivantes

Nous nous efforçons toujours d’améliorer l’expérience de nos clients. Si vous rencontrez des problèmes de passerelle NAT qui ne sont pas traités ou résolus par cet article, fournissez des commentaires via GitHub en bas de cette page.

Pour en savoir plus sur la passerelle NAT, consultez :