ExpressRoute pluss VPN: hvilke feildomener dekker du?

En IPsec-tunnel som kjører over ExpressRoutes private peering legger til kryptering på en transport som allerede finnes. En andre tunnel forbedrer endepunktets tilgjengelighet, og den gjør absolutt ingenting for carrier-stien under dem begge. Den forskjellen er lett å miste når dashbordene viser to grønne tunneler og designgjennomgangen stiller et annet spørsmål: hvilke feil må denne forbindelsen overleve? Svar på det først, og tell deretter tunneler, fordi antallet grønne indikatorer er en egenskap ved krypteringslaget og antallet feildomener er en egenskap ved hele stien.

Start med feil, ikke med grønne tunneler

Skriv fire rader før du tegner noe: ett VPN-endepunkt eller ett peer-eksemplar som feiler, én lokal ruter eller first-mile-forbindelse som feiler, den delte ExpressRoute-stien som feiler, og IPsec som blir utilgjengelig mens privat peering fortsatt bærer trafikk. Hver rad navngir hva designet må bevare, og hver av dem besvares av en annen mekanisme.

Microsoft dokumenterer site-til-site-VPN med private IP-adresser over ExpressRoutes private peering, og støttet sameksistens med internettbaserte site-til-site-forbindelser. Den sameksistensen er et annet underliggende design, og den oppstår ikke bare fordi du la til nok et privat tunnelendepunkt.

Feildomene 1: VPN-endepunktet

To tunneler på én gateway er vanligvis active-active-par som terminerer på den samme ressursen på Azure-siden. De beskytter mot et problem med én tunnel eller én instans, og de beskytter ikke mot at ressursen blir utilgjengelig, omkonfigurert eller går tom for kapasitet. Endepunktredundans betyr et andre støttet endepunkt, med sin egen sti og sin egen konfigurasjon, pluss en rute som kan nå det.

Kontroller hva du faktisk har rullet ut, ikke hva diagrammet sier, fordi portalen grupperer disse ressursene på måter som skjuler forholdet mellom dem:

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

Hvis begge tunnelene peker på én gateway med én offentlig IP, har du endepunktredundans av en bestemt og begrenset type. Det kan være akkurat det kravet ber om, og det bør sies slik i stedet for å beskrives som en redundant forbindelse.

Feildomene 2: den lokale stien og carrieren

Under krypteringen ligger en fysisk og kommersiell virkelighet: en kundekantenhet, en krysskobling, et leverandørnett og en peering-plassering. retningslinjene for ExpressRoute-tilgjengelighet er tydelige på at redundans fra ende til ende omfatter kunde- og tjenesteleverandørsegmentene, ikke bare Microsoft-siden. To logiske stier som deler en ruter, en strømforsyning eller en first-mile-forbindelse deler fortsatt den avhengigheten.

Det er her et design vanligvis stryker i en ærlig gjennomgang. To kretser fra samme leverandør, som terminerer i samme bygning, på utstyr fra samme innkjøpsordre, er ikke to feildomener. De er ett feildomene med to fakturaer.

Still carrier-spørsmålet skriftlig: hvilke av disse stiene divergerer, hvor, og hva er den dokumenterte oppførselen når det delte segmentet feiler? En muntlig forsikring under en designsamtale overlever ikke det avbruddet du designer for.

Feildomene 3: ruten som overlever uten IPsec

Privat peering og IPsec kan tilby konkurrerende ruter til samme applikasjonsprefiks. Hvis den beskyttede ruten forsvinner, kan en overlevende direkte ExpressRoute-rute fortsatt være brukbar, uten krypteringslaget tunnelen ga. Om det er akseptabelt er en policybeslutning, og det er beslutningen som oftest blir latt implisitt.

Krypteringskrav og tilgjengelighetskrav kan her virkelig komme i konflikt. «Enhver overlevende rute teller som suksess» er en tilgjengelighetserklæring som stille besvarer krypteringsspørsmålet med «nei». Skriv ned hvilket krav som vinner, for hvilke prefikser, og hvem som godkjente det.

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

Sammenlign de lærte rutene med prefiksene du forventet. En reservevei som bærer en liten administrativ arbeidsmengde kan være helt tilstrekkelig for den arbeidsmengden og langt fra kapasiteten produksjonsbehovet trenger, så noter kapasitetsantakelsen ved siden av ruten.

Noter tre separate rader, ikke én dom

Hold endepunktredundans, transportredundans og katastrofegjenoppretting som separate poster i designregistret, hver med sin egen mekanisme, sin egen verifisering og sin egen eier. Når en hendelsesgjennomgang spør hvorfor forbindelsen overlevde en gateway-omstart, men ikke et fiberbrudd, svarer tre rader i én setning; en enkelt «redundant»-avkrysningsboks kan ikke.

Test deretter radene du kan teste billig. Få én tunnel til å feile og bekreft at trafikken flytter seg og krypteres på nytt. Trekk tilbake én rute og bekreft at den overlevende stien er den du mente, og bekreft deretter om den fortsatt er kryptert. Dokumenter feilene du ikke kunne simulere, fordi en utestet rad er en antakelse og bør merkes som det.

Det nyttige resultatet er en kort tabell pluss én setning per rad. Hvis en rad ikke har noen mekanisme, er det funnet, og det er mye billigere å oppdage i en designgjennomgang enn under et carrier-avbrudd som ingen av de to tunnelene noen gang ville ha overlevd.