ExpressRoute plus VPN: ktoré domény zlyhania pokrývate?
Druhý tunel IPsec pokrýva koncový bod, nie okruh pod ním. Zmapujte každú doménu zlyhania a potom rozhodnite, či je povolená nešifrovaná záložná cesta.
Tunel IPsec prevádzkovaný cez privátny peering ExpressRoute pridáva šifrovanie transportu, ktorý už existuje. Druhý tunel zlepšuje dostupnosť koncového bodu a pre cestu operátora pod oboma nerobí vôbec nič. Tento rozdiel sa ľahko stratí, keď dashboardy ukazujú dva zelené tunely a revízia návrhu kladie inú otázku: ktoré poruchy musí toto pripojenie prežiť? Najprv na to odpovedzte, potom počítajte tunely, pretože počet zelených indikátorov je vlastnosťou šifrovacej vrstvy a počet domén zlyhania je vlastnosťou celej cesty.
Začnite poruchami, nie zelenými tunelmi
Napíšte štyri riadky, skôr než čokoľvek nakreslíte: zlyhanie jedného koncového bodu VPN alebo jednej inštancie peer, zlyhanie jedného lokálneho routera alebo pripojenia prvej míle, zlyhanie spoločnej cesty ExpressRoute a nedostupnosť IPsec, zatiaľ čo privátny peering stále prenáša prevádzku. Každý riadok pomenúva, čo má návrh zachovať, a na každý odpovedá iný mechanizmus.
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft dokumentuje VPN typu site-to-site s privátnymi IP adresami cez privátny peering ExpressRoute a podporovanú koexistenciu s pripojeniami site-to-site cez internet. Táto koexistencia je iný návrh spodnej vrstvy a neobjaví sa len preto, že ste pridali ďalší koncový bod privátneho tunela.
Doména zlyhania 1: koncový bod VPN
Dva tunely na jednej bráne sú zvyčajne páry active-active, ktoré končia na tom istom prostriedku na strane Azure. Chránia pred problémom jedného tunela alebo jednej inštancie a nechránia pred tým, že tento prostriedok bude nedostupný, prekonfigurovaný alebo bez kapacity. Redundancia koncového bodu znamená druhý podporovaný koncový bod s vlastnou cestou a vlastnou konfiguráciou plus trasu, ktorá sa k nemu dostane.
Overte, čo ste skutočne nasadili, a nie čo hovorí diagram, pretože portál tieto prostriedky zoskupuje spôsobom, ktorý skrýva ich vzťah:
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}'Ak oba tunely smerujú na jednu bránu s jednou verejnou IP, máte redundanciu koncového bodu určitého a obmedzeného druhu. Môže to byť presne to, čo požiadavka žiada, a malo by sa to tak povedať, namiesto opisovať ako redundantné pripojenie.
Doména zlyhania 2: lokálna cesta a operátor
Pod šifrovaním leží fyzická a obchodná realita: zariadenie na okraji zákazníka, prepojenie, sieť poskytovateľa a lokalita peeringu. usmernenia k dostupnosti ExpressRoute výslovne uvádzajú, že redundancia od konca po koniec zahŕňa segmenty zákazníka aj poskytovateľa služieb, nielen stranu Microsoftu. Dve logické cesty, ktoré zdieľajú router, napájanie alebo pripojenie prvej míle, stále zdieľajú túto závislosť.
Tu návrh zvyčajne neuspeje pri poctivom preskúmaní. Dva okruhy od rovnakého poskytovateľa, končiace v tej istej budove, na zariadeniach z tej istej objednávky, nie sú dve domény zlyhania. Sú to jedna doména zlyhania s dvoma fakturami.
Položte otázku operátorovi písomne: ktoré z týchto ciest sa rozchádzajú, kde a aké je dokumentované správanie, keď spoločný segment zlyhá? Ústne uistenie počas návrhového hovoru neprežije výpadok, na ktorý navrhujete.
Doména zlyhania 3: trasa, ktorá prežije bez IPsec
Privátny peering a IPsec môžu ponúknuť konkurenčné trasy k rovnakému prefixu aplikácie. Ak chránená trasa zmizne, prežívajúca priama trasa ExpressRoute môže byť stále použiteľná, bez šifrovacej vrstvy, ktorú tunel poskytoval. Či je to prijateľné, je rozhodnutie politiky, a práve toto rozhodnutie sa najčastejšie necháva implicitné.
Požiadavky na šifrovanie a požiadavky na dostupnosť tu môžu skutočne kolidovať. „Každá prežívajúca trasa sa počíta ako úspech“ je tvrdenie o dostupnosti, ktoré potichu odpovedá na otázku šifrovania „nie“. Zapíšte, čo víťazí, pre ktoré prefixy a kto to schválil.
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 tablePorovnajte naučené trasy s prefixami, ktoré ste očakávali. Záložná cesta, ktorá nesie malú administratívnu záťaž, môže byť pre túto záťaž úplne postačujúca a ďaleko od kapacity, ktorú produkčný dopyt potrebuje, preto si poznamenajte predpoklad kapacity vedľa trasy.
Zaznamenajte tri samostatné riadky, nie jeden verdikt
Držte redundanciu koncového bodu, redundanciu transportu a obnovu po havárii ako samostatné položky v návrhovom zázname, každú s vlastným mechanizmom, vlastným overením a vlastným vlastníkom. Keď sa revízia incidentu pýta, prečo pripojenie prežilo reštart brány, ale nie prerušenie vlákna, tri riadky odpovedia jednou vetou; jedno zaškrtávacie pole „redundantné“ to nedokáže.
Potom otestujte riadky, ktoré sa dajú testovať lacno. Vypnite jeden tunel a potvrďte, že prevádzka sa presunie a znova zašifruje. Stiahnite jednu trasu a potvrďte, že prežívajúca cesta je tá zamýšľaná, a potom potvrďte, či je stále šifrovaná. Zdokumentujte poruchy, ktoré ste nedokázali simulovať, pretože netestovaný riadok je predpoklad a mal by tak byť označený.
Užitočným výstupom je krátka tabuľka plus jedna veta na riadok. Ak riadok nemá mechanizmus, to je zistenie, a objaviť ho pri revízii návrhu je oveľa lacnejšie než počas výpadku operátora, ktorý by oba tunely nikdy neprežili.