ExpressRoute plus VPN: katere domene odpovedi pokrivate?
Drugi tunel IPsec pokriva končno točko, ne pa vezja pod njo. Zarišite vsako domeno odpovedi in nato odločite, ali je dovoljena nešifrirana rezervna pot.
Tunel IPsec, ki teče čez zasebni peering ExpressRoute, doda šifriranje transportu, ki že obstaja. Drugi tunel izboljša razpoložljivost končne točke in za pot operaterja pod obema ne naredi prav nič. To razliko je lahko izgubiti, ko nadzorne plošče prikazujejo dva zelena tunela in pregled zasnove postavi drugo vprašanje: katere odpovedi mora ta povezava preživeti? Najprej odgovorite na to, nato štejte tunele, ker je število zelenih kazalnikov lastnost šifrirnega sloja in število domen odpovedi lastnost celotne poti.
Začnite z odpovedmi, ne z zelenimi tuneli
Napišite štiri vrstice, preden karkoli narišete: odpoved ene končne točke VPN ali ene instance peer, odpoved enega lokalnega usmerjevalnika ali povezave prve milje, odpoved skupne poti ExpressRoute in nedostopnost IPsec, medtem ko zasebni peering še prenaša promet. Vsaka vrstica poimenuje, kaj mora zasnova ohraniti, in na vsako odgovori drugačen mehanizem.
| 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 dokumentira VPN od mesta do mesta z zasebnimi IP naslovi čez zasebni peering ExpressRoute in podprto sožitje s povezavami od mesta do mesta prek interneta. To sožitje je drugačna zasnova spodnjega sloja in se ne pojavi le zato, ker ste dodali še eno končno točko zasebnega tunela.
Domena odpovedi 1: končna točka VPN
Dva tunela na enem prehodu sta običajno para active-active, ki se končata na istem viru na strani Azure. Ščitita pred težavo enega tunela ali ene instance in ne ščitita pred tem, da ta vir postane nedosegljiv, se prekonfigurira ali ostane brez zmogljivosti. Redundanca končne točke pomeni drugo podprto končno točko z lastno potjo in lastno konfiguracijo ter pot, ki jo lahko doseže.
Preverite, kaj ste dejansko uvedli, in ne, kaj pravi diagram, ker portal te vire združuje tako, da skriva njihov odnos:
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}'Če oba tunela kažeta na en prehod z enim javnim IP, imate redundanco končne točke posebne in omejene vrste. To je morda natanko tisto, kar zahteva zahteva, in tako bi bilo treba tudi povedati, namesto opisovati kot redundantno povezavo.
Domena odpovedi 2: lokalna pot in operater
Pod šifriranjem leži fizična in poslovna resničnost: naprava na robu stranke, navzkrižna povezava, omrežje ponudnika in lokacija peeringa. smernice za razpoložljivost ExpressRoute izrecno navajajo, da redundanca od konca do konca vključuje segmente stranke in ponudnika storitev, ne le strani Microsoft. Dve logični poti, ki si delita usmerjevalnik, napajanje ali povezavo prve milje, si še vedno delita to odvisnost.
Tu zasnova običajno ne uspe pri poštenem pregledu. Dva voda od istega ponudnika, ki se končata v isti zgradbi, na opremi iz istega naročila, nista dve domeni odpovedi. To je ena domena odpovedi z dvema računoma.
Vprašajte operaterja pisno: katere od teh poti se razhajajo, kje, in kakšno je dokumentirano vedenje, ko skupni segment odpove? Ustno zagotovilo med klicem o zasnovi ne preživi izpada, za katerega načrtujete.
Domena odpovedi 3: pot, ki preživi brez IPsec
Zasebni peering in IPsec lahko ponudita konkurenčne poti do istega predpone aplikacije. Če zaščitena pot izgine, je preživela neposredna pot ExpressRoute morda še vedno uporabna, brez šifrirnega sloja, ki ga je zagotavljal tunel. Ali je to sprejemljivo, je odločitev politike, in prav ta odločitev najpogosteje ostane implicitna.
Zahteve po šifriranju in zahteve po razpoložljivosti se tu lahko resnično spopadejo. „Vsaka preživela pot šteje kot uspeh“ je trditev o razpoložljivosti, ki tiho odgovori na vprašanje šifriranja z „ne“. Zapišite, kaj zmaga, za katere predpone in kdo je to odobril.
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 tablePrimerjajte naučene poti s predponami, ki ste jih pričakovali. Rezervna pot, ki nosi majhno administrativno obremenitev, je lahko za to obremenitev povsem ustrezna in daleč od zmogljivosti, ki jo potrebuje proizvodno povpraševanje, zato zapišite predpostavko o zmogljivosti ob poti.
Zabeležite tri ločene vrstice, ne ene razsodbe
Ohranite redundanco končne točke, redundanco transporta in obnovitev po katastrofi kot ločene vnose v načrtovalskem dnevniku, vsak s svojim mehanizmom, svojim preverjanjem in svojim lastnikom. Ko pregled incidenta vpraša, zakaj je povezava preživela ponovni zagon prehoda, ne pa tudi prereza vlakna, tri vrstice odgovorijo v enem stavku; eno potrditveno polje „redundantno“ tega ne zmore.
Nato preizkusite vrstice, ki jih lahko preizkusite poceni. Povzročite odpoved enega tunela in potrdite, da se promet premakne in znova šifrira. Umaknite eno pot in potrdite, da je preživela pot tista, ki ste jo nameravali, nato potrdite, ali je še vedno šifrirana. Dokumentirajte odpovedi, ki jih niste mogli simulirati, ker je nepreizkušena vrstica predpostavka in mora biti tako označena.
Uporaben rezultat je kratka tabela in en stavek na vrstico. Če vrstica nima mehanizma, je to ugotovitev, in odkriti jo pri pregledu zasnove je veliko ceneje kot med izpadom operaterja, ki ga noben od obeh tunelov ne bi preživel.