Du vietiniai VPN adresai: du Azure partneriai, o ne vienas

Diagramoje filiale yra dvi interneto jungtys ir viena Azure VPN tarpinė, todėl vietinio tinklo tarpinė gauna abu viešuosius adresus. Tai atrodo tvarkingai ir neveikia taip, kaip diagrama leidžia suprasti. Kiekvienas vietinis VPN įrenginys yra atskiras partnerio ryšys, o Microsoft kelių įrenginių dizainas kiekvienam suteikia savo vietinio tinklo tarpinės išteklių ir savo jungtį. Antrojo adreso pridėjimas prie vieno ištekliaus nesukuria antrojo partnerio. Jis sukuria išteklių, kuris tinkamai neaprašo nė vieno įrenginio.

Mitas: viena tarpinė, du adresai

Vietinio tinklo tarpinė yra nuotolinio partnerio aprašymas: vienas viešasis galinis taškas ir už jo esantys privatūs priešdėliai. Nėra palaikomo būdo, kaip šis išteklius galėtų reikšti „bet kuris iš šių dviejų įrenginių“.

Tas pats sumišimas pasitaiko ir priešinga kryptimi, kai du viešieji Azure IP adresai skaitomi kaip dviejų Azure tarpinių egzistavimo įrodymas.

Suskaičiuokite objektus, tada tunelius

Paimkite du savarankiškai valdomus vietinius įrenginius, kiekvieną su savo viešuoju adresu ir prieiga prie tų pačių privačių tinklų, plius vieną maršrutais pagrįstą Azure tarpinę aktyviu-aktyviu režimu. Azure tarpinė turi dvi aktyvias instances su atskirais viešaisiais IP. Kiekvienas vietinis įrenginys jungiasi prie abiejų instancijų. Tai visas tinklas, o objektų skaičius išplaukia iš jo, o ne iš diagramos.

Aritmetika pakankamai trumpa, kad ją būtų galima įklijuoti į projektavimo dokumentą:

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

Vienas jungties išteklius gali pernešti daugiau nei vieną pagrindinį tunelį, todėl keturi tuneliai nereiškia keturių virtualaus tinklo tarpinių. Du viešieji Azure IP taip pat nėra tie patys objektai kaip dvi vietinio tinklo tarpinės, aprašančios nuotolinę vietą.

Ką aktyvus-aktyvus prideda Azure pusėje

Aktyvus-aktyvus pakeičia Azure tarpinę iš vienos aktyvios instancijos į dvi, kiekvieną su savo viešuoju IP, ir būtent tai apskritai leidžia visą tinklą. Tai nepadidina vieno srauto pralaidumo dvigubai. Tai taip pat nepašalina poreikio vietinei pusei palaikyti vienodos kainos kelių kelių maršrutizavimą, jei abu įrenginiai persiunčia vienu metu. Prieš ką nors paruošdami patvirtinkite tarpinės režimą, SKU ir nuotolinio įrenginio galimybes.

Pasyvios budėjimo būsenos tarpinė yra visiškai tinkamas dizainas; ji tiesiog duoda kitokį tunelių skaičių.

BGP padaro abu kelius naudojamus

Kelių įrenginių dizainui abu vietiniai įrenginiai vykdo BGP. Suteikite kiekvienam unikalų BGP partnerio adresą ir skelbkite tuos pačius numatytus privačius priešdėlius atitinkamais keliais. Privatūs priešdėliai identifikuoja apsaugotus tinklus, o viešieji adresai identifikuoja, kur baigiasi užšifruotos perdavimo jungtys. Sumaišius abu, gaunamas dizainas, kuriame visi tuneliai yra aktyvūs, o maršrutai neteisingi.

Suplanuokite grįžtamąjį maršrutizavimą ir bet kokią būsenos patikrą, kuri turi atlaikyti bet kurį iš dviejų kelių. Sveika IKE sesija kiekviename galiniame taške neįrodo, kad darbo krūvis gali naudoti kiekvieną paskelbtą maršrutą.

Srautu pagrįstas pasirinkimas nėra pralaidumo sujungimas

Azure parenka kelią kiekvienam srautui naudodama maišą per srauto adresus ir prievadus. Pastovioje būsenoje tam tikro TCP arba UDP srauto paketai paprastai eina tuo pačiu tuneliu, o vietinė pusė gali pasirinkti kitą tunelį grįžimo krypčiai. Todėl du įrenginiai ir keturi tuneliai pagerina prieinamumą, o ne vieno perdavimo greitį. Kai pardavėjo skaidrė žada sujungimą, ji aprašo kitą funkciją arba nesusipratimą.

Išbandykite su lygiagrečiais srautais, jei norite pamatyti, kaip keliai pasiskirsto, ir su vienu srautu, jei norite pamatyti ribą.

Kokią pertekliškumą iš tikrųjų pašalinote

Du WAN adresai viename įrenginyje pagerina prieigos jungties parinktis, bet dalijasi to įrenginio maitinimu, programine įranga ir gedimo būsena. Jie nėra tas pats kaip du įrenginiai, ir jokia Azure pusės konfigūracija to nepakeis. Vadovaukitės pardavėjo palaikomu dviejų WAN arba klasterio dizainu, o ne darykite pertekliškumo išvadą iš adresų skaičiaus. Tada išbandykite: pašalinkite po vieną kelią ir patvirtinkite likusius maršrutus bei realų programos mainus abiem kryptimis.

Tikėkitės aptikimo ir konvergencijos vėlavimų ir tikėkitės, kad kai kurios esamos sesijos pasibaigs.