Vienam Azure VM reikia tunelio: svečio klientas ar VPN šliuzas?
Trys sąlygos nusprendžia, ar vienas Azure VM turi paleisti savo VPN klientą, ar ryšys labiau priklauso tinklo sluoksniui.
Viena darbo apkrova viename Azure VM turi pasiekti privatų tinklą per tunelį. Projektą lemiantis klausimas nėra tai, kuris VPN produktas geresnis, o tai, ar kada nors kitai mašinai prireiks šio kelio. Atsakykite į tai pirmiausia ir likusi architektūros dalis dažniausiai išsirenka pati. Suklydę paveldėsite VM, kuri tyliai tapo maršrutizatoriumi, kurio niekas nedokumentavo.
Dvi užduotys, kurios atrodo vienodai
VM gali būti galinis taškas arba tranzito taškas, ir skirtumas ne įdiegtoje programinėje įrangoje, o tame, kas naudoja tunelį. Kaip galinis taškas, svečias paleidžia klientą savo procesams. Kaip tranzito taškas, jis persiunčia kitų darbo apkrovų paketus, todėl tampa jūsų tinklo topologijos dalimi.
| Užduotis | Ką daro VM | Kam priklauso maršrutizavimas |
|---|---|---|
| Darbo apkrovos galinis taškas | Paleidžia palaikomą klientą savo procesams | Svečio maršrutai parenka patvirtintas paskirties vietas |
| Tranzito įrenginys | Persiunčia kitas darbo apkrovas į svetainės ryšį | Potinklio maršrutų lentelės, NIC persiuntimas, svečio politika ir grįžimo keliai |
Dauguma vieno VM prašymų yra pirmoji užduotis antrosios užduoties kalba. Kažkas sako „VM yra mūsų VPN“, o iš tikrųjų nori pasakyti, kad vienai joje esančiai programai reikia pasiekti duomenų bazę kitoje pusėje.
Sąlyga pirma: ar dar kažkam reikia tolimosios pusės?
Jei atsakymas ne, įdiekite klientą svečio aplinkoje ir nustokite projektuoti. Niekas tame pasirinkime nereikalauja valdomo šliuzo ir niekas nepaverčia VM šliuzu jos kaimynams. Jūs pridedate maršrutą vienoje operacinėje sistemoje.
Jei atsakymas taip, arba greičiausiai taip per metus, traktuokite tai kaip tinklo projektą dabar. Kitos VM pasiekia tranzito VM tik tada, kai potinklio maršrutų lentelė nusiunčia jas ten ir NIC priima persiųstą srautą, todėl darbas yra maršrutų lentelės ir persiuntimo leidimai, o ne dar vienas kliento diegimas.
Sąlyga antra: ar galite išsaugoti administravimo kelią?
VPN klientas, įdiegiantis platų maršrutą, gali užvaldyti kelią, kuriuo administruojate VM. Jei tunelio paskirties sąrašas sutampa su valdymo tinklu, jūsų SSH arba RDP sesija nutrūksta tą akimirką, kai klientas prisijungia, o taisymą reikia atlikti per nuosekliąją konsolę arba perstatant.
Patikrinkite prieš ir po. Linux sistemoje ip route get <management-ip> parodo, kurią sąsają ir šaltinį branduolys naudotų dabar; palyginkite tai su atsakymu, kol tunelis veikia. Padalintas tunelis su aiškiu paskirties sąrašu lengviau apginamas nei numatytasis maršrutas, ir paprastai tai yra tai, ko darbo apkrovai iš tikrųjų reikia.
Sąlyga trečia: kas ją pleistruoja vidurnaktį?
Svečio klientas yra jūsų operacinė sistema, jūsų kliento versija ir jūsų sertifikatai. Tai gerai, kai jau valdote VM ir jos pleistrų ciklą. Tai blogas sandoris, kai VM egzistuoja tik tuneliui išlaikyti. Suskaičiuokite pleistravimo valandas prieš pavadindami svečio klientą pigesniu. Kliento atnaujinimas, kuriam reikia perkrovimo, yra pertrauka, kurią suplanavote mašinai, egzistuojančiai tam, kad tunelis liktų prijungtas.
Valdomas šliuzas perkelia tą priežiūrą į platformą. Jūs vis dar valdote tapatybę, autorizaciją ir už jo esančius tinklo kelius, bet neperkraunate mašinos, kad pritaikytumėte kliento atnaujinimą.
Ko valdomas šliuzas nedaro
Azure VPN Gateway yra VNet jungiamumo paslauga su savo svetainės į svetainę ir taško į tašką sprendimais. Tai nėra taisyklė, draudžianti VPN programinę įrangą svečio aplinkoje, ir tai nėra tiesioginis pakaitalas kliento, kurio reikia vienai programai.
Ką ji duoda, tai ryšys tinklo sluoksnyje, pasiekiamas daugeliui darbo apkrovų per maršrutizavimą. Ko ji neduoda, tai tunelio, kurį naudoja tik vienas procesas viename VM ir kuris apribotas to proceso tapatybe. Šis apribojimas nėra trūkumas, už kurį reikėtų atsiprašinėti; būtent tai yra svečio kliento projekto esmė. Viena programa, vienas maršrutas, vienas prisijungimo duomenų rinkinys, jokio poveikio kitiems potinklio VM.
Taigi palyginimas nėra valdoma prieš programinę įrangą. Tai tinklo masto jungiamumas prieš proceso masto jungiamumą, o antrasis yra teisėtas, kai jo reikia tik vienam procesui.
Suplanuokite augimo kelią prieš jam prireikiant
Jei poreikis išauga nuo vieno VM iki potinklio, perstatykite projektą, o neplėskite leidžiamų kliento prefiksų. Patogios sesijos naudojimas kaip nedokumentuoto maršrutizatoriaus pririša kiekvieną naudotoją prie to VM gyvavimo trukmės, jo prisijungimo duomenų ir jo pleistrų lango.
Tinkamas atspirties taškas, kai ryšys tampa tinklo, o ne darbo apkrovos masto, yra „Azure VPN Gateway“ apžvalga.
Prieš rinkdamiesi, parašykite tris eilutes: kam reikia tolimosios pusės, kas administruoja VM ir kas pleistruoja tunelį. Jei visi trys atsakymai nurodo vieną darbo apkrovą, svečio klientas yra sąžiningas projektas. Jei bent vienas jų nurodo potinklį, projektuokite tinklo sluoksnį dabar.