ExpressRoute plus VPN: hokker faaldomeinen dekke jo?
In twadde IPsec-tunnel dekt in einpunt, net it circuit dêr't it op stipet. Map elk faaldomein, en beslút dan oft in net-fersifere fallback tastien is.
In IPsec-tunnel oer de privee peering fan ExpressRoute foeget fersifering ta oan in transport dat al bestiet. In twadde tunnel ferbetteret de beskikberens fan it einpunt en docht foar it operatortrajekt ûnder beide folslein neat. Dat ûnderskied is maklik te ferliezen as de dashboards twa griene tunnels sjen litte en de ûntwerpbesprek in oare fraach stelt: hokker flaters moat dizze ferbining oerlibje? Beäntwurdzje dat earst en tel dan tunnels, want it oantal griene yndikatoaren is in eigenskip fan 'e fersiferingslaach en it oantal faaldomeinen is in eigenskip fan it hiele trajekt.
Begjin mei flaters, net mei griene tunnels
Skriuw fjouwer rigen foardat jo wat tekenje: ien VPN-einpunt of peer-eksimplaar dat falt, ien lokale router of earste-mile-ferbining dy't falt, it mienskiplike ExpressRoute-trajekt dat falt, en IPsec dat net beskikber wurdt wylst privee peering noch ferkear draacht. Eltse rige neamt wat it ûntwerp behâlde moat, en op elk fan harren antwurdet in oar meganisme.
| 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 dokumintearret site-to-site-VPN mei privee IP-adressen oer privee peering fan ExpressRoute, en de stipe njonkenino-bestean mei internet-basearre site-to-site-ferbiningen. Dat njonkenino-bestean is in oar ûnderlizzend ûntwerp, en it ûntstiet net samar om't jo noch in privee tunneleinpunt tafoege hawwe.
Faaldomein 1: it VPN-einpunt
Twa tunnels op ien gateway binne meastentiids active-active-pearen dy't op deselde Azure-side boarne einigje. Se beskermje tsjin in probleem mei ien tunnel of eksimplaar, en se beskermje net tsjin dat dy boarne net beskikber, opnij konfigurearre of sûnder kapasiteit rekket. Redundânsje fan it einpunt betsjut in twadde stipe einpunt, mei syn eigen paad en syn eigen konfiguraasje, plus in rûte dy't it berikke kin.
Kontrolearje wat jo eins útdroege hawwe, net wat it diagram seit, want it portaal groepearret dizze boarnen op manieren dy't har relaasje ferbergje:
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 beide tunnels nei ien gateway mei ien publike IP wize, hawwe jo redundânsje fan it einpunt fan in bepaald en beheind soarte. Dat kin krekt wêze wat de eask freget, en it moat sa sein wurde ynstee fan beskreaun te wurden as in redundante ferbining.
Faaldomein 2: it lokale paad en de operator
Under de fersifering leit in fysike en kommersjele realiteit: in klantrântapparaat, in krúsferbining, in providernetwurk en in peering-lokaasje. de beskikberensrjochtlinen fan ExpressRoute binne dúdlik dat redundânsje fan ein oant ein de segminten fan 'e klant en de tsjinstferlener omfettet, net allinnich de Microsoft-kant. Twa logyske paden dy't in router, in stroomfoarsjenning of in earste-mile-ferbining diele, diele noch hieltyd dy ôfhinklikens.
Hjir falt in ûntwerp meastentiids troch by in earlike beoardieling. Twa circuits fan deselde provider, dy't yn itselde gebou einigje, op apparatuer út deselde oankeapopdracht, binne gjin twa faaldomeinen. Se binne ien faaldomein mei twa faktueren.
Stel de fraach oan de operator skriftlik: hokker fan dizze paden wykt ôf, wêr, en wat is it dokumintearre gedrach as it mienskiplike segmint falt? In mûnlinge fersekering by in ûntwerpspetear oerlibbet de steuring net dêr't jo foar ûntwerpe.
Faaldomein 3: de rûte dy't sûnder IPsec oerlibbet
Privee peering en IPsec kinne konkurrearjende rûtes nei itselde applikaasjeprefiks biede. As de beskerme rûte ferdwynt, kin in oerlibjende direkte ExpressRoute-rûte noch brûkber wêze, sûnder de fersiferingslaach dy't de tunnel levere. Oft dat akseptabel is, is in beliedsbeslút, en it is it beslút dat it meast ymplisyt litten wurdt.
Fersiferings- en beskikberenseasken kinne hjir wier meiinoar yn konflikt komme. «Elke oerlibjende rûte jildt as súkses» is in beskikberensbewearing dy't stilwei «nee» antwurdet op 'e fersiferingsfraach. Skriuw op hokker wint, foar hokker prefiksen en wa't it goedkard hat.
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 tableFergelykje de learde rûtes mei de prefiksen dy't jo ferwachte. In fallback dy't in lytse administrative lading draacht, kin foar dy lading folslein genôch wêze en fier fan 'e kapasiteit dy't de produksje-eask nedich hat, dus skriuw de kapasiteitsanname njonken de rûte op.
Skriuw trije aparte rigen op, gjin ien fûnis
Hâld redundânsje fan it einpunt, redundânsje fan it transport en needherstel as aparte ynskriuwingen yn it ûntwerpregister, elk mei syn eigen meganisme, syn eigen kontrôle en syn eigen eigner. As in ynsidintbesprek freget wêrom't de ferbining in gateway-herstart oerlibbe mar gjin glêstriedbrek, antwurdzje trije rigen yn ien sin; ien ienfâldich «redundant»-fakje kin dat net.
Test dan de rigen dy't jo goedkeap testen kinne. Lit ien tunnel falle en befêstigje dat it ferkear ferpleatst en opnij fersifere wurdt. Lûk ien rûte werom en befêstigje dat it oerlibjende paad it paad is dat jo bedoelden, en befêstigje dan oft it noch fersifere is. Dokumintearje de flaters dy't jo net simulearje koene, want in net teste rige is in oanname en moat as sadanich oanmerke wurde.
De nuttige útfier is in koarte tabel plus in sin per rige. As in rige gjin meganisme hat, is dat de befinning, en it is folle goedkeaper om dat by in ûntwerpbesprek te ûntdekken as by in operatorsteuring dy't beide tunnels nea oerlibbe hawwe soene.