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é.
Comme condition préalable à ce guide, vous devez avoir une connaissance pratique d'Azure NAT Gateway et comprendre ses fonctionnalités respectives. Pour plus d'informations, consultez la documentation de Azure NAT Gateway.
Optimisation des coûts
Configurez l'accès aux solutions de plateforme en tant que service (PaaS) via Azure Private Link ou les points de terminaison des services, y compris le stockage, afin de ne pas avoir à 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 gigaoctet (Go) de données traitées, par rapport au coût d'utilisation d'une passerelle NAT. La liaison privée et les points de terminaison des services offrent également des avantages en termes 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 une passerelle NAT à chaque sous-réseau ou groupe de sous-réseaux afin de les faire évoluer.
Chaque adresse IP publique de passerelle NAT fournit 64 512 ports SNAT (Source Network Address Translation). Vous pouvez attribuer jusqu'à 16 adresses IP à une passerelle NAT, y compris des adresses IP publiques standard individuelles, le préfixe IP public ou les deux. Pour chaque adresse IP sortante attribuée qui va au même point de terminaison, la passerelle NAT peut prendre en charge jusqu'à 50 000 flux simultanés pour le protocole de contrôle de transmission (TCP) et le protocole de datagramme d'utilisateur (UDP) respectivement.
Épuisement des ressources SNAT
Tenez compte des conseils suivants pour éviter l'épuisement du SNAT :
Les ressources de passerelle NAT ont un délai d’inactivité TCP par défaut de quatre minutes. Vous pouvez configurer le délai d'attente jusqu'à 120 minutes. Si vous modifiez ce paramètre à une valeur plus élevée que la valeur par défaut, la passerelle NAT conserve les flux plus longtemps, ce qui peut créer une pression inutile sur l'inventaire des ports SNAT.
Les requêtes atomiques (une requête par connexion) limitent l'échelle, réduisent les performances et la fiabilité. Au lieu de requêtes atomiques, vous pouvez réutiliser des connexions HTTP ou HTTPS pour réduire le nombre de connexions et de ports SNAT associés. Lorsque vous réutilisez des connexions, l'application peut mieux évoluer. Les performances de l'application s'améliorent grâce à la réduction des liaisons, des frais généraux et des coûts des opérations cryptographiques lorsque vous utilisez le protocole TLS (Transport Layer Security).
Si vous ne mettez pas en cache les résultats du résolveur DNS, les consultations du système de noms de domaine (DNS) peuvent introduire de nombreux flux individuels en volume. 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 délai d'attente UDP est fixé à quatre minutes.
Utilisez des pools de connexions pour déterminer votre volume de connexions.
Pour nettoyer les flux, n'abandonnez pas silencieusement les flux TCP et ne vous fiez pas aux temporisateurs TCP. Si vous ne laissez pas le protocole TCP fermer explicitement une 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 modifiez pas les valeurs des temporisateurs TCP-close au niveau du système d'exploitation à moins d'en connaître les implications. Si les points de terminaison d'une connexion n'ont pas les mêmes attentes, la pile TCP peut se rétablir, mais cela peut avoir un effet négatif sur les performances de votre application. Vous avez généralement un problème de conception sous-jacent si vous devez modifier les valeurs des temporisateurs. Et si l'application sous-jacente présente d'autres antimodèles et que vous modifiez les valeurs des temporisateurs, vous risquez également d'accélérer l'épuisement du SNAT.
Passez en revue les conseils suivants pour améliorer la mise à l'échelle et la fiabilité de votre service :
Considérez les effets de la réduction du délai d'inactivité TCP à une valeur inférieure. Un délai d'inactivité par défaut de quatre minutes peut libérer de manière préemptive l'inventaire des ports SNAT.
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.
Envisagez d'utiliser des keepalives TCP ou des keepalives de la couche application pour les flux TCP de longue durée, tels que les connexions TCP réutilisées, afin d'éviter que les systèmes intermédiaires ne s'arrêtent au bout d'un certain temps. 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 première. Un délai d'attente trop long peut entraîner des défaillances à faible taux à l'expiration du délai. Il peut également entraîner un retard et des défaillances inutiles. Vous pouvez activer les keepalives TCP d'un côté d'une connexion pour maintenir une connexion en vie des deux côtés.
Pensez à utiliser les keepalives UDP pour les flux UDP à longue durée de vie afin d'éviter que les systèmes intermédiaires ne se désynchronisent. Lorsque vous activez les keepalives UDP d'un côté de la connexion, seul un côté de la connexion reste actif. Vous devez activer les keepalives UDP des deux côtés d'une connexion pour qu'elle reste active.
Envisagez des modèles de tentatives gracieuses pour éviter les tentatives agressives et les rafales en cas de défaillance transitoire ou de reprise après une défaillance. Dans le cas des antimodèles de connexions atomiques, vous créez une nouvelle connexion TCP pour chaque opération HTTP. Les connexions atomiques gaspillent des ressources et empêchent votre application d'évoluer correctement.
Pour augmenter la vitesse des transactions et réduire le coût des ressources de votre application, il est préférable de toujours utiliser le pipeline pour plusieurs opérations dans la même connexion. Lorsque votre application utilise le chiffrement de la couche de transport, par exemple TLS, le traitement des nouvelles connexions augmente les coûts. Pour plus de modèles de meilleures pratiques, consultez les modèles de conception du cloud Azure.
Excellence opérationnelle
Vous pouvez utiliser une passerelle NAT avec Azure Kubernetes Service (AKS), mais la gestion des passerelles NAT n'est pas incluse dans AKS. Si vous attribuez une passerelle NAT au sous-réseau Container Networking Interface (CNI), vous permettez aux pods AKS de sortir via la passerelle NAT.
Lorsque vous utilisez plusieurs passerelles NAT à travers des zones ou des régions, gardez le domaine IP sortant gérable en utilisant des préfixes IP publics Azure ou des préfixes BYOIP (bring-your-own IP). Vous ne pouvez pas attribuer une taille de préfixe IP supérieure à 16 adresses IP (taille de préfixe /28) à une passerelle NAT.
Utilisez les alertes Azure Monitor pour surveiller et alerter sur l'utilisation des ports SNAT, les paquets traités ou abandonnés, et la quantité de données transmises. Utilisez les journaux de flux du groupe de sécurité réseau (NSG) pour surveiller le flux de trafic sortant des instances de machines virtuelles (VM) dans un sous-réseau configuré avec une passerelle NAT.
Lorsque vous configurez un sous-réseau 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 est prioritaire sur un équilibreur de charge, quelles que soient les règles de sortie. La passerelle est également prioritaire sur les adresses IP publiques attribuées directement aux machines virtuelles. Azure suit la direction d'un flux et empêche le routage asymétrique. Le trafic entrant, tel que l'IP frontale d'un équilibreur de charge, est traduit correctement et séparément du trafic sortant par l'intermédiaire d'une passerelle NAT. Cette séparation permet aux services entrants et sortants de coexister en toute transparence.
Nous recommandons l'utilisation d'une passerelle NAT par défaut pour permettre la connectivité sortante des réseaux virtuels. Une passerelle NAT offre une efficacité et une simplicité opérationnelle par rapport à d'autres techniques de connectivité sortante dans 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 à l'antimodèle de connectivité sortante par défaut pour votre domaine. Au lieu de cela, définissez explicitement votre configuration avec les ressources de la passerelle NAT.
Fiabilité
Les ressources de passerelle NAT sont hautement disponibles dans une zone de disponibilité et couvrent différents domaines d’erreur. Vous pouvez déployer une passerelle NAT dans une no zone dans laquelle Azure sélectionne automatiquement une zone pour placer la passerelle NAT ou isole la passerelle NAT dans une zone de disponibilité spécifique.
Pour assurer l'isolation des zones de disponibilité, chaque sous-réseau doit disposer de ressources uniquement dans une zone spécifique. Pour mettre en œuvre cette approche, vous pouvez procéder comme suit :
- Déployez un sous-réseau pour chacune des zones de disponibilité où des machines virtuelles sont déployées.
- Alignez les machines virtuelles zonales avec les passerelles NAT zonales correspondantes.
- Créez des piles zonales distinctes.
Dans le diagramme suivant, une machine virtuelle de la zone de disponibilité 1 se trouve sur un sous-réseau avec d'autres ressources qui se trouvent également uniquement dans la zone de disponibilité 1. Une passerelle NAT est configurée dans la zone de disponibilité 1 pour servir ce sous-réseau.
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 une passerelle NAT, les machines virtuelles individuelles ou d'autres ressources de calcul n'ont pas besoin d'adresses IP publiques et peuvent rester totalement 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 IP public pour vous assurer que vous utilisez un ensemble contigu d'IP pour la connectivité sortante. Vous pouvez configurer des règles de pare-feu de destination basées sur cette liste d'adresses IP prévisibles.
Une approche courante consiste à concevoir un scénario d'appliance virtuelle réseau (NAT) uniquement pour la connectivité sortante avec des pare-feu non Microsoft ou des serveurs proxy. Lorsque vous déployez une passerelle NAT sur un sous-réseau avec un ensemble de NVA à l'échelle d'une machine virtuelle, ces NVA utilisent une ou plusieurs adresses de passerelle NAT pour la connectivité sortante au lieu d'une IP d'équilibreur de charge ou d'IP individuelles. Pour utiliser ce scénario avec le Pare-feu Azure, consultez Intégrer le Pare-feu Azure à Azure Standard Load Balancer.
Vous pouvez utiliser la fonctionnalité d'alerte de Microsoft Defender pour le Cloud pour surveiller toute connectivité sortante suspecte dans une passerelle NAT.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Ethan Haslett | Architecte de solution cloud senior
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Microsoft Well-Architected Framework
- Tutoriel : Créer une passerelle NAT avec le portail Azure
- Recommandations relatives à l’utilisation des zones de disponibilité et des régions