Azure NSG, UDR et Firewall : diagnostiquer un trafic bloqué avant d'ajouter une règle

Un flux applicatif bloqué dans Azure finit souvent par produire la même demande : “ajoute une règle NSG” ou “ouvre le firewall pour tester”. C’est rapide, mais rarement un diagnostic. Entre une route effective inattendue, une UDR vers une appliance, un NSG sur la subnet, un NSG sur la carte réseau, Azure Firewall, une résolution DNS incorrecte ou une identité qui appelle le mauvais endpoint, la règle manquante n’est qu’une hypothèse.

Le cas d’usage : une application dans un spoke Azure ne parvient plus à joindre une dépendance interne ou un service PaaS exposé privé. Le déploiement applicatif vient peut-être de changer, une route a été modifiée, un firewall centralisé filtre le trafic, ou un NSG a été durci. L’objectif du runbook est de prouver où le flux s’arrête avant d’ajouter une exception, puis de valider que la correction est limitée et réversible.

Nommer le flux exact

Un incident réseau commence rarement avec assez de détails. “L’application ne joint pas l’API” ne suffit pas pour changer une règle. Il faut décrire le flux comme un objet exploitable : source, destination, port, protocole, environnement, identité applicative et chemin attendu.

Flux a qualifier
Source: subnet-app-prod / vmss-api-prod / private IP 10.42.12.18
Destination: api.internal.example.net / private IP attendue 10.55.4.20
Protocole: TCP
Port: 443
Sens: spoke application vers hub service
Fenetre observee: 30 dernieres minutes
Changement recent: nouvelle UDR sur subnet-app-prod

Preuve attendue avant exception
Resolution DNS depuis la source
Route effective depuis la NIC ou subnet
Decision NSG effective
Logs Azure Firewall ou appliance
Test applicatif avec correlation ID

Ce contrat évite les ouvertures larges du type “source any vers destination any sur 443”. Il force aussi à distinguer un problème de nom, de route, de filtrage ou de service.

Vérifier DNS avant la route

Si la destination est un FQDN, la première question est simple : la source résout-elle l’adresse attendue ? Beaucoup d’incidents réseau sont en réalité des incidents de résolution : zone privée non liée, forwarder absent, suffixe public résolu au mauvais endroit ou cache DNS encore actif.

Depuis le reseau source
nslookup api.internal.example.net
nslookup api.internal.example.net <dns-resolver-attendu>

A comparer
IP retournee depuis la source applicative
IP attendue dans le runbook ou l'inventaire
TTL et cache local
Chaine CNAME si service PaaS ou endpoint prive
Resolver utilise par la VM, le container ou la plateforme

Changer une règle NSG alors que le nom pointe vers une adresse publique ou vers une ancienne IP ne fait qu’ajouter du bruit. Le flux doit d’abord viser la bonne destination.

Lire la route effective

La route théorique dans un schéma ne suffit pas. Dans Azure, la décision dépend des routes système, des peering, des UDR, des propagated routes, du subnet source et parfois du chemin forcé vers Azure Firewall ou une NVA. Il faut lire la route effective depuis la ressource qui émet le trafic.

Controle route effective
Source: NIC ou subnet du workload
Destination: IP resolue de la dependance

Questions
La destination passe-t-elle par VirtualNetwork, Internet, VirtualAppliance ou None ?
Une UDR plus specifique prend-elle le dessus ?
Le next hop correspond-il au firewall attendu ?
Le peering autorise-t-il le forwarded traffic si necessaire ?
Le chemin retour est-il symetrique ou au moins autorise ?

Si la route effective envoie le trafic vers un firewall centralisé, le diagnostic se déplace vers ce firewall. Si elle part vers Internet alors que la destination devrait être privée, la correction est probablement DNS, route ou peering, pas une exception applicative.

Séparer NSG subnet et NSG NIC

Un NSG peut filtrer au niveau subnet et au niveau interface réseau. Les deux décisions comptent. Une règle autorisée sur la subnet ne compense pas un deny plus spécifique sur la NIC, et inversement. Le bon contrôle consiste à regarder les règles effectives, pas seulement le fichier Terraform ou la convention de nommage.

Pour le flux source -> destination
NSG subnet source: regle appliquee, priorite, action
NSG NIC source: regle appliquee, priorite, action
NSG subnet destination si workload Azure: regle appliquee, priorite, action
NSG NIC destination si VM: regle appliquee, priorite, action

Points d'attention
Priorite plus basse = plus prioritaire
Service tag trop large
Regle deny historique
Port ephemeral confondu avec port destination
Flux retour bloque par une regle stateful externe

Les NSG Azure sont stateful pour les flux autorisés, mais cela ne dispense pas de vérifier le chemin retour quand une appliance ou un firewall intervient. Le blocage peut être ailleurs que dans le premier NSG lu.

Utiliser les logs comme preuve, pas comme décoration

Les logs NSG flow logs, Azure Firewall et les journaux applicatifs doivent répondre à une question précise : le paquet a-t-il été vu, autorisé, refusé, traduit ou ignoré ? Une absence de log est aussi un signal, à condition de savoir quel composant aurait dû voir le flux.

let Window = 2h;
let SourceIp = "10.42.12.18";
let DestinationIp = "10.55.4.20";
AzureDiagnostics
| where TimeGenerated > ago(Window)
| where Category in ("AzureFirewallNetworkRule", "AzureFirewallApplicationRule")
| where msg_s has SourceIp or msg_s has DestinationIp
| project TimeGenerated, Category, msg_s, Resource
| order by TimeGenerated desc

Si le firewall voit un deny explicite, la correction peut être une règle firewall ciblée. Si le firewall ne voit rien alors que la route effective pointe vers lui, il faut vérifier le next hop, le peering, l’appliance, la table de routes ou la collecte de logs avant d’ouvrir une règle.

Construire une exception minimale

Quand le blocage est prouvé, l’exception doit rester proche du flux qualifié. Une règle temporaire trop large devient souvent permanente parce qu’elle “marche”. Une règle exploitable doit avoir un propriétaire, une raison, une durée si elle est transitoire, et une validation.

Exception ciblee
Nom: allow-app-prod-to-api-internal-443
Source: 10.42.12.0/24 ou groupe applicatif precis
Destination: 10.55.4.20/32 ou FQDN tag controle
Protocole: TCP
Port: 443
Action: Allow
Priorite: documentee et sans masquer un deny critique
Proprietaire: equipe applicative ou plateforme
Ticket: INC ou CHG associe
Expiration: obligatoire si exception temporaire

Validation
Test depuis la source reelle
Log allow observe
Metrique applicative revenue au niveau attendu
Aucun elargissement vers d'autres destinations

Le plus important n’est pas seulement que le flux passe. Il faut aussi prouver que l’ouverture ne couvre pas un autre cas et qu’elle peut être retirée sans surprise.

Décider entre route, règle et rollback

Toutes les corrections ne se valent pas. Ajouter une règle peut être juste si un deny explicite bloque un flux légitime. Rollbacker une UDR peut être plus propre si une table de routes a détourné tout un subnet. Corriger DNS peut être nécessaire si le flux cible la mauvaise adresse.

Constat
DNS retourne une IP inattendue
  Decision: corriger zone, lien VNet ou forwarder
  Validation: resolution correcte depuis la source

Route effective vers un mauvais next hop
  Decision: corriger ou rollback UDR / peering / propagation
  Validation: next hop attendu et test applicatif OK

NSG deny explicite sur le flux attendu
  Decision: regle NSG minimale ou correction de priorite
  Validation: effective rule allow et logs conformes

Azure Firewall deny explicite
  Decision: regle firewall ciblee avec proprietaire
  Validation: log allow puis succes applicatif

Aucun composant ne voit le flux
  Decision: revenir au test source, agent, host firewall ou chemin DNS
  Validation: capture ou log sur le premier composant attendu

Cette matrice évite de choisir la correction par habitude. Le bon changement est celui qui correspond à la première preuve solide.

Prévoir le rollback de la règle

Une exception réseau doit avoir un retour arrière aussi clair qu’un déploiement applicatif. Avant de changer, capturer l’état précédent. Après correction, vérifier que le symptôme est résolu et que la règle n’a pas été créée plus large que nécessaire.

Avant changement
Exporter ou capturer NSG, route table ou policy firewall
Noter priorite, source, destination, protocole, port
Lier au ticket incident ou changement
Definir le test de retour au nominal

Rollback
Supprimer la regle temporaire ou restaurer l'ancienne priorite
Restaurer UDR ou route table precedente si modifiee
Rejouer le test depuis la source reelle
Confirmer que les logs reviennent au comportement attendu
Documenter la cause racine ou la dette restante

Un rollback réseau n’est pas un aveu d’échec. C’est ce qui permet de tester une correction sans transformer l’incident en changement permanent mal documenté.

Conclusion

Avant d’ajouter une règle Azure NSG ou Firewall, il faut prouver le chemin du flux : nom résolu, route effective, règles effectives, logs du point de filtrage et test depuis la source réelle. Cette séquence sépare les problèmes DNS, UDR, NSG, firewall et applicatifs sans ouvrir plus large que nécessaire.

La décision finale doit être lisible : corriger DNS si le nom est faux, rollbacker la route si le next hop est mauvais, ajouter une exception minimale si un deny est prouvé, ou revenir au test source si aucun composant ne voit le trafic. Le but n’est pas d’ouvrir vite. Le but est d’ouvrir juste, de valider, puis de pouvoir refermer.