ExpressRoute plus VPN: kiujn fiaskodomajnojn vi kovras?
Dua IPsec-tunelo kovras finpunkton, ne la cirkviton sub ĝi. Mapu ĉiun fiaskodomajnon, poste decidu ĉu senĉifra rezervvojo estas permesata.
IPsec-tunelo funkcianta super privata peerado de ExpressRoute aldonas ĉifradon al transporto kiu jam ekzistas. Dua tunelo plibonigas la disponeblecon de la finpunkto, kaj ĝi faras absolute nenion por la portanto-vojo sub ambaŭ. Tiu distingo facile perdiĝas kiam la paneloj montras du verdajn tunelojn kaj la dezajnrevizio starigas alian demandon: kiujn fiaskojn devas postvivi ĉi tiu konekto? Respondu tion unue, poste kalkulu tunelojn, ĉar la nombro de verdaj indikiloj estas eco de la ĉifrada tavolo kaj la nombro de fiaskodomajnoj estas eco de la tuta vojo.
Komencu per fiaskoj, ne per verdaj tuneloj
Skribu kvar vicojn antaŭ ol desegni ion ajn: unu VPN-finpunkto aŭ peer-kazo fiaskanta, unu loka enkursigilo aŭ unua-mejla konekto fiaskanta, la komuna ExpressRoute-vojo fiaskanta, kaj IPsec fariĝanta nedisponebla dum privata peerado ankoraŭ portas trafikon. Ĉiu vico nomas tion, kion la dezajno devas konservi, kaj al ĉiu respondas malsama mekanismo.
| 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 dokumentas private-IP Site-to-Site VPN super privata peerado de ExpressRoute, kaj la subtenatan kunekziston kun interret-bazitaj Site-to-Site-konektoj. Tiu kunekzisto estas malsama suba tavola dezajno, kaj ĝi ne aperas nur ĉar vi aldonis alian privatan tunelan finpunkton.
Fiaskodomajno 1: la VPN-finpunkto
Du tuneloj sur unu enirejo kutime estas active-active paroj finiĝantaj sur la sama Azure-flanka rimedo. Ili protektas kontraŭ problemo de unu tunelo aŭ kazo, kaj ili ne protektas kontraŭ tio, ke tiu rimedo fariĝu nedisponebla, rekonfigurita aŭ sen kapacito. Finpunkta redundo signifas duan subtenatan finpunkton, kun sia propra vojo kaj sia propra agordo, plus vojon kiu povas atingi ĝin.
Kontrolu kion vi efektive disfaldigis, ne kion diras la diagramo, ĉar la portalo grupigas ĉi tiujn rimedojn tiel, ke ĝi kaŝas ilian rilaton:
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}'Se ambaŭ tuneloj montras al unu enirejo kun unu publika IP, vi havas finpunktan redundon de specifa kaj limigita speco. Tio eble estas ĝuste kion la postulo petas, kaj ĝi devus esti dirita tiel anstataŭ esti priskribita kiel redunda konekto.
Fiaskodomajno 2: la loka vojo kaj la portanto
Sub la ĉifrado kuŝas fizika kaj komerca realo: klienta randa aparato, kruca konekto, provizanta reto kaj peerada loko. la disponeblaj gvidlinioj de ExpressRoute estas eksplicitaj, ke redundo de fino al fino inkluzivas la segmentojn de la kliento kaj de la servoprovizanto, ne nur la Microsoft-flankon. Du logikaj vojoj kiuj dividas enkursigilon, elektran provizon aŭ unua-mejlan konekton ankoraŭ dividas tiun dependecon.
Ĉi tie dezajno kutime malsukcesas honestan revizion. Du cirkvitoj de la sama provizanto, finiĝantaj en la sama konstruaĵo, sur ekipaĵo el la sama aĉetordo, ne estas du fiaskodomajnoj. Ili estas unu fiaskodomajno kun du fakturoj.
Demandu la portanto-demandan skribe: kiuj el ĉi tiuj vojoj diverĝas, kie, kaj kio estas la dokumentita konduto kiam la komuna segmento fiaskas? Parola certigo dum dezajna alvoko ne postvivas la interrompon por kiu vi dezajnas.
Fiaskodomajno 3: la vojo kiu postvivas sen IPsec
Privata peerado kaj IPsec povas proponi konkurantajn vojojn al la sama aplikaĵa prefikso. Se la protektita vojo malaperas, postvivanta rekta ExpressRoute-vojo eble ankoraŭ estas uzebla, sen la ĉifrada tavolo kiun la tunelo provizis. Ĉu tio estas akceptebla estas politika decido, kaj ĝi estas la decido plej ofte lasita implica.
Ĉifradaj postuloj kaj disponeblaj postuloj povas vere konflikti ĉi tie. «Ĉiu postvivanta vojo validas kiel sukceso» estas disponebla aserto kiu silente respondas la ĉifradan demandon per «ne». Skribu kiu venkas, por kiuj prefiksoj, kaj kiu aprobis ĝin.
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 tableKomparu la lernitajn vojojn kun la prefiksoj kiujn vi atendis. Rezerva vojo kiu portas malgrandan administran ŝarĝon povas esti tute taŭga por tiu ŝarĝo kaj tute malproksima de la kapacito kiun la produktada postulo bezonas, do notu la kapacitan supozon apud la vojo.
Notu tri apartajn vicojn, ne unu verdikton
Tenu finpunktan redundon, transportan redundon kaj katastrofan reakiron kiel apartajn erojn en la dezajna registro, ĉiu kun sia propra mekanismo, sia propra kontrolo kaj sia propra posedanto. Kiam incidenta revizio demandas kial la konekto postvivis enirejan restartigon sed ne fibran tranĉon, tri vicoj respondas per unu frazo; unu «redunda» markobutono ne povas.
Poste testu la vicojn kiujn vi povas testi malmultekoste. Fiaskigu unu tunelon kaj konfirmu ke la trafiko moviĝas kaj reĉifriĝas. Retiru unu vojon kaj konfirmu ke la postvivanta vojo estas tiu kiun vi intencis, poste konfirmu ĉu ĝi ankoraŭ estas ĉifrita. Dokumentu la fiaskojn kiujn vi ne povis simuli, ĉar netestita vico estas supozo kaj devus esti tiel etikedita.
La utila rezulto estas mallonga tabelo plus frazo por vico. Se vico havas neniun mekanismon, tio estas la trovajo, kaj estas multe pli malmultekoste malkovri ĝin en dezajnrevizio ol dum portanto-interrompo kiun ambaŭ tuneloj neniam postvivus.