ExpressRoute plus VPN : quels domaines de défaillance couvrez-vous ?

Un tunnel IPsec exécuté sur le peering privé d'ExpressRoute ajoute du chiffrement à un transport qui existe déjà. Un second tunnel améliore la disponibilité du point de terminaison et ne fait absolument rien pour le chemin de l'opérateur situé sous les deux. Cette distinction se perd facilement lorsque les tableaux de bord affichent deux tunnels verts et que la revue de conception pose une autre question : quelles défaillances cette connexion doit-elle survivre ? Répondez d'abord à cela, puis comptez les tunnels, car le nombre d'indicateurs verts est une propriété de la couche de chiffrement et le nombre de domaines de défaillance est une propriété du chemin entier.

Commencez par les défaillances, pas par les tunnels verts

Écrivez quatre lignes avant de dessiner quoi que ce soit : la défaillance d'un point de terminaison VPN ou d'une instance de pair, la défaillance d'un routeur local ou d'une liaison de premier mile, la défaillance du chemin ExpressRoute partagé et l'indisponibilité d'IPsec alors que le peering privé transporte encore du trafic. Chaque ligne nomme ce que la conception doit préserver, et chacune reçoit une réponse d'un mécanisme différent.

Microsoft documente le VPN site à site à IP privées sur le peering privé d'ExpressRoute, ainsi que la coexistence prise en charge avec les connexions site à site via Internet. Cette coexistence est une conception de sous-couche différente, et elle n'apparaît pas simplement parce que vous avez ajouté un autre point de terminaison de tunnel privé.

Domaine de défaillance 1 : le point de terminaison VPN

Deux tunnels sur une passerelle sont généralement des paires actif-actif qui se terminent sur la même ressource côté Azure. Ils protègent contre un problème d'un seul tunnel ou d'une seule instance, et ils ne protègent pas contre l'indisponibilité, la reconfiguration ou la saturation de cette ressource. La redondance de point de terminaison signifie un second point de terminaison pris en charge, avec son propre chemin et sa propre configuration, plus une route capable de l'atteindre.

Vérifiez ce que vous avez réellement déployé plutôt que ce que dit le schéma, car le portail regroupe ces ressources d'une manière qui masque leur relation :

az network vpn-connection show -g rg-connectivity -n vpn-to-hub   --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub   --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'

Si les deux tunnels pointent vers une passerelle avec une seule IP publique, vous disposez d'une redondance de point de terminaison d'un type particulier et limité. C'est peut-être exactement ce que demande l'exigence, et il faudrait le dire ainsi au lieu de le décrire comme une connexion redondante.

Domaine de défaillance 2 : le chemin local et l'opérateur

Sous le chiffrement se trouve une réalité physique et commerciale : un équipement de bord client, une interconnexion, un réseau de fournisseur et un emplacement de peering. les recommandations de disponibilité d'ExpressRoute sont explicites : la redondance de bout en bout inclut les segments du client et du fournisseur de services, pas seulement le côté Microsoft. Deux chemins logiques qui partagent un routeur, une alimentation électrique ou une liaison de premier mile partagent encore cette dépendance.

C'est là qu'une conception échoue généralement à une revue honnête. Deux circuits du même fournisseur, aboutissant dans le même bâtiment, sur des équipements issus de la même commande, ne sont pas deux domaines de défaillance. Ce sont un domaine de défaillance avec deux factures.

Posez la question à l'opérateur par écrit : lesquels de ces chemins divergent, où, et quel est le comportement documenté lorsque le segment partagé tombe ? Une assurance verbale lors d'un appel de conception ne survit pas à la panne pour laquelle vous concevez.

Domaine de défaillance 3 : la route qui survit sans IPsec

Le peering privé et IPsec peuvent offrir des routes concurrentes vers le même préfixe d'application. Si la route protégée disparaît, une route directe ExpressRoute survivante peut encore être utilisable, sans la couche de chiffrement que fournissait le tunnel. Savoir si c'est acceptable est une décision de politique, et c'est la décision la plus souvent laissée implicite.

Les exigences de chiffrement et de disponibilité peuvent ici entrer réellement en conflit. « Toute route survivante compte comme un succès » est une affirmation de disponibilité qui répond discrètement « non » à la question du chiffrement. Écrivez laquelle gagne, pour quels préfixes, et qui l'a approuvée.

az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o table

Comparez les routes apprises aux préfixes que vous attendiez. Une route de repli qui transporte une petite charge administrative peut être parfaitement adaptée à cette charge et très loin de la capacité dont la demande de production a besoin ; notez donc l'hypothèse de capacité à côté de la route.

Consignez trois lignes distinctes, pas un seul verdict

Gardez la redondance de point de terminaison, la redondance de transport et la reprise après sinistre comme des entrées distinctes dans le dossier de conception, chacune avec son propre mécanisme, sa propre vérification et son propre responsable. Quand une revue d'incident demande pourquoi la connexion a survécu à un redémarrage de passerelle mais pas à une coupure de fibre, trois lignes répondent en une phrase ; une seule case « redondant » ne le peut pas.

Testez ensuite les lignes que vous pouvez tester à peu de frais. Faites tomber un tunnel et confirmez que le trafic se déplace et se chiffre à nouveau. Retirez une route et confirmez que le chemin survivant est celui que vous vouliez, puis confirmez s'il est toujours chiffré. Documentez les défaillances que vous n'avez pas pu simuler, car une ligne non testée est une hypothèse et doit être étiquetée comme telle.

Le résultat utile est un tableau court plus une phrase par ligne. Si une ligne n'a aucun mécanisme, c'est là le constat, et il est bien moins coûteux de le découvrir en revue de conception que pendant une panne d'opérateur que les deux tunnels n'auraient jamais surmontée.