ExpressRoute pluss VPN: milliseid tõrkedomeene te katate?
Teine IPsec-tunnel katab lõpp-punkti, mitte selle all olevat vooluahelat. Kaardistage iga tõrkedomeen ja otsustage siis, kas krüptimata varutee on lubatud.
ExpressRoute'i privaatse peeringu kohal jooksev IPsec-tunnel lisab krüptimise transpordile, mis on juba olemas. Teine tunnel parandab lõpp-punkti kättesaadavust ega tee nende mõlema all oleva operaatori tee jaoks üldse midagi. Seda erinevust on lihtne kaotada, kui armatuurlaud näitab kahte rohelist tunnelit ja disainiülevaatus küsib hoopis teist küsimust: millised tõrked peab see ühendus üle elama? Vastake kõigepealt sellele ja loendage siis tunneleid, sest roheliste indikaatorite arv on krüptimiskihi omadus ja tõrkedomeenide arv on kogu tee omadus.
Alustage tõrgetest, mitte rohelistest tunnelitest
Kirjutage neli rida enne, kui midagi joonistate: ühe VPN-i lõpp-punkti või peer-eksemplari tõrge, ühe kohaliku ruuteri või esimese miili ühenduse tõrge, jagatud ExpressRoute'i tee tõrge ja IPsec-i kättesaamatus, samal ajal kui privaatne peering kannab endiselt liiklust. Iga rida nimetab, mida disain peab säilitama, ja igale neist vastab erinev mehhanism.
| 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 dokumenteerib privaatse IP-ga saidi-saiti VPN-i üle ExpressRoute'i privaatse peeringu ja toetatud kooseksisteerimise internetipõhiste saidi-saiti ühendustega. See kooseksisteerimine on teistsugune alumise kihi disain ega ilmne lihtsalt sellepärast, et lisasite veel ühe privaatse tunneli lõpp-punkti.
Tõrkedomeen 1: VPN-i lõpp-punkt
Kaks tunnelit ühel lüüsil on tavaliselt active-active paarid, mis lõpevad samal Azure'i poolsusel ressursil. Need kaitsevad ühe tunneli või eksemplari probleemi eest ega kaitse selle eest, et see ressurss muutub kättesaamatuks, konfigureeritakse ümber või jääb mahust ilma. Lõpp-punkti liiasus tähendab teist toetatud lõpp-punkti, millel on oma tee ja oma konfiguratsioon, pluss marsruut, mis suudab selleni jõuda.
Kontrollige, mida te tegelikult juurutasite, mitte mida diagramm ütleb, sest portaal rühmitab neid ressursse viisil, mis peidab nende seose:
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}'Kui mõlemad tunnelid osutavad ühele lüüsile ühe avaliku IP-ga, on teil kindlat ja piiratud tüüpi lõpp-punkti liiasus. See võib olla täpselt see, mida nõue küsib, ja nii tuleks seda ka sõnastada, mitte kirjeldada seda liiasuse ühendusena.
Tõrkedomeen 2: kohalik tee ja operaator
Krüptimise all on füüsiline ja äriline reaalsus: kliendi servaseade, ristühendus, teenusepakkuja võrk ja peeringu asukoht. ExpressRoute'i kättesaadavuse juhised on selgesõnalised, et otsast-otsani liiasus hõlmab kliendi ja teenusepakkuja segmente, mitte ainult Microsofti poolt. Kaks loogilist teed, mis jagavad ruuterit, toiteallikat või esimese miili ühendust, jagavad endiselt seda sõltuvust.
Siin kukub disain tavaliselt ausal ülevaatusel läbi. Kaks sama operaatori vooluahelat, mis lõpevad samas hoones, sama ostutellimuse seadmetel, ei ole kaks tõrkedomeeni. Need on üks tõrkedomeen kahe arvega.
Esitage operaatorile küsimus kirjalikult: millised neist teedest lahknevad, kus, ja milline on dokumenteeritud käitumine, kui jagatud segment tõrgub? Suuline kinnitus disainikõne ajal ei ela üle katkestust, mille jaoks te disainite.
Tõrkedomeen 3: marsruut, mis jääb ilma IPsec-ita
Privaatne peering ja IPsec võivad pakkuda konkureerivaid marsruute samale rakenduse prefiksile. Kui kaitstud marsruut kaob, võib allesjäänud otsene ExpressRoute'i marsruut olla endiselt kasutatav, ilma krüptimiskihita, mida tunnel pakkus. Kas see on vastuvõetav, on poliitika otsus, ja just see otsus jäetakse kõige sagedamini kaudseks.
Krüptimisnõuded ja kättesaadavusnõuded võivad siin tõesti vastuollu minna. „Iga allesjäänud marsruut loeb eduks“ on kättesaadavusväide, mis vastab krüptimisküsimusele vaikselt „ei“. Kirjutage üles, milline võidab, milliste prefiksite puhul ja kes selle heaks kiitis.
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 tableVõrrelge õpitud marsruute eeldatud prefiksitega. Väikest halduskoormust kandev varutee võib olla selle koormuse jaoks täiesti piisav ja tootmisnõudluse vajaminevast mahust kaugel, seega kirjutage mahu eeldus marsruudi kõrvale.
Kirjutage üles kolm eraldi rida, mitte üks otsus
Hoidke lõpp-punkti liiasus, transpordi liiasus ja katastroofijärgne taastamine disainikirjes eraldi kirjetena, igaüks oma mehhanismi, oma kontrolli ja oma omanikuga. Kui intsidendi ülevaatus küsib, miks ühendus elas üle lüüsi taaskäivituse, aga mitte kiudkaabli läbilõike, vastavad kolm rida ühe lausega; üks „liiane“ märkeruut seda ei suuda.
Seejärel testige ridu, mida saab odavalt testida. Laske ühel tunnelil tõrkeda ja kinnitage, et liiklus liigub ja krüptitakse uuesti. Võtke üks marsruut tagasi ja kinnitage, et allesjäänud tee on kavandatu, seejärel kinnitage, kas see on endiselt krüptitud. Dokumenteerige tõrked, mida te ei suutnud simuleerida, sest testimata rida on eeldus ja seda tuleks nii märgistada.
Kasulik väljund on lühike tabel pluss üks lause rea kohta. Kui real pole mehhanismi, on see leid, ja seda on palju odavam avastada disainiülevaatusel kui operaatori katkestuse ajal, mida kumbki tunnel ei oleks kunagi üle elanud.