Azure UDR : diagnostiquer un trou noir vers une NVA avant de modifier les routes

Une application dans un spoke Azure ne joint plus une API interne après une modification de table de routes. Le DNS renvoie la bonne adresse, le NSG n’affiche pas de refus évident et la route 10.40.0.0/16 -> Virtual appliance semble présente. L’équipe hésite entre supprimer l’UDR, ouvrir le firewall ou redémarrer l’appliance. Ces trois actions modifient le système avant d’avoir localisé la perte.

Le cas fil rouge est un flux TCP 443 entre une VM applicative 10.20.1.4 et un service 10.40.2.10. Le spoke envoie le trafic vers une NVA dans le hub, à l’adresse 10.10.0.4. Le but du runbook est de décider à partir de preuves : corriger l’association ou le préfixe UDR, remettre l’appliance en état, réparer le chemin retour, revenir à la route précédente ou maintenir le changement sans contourner l’inspection.

Figer le flux exact et le dernier changement

Une « panne réseau » est trop large pour être testée. Notez le tuple source, destination, protocole et port, puis le chemin attendu dans les deux sens. Conservez aussi l’heure du premier échec et le changement qui peut être retiré sans en déduire qu’il est déjà coupable.

incident: inc-<id>
window_utc: <start>/<end>
source:
resource: vm-app-prod
nic: nic-vm-app-prod
ip: 10.20.1.4
subnet: snet-app-prod
destination:
ip: 10.40.2.10
port: 443
protocol: tcp
expected_path:
forward: spoke-app -> udr -> nva-hub -> service
return: service -> hub -> nva-hub -> spoke-app
change_candidate:
route_table: rt-spoke-app-prod
route: to-services-via-nva
deployment: <commit-or-change-id>
preserve:
- route table and subnet association before change
- effective routes on source and destination NICs
- Network Watcher next hop result
- NVA health, forwarding and session logs
- one failed probe with timestamp and correlation data

Gelez les changements concurrents sur les tables de routes, le peering et la NVA pendant la collecte. Une route ajoutée pour « tester » peut gagner par préfixe plus spécifique et faire disparaître le symptôme sans expliquer la cause.

Capturer la configuration déclarée avant de la corriger

La table associée au subnet n’est pas encore la route réellement utilisée par une interface. Capturez néanmoins l’état déclaré, l’association et le next hop configuré avant toute suppression.

set -euo pipefail

RG="<resource-group>"
VNET="<spoke-vnet>"
SUBNET="<source-subnet>"
ROUTE_TABLE="<route-table>"
NIC="<source-nic>"

az network route-table show --resource-group "$RG" --name "$ROUTE_TABLE" --output json > route-table-before.json

az network vnet subnet show --resource-group "$RG" --vnet-name "$VNET" --name "$SUBNET" --query '{id:id,addressPrefix:addressPrefix,addressPrefixes:addressPrefixes,routeTable:routeTable.id,networkSecurityGroup:networkSecurityGroup.id}' --output json > subnet-before.json

az network nic show --resource-group "$RG" --name "$NIC" --query '{id:id,ipConfigurations:ipConfigurations[].privateIPAddress,ipForwarding:enableIpForwarding}' --output json > source-nic-before.json

az network nic show-effective-route-table --resource-group "$RG" --name "$NIC" --output json > source-effective-routes-before.json

Vérifiez les préfixes ligne par ligne. Une faute de CIDR, une route plus spécifique, un next hop resté sur l’ancienne IP ou une table associée au mauvais subnet suffit à créer un trou noir. Ne vous arrêtez pas au nom de la route : il n’influence pas la sélection.

Prouver la route réellement sélectionnée

Azure combine routes système, routes utilisateur et routes propagées. Le préfixe le plus spécifique gagne d’abord ; à préfixe identique, une route utilisateur est prioritaire sur une route BGP, elle-même prioritaire sur une route système. Il faut donc lire l’état Active ou Invalid, la source, le préfixe et le next hop dans les routes effectives de la NIC source.

Utilisez ensuite Network Watcher next hop pour la destination exacte. Le résultat doit annoncer VirtualAppliance, l’IP attendue et la table de routes responsable. Un type None prouve une absence de chemin. VirtualNetworkPeering, VirtualNetworkGateway ou Internet alors qu’une inspection est attendue prouve que le trafic prend une autre route.

set -euo pipefail

VM_RG="<source-vm-resource-group>"
VM="<source-vm>"
NIC="<source-nic>"
SOURCE_IP="10.20.1.4"
DEST_IP="10.40.2.10"

az network watcher show-next-hop --resource-group "$VM_RG" --vm "$VM" --nic "$NIC" --source-ip "$SOURCE_IP" --dest-ip "$DEST_IP" --output json > next-hop-source-to-destination.json

Exécutez le test depuis la ressource et la NIC qui portent réellement le flux. Une VM d’administration placée dans un autre subnet peut avoir une table effective différente et produire un résultat rassurant mais inutile.

Vérifier que la NVA peut réellement transférer le paquet

Un next hop correct prouve que la plateforme remet le trafic à l’appliance ; il ne prouve pas que celle-ci le transfère. Contrôlez séparément quatre couches : état de la VM ou du scale set, enableIpForwarding sur chaque NIC de transit, forwarding dans le système invité, puis policy et table de routage de l’appliance.

Plan de controle NVA
Plateforme Azure
  instance demarree et NIC attendue attachee
  adresse privee du next hop toujours presente
  enableIpForwarding=true sur les NIC de transit
  health probe saine si un load balancer porte le next hop

Systeme invite
  IP forwarding active selon le systeme et le produit
  interface, route et voisinage attendus disponibles
  service firewall ou routeur demarre
  CPU, memoire, sessions et files non satures

Policy
  regle autorisant source, destination, protocole et port
  NAT applique uniquement si l'architecture le prevoit
  journal montrant reception puis transmission du meme flux

Preuve minimale
  timestamp UTC du probe
  compteurs ou logs sur interface entree et sortie
  raison explicite en cas de drop
  identifiant de l'instance qui a traite le paquet

Si enableIpForwarding est désactivé, vérifiez aussi le réglage équivalent dans l’OS ou le produit NVA avant de conclure. Si le next hop est l’adresse frontend d’un load balancer interne, qualifiez ses probes, ses règles HA Ports ou spécifiques et son backend actif ; ne remplacez pas arbitrairement cette adresse par celle d’une instance.

Traiter le retour comme un second problème de routage

Un SYN visible sur l’entrée de la NVA sans réponse côté application ne prouve pas un blocage aller. La destination peut répondre par un peering direct, une gateway ou une autre appliance. Un firewall stateful abandonne alors la session asymétrique, ou le retour atteint la source avec une identité différente.

Construisez une matrice avec deux tests de route distincts. Pour l’aller, utilisez la NIC source et l’IP destination. Pour le retour, utilisez une NIC représentative du réseau destination et l’IP source. Comparez les routes effectives, les associations de table et les logs de l’appliance dans la même fenêtre.

Sens aller 10.20.1.4 -> 10.40.2.10:443
route effective selectionnee: <prefix/source/state>
next hop observe: <type/ip/route-table>
NVA reception: <yes/no/timestamp>
NVA transmission: <yes/no/reason>

Sens retour 10.40.2.10 -> 10.20.1.4
route effective selectionnee: <prefix/source/state>
next hop observe: <type/ip/route-table>
NVA reception: <yes/no/timestamp>
NVA transmission: <yes/no/reason>

Application
DNS cible: <ip>
connexion TCP: <success/timeout/reset>
reponse TLS ou HTTP: <result>

Conclusion
<wrong-route|dead-next-hop|nva-drop|asymmetric-return|application>

Cette lecture évite de créer une UDR de retour par réflexe. Le bon correctif dépend du domaine d’adressage, des routes propagées et du contrat d’inspection. Une route réciproque peut être nécessaire, mais elle doit être conçue, pas improvisée pendant l’incident.

Séparer routage, filtrage et application

Un timeout ne dit pas quelle couche a perdu le flux. Classez l’incident avant d’agir.

Mauvaise route ou association
Next hop inattendu, None, prefixe absent ou route Invalid
Action: corriger l'association, le CIDR ou le next hop exact

Next hop correct mais NVA indisponible
VirtualAppliance pointe vers la bonne IP, aucun paquet n'est transfere
Action: restaurer l'instance, le backend ou le service NVA

Forwarding incomplet
Paquet recu, pas retransmis, IP forwarding ou route OS absent
Action: corriger plateforme et OS selon le contrat NVA

Drop de policy
NVA saine, refus explicite pour le tuple teste
Action: corriger une regle ciblee avec preuve et expiration si temporaire

Retour asymetrique
Aller visible, retour absent ou vu sur un autre chemin
Action: restaurer la symetrie ou le design NAT attendu

Probleme applicatif
TCP et TLS traversent la NVA, reponse applicative en erreur
Action: sortir la table de routes du perimetre de correction

Une ouverture NSG ou firewall n’est justifiée que par une preuve de filtrage. Une route effective incorrecte ne se corrige pas avec une règle de sécurité ; une NVA saine ne se répare pas en supprimant toute inspection.

Choisir une correction bornée

Préparez un changement unique et réversible. Pour une route erronée, corrigez le préfixe ou le next hop précis, puis attendez que la route effective reflète la valeur attendue. Pour une association incorrecte, rattachez la bonne table au seul subnet concerné. Pour une NVA défaillante, restaurez son backend ou basculez selon le mécanisme HA prévu par le produit.

Évitez trois raccourcis : supprimer une route 0.0.0.0/0 sans inventorier les flux concernés, créer une route plus spécifique temporaire sans expiration, ou pointer directement vers une instance derrière un load balancer. Ils peuvent rétablir un test tout en créant une dérive de sécurité ou de disponibilité.

decision:
diagnosis: <wrong-route|dead-next-hop|forwarding|policy|asymmetric-return|application>
evidence_window_utc: <start>/<end>
owner: <operator>

change:
resource: <route-table|subnet|nva|policy>
exact_property: <prefix|next-hop|association|backend|rule>
previous_value: <captured-value>
proposed_value: <new-value>
blast_radius: <subnet-and-prefixes>
expires_at_utc: <timestamp-or-not-applicable>

validation:
- effective route is Active with expected source and prefix
- next hop matches the intended appliance path
- NVA sees forward and return packets
- TCP and application probe succeed from the real source subnet
- unrelated canary destinations keep their expected path

rollback:
trigger: <route-mismatch|probe-failure|asymmetry|unexpected-bypass>
action: restore captured property or previous IaC revision
post_check: replay route, next-hop and application probes

Valider puis rollbacker sans perdre les preuves

Après le changement, recapturez la table, l’association, les routes effectives et le résultat next hop. Rejouez le même probe depuis le même workload, avec la même destination et le même port. Ajoutez un canary vers une destination qui ne devait pas être affectée afin de détecter un bypass trop large.

Le succès exige cinq preuves cohérentes : route active attendue, next hop attendu, passage NVA dans les deux sens, probe applicative réussie et absence de régression sur le canary. Si l’une manque, revenez à la valeur capturée ou à la révision IaC précédente. Ne laissez pas une route de diagnostic hors code : elle deviendrait la prochaine route « inexpliquée ».

Le rollback doit viser la propriété modifiée. Restaurez un préfixe, un next hop ou une association précise ; ne détachez pas toute la table pour annuler une seule route. Après retour, contrôlez la disparition de la route fautive dans les routes effectives, puis confirmez que le chemin antérieur est de nouveau observé.

Conclusion

Un trou noir UDR vers une NVA se diagnostique comme une chaîne : table associée, route effective sélectionnée, next hop atteint, paquet transféré, retour symétrique et réponse applicative. Une ligne correcte dans la table déclarée ne valide qu’un maillon.

La décision de production devient alors nette : corriger la route si Azure sélectionne le mauvais chemin, réparer la NVA si le paquet s’y arrête, restaurer la symétrie si le retour diverge, ou sortir le réseau du périmètre si le flux traverse correctement. Le bon rollback restaure la propriété exacte et rejoue les mêmes preuves ; il ne contourne pas l’inspection pour faire disparaître le symptôme.