ExpressRoute plus VPN: welke faaldomeinen dekt u?

Een IPsec-tunnel over de private peering van ExpressRoute voegt versleuteling toe aan een transport dat al bestaat. Een tweede tunnel verbetert de beschikbaarheid van het eindpunt en doet absoluut niets voor het carrierpad onder beide. Dat onderscheid raakt snel zoek wanneer de dashboards twee groene tunnels tonen en de ontwerpreview een andere vraag stelt: welke storingen moet deze verbinding overleven? Beantwoord dat eerst en tel dan tunnels, want het aantal groene indicatoren is een eigenschap van de versleutelingslaag en het aantal faaldomeinen is een eigenschap van het hele pad.

Begin met storingen, niet met groene tunnels

Schrijf vier regels voordat u iets tekent: één VPN-eindpunt of peer-instantie die uitvalt, één lokale router of first-mile-verbinding die uitvalt, het gedeelde ExpressRoute-pad dat uitvalt, en IPsec dat onbeschikbaar wordt terwijl private peering nog verkeer draagt. Elke regel benoemt wat het ontwerp moet behouden, en elk ervan wordt door een ander mechanisme beantwoord.

Microsoft documenteert site-naar-site-VPN met privé-IP's over de private peering van ExpressRoute, en de ondersteunde coëxistentie met internetgebaseerde site-naar-site-verbindingen. Die coëxistentie is een ander ontwerp van de onderlaag, en ze ontstaat niet zomaar omdat u nog een privé-tunneleindpunt hebt toegevoegd.

Faaldomein 1: het VPN-eindpunt

Twee tunnels op één gateway zijn meestal active-active-paren die op dezelfde Azure-zijde-resource eindigen. Ze beschermen tegen een probleem met één tunnel of instantie, en ze beschermen niet tegen het onbeschikbaar worden, herconfigureren of vol raken van die resource. Eindpuntredundantie betekent een tweede ondersteund eindpunt, met zijn eigen pad en zijn eigen configuratie, plus een route die het kan bereiken.

Controleer wat u daadwerkelijk hebt uitgerold en niet wat het diagram zegt, omdat de portal deze resources groepeert op manieren die hun relatie verbergen:

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}'

Als beide tunnels naar één gateway met één openbaar IP wijzen, hebt u eindpuntredundantie van een bepaald en beperkt soort. Dat kan precies zijn wat de eis vraagt, en het zou zo moeten worden gezegd in plaats van te worden beschreven als een redundante verbinding.

Faaldomein 2: het lokale pad en de carrier

Onder de versleuteling ligt een fysieke en commerciële werkelijkheid: een klantrandapparaat, een kruisverbinding, een providernetwerk en een peeringlocatie. de beschikbaarheidsrichtlijnen van ExpressRoute zijn expliciet dat redundantie van begin tot eind de segmenten van de klant en de dienstverlener omvat, niet alleen de Microsoft-kant. Twee logische paden die een router, een stroomvoorziening of een first-mile-verbinding delen, delen nog steeds die afhankelijkheid.

Hier zakt een ontwerp meestal door een eerlijke review. Twee circuits van dezelfde provider, die in hetzelfde gebouw eindigen, op apparatuur uit dezelfde inkooporder, zijn geen twee faaldomeinen. Het zijn één faaldomein met twee facturen.

Stel de carriervraag schriftelijk: welke van deze paden divergeren, waar, en wat is het gedocumenteerde gedrag wanneer het gedeelde segment uitvalt? Een mondelinge toezegging tijdens een ontwerpgesprek overleeft de storing niet waarvoor u ontwerpt.

Faaldomein 3: de route die zonder IPsec overleeft

Private peering en IPsec kunnen concurrerende routes naar hetzelfde applicatieprefix bieden. Als de beschermde route verdwijnt, kan een overlevende directe ExpressRoute-route nog bruikbaar zijn, zonder de versleutelingslaag die de tunnel bood. Of dat aanvaardbaar is, is een beleidsbeslissing, en het is de beslissing die het vaakst impliciet blijft.

Versleutelings- en beschikbaarheidseisen kunnen hier echt botsen. ‘Elke overlevende route telt als succes’ is een beschikbaarheidsuitspraak die de versleutelingsvraag stil met ‘nee’ beantwoordt. Schrijf op welke wint, voor welke prefixen en wie het heeft goedgekeurd.

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

Vergelijk de geleerde routes met de prefixen die u verwachtte. Een terugvalroute die een kleine administratieve werklast draagt, kan voor die werklast volkomen toereikend zijn en ver verwijderd van de capaciteit die de productievraag nodig heeft, dus noteer de capaciteitsaanname naast de route.

Noteer drie afzonderlijke regels, niet één oordeel

Houd eindpuntredundantie, transportredundantie en disaster recovery als afzonderlijke vermeldingen in het ontwerpregister, elk met zijn eigen mechanisme, zijn eigen verificatie en zijn eigen eigenaar. Wanneer een incidentreview vraagt waarom de verbinding een gateway-herstart wel overleefde maar een vezelbreuk niet, antwoorden drie regels in één zin; één vinkje ‘redundant’ kan dat niet.

Test daarna de regels die u goedkoop kunt testen. Laat één tunnel falen en bevestig dat het verkeer verplaatst en opnieuw wordt versleuteld. Trek één route terug en bevestig dat het overlevende pad het bedoelde is, en bevestig daarna of het nog steeds versleuteld is. Documenteer de storingen die u niet kon simuleren, want een ongeteste regel is een aanname en moet als zodanig worden gelabeld.

De bruikbare uitvoer is een korte tabel plus een zin per regel. Als een regel geen mechanisme heeft, is dat de bevinding, en het is veel goedkoper om die in een ontwerpreview te ontdekken dan tijdens een carrierstoring die beide tunnels nooit hadden overleefd.