ExpressRoute pluss VPN: kva feildomene dekkjer du?

Ein IPsec-tunnel som køyrer over den private peeringa til ExpressRoute legg til kryptering på ein transport som alt finst. Ein annan tunnel betrar tilgjengelegda til endepunktet, og han gjer absolutt ingenting for carrier-stien under dei båe. Den skilnaden er lett å miste når dashborda viser to grøne tunnelar og designgjennomgangen stiller eit anna spørsmål: kva feil må denne sambindinga overleve? Svar på det fyrst, og tel deretter tunnelar, fordi talet på grøne indikatorar er ein eigenskap ved krypteringslaget og talet på feildomene er ein eigenskap ved heile stien.

Start med feil, ikkje med grøne tunnelar

Skriv fire rader før du teiknar noko: eitt VPN-endepunkt eller eitt peer-eksemplar som feilar, éin lokal ruter eller first-mile-sambinding som feilar, den delte ExpressRoute-stien som feilar, og IPsec som blir utilgjengeleg medan privat peering framleis ber trafikk. Kvar rad namngir kva designet må ta vare på, og kvar av dei blir svara av ein annan mekanisme.

Microsoft dokumenterer site-til-site-VPN med private IP-adresser over den private peeringa til ExpressRoute, og støtta sameksistens med internettbaserte site-til-site-sambindingar. Den sameksistensen er eit anna underliggjande design, og han oppstår ikkje berre fordi du la til endå eit privat tunnelendepunkt.

Feildomene 1: VPN-endepunktet

To tunnelar på éin gateway er vanlegvis active-active-par som terminerer på den same ressursen på Azure-sida. Dei vernar mot eit problem med éin tunnel eller éin instans, og dei vernar ikkje mot at ressursen blir utilgjengeleg, omkonfigurert eller går tom for kapasitet. Endepunktredundans tyder eit andre støtta endepunkt, med sin eigen sti og si eiga konfigurasjon, pluss ei rute som kan nå det.

Kontroller kva du faktisk har rulla ut, ikkje kva diagrammet seier, fordi portalen grupperer desse ressursane på måtar som skjuler tilhøvet mellom dei:

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

Viss båe tunnelane peikar på éin gateway med éin offentleg IP, har du endepunktredundans av ein bestemd og avgrensa type. Det kan vere nett det kravet ber om, og det bør seiast slik i staden for å bli skildra som ei redundant sambinding.

Feildomene 2: den lokale stien og carrieren

Under krypteringa ligg ein fysisk og kommersiell røyndom: ei kundekanteining, ei krysskopling, eit leverandørnett og ein peering-stad. retningslinjene for ExpressRoute-tilgjengelegheit er tydelege på at redundans frå ende til ende omfattar kunde- og tenesteleverandørsegmenta, ikkje berre Microsoft-sida. To logiske stiar som deler ein ruter, ein straumforsyning eller ei first-mile-sambinding deler framleis den avhengnaden.

Det er her eit design vanlegvis stryk i ein ærleg gjennomgang. To kretsar frå same leverandør, som terminerer i same bygning, på utstyr frå same innkjøpsordre, er ikkje to feildomene. Dei er eitt feildomene med to fakturaer.

Still carrier-spørsmålet skriftleg: kva av desse stiane divergerer, kvar, og kva er den dokumenterte åtferda når det delte segmentet feilar? Ei munnleg forsikring under ein designsamtale overlever ikkje det avbrotet du designar for.

Feildomene 3: ruta som overlever utan IPsec

Privat peering og IPsec kan tilby konkurrerande ruter til same applikasjonsprefiks. Viss den verna ruta forsvinn, kan ei overlevande direkte ExpressRoute-rute framleis vere brukbar, utan krypteringslaget tunnelen gav. Om det er akseptabelt er ei policyavgjerd, og det er avgjerda som oftast blir latt implisitt.

Krypteringskrav og tilgjengelegheitskrav kan her verkeleg kome i konflikt. «Kvar overlevande rute tel som suksess» er ei tilgjengelegheitsfråsegn som stille svarar krypteringsspørsmålet med «nei». Skriv ned kva krav som vinn, for kva prefiks, og kven som godkjende 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

Samanlikn dei lærte rutene med prefiksa du venta. Ein reserveveg som ber ei lita administrativ arbeidsmengd kan vere heilt tilstrekkeleg for den arbeidsmengda og langt frå kapasiteten produksjonsbehovet treng, så noter kapasitetsantakinga ved sida av ruta.

Noter tre separate rader, ikkje éin dom

Hald endepunktredundans, transportredundans og katastrofegjenoppretting som separate postar i designregisteret, kvar med sin eigen mekanisme, si eiga stadfesting og sin eigen eigar. Når ein hendingsgjennomgang spør kvifor sambindinga overlevde ein gateway-omstart, men ikkje eit fiberbrot, svarar tre rader i éi setning; ein einaste «redundant»-avkryssingsboks kan ikkje.

Test deretter radene du kan teste billeg. Få éin tunnel til å feile og stadfest at trafikken flyttar seg og blir kryptert på nytt. Trekk tilbake éi rute og stadfest at den overlevande stien er den du meinte, og stadfest deretter om han framleis er kryptert. Dokumenter feila du ikkje kunne simulere, fordi ei utesta rad er ei antaking og bør merkast som det.

Det nyttige resultatet er ein kort tabell pluss éi setning per rad. Viss ei rad ikkje har nokon mekanisme, er det funnet, og det er mykje billegare å oppdage i ein designgjennomgang enn under eit carrier-avbrot som ingen av dei to tunnelane nokon gong ville ha overlevd.