ExpressRoute plus VPN: hvilke fejldomæner dækker du?

En IPsec-tunnel, der kører over ExpressRoute private peering, tilføjer kryptering til en transport, der allerede findes. En anden tunnel forbedrer endepunktets tilgængelighed og gør absolut intet for carrier-stien nedenunder dem begge. Den forskel er let at tabe, når dashboards viser to grønne tunneller, og designgennemgangen stiller et andet spørgsmål: hvilke fejl skal denne forbindelse overleve? Svar på det først, og tæl derefter tunneller, for antallet af grønne indikatorer er en egenskab ved krypteringslaget, og antallet af fejldomæner er en egenskab ved hele stien.

Begynd med fejl, ikke med grønne tunneller

Skriv fire rækker, før du tegner noget: ét VPN-endepunkt eller peer-instans, der fejler, én lokal router eller first-mile-forbindelse, der fejler, den delte ExpressRoute-sti, der fejler, og IPsec, der bliver utilgængelig, mens private peering stadig bærer trafik. Hver række navngiver, hvad designet skal bevare, og hver af dem besvares af en anden mekanisme.

Microsoft dokumenterer site-to-site-VPN med private IP-adresser over ExpressRoute private peering og understøttet sameksistens med internetbaserede site-to-site-forbindelser. Den sameksistens er et andet underliggende design, og den opstår ikke blot, fordi du tilføjede endnu et privat tunnelendepunkt.

Fejldomæne 1: VPN-endepunktet

To tunneller på én gateway er normalt active-active-par, der terminerer på den samme ressource på Azure-siden. De beskytter mod et problem med en enkelt tunnel eller instans og beskytter ikke mod, at ressourcen bliver utilgængelig, omkonfigureret eller løber tør for kapacitet. Endepunktsredundans betyder et andet understøttet endepunkt med sin egen sti og sin egen konfiguration plus en rute, der kan nå det.

Kontrollér, hvad du faktisk har implementeret, i stedet for hvad diagrammet siger, fordi portalen grupperer disse ressourcer på måder, der skjuler deres forhold:

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 tunneller peger på én gateway med én offentlig IP, har du endepunktsredundans af en bestemt og begrænset slags. Det kan være præcis det, kravet beder om, og det bør siges sådan i stedet for at blive beskrevet som en redundant forbindelse.

Fejldomæne 2: den lokale sti og carrieren

Under krypteringen ligger en fysisk og kommerciel virkelighed: en kundekantenhed, en krydsforbindelse, et udbydernetværk og en peering-lokation. retningslinjerne for ExpressRoute-tilgængelighed er eksplicitte om, at redundans fra ende til ende omfatter kunde- og tjenesteudbydersegmenterne, ikke kun Microsoft-siden. To logiske stier, der deler en router, en strømforsyning eller en first-mile-forbindelse, deler stadig den afhængighed.

Det er her, et design normalt fejler i en ærlig gennemgang. To kredsløb fra samme udbyder, der terminerer i samme bygning, på udstyr fra samme indkøbsordre, er ikke to fejldomæner. De er ét fejldomæne med to fakturaer.

Stil carrier-spørgsmålet skriftligt: hvilke af disse stier divergerer, hvor, og hvad er den dokumenterede adfærd, når det delte segment fejler? En mundtlig forsikring under et designopkald overlever ikke det udfald, du designer til.

Fejldomæne 3: ruten, der overlever uden IPsec

Private peering og IPsec kan tilbyde konkurrerende ruter til det samme applikationspræfiks. Hvis den beskyttede rute forsvinder, kan en overlevende direkte ExpressRoute-rute stadig være brugbar, uden det krypteringslag, tunnellen leverede. Om det er acceptabelt, er en politikbeslutning, og det er den beslutning, der oftest lades implicit.

Krypteringskrav og tilgængelighedskrav kan her reelt støde sammen. «Enhver overlevende rute tæller som succes» er en tilgængelighedserklæring, der stille besvarer krypteringsspørgsmålet med «nej». Skriv ned, hvilket krav der vinder, for hvilke præfikser, og hvem der godkendte 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 ruter med de præfikser, du forventede. En reservesti, der bærer en lille administrativ arbejdsbyrde, kan være helt passende til den byrde og langt fra den kapacitet, produktionsbehovet kræver, så notér kapacitetsantagelsen ved siden af ruten.

Notér tre separate rækker, ikke én dom

Hold endepunktsredundans, transportredundans og katastrofegendannelse som separate poster i designregistret, hver med sin egen mekanisme, sin egen verifikation og sin egen ejer. Når en hændelsesgennemgang spørger, hvorfor forbindelsen overlevede en gateway-genstart, men ikke et fiberbrud, svarer tre rækker i én sætning; et enkelt «redundant»-afkrydsningsfelt kan ikke.

Test derefter de rækker, du kan teste billigt. Lad en tunnel fejle, og bekræft, at trafikken flytter sig og krypteres igen. Træk en rute tilbage, og bekræft, at den overlevende sti er den, du havde tænkt dig, og bekræft derefter, om den stadig er krypteret. Dokumentér de fejl, du ikke kunne simulere, fordi en utestet række er en antagelse og bør mærkes som sådan.

Det nyttige output er en kort tabel plus en sætning pr. række. Hvis en række ikke har nogen mekanisme, er det fundet, og det er meget billigere at opdage i en designgennemgang end under et carrier-udfald, som begge tunneller aldrig ville have overlevet.