Éin Azure VM treng tunnelen: gjesteklient eller VPN-gateway?
Tre vilkår avgjer om éin einaste Azure VM skal køyre sin eigen VPN-klient, eller om sambandet heller høyrer til på nettverkslaget.
Éi arbeidslast i éin Azure VM må nå eit privat nettverk gjennom ein tunnel. Spørsmålet som avgjer designet er ikkje kva VPN-produkt som er best, men om noka anna maskin nokon gong vil trenge den vegen. Svar på det fyrst, og resten av arkitekturen vel seg vanlegvis sjølv. Går det gale, arvar du ein VM som stille vart ein ruter ingen dokumenterte.
To jobbar som ser like ut
Ein VM kan vere eit endepunkt eller eit transittpunkt, og skilnaden er ikkje programvara du installerer, men kven som brukar tunnelen. Som endepunkt køyrer gjesten ein klient for sine eigne prosessar. Som transittpunkt sender han pakkar frå andre arbeidslaster vidare, noko som gjer han til ein del av nettverkstopologien din.
| Jobb | Kva VM-en gjer | Kven eig rutinga |
|---|---|---|
| Endepunkt for arbeidslast | Køyrer ein støtta klient for sine eigne prosessar | Rutene til gjesten vel dei godkjende destinasjonane |
| Transittapparat | Sender andre arbeidslaster vidare til nettstadssambandet | Rutetabellar for subnett, NIC-vidaresending, gjestepolicy og returvegar |
Dei fleste førespurnader om éin VM er den fyrste jobben i språket til den andre. Nokon seier «VM-en er VPN-en vår» når dei meiner at éin applikasjon på han må nå ein database på den andre sida.
Vilkår éin: treng noko anna den fjerne sida?
Er svaret nei, installer klienten i gjesten og slutt å designe. Ingenting ved det valet krev den administrerte gatewayen, og ingenting ved det gjer VM-en til ein gateway for naboane sine. Du legg til ei rute inne i eitt operativsystem.
Er svaret ja, eller truleg ja innan eitt år, handsam det som eit nettverksdesign no. Andre VM-ar når berre ein transitt-VM når rutetabellen til subnettet sender dei dit og NIC-en godtek vidaresendt trafikk, så arbeidet er rutetabellar og vidaresendingløyve, ikkje nok ein klientinstallasjon.
Vilkår to: kan du halde på administrasjonsvegen?
Ein VPN-klient som installer ei brei rute, kan fange vegen du brukar til å administrere VM-en. Viss destinasjonslista til tunnelen overlappar administrasjonsnettet, fell SSH- eller RDP-økta di i det augneblinken klienten koplar til, og rettinga må leggjast inn via seriekonsollen eller ein gjenoppbygging.
Kontroller før og etter. På Linux viser ip route get <management-ip> kva grensesnitt og kva kjelde kjernen ville bruke akkurat no; samanlikn det med svaret medan tunnelen er oppe. Ein delt tunnel med ei eksplisitt destinasjonsliste er lettare å forsvare enn ei standardrute, og det er vanlegvis det arbeidslasta faktisk treng.
Vilkår tre: kven patchar han ved midnatt?
Ein gjesteklient er operativsystemet ditt, klientversjonen din og sertifikata dine. Det er greitt når du alt driftar VM-en og patch-syklusen hans. Det er ein dårleg byttehandel når VM-en berre finst for å halde tunnelen. Tel patch-timane før du kallar gjesteklienten billegare. Ei klientoppgradering som krev omstart, er eit avbrot du sjølv har planlagt for ein maskin som finst for å halde tunnelen oppe.
Den administrerte gatewayen flyttar det vedlikehaldet til plattforma. Du eig framleis identitet, autorisasjon og nettverksvegane bak han, men du startar ikkje om ein maskin for å leggje inn ein klientoppdatering.
Kva den administrerte gatewayen ikkje gjer
Azure VPN Gateway er ein VNet-tilkoplings-teneste med eigne ordningar for nettstad-til-nettstad og punkt-til-punkt. Han er ikkje ei regel som forbyr VPN-programvare i gjesten, og han er ikkje ein direkte erstattar for ein klient som éin applikasjon treng.
Det han gjev, er eit samband på nettverkslaget, nåbart for mange arbeidslaster gjennom ruting. Det han ikkje gjev, er ein tunnel som berre éin prosess på éin VM brukar, avgrensa til identiteten til den prosessen. Den avgrensinga er ikkje ei avgrensing ein må be om orsaking for; det er nettopp poenget med gjesteklientdesignet. Éin applikasjon, éi rute, eitt sett legitimasjon, ingen verknad på dei andre VM-ane i subnettet.
Samanlikninga er altså ikkje administrert mot programvare. Det er nettverksavgrensa tilkopling mot prosessavgrensa tilkopling, og den andre er legitim når berre éin prosess treng han.
Planlegg vekstvegen før du treng han
Viss kravet veks frå éin VM til eit subnett, bygg designet på nytt i staden for å utvide dei tillatne prefiksa til klienten. Å bruke om att ei praktisk økt som ein udokumentert ruter knyter kvar brukar til levetida til den VM-en, legitimasjonen hans og patch-vindauget hans.
Det rette utgangspunktet, når sambandet er nettverksavgrensa snarare enn arbeidslastavgrensa, er oversynet over Azure VPN Gateway.
Skriv tre linjer før du vel: kva treng den fjerne sida, kven administrerer VM-en, og kven patchar tunnelen. Viss alle tre svara peikar på éi arbeidslast, er ein gjesteklient det ærlege designet. Viss noko av dei peikar på eit subnett, design nettverkslaget no.