Modifier

Révision Azure Well-Architected Framework d'une passerelle NAT Azure

Azure Application Gateway
Réseau virtuel Azure
Azure Private Link

Cet article présente les meilleures pratiques relatives à une passerelle NAT Azure. Les conseils sont fondés sur les cinq piliers de l’excellence architecturale : l’optimisation des coûts, l’excellence opérationnelle, l’efficacité des performances, la fiabilité et la sécurité.

Nous partons du principe que vous avez des connaissances pratiques sur le service Azure NAT Gateway, et que vous êtes à l’aise avec leurs fonctionnalités respectives. Pour vous rafraîchir la mémoire, consultez la documentation complète consacrée à Azure NAT Gateway.

NAT (Network Address Translation) signifie traduction d'adresses réseau. Consultez Présentation de la traduction d'adresses réseau (NAT).

Optimisation des coûts

L'accès aux services PaaS doit se faire par le biais d'Azure Private Link ou de points de terminaison de service (y compris pour le stockage) afin d'éviter d'utiliser une passerelle NAT. Avec Private Link et les points de terminaison de service, il n'est pas nécessaire de traverser la passerelle NAT pour accéder aux services PaaS. Cette approche permet de réduire le coût par Go de données traitées si l'on compare les coûts d'une passerelle NAT à ceux de Private Link ou des points de terminaison de service. L'utilisation de Private Link ou de points de terminaison de service présente des avantages supplémentaires en matière de sécurité.

Efficacité des performances

Chaque ressource de passerelle NAT fournit jusqu'à 50 Gbits/s de débit. Vous pouvez diviser vos déploiements en plusieurs sous-réseaux, puis attribuer à chaque sous-réseau ou groupe de sous-réseaux une passerelle NAT pour effectuer un scale-out.

Chaque adresse IP publique de passerelle NAT fournit 64 512 ports SNAT. Jusqu'à 16 adresses IP peuvent être attribuées à une passerelle NAT. Les adresses IP peuvent être des adresses IP publiques standard individuelles, le préfixe de l'adresse IP publique, ou les deux. Pour les connexions qui accèdent au même point de terminaison de destination, la passerelle NAT peut prendre en charge jusqu’à 50 000 flux simultanés respectivement pour TCP et pour UDP par adresse IP sortante attribuée. Pour plus de détails, consultez la section suivante sur la traduction d'adresses réseau sources (SNAT). TCP est l'abréviation de Transmission Control Protocol, et UDP d'User Datagram Protocol.

Épuisement des ressources SNAT

  • Les ressources de la passerelle NAT ont un délai d’expiration pour inactivité de TCP de 4 minutes par défaut, qui peut être configuré jusqu’à 120 minutes. Si ce paramètre est défini sur une valeur plus élevée que la valeur par défaut, la traduction d’adresses réseau (passerelle NAT) se mettra en attente plus longtemps sur les flux et entraîner une pression inutile sur le stock des ports SNAT.
  • Les requêtes atomiques (une requête par connexion) ne constituent pas un bon choix de conception, car elles limitent la mise à l'échelle, et réduisent les performances et la fiabilité. Réutilisez plutôt les connexions HTTP/S afin de réduire le nombre de connexions et de ports SNAT associés. La réutilisation des connexions permettra une meilleure mise à l'échelle de l'application. Les performances de l'application s'amélioreront grâce à la réduction du nombre d'établissements de liaison, des frais généraux et des coûts des opérations de chiffrement lors de l'utilisation du protocole TLS.
  • Les recherches de DNS (Domain Name System) peuvent introduire un grand nombre de flux individuels lorsque le client ne met pas en cache le résultat des programmes de résolution DNS. Utilisez la mise en cache DNS pour réduire le volume des flux et le nombre de ports SNAT. DNS est le système de nommage qui mappe les noms de domaine aux adresses IP pour les ressources connectées à Internet ou à un réseau privé.
  • Les flux UDP, tels que les recherches DNS, utilisent les ports SNAT pendant le délai d'inactivité. Le minuteur de délai d’inactivité UDP est défini sur 4 minutes et ne peut pas être modifié.
  • Utilisez des pools de connexions pour déterminer votre volume de connexions.
  • N’abandonnez jamais un flux TCP en mode silencieux et ne vous fiez pas aux minuteries TCP pour nettoyer un flux. Si vous ne laissez pas le protocole TCP fermer explicitement la connexion, la connexion TCP reste ouverte. Les systèmes intermédiaires et les points de terminaison maintiennent cette connexion en service, ce qui rend le port SNAT indisponible pour d'autres connexions. Cet anti-modèle peut provoquer l'échec des applications et l'épuisement des ports SNAT.
  • Ne changez pas les valeurs du minuteur de fermeture TCP au niveau du système d'exploitation sans en connaître précisément l'impact. Même si la pile TCP est récupérée, les performances de votre application risquent d’être affectées si les points de terminaison d’une connexion ont des attentes incompatibles. La modification des valeurs du minuteur est généralement le signe d'un problème de conception sous-jacent. Lorsque l'application sous-jacente présente d'autres anti-modèles, l'épuisement des ports SNAT peut également être amplifié si les valeurs du minuteur sont modifiées.

Passez en revue les conseils suivants pour améliorer la mise à l'échelle et la fiabilité de votre service :

  • Examinez l'effet d'une réduction du délai d'inactivité TCP à des valeurs inférieures. Un délai d'inactivité par défaut de 4 minutes peut libérer l'inventaire des ports SNAT plus tôt.
  • Envisagez d'utiliser des modèles d'interrogation asynchrone pour les opérations de longue durée afin de libérer vos ressources de connexion pour d'autres opérations.
  • Les flux à longue durée de vie, comme les connexions TCP réutilisées, doivent utiliser les conservations de connexion active associées au protocole TCP ou à la couche Application afin d'éviter l'expiration du délai d'attente des systèmes intermédiaires. Vous ne devez augmenter le délai d'inactivité qu'en dernier recours, et il se peut que cela ne résolve pas la cause racine. Un long délai d'expiration peut entraîner des échecs liés au faible débit, lorsque le délai d'attente expire, ainsi qu'un retard et des échecs inutiles. Les conservations de connexion active TCP peuvent être activées à partir d’un côté de la connexion afin de maintenir la connexion des deux côtés.
  • Pour les flux de longue durée avec le trafic UDP, vous pouvez activer les conservations de connexion active UDP pour conserver les connexions actives. N’oubliez pas que les conservations de connexion active UDP sur un côté de la connexion ne conservent la connexion active qu’à partir d’un côté. Les conservations de connexion active UDP doivent être activées sur les deux côtés d’une connexion afin de conserver une connexion active.
  • Les modèles de nouvelle tentative sans perte de données doivent être utilisés pour éviter les nouvelles tentatives agressives/rafales en cas de défaillance temporaire ou de reprise d’activité après défaillance. Les connexions atomiques constituent un anti-modèle associé à création d'une nouvelle connexion TCP pour chaque opération HTTP. Les connexions atomiques empêchent votre application d'être correctement mise à l'échelle et gaspillent des ressources. Canalisez toujours plusieurs opérations dans la même connexion. Votre application tire parti de la vitesse des transactions et des coûts des ressources. Lorsque votre application utilise le chiffrement de la couche de transport (par exemple, TLS), un coût élevé est associé au traitement des nouvelles connexions. Consultez Modèles de conception Azure Cloud pour accéder à d'autres modèles de bonnes pratiques.

Excellence opérationnelle

Bien que la passerelle NAT puisse être utilisée avec Azure Kubernetes Service (AKS), elle n'est pas gérée dans le cadre d'AKS. Si vous attribuez une passerelle NAT au sous-réseau Container Networking Interface (CNI), vous permettrez aux pods AKS de sortir via la passerelle NAT.

Lorsque vous utilisez plusieurs passerelles NAT dans différentes zones ou régions, faites en sorte que le domaine IP sortant reste gérable en utilisant des préfixes d'adresses IP publiques Azure ou des préfixes BYOIP. Vous ne pouvez pas affecter une taille de préfixe IP supérieure à 16 adresses IP (taille de préfixe /28) à la passerelle NAT.

Utilisez des alertes Azure Monitor pour superviser et alerter sur l’utilisation des ports SNAT, sur les paquets traités ou supprimés, et sur la quantité de données transmises. Utilisez les journaux de flux NSG pour superviser le flux du trafic sortant provenant d’instances de machine virtuelle dans un sous-réseau configuré en passerelle NAT.

Lorsqu'un sous-réseau est configuré avec une passerelle NAT, celle-ci remplace toute autre connectivité sortante vers l'Internet public pour toutes les machines virtuelles de ce sous-réseau. La passerelle NAT aura la priorité sur un équilibreur de charge avec ou sans règles de trafic sortant, et sur les adresses IP publiques attribuées directement aux machines virtuelles. Azure suit la direction d'un flux, et aucun routage asymétrique ne se produit. Le trafic entrant est correctement traduit, comme l'adresse IP front-end d'un équilibreur de charge, et il est traduit séparément du trafic sortant via une passerelle NAT. Cette séparation permet aux services entrants et sortants de coexister en toute transparence.

La passerelle NAT est recommandée par défaut pour activer la connectivité sortante des réseaux virtuels. La passerelle NAT est plus efficace et moins complexe sur le plan opérationnel que les autres techniques de connectivité sortante d'Azure. Les passerelles NAT allouent les ports SNAT à la demande et utilisent un algorithme plus efficace pour éviter les conflits de réutilisation des ports SNAT. Ne vous fiez pas à la connectivité sortante par défaut (anti-modèle) pour votre domaine. Au lieu de cela, définissez-le explicitement avec des ressources de passerelle NAT.

Fiabilité

Les ressources de passerelle NAT sont hautement disponibles dans une zone de disponibilité et couvrent différents domaines d’erreur. La passerelle NAT peut être déployée sur « aucune zone », où Azure sélectionne automatiquement une zone pour placer la passerelle NAT. La passerelle NAT peut également être isolée dans une zone spécifique par un utilisateur.

L'isolation par zone de disponibilité ne peut pas être assurée, sauf si chaque sous-réseau ne possède des ressources que dans une zone spécifique. Déployez plutôt un sous-réseau pour chacune des zones de disponibilité où les machines virtuelles sont déployées, alignez les machines virtuelles zonales sur les passerelles NAT zonales correspondantes, et créez des piles zonales distinctes. Par exemple, une machine virtuelle de la zone de disponibilité 1 se trouve sur un sous-réseau avec d'autres ressources qui ne se trouvent également que dans la zone de disponibilité 1. Une passerelle NAT est configurée dans la zone de disponibilité 1 pour servir ce sous-réseau. Consultez le schéma suivant.

Schéma illustrant le flux directionnel d'une pile zonale.

Les réseaux virtuels et les sous-réseaux couvrent toutes les zones de disponibilité d’une région. Vous n’avez pas besoin de les diviser par zones de disponibilité pour prendre en charge les ressources zonales.

Sécurité

Avec la passerelle NAT, les machines virtuelles individuelles (ou d’autres ressources de calcul) n’ont pas besoin d’adresses IP publiques et peuvent rester entièrement privées. Les ressources sans adresse IP publique peuvent néanmoins toujours atteindre des sources externes en dehors du réseau virtuel. Vous pouvez associer un préfixe d’adresse IP publique pour garantir qu’un ensemble contigu d’adresses IP sera utilisé pour la connectivité sortante. Des règles de pare-feu de destination peuvent être configurées en fonction de cette liste d’adresses IP prévisibles.

Une approche courante consiste à concevoir un scénario d'appliance virtuelle de réseau (NVA) uniquement en sortie avec des pare-feu tiers ou des serveurs proxy. Lorsqu'une passerelle NAT est déployée sur un sous-réseau avec un groupe de machines virtuelles identiques de NVA, ces NVA utilisent les adresses de la passerelle NAT pour la connectivité sortante, par opposition à l'adresse IP d'un équilibreur de charge ou à des adresses IP individuelles. Pour utiliser ce scénario avec le Pare-feu Azure, consultez Intégrer le Pare-feu Azure à Azure Standard Load Balancer.

Schéma illustrant des pare-feu avec un sandwich d'équilibreurs de charge et une passerelle NAT.

Microsoft Defender pour le cloud peut surveiller toute connectivité sortante suspecte via une passerelle NAT. Il s’agit d’une fonctionnalité d’alerte de Microsoft Defender pour le cloud.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes