ExpressRoute plus VPN: watter foutdomeine dek jy?

’n IPsec-tonnel wat oor ExpressRoute-privaatpeering loop, voeg versleuteling by ’n vervoer wat reeds bestaan. ’n Tweede tonnel verbeter die beskikbaarheid van die eindpunt, en dit doen heeltemal niks vir die vervoerderpad onder albei nie. Dié onderskeid is maklik om te verloor wanneer die paneelborde twee groen tonnele wys en die ontwerphersiening ’n ander vraag vra: watter foute moet hierdie verbinding oorleef? Beantwoord dit eerste en tel dan tonnele, want die aantal groen aanwysers is ’n eienskap van die versleutelingslaag en die aantal foutdomeine is ’n eienskap van die hele pad.

Begin met foute, nie met groen tonnele nie

Skryf vier rye voordat jy enigiets teken: een VPN-eindpunt of eweknie-instantie wat faal, een plaaslike router of eerste-myl-verbinding wat faal, die gedeelde ExpressRoute-pad wat faal, en IPsec wat onbeskikbaar word terwyl privaatpeering steeds verkeer dra. Elke ry benoem wat die ontwerp moet behou, en elkeen word deur ’n ander meganisme beantwoord.

Microsoft dokumenteer private-IP Site-to-Site VPN oor ExpressRoute-privaatpeering, en die ondersteunde naasbestaan met internetgebaseerde Site-to-Site-verbindings. Daardie naasbestaan is ’n ander onderlaag-ontwerp, en dit verskyn nie bloot omdat jy nog ’n private tonnel-eindpunt bygevoeg het nie.

Foutdomein 1: die VPN-eindpunt

Twee tonnele op een poort is gewoonlik aktief-aktiewe pare wat op dieselfde Azure-hulpbron eindig. Hulle beskerm teen ’n probleem met ’n enkele tonnel of instansie, en hulle beskerm nie daarteen dat daardie hulpbron onbeskikbaar, herkonfigureer of buite kapasiteit is nie. Eindpunt-oortolligheid beteken ’n tweede ondersteunde eindpunt, met sy eie pad en sy eie konfigurasie, plus ’n roete wat dit kan bereik.

Kontroleer wat jy werklik ontplooi het eerder as wat die diagram sê, want die portaal groepeer hierdie hulpbronne op maniere wat hulle verwantskap verberg:

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

As albei tonnele na een poort met een openbare IP wys, het jy eindpunt-oortolligheid van ’n spesifieke en beperkte soort. Dit is dalk presies wat die vereiste vra, en dit moet so gestel word eerder as om dit as ’n oortollige verbinding te beskryf.

Foutdomein 2: die plaaslike pad en die vervoerder

Onder die versleuteling sit ’n fisiese en kommersiële werklikheid: ’n kliëntekant-toestel, ’n kruisverbinding, ’n verskaffernetwerk en ’n peering-ligging. Die ExpressRoute-beskikbaarheidsriglyne is eksplisiet dat end-tot-end-oortolligheid die kliënt- en diensverskaffersegmente insluit, nie net die Microsoft-kant nie. Twee logiese paaie wat ’n router, ’n kragtoevoer of ’n eerste-myl-verbinding deel, deel steeds daardie afhanklikheid.

Dit is waar ’n ontwerp gewoonlik ’n eerlike hersiening misluk. Twee stroombane van dieselfde verskaffer, wat in dieselfde gebou eindig, op toerusting uit dieselfde aankoopbestelling, is nie twee foutdomeine nie. Hulle is een foutdomein met twee fakture.

Vra die vervoerdervraag skriftelik: watter van hierdie paaie divergeer, waar, en wat is die gedokumenteerde gedrag wanneer die gedeelde segment faal? ’n Mondelinge versekering tydens ’n ontwerpgesprek oorleef nie die onderbreking waarvoor jy ontwerp nie.

Foutdomein 3: die roete wat sonder IPsec oorleef

Privaatpeering en IPsec kan mededingende roetes na dieselfde toepassingsvoorvoegsel bied. As die beskermde roete verdwyn, kan ’n oorlewende direkte ExpressRoute-roete steeds bruikbaar wees, sonder die versleutelingslaag wat die tonnel verskaf het. Of dit aanvaarbaar is, is ’n beleidsbesluit, en dit is die besluit wat die meeste implisiet gelaat word.

Versleutelingsvereistes en beskikbaarheidsvereistes kan hier werklik bots. “Enige oorlewende roete tel as sukses” is ’n beskikbaarheidsstelling wat die versleutelingsvraag stilweg met “nee” beantwoord. Skryf neer watter een wen, vir watter voorvoegsels, en wie dit goedgekeur het.

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

Vergelyk die aangeleerde roetes met die voorvoegsels wat jy verwag het. ’n Terugval wat ’n klein administratiewe werklading dra, kan heeltemal voldoende wees vir daardie werklading en nêërens naby die kapasiteit wat die produksievereiste nodig het nie, so teken die kapasiteitsaanname saam met die roete aan.

Teken drie afsonderlike rye aan, nie een uitspraak nie

Hou eindpunt-oortolligheid, vervoer-oortolligheid en rampherstel as afsonderlike inskrywings in die ontwerpverslag, elk met sy eie meganisme, sy eie verifikasie en sy eie eienaar. Wanneer ’n voorvalhersiening vra hoekom die verbinding ’n poort-herstarting oorleef het maar nie ’n veselkopping nie, antwoord drie rye in een sin; ’n enkele “oortollige” merkblokkie kan dit nie.

Toets dan die rye wat jy goedkoop kan toets. Laat een tonnel faal en bevestig dat die verkeer beweeg en herversleutel. Trek een roete terug en bevestig dat die oorlewende pad dié is wat jy bedoel het, en bevestig dan of dit steeds versleutel is. Dokumenteer die foute wat jy nie kon simuleer nie, want ’n ongetoetsde ry is ’n aanname en moet as sodanig gemerk word.

Die nuttige uitset is ’n kort tabel plus ’n sin per ry. As ’n ry geen meganisme het nie, is dit die bevinding, en dit is baie goedkoper om in ’n ontwerphersiening te ontdek as tydens ’n vervoerderonderbreking wat albei tonnele nooit sou oorleef nie.