Cloud
Azure NAT Gateway : diagnostiquer l’épuisement SNAT et la dérive d’IP sortante
Un runbook opérationnel pour qualifier les incidents de sortie Azure liés à NAT Gateway, aux ports SNAT, aux UDR, aux NSG, aux firewalls, aux allowlists et au rollback.
Un incident NAT Gateway ressemble rarement à un incident NAT. Une API externe répond par intermittence, un partenaire refuse une IP non prévue, des workers voient des timeouts, ou un service SaaS commence à rejeter des appels pourtant valides. La tentation est forte d’ouvrir l’allowlist côté destination ou de redéployer l’application.
Le bon réflexe est de traiter la sortie Azure comme une chaîne exploitable : subnet source, routes, filtrage, NAT Gateway, ports SNAT, IP observée par la destination, logs et rollback. Le cas d’usage est un workload Azure qui sort vers Internet, un partenaire, une API SaaS ou un service exposé publiquement avec allowlist d’IP.
Lire la sortie comme une chaîne
NAT Gateway agit au niveau du subnet. Il ne corrige pas une route qui part vers un firewall, une résolution DNS incorrecte, une règle NSG trop stricte ou une destination qui refuse l’IP réellement vue.
Workload
App Service via VNet Integration, AKS node subnet, VM, job, runner or appliance
Source subnet documented
Expected destination hostname, port and protocol
Resolution
FQDN resolved from the workload path
Public or private address expected
No conclusion based only on the admin workstation
Routing
Effective route from the source subnet
UDR toward Internet, NAT Gateway path, Azure Firewall or NVA
No accidental default route overriding the expected egress
Filtering
NSG on the source subnet or NIC
Azure Firewall or NVA rule when traffic is routed there
Destination-side allowlist or policy
NAT and evidence
NAT Gateway attached to the source subnet
Public IP or prefix expected
SNAT capacity and connection churn
Destination logs, firewall logs and application traces aligned by timestampCette lecture évite deux erreurs fréquentes : conclure trop vite à un épuisement SNAT alors que la route contourne NAT Gateway, ou modifier l’application alors que la destination voit une IP différente de celle documentée.
Classer le symptôme avant de changer l’allowlist
Les mêmes timeouts peuvent venir d’une saturation de ports SNAT, d’un firewall, d’une route, d’une règle destination ou d’une résolution DNS. Le premier travail est de classer le symptôme avec le point de test.
Symptôme observé
Timeouts intermittents sous charge
Vérifier la réutilisation de connexions, le churn TCP, la capacité SNAT et les métriques NAT Gateway
403 ou refus côté partenaire
Comparer l’IP sortante observée avec l’allowlist réellement active
Fonctionne depuis une VM mais pas depuis l’application
Rejouer depuis le subnet réel ou un probe équivalent
Aucun log côté NAT Gateway ou firewall
Revenir à DNS, route effective, NSG ou mauvais point de test
Incident après un changement réseau
Comparer UDR, association NAT Gateway, IP publique, préfixe, firewall et NSG
Incident après montée de trafic
Vérifier ports SNAT, pooling de connexions, keep-alive et fan-out vers la même destinationUne allowlist plus large peut masquer le problème pendant quelques heures. Elle ne prouve pas que l’egress est maîtrisé.
Prouver le subnet et l’IP sortante
Commencez par vérifier que le workload sort bien depuis le subnet que vous diagnostiquez, puis contrôlez l’association NAT Gateway et l’IP vue par la destination.
VNET_RG=rg-prod-network
VNET=vnet-prod-spoke
SUBNET=snet-prod-workers
az network vnet subnet show -g "$VNET_RG" --vnet-name "$VNET" -n "$SUBNET" --query "{name:name,addressPrefix:addressPrefix,natGateway:natGateway.id,routeTable:routeTable.id,nsg:networkSecurityGroup.id}" -o jsonc
az network nat gateway show --ids "$(az network vnet subnet show -g "$VNET_RG" --vnet-name "$VNET" -n "$SUBNET" --query natGateway.id -o tsv)" --query "{name:name,publicIps:publicIpAddresses[].id,publicPrefixes:publicIpPrefixes[].id,sku:sku.name,idleTimeout:idleTimeoutInMinutes}" -o jsonc
# A exécuter depuis le workload, un conteneur de diagnostic ou un probe équivalent.
curl -s https://ifconfig.me
curl -vk --connect-timeout 5 https://api.partner.example/healthPour App Service ou Functions avec VNet Integration, le test doit être fait depuis le contexte applicatif ou un point réellement équivalent. Pour AKS, le subnet des nodes et les chemins de sortie du cluster doivent être distingués des pods, ingress et appliances.
Lire routes, NSG et firewall ensemble
NAT Gateway n’est pas toujours le dernier composant avant Internet. Une route par défaut vers Azure Firewall ou une NVA peut être volontaire. Dans ce cas, l’IP sortante observée par la destination peut être celle du firewall, pas celle de NAT Gateway.
NIC_ID=/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod/providers/Microsoft.Network/networkInterfaces/nic-prod-worker-01
az network nic show-effective-route-table --ids "$NIC_ID" -o table
az network nic list-effective-nsg --ids "$NIC_ID" -o table
# Si le subnet est routé vers Azure Firewall, vérifier le chemin firewall au lieu de conclure sur NAT Gateway.
FIREWALL_RG=rg-prod-sec
FIREWALL_NAME=afw-prod
az network firewall show -g "$FIREWALL_RG" -n "$FIREWALL_NAME" --query "{name:name,ipConfigurations:ipConfigurations[].publicIpAddress.id,sku:sku.tier}" -o jsoncLe diagnostic doit donc répondre à une question simple : quel composant porte réellement l’IP de sortie pour ce flux précis ?
Chercher l’épuisement SNAT avec des preuves
L’épuisement SNAT apparaît surtout avec beaucoup de connexions sortantes vers le même endpoint, des connexions courtes, peu de pooling ou une montée de charge brutale. Le symptôme typique est intermittent : tout fonctionne en faible charge, puis les timeouts apparaissent.
Pack de preuves minimal
Période exacte de l’incident
Subnet source et NAT Gateway associée
Destination, port et protocole
Volume de connexions et taux d’erreur applicatif
IP sortante observée par la destination
Métriques NAT Gateway sur la même période
Logs firewall ou destination si un intermédiaire existe
Changement récent de route, NAT, IP publique, code ou chargeLes métriques disponibles dépendent de la configuration et de la collecte activée. Le principe reste le même : corréler capacité SNAT, tentatives de connexion et erreurs applicatives sur la même fenêtre.
let Window = 2h;
let TargetHost = "api.partner.example";
AppTraces
| where TimeGenerated > ago(Window)
| where Message has_any (TargetHost, "timeout", "SocketException", "connection reset", "connection refused", "403")
| project TimeGenerated, AppRoleName, SeverityLevel, Message, OperationId
| order by TimeGenerated descSi la destination fournit des logs, demandez l’IP source, le timestamp, le path et le statut. Une erreur 403 avec IP inattendue ne se traite pas comme un timeout sans aucune trace côté destination.
Corriger sans ouvrir trop large
La correction doit viser la couche prouvée. Ajouter une IP à l’allowlist peut être correct si l’IP observée est légitime et documentée. Ajouter toute une plage ou contourner le firewall sans preuve est une dette d’exploitation.
Cause prouvée
NAT Gateway absent du subnet source
Correction: associer NAT Gateway au bon subnet ou corriger le point de sortie
Validation: la destination voit l’IP attendue
Route par défaut vers firewall ou NVA
Correction: documenter l’egress réel ou ajuster UDR et règles firewall
Validation: logs firewall et destination cohérents
IP sortante non alignée avec l’allowlist
Correction: aligner IP publique, préfixe ou allowlist ciblée
Validation: test horodaté depuis le workload
Epuisement SNAT probable
Correction: réduire le churn, réutiliser les connexions, répartir la charge ou augmenter la capacité de sortie
Validation: baisse des timeouts et métriques stables
NSG ou firewall bloque le flux
Correction: règle ciblée source, destination, port, protocole
Validation: deny disparu sans ouverture globaleDans beaucoup d’incidents, la meilleure correction n’est pas réseau : activer le pooling HTTP, réduire le fan-out, fixer un timeout raisonnable ou éviter de recréer un client par requête peut réduire fortement la pression SNAT.
Préparer rollback et décision
Un changement d’egress doit avoir un retour arrière clair. Sinon, l’équipe découvre trop tard qu’elle ne sait plus quelle IP un partenaire doit autoriser.
Changement
Association NAT Gateway
Rollback: réassocier l’ancien NAT Gateway ou retirer l’association fautive
Preuve: IP sortante avant/après et test destination
IP publique ou préfixe
Rollback: restaurer l’IP ou le préfixe précédemment autorisé
Preuve: allowlist partenaire et logs de refus
UDR vers firewall ou Internet
Rollback: remettre la route précédente
Preuve: route effective et logs du composant de sortie
Règle NSG ou firewall
Rollback: revenir à la règle précédente ou exception temporaire ciblée
Preuve: deny identifié et périmètre limité
Changement applicatif de pooling
Rollback: revenir à la version précédente si erreurs fonctionnelles
Preuve: timeouts SNAT réduits ou revenusLa décision de retour au service doit être factuelle : l’IP sortante est attendue, les logs destination sont propres, les timeouts ont cessé, et le chemin réseau est documenté.
Conclusion
Un incident NAT Gateway se traite rarement en regardant NAT Gateway seul. Il faut prouver le subnet source, la route effective, le filtrage, l’IP réellement vue, la pression SNAT et les logs de la destination.
La décision devient alors défendable : corriger l’association NAT si le subnet est faux, ajuster les UDR si le trafic sort ailleurs, cibler NSG ou firewall si un deny est prouvé, aligner l’allowlist si l’IP a dérivé, ou réduire le churn applicatif si l’épuisement SNAT est le vrai signal.