Azure Network Watcher : diagnostiquer un chemin intermittent avant de modifier NSG ou UDR

Une application joint une dépendance la plupart du temps, mais quelques requêtes expirent chaque heure. Le NSG paraît ouvert, la route table n’a pas changé et un test manuel réussit. Ajouter une règle ou retirer l’UDR peut masquer le symptôme, mais détruit aussi la preuve nécessaire pour distinguer une panne réseau transitoire d’une rotation DNS, d’une saturation backend ou d’un timeout applicatif.

Le cas fil rouge est un service de commandes sur VM Azure qui appelle orders-db.internal.example en TCP 5432 via un firewall de hub. Les échecs ne touchent que certaines instances et durent moins de deux minutes. Ce runbook utilise Azure Network Watcher Connection Monitor pour conserver la série temporelle, puis Connection Troubleshoot et les preuves du data plane pour isoler la couche défaillante. Il se termine par une décision explicite : corriger un composant borné, suspendre le changement ou restaurer le chemin précédent.

Figer le contrat de flux avant les tests

Ne commencez pas par un ping générique. Décrivez exactement le flux utilisé en production : cohorte source, FQDN de destination, adresses résolues, protocole, port, chemin attendu, budget de timeout et dernière fenêtre saine. Incluez toutes les instances susceptibles de servir du trafic ; une VM saine ne disculpe pas un service distribué.

incident: INC-NET-427
window_utc: 2026-09-27T05:40:00Z/2026-09-27T06:20:00Z
sources:
resource_group: rg-orders-prod
instances: [vm-orders-01, vm-orders-02, vm-orders-03]
destination:
fqdn: orders-db.internal.example
protocol: TCP
port: 5432
expected_path:
next_hop: azure-firewall
egress_identity: firewall-policy-prod
service_budget:
connection_timeout_ms: 2000
failed_checks_percent: less-than-1
changes_to_freeze:
- DNS records and TTL
- subnet NSG and security admin rules
- UDR and route propagation
- firewall policy
- backend listener and deployment

Capturez la ressource Connection Monitor et la configuration réseau concernée avant toute modification. Conservez la définition du monitor, l’appartenance des endpoints, les test groups, le protocole, la fréquence et les success thresholds. Un monitor qui teste le mauvais sous-ensemble de sources, ou une IP alors que l’application utilise un FQDN, peut être vert tout en représentant mal l’incident.

SUB="<subscription-id>"
RG="NetworkWatcherRG"
LOCATION="westeurope"
WATCHER="NetworkWatcher_westeurope"
MONITOR="orders-to-db-prod"
CM_ID="/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.Network/networkWatchers/$WATCHER/connectionMonitors/$MONITOR"

az resource show --ids "$CM_ID" --output json > connection-monitor-before.json

az network nic show-effective-route-table   --resource-group rg-orders-prod   --name nic-vm-orders-02   --output json > effective-routes-before.json

az network nic list-effective-nsg   --resource-group rg-orders-prod   --name nic-vm-orders-02   --output json > effective-nsg-before.json

Ces fichiers sont des entrées de rollback et des preuves d’incident. Ils ne démontrent pas que le chemin est sain.

Faire représenter la production par le test continu

Connection Monitor organise endpoints, configurations et groupes de tests. Au niveau d’un test individuel, il mesure le pourcentage de contrôles en échec et le round-trip time. Construisez le test autour d’une question opérationnelle, pas autour d’un inventaire de ressources.

Dans ce cas, utilisez chaque VM qui sert le trafic comme source, le FQDN de production comme destination et TCP 5432 comme test. Gardez la résolution DNS dans le chemin en surveillant le FQDN plutôt qu’en épinglant l’adresse courante. Si l’application dépend aussi de TLS ou d’un contrat de readiness HTTP, ajoutez une configuration distincte ; un handshake TCP ne prouve ni réponse HTTP, ni authentification, ni requête base de données utile.

Vérifiez que les sources remontent réellement des mesures. Une absence de données n’est pas une connectivité réussie. Séparez quatre états :

• les contrôles réussissent dans le budget de latence ;
• les contrôles échouent ou la latence augmente ;
• une source cesse de remonter des mesures ;
• le test résout ou cible un endpoint différent de l’application.

Alertez sur le pourcentage d’échec et le round-trip time avec une fenêtre assez longue pour qu’une seule probe ne crée pas un incident, mais assez courte pour capturer le burst observé. Surveillez séparément l’absence de données si votre design le permet. Une moyenne globale peut diluer une panne limitée à une VM : descendez jusqu’à la combinaison source-destination-test.

Corréler la perte à la cohorte touchée

Commencez par la timeline Connection Monitor. Comparez pour chaque source le taux d’échec et le RTT sur la fenêtre UTC figée. La forme du signal réduit les hypothèses :

• une source échoue alors que ses pairs restent sains : inspectez NIC, règles effectives, routes, firewall invité et pression sur l’hôte ;
• toutes les sources échouent vers une même adresse résolue : inspectez rotation DNS, instance de destination et chemin retour ;
• toutes les destinations passant par le même next hop se dégradent : inspectez firewall de hub, NVA, gateway ou propagation de routes ;
• le RTT augmente avant la perte : cherchez saturation et mise en file avant d’ouvrir des règles ;
• le monitor reste sain tandis que l’application échoue : remontez vers TLS, authentification, connection pool ou timeout applicatif.

Ne moyennez pas l’incident jusqu’à le rendre invisible. Conservez la source, l’adresse de destination et l’intervalle défaillants les plus précis. Ce tuple alimente le diagnostic ponctuel et les requêtes de logs.

Lancer Connection Troubleshoot pendant l’échec

Connection Monitor prouve quand et où le symptôme se répète. Connection Troubleshoot exécute le diagnostic borné sur le tuple exact. Lancez-le depuis la source touchée vers le FQDN ou l’adresse et le port pendant que le problème est actif. Conservez le statut de connectivité, les probes envoyées et perdues, la latence, les hops, l’analyse du next hop et les problèmes signalés.

Le résultat peut exposer la résolution DNS, une décision NSG, une user-defined route, le firewall invité, un port sans listener ou la pression sur la ressource. Traitez-le comme un instantané, pas comme un substitut à la série continue. Un succès après le burst prouve seulement l’état du chemin à ce nouvel instant.

Recoupez chaque conclusion avec un outil ciblé :

• Next Hop pour prouver la route effective vers la destination résolue ;
• IP Flow Verify ou NSG diagnostics pour identifier la règle de sécurité décisive ;
• routes et règles effectives sur la NIC concernée ;
• VNet flow logs ou logs firewall sur le même five-tuple et la même fenêtre UTC ;
• listener de destination et logs applicatifs.

Un résultat NSG Allowed ne prouve pas que le firewall a accepté la session, et un next hop correct ne prouve pas le chemin retour. De même, l’absence d’enregistrement dans les flow logs peut indiquer que la collecte ne couvrait pas le flux ; ce n’est pas automatiquement la preuve d’un refus.

Séparer rotation DNS et instabilité du chemin

Un FQDN intermittent résout souvent plusieurs adresses. Relevez plusieurs fois les réponses depuis chaque source touchée pendant la fenêtre, puis comparez-les aux preuves de destination du monitor. Vérifiez chaîne CNAME, TTL, chemin du resolver et appartenance de chaque adresse au jeu de backends approuvé.

TARGET="orders-db.internal.example"
PORT="5432"

for attempt in 1 2 3 4 5; do
date -u +"%Y-%m-%dT%H:%M:%SZ"
getent ahostsv4 "$TARGET" | awk '{print $1}' | sort -u
timeout 3 bash -c "true >/dev/tcp/$TARGET/$PORT"     && echo "tcp=ok"     || echo "tcp=failed"
sleep 10
done

Exécutez ce test depuis une source de production représentative ou un hôte de diagnostic autorisé sur le même chemin. Si une adresse échoue constamment, conservez le contrat FQDN et réparez ou retirez le backend défaillant via son service propriétaire. N’épinglez pas une entrée hosts comme correctif de production. Si les réponses diffèrent selon la source, examinez forwarding, cache et split-horizon DNS avant de modifier NSG ou UDR.

Prouver les chemins aller et retour

Pour un trafic hub-and-spoke routé ou hybride, validez les deux sens. La route source peut sélectionner correctement Azure Firewall alors que la destination retourne par un autre hub, VPN, chemin ExpressRoute ou défaut local. Les équipements stateful ne voient alors qu’une moitié de la conversation.

Corrélez un contrôle en échec avec les allow ou deny du firewall et, lorsqu’ils existent, la création et la fermeture de session. Vérifiez le comportement SNAT et l’identité source observée par la destination. Comparez les routes effectives des deux subnets, y compris routes propagées et préfixes plus spécifiques.

Si les preuves désignent un NSG ou une UDR, nommez la règle ou le préfixe exact. « Problème réseau » n’est pas un diagnostic exploitable. La correction doit rester aussi étroite que la preuve : une priorité, un préfixe, un next hop, une route backend ou une annonce de retour.

Canaryer une correction sans effacer la baseline

Gardez le monitor d’origine actif. Appliquez le candidat à un subnet source, un préfixe de route, une rule collection firewall ou un backend, selon la panne prouvée. Notez l’identifiant et l’heure du changement pour séparer avant et après dans les métriques.

Utilisez trois contrôles :

1. Le flux positif doit se rétablir depuis la source touchée et rester dans son budget de perte et de latence.
2. Une source témoin sur le chemin inchangé doit rester stable.
3. Une destination qui doit être refusée doit le rester.

Observez plusieurs intervalles complets et une transaction applicative, pas seulement une probe verte. Suivez la même série source-destination, les preuves firewall et les logs backend. Si le candidat déplace seulement la panne vers une autre source ou rend le contrôle négatif accessible, arrêtez et rollbackez.

Décider, valider ou rollbacker

Promouvez la correction quand Connection Monitor reste dans le budget pour toutes les sources requises, que Connection Troubleshoot ne signale plus la panne diagnostiquée, que la transaction applicative réussit et que le contrôle de refus tient toujours. Ajoutez au change record les routes effectives, règles et définition finale du monitor.

Suspendez quand le monitor détecte le symptôme mais que la couche reste ambiguë. Continuez la collecte plutôt que d’élargir l’accès réseau. Une panne courte sans preuve corrélée justifie d’améliorer l’observabilité, pas de retirer les contrôles.

Rollbackez si perte ou latence s’aggrave, si le next hop sort du contrat, si un flux non prévu devient joignable ou si la santé applicative ne revient pas. Restaurez la révision IaC sauvegardée ou l’unique règle, route ou configuration du monitor modifiée par le canari. Prouvez ensuite le retour du chemin précédent et de la couverture de monitoring ; un déploiement de configuration ne suffit pas à clore le rollback.

Conclusion

La connectivité intermittente est difficile parce qu’un succès manuel s’obtient facilement après la disparition des preuves. Connection Monitor transforme le chemin en série temporelle par source ; Connection Troubleshoot, les configurations effectives et les logs de trafic expliquent ensuite un intervalle défaillant.

La décision de production suit la preuve : corriger le membre DNS, la route, la règle de sécurité, le chemin firewall ou le backend réellement en panne ; suspendre si la couche reste incertaine ; restaurer l’état précédent si le canari casse le contrat. L’objectif n’est pas de rendre la prochaine probe verte, mais de garder un chemin explicable en continu et réversible.