Kaks kohalikku VPN-aadressi: kaks Azure'i peeri, mitte üks

Diagrammil on harukontoris kaks internetilingi ja üks Azure'i VPN-lüüs, seega saab kohaliku võrgu lüüs mõlemad avalikud aadressid. See näeb korrektne välja ja ei tööta nii, nagu diagramm vihjab. Iga kohalik VPN-seade on eraldi peer-suhe ning Microsofti mitme seadme lahendus annab igaühele oma kohaliku võrgu lüüsi ressursi ja oma ühenduse. Teise aadressi lisamine ühele ressursile ei loo teist peeri. See loob ressursi, mis ei kirjelda korralikult kumbagi seadet.

Müüt: üks lüüs, kaks aadressi

Kohaliku võrgu lüüs on kaugema peeri kirjeldus: üks avalik lõpp-punkt ja selle taga olevad privaatsed prefiksid. Puudub toetatud viis, kuidas see ressurss tähendaks «ükskõik kumb neist kahest seadmest».

Sama segadus esineb ka vastassuunas, kus kahte Azure'i avalikku IP-d loetakse tõendiks kahe Azure'i lüüsi olemasolust.

Loendage objektid, seejärel tunnelid

Võtke kaks sõltumatult hallatavat kohalikku seadet, kummalgi oma avalik aadress ja juurdepääs samadele privaatsetele võrkudele, pluss üks marsruutimispõhine Azure'i lüüs aktiiv-aktiivses režiimis. Azure'i lüüsil on kaks aktiivset eksemplari eraldi avalike IP-dega. Iga kohalik seade ühendub mõlema eksemplariga. See on täielik võrk ja objektide arv tuleneb sellest, mitte diagrammist.

Aritmeetika on piisavalt lühike, et see projekteerimisdokumenti kleepida:

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

Üks ühenduse ressurss võib kanda rohkem kui ühte alus tunnelit, seega neli tunnelit ei tähenda nelja virtuaalvõrgu lüüsi. Kaks Azure'i avalikku IP-d ei ole samad objektid nagu kaks kohaliku võrgu lüüsi, mis kirjeldavad kaugemat saidi.

Mida aktiiv-aktiiv Azure'i poolel lisab

Aktiiv-aktiiv muudab Azure'i lüüsi ühest aktiivsest eksemplarist kaheks, kummalgi oma avalik IP, ja just see teeb täieliku võrgu üldse võimalikuks. See ei kahekordista ühe voolu läbilaskevõimet. See ei kõrvalda ka vajadust, et kohalik pool toetaks võrdse kuluga mitmikteed, kui mõlemad seadmed edastavad korraga. Enne millegi seadistamist kinnitage lüüsi režiim, SKU ja kaugema seadme võimekus.

Passiivse ooterežiimiga lüüs on täiesti kehtiv lahendus; see annab lihtsalt teistsuguse tunnelite arvu.

BGP muudab mõlemad teed kasutatavaks

Mitme seadme lahenduse puhul käitavad mõlemad kohalikud seadmed BGP-d. Andke kummalelegi unikaalne BGP-peeri aadress ja kuulutage samu kavandatud privaatseid prefikseid asjakohastel teedel. Privaatsed prefiksid tähistavad kaitstud võrke, avalikud aadressid aga seda, kus krüpteeritud kandjaühendused lõpevad. Nende kahe segamine annab lahenduse, kus iga tunnel on üleval ja marsruudid on valed.

Planeerige tagasitee marsruutimine ja igasugune olekupõhine kontroll, mis peab taluma kumbagi teed. Terve IKE-sessioon igas lõpp-punktis ei tõesta, et töökoormus saab kasutada iga kuulutatud marsruuti.

Voolupõhine valik ei ole ribalaiuse ühendamine

Azure valib iga voolu jaoks tee, kasutades räsi voolu aadresside ja portide põhjal. Püsiolekus liiguvad antud TCP- või UDP-voolu paketid tavaliselt sama tunneliga ning kohalik pool võib tagasisuunaks valida teise tunneli. Seega parandavad kaks seadet ja neli tunnelit käideldavust, mitte ühe ülekande kiirust. Kui müüja slaid lubab liitmist, kirjeldab see teist funktsiooni või arusaamatust.

Testige paralleelsete vooludega, kui tahate näha teede jaotumist, ja ühe vooluga, kui tahate näha piiri.

Millise liiasuse te tegelikult eemaldasite

Kaks WAN-aadressi ühel seadmel parandavad juurdepääsulingi valikuid, kuid jagavad selle seadme toidet, tarkvara ja rikkeolekut. Need ei ole sama mis kaks seadet ja ükski Azure'i-poolne konfiguratsioon ei muuda seda. Järgige müüja toetatud kahe WAN-i või klastri lahendust, selle asemel et tuletada liiasus aadresside arvust. Seejärel testige: eemaldage korraga üks tee ja kinnitage allesjäänud marsruudid ning tegelik rakenduse vahetus mõlemas suunas.

Oodake tuvastamise ja koondumise viivitusi ning oodake, et mõned olemasolevad sessioonid lõpevad.