Dva lokalna naslova VPN: dva partnerja Azure, ne eden

Diagram ima v podružnici dve internetni povezavi in en prehod VPN v Azure, zato prehod lokalnega omrežja prejme oba javna naslova. Videti je urejeno in ne deluje tako, kot nakazuje diagram. Vsaka lokalna naprava VPN je ločen partnerski odnos, Microsoftova zasnova za več naprav pa vsaki daje svoj vir prehoda lokalnega omrežja in svojo povezavo. Dodajanje drugega naslova enemu viru ne ustvari drugega partnerja. Ustvari vir, ki pravilno ne opisuje nobene od obeh naprav.

Mit: en prehod, dva naslova

Prehod lokalnega omrežja je opis oddaljenega partnerja: ena javna končna točka in zasebne predpone za njo. Ni podprtega načina, da bi ta vir pomenil «katera koli od teh dveh naprav».

Ista zmeda je tudi v nasprotni smeri, kjer se dva javna IP naslova Azure bereta kot dokaz, da obstajata dva prehoda Azure.

Preštejte objekte, nato tunele

Vzemite dve neodvisno upravljani lokalni napravi, vsaka z lastnim javnim naslovom in dostopom do istih zasebnih omrežij, plus en prehod Azure, ki temelji na usmerjanju v načinu aktivno-aktivno. Prehod Azure ima dva aktivna primerka z ločenima javnima IP naslovoma. Vsaka lokalna naprava se poveže z obema primerki. To je polna mreža in število objektov izhaja iz nje, ne iz diagrama.

Aritmetika je dovolj kratka, da jo prilepite v načrtovalski dokument:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

En vir povezave lahko nosi več kot en osnovni tunel, zato štirje tuneli ne pomenijo štirih prehodov virtualnega omrežja. Tudi dva javna IP naslova Azure nista ista objekta kot dva prehoda lokalnega omrežja, ki opisujeta oddaljeno lokacijo.

Kaj doda aktivno-aktivno na strani Azure

Aktivno-aktivno spremeni prehod Azure iz enega aktivnega primerka v dva, vsakega z lastnim javnim IP naslovom, in prav to sploh omogoča polno mrežo. Ne podvoji prepustnosti enega toka. Prav tako ne odpravi potrebe, da lokalna stran podpira večpotno usmerjanje z enakimi stroški, če obe napravi posredujeta hkrati. Preden kar koli zagotovite, potrdite način prehoda, SKU in zmogljivosti oddaljene naprave.

Prehod v pasivnem pripravljenosti je povsem veljavna zasnova; le daje drugačno število tunelov.

BGP naredi obe poti uporabni

Za zasnovo z več napravami obe lokalni napravi izvajata BGP. Vsaki dajte edinstven naslov partnerja BGP in objavite enake predvidene zasebne predpone po ustreznih poteh. Zasebne predpone opredeljujejo zaščitena omrežja, javni naslovi pa opredeljujejo, kje se končajo šifrirane prenosne povezave. Zamenjava teh dveh ustvari zasnovo, v kateri so vsi tuneli aktivni, poti pa napačne.

Načrtujte povratno usmerjanje in vsak pregled stanja, ki mora prenesti katero koli od obeh poti. Zdrava seja IKE na vsaki končni točki ne dokazuje, da lahko delovna obremenitev uporabi vsako objavljeno pot.

Izbira na podlagi toka ni združevanje pasovne širine

Azure izbere pot za vsak tok z zgoščevalno funkcijo čez naslove in vrata toka. V stabilnem stanju paketi določenega toka TCP ali UDP običajno gredo po istem tunelu, lokalna stran pa lahko za povratno smer izbere drug tunel. Zato dve napravi in štirje tuneli izboljšajo razpoložljivost, ne hitrosti enega prenosa. Ko prodajna predstavitev obljublja združevanje, opisuje drugo funkcijo ali nesporazum.

Preizkusite z vzporednimi tokovi, če želite videti širjenje poti, in z enim tokom, če želite videti mejo.

Katero odvečnost ste dejansko odstranili

Dva naslova WAN na eni napravi izboljšata možnosti dostopne povezave, vendar si delita napajanje, programsko opremo in stanje okvare te naprave. Nista enako kot dve napravi in nobena konfiguracija na strani Azure tega ne spremeni. Sledite proizvajalčevi podprti zasnovi z dvojnim WAN ali gručo, namesto da bi odvečnost sklepali iz števila naslovov. Nato to preizkusite: odstranite po eno pot in potrdite preostale poti ter resnično izmenjavo aplikacije v obeh smereh.

Pričakujte zamude pri zaznavanju in konvergenci ter pričakujte, da se bodo nekatere obstoječe seje končale.