Azure Virtual WAN : valider Routing Intent avant d'imposer l'inspection en production

Une équipe réseau veut imposer l’inspection des flux est-ouest et Internet dans un hub Azure Virtual WAN sécurisé. Activer Routing Intent paraît plus simple que maintenir des associations, propagations et routes statiques par connexion. Quelques minutes après le changement, une application dans un spoke ne joint plus une API on-premises, un autre spoke conserve sa sortie Internet, et les logs Azure Firewall ne montrent pas tous les flux attendus.

Le cas d’usage est un Virtual WAN Standard avec plusieurs hubs, des connexions VNet, un VPN site-to-site, ExpressRoute et Azure Firewall dans chaque hub sécurisé. Le runbook doit décider si les policies de trafic privé et Internet peuvent être activées, si la bascule doit rester limitée à un hub, ou si l’état de routage précédent doit être restauré. Il ne cherche pas seulement à obtenir un provisioning state vert : il doit prouver le chemin aller-retour de chaque famille de flux.

Figer le contrat de trafic avant les policies

Routing Intent manipule deux familles. La policy Private Traffic dirige les flux entre branches, VNets et hubs vers la solution de sécurité choisie. La policy Internet Traffic fait apprendre une route par défaut aux connexions concernées et envoie la sortie Internet vers ce next hop. Une erreur sur la première casse les chemins internes. Une erreur sur la seconde peut déplacer tout l’egress d’un workload.

Commencez par écrire la matrice qui devra rester vraie après la bascule.

change: vwan-routing-intent-weu-prod
hub: vhub-weu-prod
security_next_hop: azfw-vhub-weu-prod

flows:
- name: spoke-to-onprem-api
  source: 10.42.8.0/24
  destination: 172.20.40.15:443
  policy: private
  expected: allow-and-log
- name: onprem-to-spoke-sql
  source: 172.20.12.0/24
  destination: 10.42.20.4:1433
  policy: private
  expected: allow-and-log
- name: spoke-to-spoke-health
  source: 10.42.8.0/24
  destination: 10.43.6.10:443
  policy: private
  expected: allow-and-log
- name: spoke-to-internet
  source: 10.42.8.0/24
  destination: approved-egress-target:443
  policy: internet
  expected: allow-log-and-stable-egress-ip

stop_conditions:
- missing_reverse_path
- firewall_does_not_observe_expected_flow
- default_route_learned_by_unapproved_connection
- private_prefix_missing_from_effective_routes

rollback: redeploy-snapshot-vwan-routing-v17

Ajoutez les flux explicitement refusés. Un test positif sans test négatif prouve seulement que le chemin est ouvert, pas que l’inspection applique la politique voulue.

Inventorier ce que Routing Intent va remplacer

Routing Intent gère les associations et propagations des connexions du hub. Il n’est pas compatible avec un hub qui dépend encore de tables de routes custom ou de routes statiques dont le next hop est une connexion VNet. Avant toute activation, exportez donc l’état complet : hubs, connexions, tables, labels, routes statiques, propagations, passerelles, peerings, prefixes BGP et paramètre de propagation de la route par défaut.

Ne transformez pas cette étape en simple capture d’écran. L’artefact de rollback doit être redéployable et versionné. La suppression ultérieure de Routing Intent ne reconstitue pas automatiquement l’ancienne defaultRouteTable.

Utilisez Azure Resource Graph pour vérifier que le changement ne vise pas le mauvais hub et pour conserver l’identité exacte des ressources.

resources
| where type =~ "microsoft.network/virtualhubs/routingintent"
 or type =~ "microsoft.network/virtualhubs/hubvirtualnetworkconnections"
 or type =~ "microsoft.network/virtualhubs/hubroutetables"
| extend hubId = tostring(split(id, "/routingIntent/")[0])
| project subscriptionId, resourceGroup, name, type, location,
        hubId, provisioningState=tostring(properties.provisioningState), properties
| order by resourceGroup asc, type asc, name asc

Le snapshot doit aussi noter le mode Internet actuel. Un egress direct via Azure Firewall n’a pas le même contrat qu’un forced tunnel vers on-premises ou une NVA. Conservez les IP publiques de sortie observées et les dépendances qui les allowlistent.

Vérifier les prérequis sans confondre contrôle et data plane

Le hub doit être éligible, et la solution de sécurité doit être prête. Pour Azure Firewall, vérifiez au minimum le provisioning state, la Firewall Policy attachée, la capacité, les diagnostics, les règles nécessaires aux canaris et le comportement SNAT attendu. Pour une NVA ou une solution SaaS intégrée, ajoutez l’état des instances, les interfaces interne et externe, les routes propres à l’appliance et les limites documentées par l’éditeur.

Séparez trois preuves :

• le contrôle Azure accepte la configuration ;
• les routes effectives désignent le next hop attendu ;
• le paquet traverse réellement la solution de sécurité et revient par un chemin cohérent.

Un déploiement Succeeded ne prouve que la première. Une route visible ne prouve pas que la Firewall Policy autorise le flux, que SNAT est correct ou que la cible sait répondre.

Lire les routes effectives depuis les deux extrémités

Après application sur un environnement de préproduction ou un premier hub borné, inspectez les routes effectives du next hop de la policy privée. Si seules les policies Internet sont actives, lisez aussi la defaultRouteTable. Vérifiez chaque prefixe du contrat, son origine, son next hop et son état.

Depuis une VM canari de chaque famille, contrôlez également les routes effectives de la NIC et utilisez Network Watcher Next Hop ou Connection Troubleshoot vers la destination exacte. Répétez depuis le sens inverse. Pour un chemin VNet vers on-premises, une route correcte côté spoke ne garantit pas que le retour ExpressRoute ou VPN revient par le même hub et le même firewall.

Dans une topologie multi-hub, activez et validez la policy privée de manière cohérente sur tous les hubs qui doivent inspecter le trafic inter-hub. Une activation partielle peut créer un chemin aller inspecté et un retour qui préfère un autre hub. Figez aussi la préférence de routage du hub et les annonces concurrentes VPN, ExpressRoute ou NVA avant de conclure à un problème de firewall.

Traiter les prefixes privés non RFC 1918 explicitement

Routing Intent reconnaît naturellement les espaces privés attendus, mais certaines entreprises transportent des prefixes internes non RFC 1918. Ces plages doivent être déclarées comme prefixes privés additionnels sur chaque hub concerné. Une déclaration sur un hub ne se propage pas automatiquement aux autres.

Pour chaque plage additionnelle, vérifiez deux effets : elle est bien dirigée vers la policy privée, et la solution de sécurité ne lui applique pas un SNAT indésirable. Un flux peut fonctionner tout en devenant inexploitable si la destination ne voit plus l’adresse source attendue.

Conservez une liste de contrôle simple : prefixe, propriétaire, hub d’origine, hubs qui doivent l’apprendre, policy attendue, comportement SNAT et sonde de validation. Toute plage sans propriétaire ou sans canari bloque la promotion.

Distinguer direct access et forced tunnel

Pour la sortie Internet, décidez du mode avant d’activer la policy.

En direct access, la policy Internet envoie les flux au composant de sécurité du hub, qui les inspecte puis les sort vers Internet. Vérifiez que les connexions qui doivent apprendre 0.0.0.0/0 ont bien la propagation de route par défaut activée, que les règles autorisent les destinations nécessaires et que les IP d’egress correspondent au contrat.

En forced tunnel, la policy privée porte aussi 0.0.0.0/0 dans les prefixes additionnels et le next hop de sécurité renvoie le trafic vers une route par défaut apprise localement depuis ExpressRoute, VPN, une NVA ou une route statique supportée. La route par défaut ne se propage pas entre hubs : chaque hub doit avoir sa propre source valide. Sans elle, le trafic Internet est bloqué après inspection.

Ne mélangez pas les deux modèles dans une même bascule. Testez explicitement DNS, récupération de secrets, accès aux registries, activation de licences, endpoints de monitoring et dépôts de paquets. Ces dépendances discrètes sont souvent les premières à révéler une route par défaut ou un SNAT mal qualifié.

Corréler probes, routes et logs Firewall

Lancez les canaris avec un identifiant, une fenêtre UTC courte et une source stable. La preuve doit relier le test, la route effective, la règle firewall et le résultat applicatif.

let StartUtc = datetime(<start-utc>);
let EndUtc = datetime(<end-utc>);
let CanarySources = dynamic(["10.42.8.4", "10.43.6.4"]);
union isfuzzy=true AZFWNetworkRule, AZFWApplicationRule
| where TimeGenerated between (StartUtc .. EndUtc)
| where SourceIp in (CanarySources)
| project TimeGenerated, SourceIp, DestinationIp, DestinationPort,
        Fqdn, Protocol, Action, RuleCollectionGroup, RuleCollection, Rule
| order by TimeGenerated asc

Adaptez les noms de tables et colonnes au mode de diagnostics du workspace. Une absence de log n’est pas immédiatement un deny : elle peut indiquer que le flux n’atteint pas le firewall, que la collecte est en retard ou que la catégorie attendue n’est pas activée. Comparez avec les métriques Firewall, Network Watcher et le log de la cible.

Pour chaque ligne de la matrice, exigez quatre résultats : next hop attendu, log d’inspection attendu, réponse applicative attendue et chemin retour prouvé. Mesurez aussi la latence avant et après. Une inspection fonctionnelle mais incompatible avec le budget de latence reste une bascule non validée.

Déployer hub par hub avec une fenêtre bornée

Routing Intent s’applique au hub, pas à un unique spoke canari. La réduction du risque passe donc par un hub de préproduction représentatif, puis par le hub de production au plus faible blast radius. Préparez les probes avant la fenêtre et exécutez-les immédiatement après la convergence des routes.

Pendant la bascule, bloquez les changements concurrents sur BGP, les connexions de hub, les tables de routes et la Firewall Policy. Sans ce gel, un flux cassé peut être attribué à la mauvaise modification.

La fenêtre d’observation doit couvrir les connexions persistantes et les nouvelles connexions. Un socket déjà établi peut survivre alors qu’une nouvelle résolution DNS ou une nouvelle route échoue. Forcez donc des sessions neuves et testez un échantillon qui inclut trafic privé, Internet, deny attendu et retour inter-hub.

Décider promotion, maintien ou rollback

Promouvez quand chaque prefixe du contrat apparaît avec le bon next hop, que les canaris aller-retour passent, que les denies restent effectifs, que les logs Firewall expliquent les décisions, que l’egress conserve son identité prévue et que la latence reste acceptable. Passez alors au hub suivant avec le même jeu de preuves.

Maintenez le changement sur le seul hub canari si les routes sont convergées mais que le retour, le SNAT, un prefixe non RFC 1918 ou l’observabilité reste ambigu. N’élargissez pas pour obtenir davantage de signal : réduisez le test à une destination et une annonce.

Rollbackez si un prefixe privé disparaît, si une connexion non prévue apprend la route par défaut, si le chemin devient asymétrique, si le firewall n’observe pas un flux qu’il doit inspecter ou si une dépendance critique perd son egress. Le rollback consiste à redéployer le snapshot versionné des associations, propagations et routes, puis à rejouer les canaris. Supprimer Routing Intent sans restaurer cet état n’est pas un plan de retour.

Conclusion

Routing Intent simplifie l’exploitation seulement lorsque l’intention déclarative reste vérifiable dans le data plane. La bonne unité de validation n’est ni la policy ni le hub pris isolément, mais un flux nommé avec sa route aller, son inspection, son retour et sa preuve applicative.

La décision de production devient alors explicite : promouvoir hub par hub avec des routes effectives et des canaris complets, maintenir tant qu’un prefixe ou un comportement SNAT reste ambigu, et restaurer l’état versionné au premier chemin inexpliqué. La centralisation du routage gagne ainsi une propriété essentielle : elle reste réversible.