Inspection NVA dans Azure : pourquoi la réponse passe par un autre pare-feu

Un flux de la succursale vers Azure peut être routé correctement dans les deux sens et échouer quand même, parce que les deux sens empruntent des équipements différents. La requête quitte la succursale par le VPN, atterrit sur NVA A et atteint la charge de travail. La réponse quitte la charge de travail, correspond à une route pointant vers NVA B et meurt là-bas. Chaque route de cette image est valide, et la session TCP reste cassée.

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

Cet écart est tout le sujet ici : la convergence de routage et la propriété de l’état de session sont deux problèmes différents qui semblent identiques sur un schéma.

Ce que Route Server programme réellement

Azure Route Server établit un peering avec les interlocuteurs BGP pris en charge, apprend leurs routes et les programme dans les routes effectives du réseau virtuel. C’est un travail de plan de contrôle. Il ne lit pas la table de sessions d’un pare-feu fournisseur et n’a aucune idée de l’équipement qui a admis une connexion donnée. Deux sauts suivants à coût égal sont, pour cette toile, simplement deux façons d’atteindre le même préfixe, et il utilisera l’une ou l’autre.

Apprendre une route prouve donc la joignabilité. Cela ne prouve rien sur le fait que l’équipement de l’autre extrémité a déjà vu ce flux.

Lisez les deux sens avant de concevoir

Commencez par écrire le pilotage que vous avez réellement dans chaque sens, pas celui que vous aviez prévu. Les routes BGP plus spécifiques, les routes définies par l’utilisateur et le comportement de la passerelle sont tous en concurrence, et le gagnant est décidé par destination, pas par session. Une route par défaut sur l’NVA ne signifie pas que chaque préfixe privé la traverse.

Une vérification utile consiste à demander, pour une IP de charge de travail précise, vers quel saut suivant chaque sens se résout. Si la réponse est deux équipements différents, vous avez un problème d’asymétrie, qu’il se soit déjà manifesté ou non.

Où vit l’état

Un pare-feu à états admet une connexion et conserve une entrée de table indexée sur le quintuplet. La réponse doit atteindre l’équipement qui détient cette entrée, ou cet équipement doit obtenir l’état autrement. Rien dans le plan de données Azure ne transfère l’entrée entre équipements. Soit le trafic est renvoyé vers le propriétaire, soit les équipements partagent l’état via un mécanisme du fournisseur, soit la conception ne fonctionne pas.

C’est pourquoi deux NVA en bonne santé ne constituent pas un contrôle de santé pour l’inspection. La santé concerne la joignabilité ; l’inspection concerne l’instance qui détient la session.

Modèles HA pris en charge et ce que chacun promet

Microsoft's guidance on l’intention de routage de Virtual WAN décrivent un comportement limité pour la connectivité à double rôle et les NVA pare-feu, où le routage direct peut contourner l’application symétrique normale du hub. Lisez ces notes comme des contraintes sur la topologie choisie, non comme une interdiction des conceptions actif-actif. Une paire fournisseur qui synchronise l’état, ou qui pilote par flux, peut être prise en charge. Une paire à coût égal qui ne fait ni l’un ni l’autre ne l’est pas.

Définissez ensuite ce qui arrive aux sessions existantes lorsqu’un nœud tombe en panne. La convergence des routes rétablit la joignabilité des nouveaux flux en quelques secondes, tandis que l’ancien état du pare-feu a simplement disparu. Une reconnexion du client peut être le résultat documenté, et c’est une décision à prendre avant l’incident, pas pendant.

Ce qu’il faut tester avant de lui faire confiance

Test with inspection enabled and la politique d’accès de la charge de travail en place, car l’une ou l’autre peut masquer l’asymétrie. Envoyez un nouveau flux autorisé dans les deux sens et confirmez que le même équipement a vu les deux moitiés. Exécutez ensuite un trafic soutenu et déclenchez le basculement approuvé, en observant si les sessions établies survivent ou se reconnectent.

Corrélez chaque flux avec l’équipement qui l’a traité. Une capture de paquets sur une seule NVA ne vous dit presque rien si la réponse n’y est jamais revenue.

Enfin, écrivez le plan en trois lignes distinctes : propriété des routes, pilotage du trafic et propriété de l’état de session. Les conceptions se cassent lorsque les deux premières sont résolues et la troisième supposée.