Unu Azure VM bezonas la tunelon: gastkliento aŭ VPN-pordego?
Tri kondiĉoj decidas, ĉu unu sola Azure VM funkciigu sian propran VPN-klienton, aŭ ĉu la konekto apartenas anstataŭe al la reta tavolo.
Unu laborŝarĝo en unu Azure VM devas atingi privatan reton tra tunelo. La demando, kiu decidas la dezajnon, ne estas, kiu VPN-produkto estas pli bona; ĝi estas, ĉu iu alia maŝino iam bezonos tiun vojon. Respondu tion unue kaj la resto de la arkitekturo kutime elektas sin mem. Se vi eraras, vi heredas VM, kiu silente fariĝis enkursigilo, kiun neniu dokumentis.
Du taskoj, kiuj aspektas similaj
VM povas esti finpunkto aŭ transita punkto, kaj la diferenco ne estas la programaro, kiun vi instalas, sed kiu konsumas la tunelon. Kiel finpunkto, la gasto funkciigas klienton por siaj propraj procezoj. Kiel transita punkto, ĝi plusendas pakaĵojn de aliaj laborŝarĝoj, kio igas ĝin parto de via reta topologio.
| Tasko | Kion faras la VM | Kiu posedas enkursigadon |
|---|---|---|
| Finpunkto de laborŝarĝo | Funkciigas subtenatan klienton por siaj propraj procezoj | Gastaj itineroj elektas la aprobitajn celojn |
| Transita aparato | Plusendas aliajn laborŝarĝojn en la ejan konekton | Subretaj itinertabeloj, NIC-plusendo, gasta politiko kaj revenaj vojoj |
La plej multaj petoj pri unu VM estas la unua tasko en la lingvaĵo de la dua. Iu diras “la VM estas nia VPN” kiam li volas diri, ke unu aplikaĵo sur ĝi devas atingi datumbazon ĉe la alia flanko.
Kondiĉo unu: ĉu io alia bezonas la malproksiman flankon?
Se la respondo estas ne, instaligu la klienton en la gasto kaj ĉesu dezajni. Nenio en tiu elekto postulas la administritan pordegon, kaj nenio en ĝi igas la VM pordego por siaj najbaroj. Vi aldonas itinero ene de unu operaciumo.
Se la respondo estas jes, aŭ verŝajne jes ene de jaro, traktu ĝin nun kiel retan dezajnon. Aliaj VM-oj atingas transitan VM nur kiam la subreta itinertabelo sendas ilin tien kaj la NIC akceptas plusenditan trafikon, do la laboro estas itinertabeloj kaj plusendaj permesoj, ne alia klientinstalaĵo.
Kondiĉo du: ĉu vi povas konservi la administran vojon?
VPN-kliento, kiu instalas larĝan itinero, povas kapti la vojon, per kiu vi administras la VM. Se la cellisto de la tunelo koincidas kun la administra reto, via SSH- aŭ RDP-seaio falas en la momento, kiam la kliento konektiĝas, kaj la riparo devas esti aplikata per la seria konzolo aŭ per rekonstruo.
Kontrolu antaŭe kaj poste. En Linux, ip route get <management-ip> montras, kiun interfacon kaj fonton la kerno uzus nun; komparu tion kun la respondo dum la tunelo estas aktiva. Dividita tunelo kun eksplicita cellisto estas pli facile defendebla ol apriora itinero, kaj kutime ĝi estas tio, kion la laborŝarĝo vere bezonas.
Kondiĉo tri: kiu flikas ĝin noktomeze?
Gastkliento signifas vian operaciumon, vian klientversion kaj viajn atestilojn. Tio estas en ordo, se vi jam funkciigas la VM kaj ĝian flikan ciklon. Ĝi estas malbona interŝanĝo, se la VM ekzistas nur por teni la tunelon. Kalkulu la flikajn horojn antaŭ ol nomi la gastklienton pli malmultekosta. Klienta ĝisdatigo, kiu postulas restarton, estas interrompo, kiun vi planis por maŝino, kiu ekzistas por teni la tunelon funkcianta.
La administrita pordego movas tiun prizorgon al la platformo. Vi ankoraŭ posedas identecon, rajtigon kaj la retajn vojojn malantaŭ ĝi, sed vi ne restartas maŝinon por apliki klientan ĝisdatigon.
Kion la administrita pordego ne faras
Azure VPN Gateway estas VNet-konekteca servo kun propraj interkonsentoj loko-al-loko kaj punkto-al-loko. Ĝi ne estas regulo, kiu malpermesas gastan VPN-programaron, kaj ĝi ne estas rekta anstataŭaĵo por kliento, kiun unu aplikaĵo bezonas.
Kion ĝi donas estas konekto ĉe la reta tavolo, atingebla de multaj laborŝarĝoj per enkursigado. Kion ĝi ne donas estas tunelo, kiun uzas nur unu procezo sur unu VM, limigita al la identeco de tiu procezo. Tiu limigo ne estas manko, por kiu oni pardonpetu; ĝi estas la senco de la gastklienta dezajno. Unu aplikaĵo, unu itinero, unu aro da akreditaĵoj, neniu efiko al la aliaj VM-oj en la subreto.
Do la komparo ne estas administrita kontraŭ programaro. Ĝi estas retskala konekteco kontraŭ proces-skala konekteco, kaj la dua estas legitima kiam nur unu procezo bezonas ĝin.
Planu la kreskan vojon antaŭ ol vi bezonos ĝin
Se la postulo kreskas de unu VM al subreto, rekonstruu la dezajnon anstataŭ larĝigi la permesitajn prefiksojn de la kliento. Reuzi oportunajn seancon kiel nedokumentitan enkursigilon ligas ĉiun konsumanton al la vivdaŭro de tiu VM, ĝiaj akreditaĵoj kaj ĝia flika fenestro.
La ĝusta deirpunkto, post kiam la konekto estas retskala anstataŭ laborŝarĝa, estas la superrigardo de Azure VPN Gateway.
Antaŭ ol elekti, skribu tri liniojn: kio bezonas la malproksiman flankon, kiu administras la VM, kaj kiu flikas la tunelon. Se ĉiuj tri respondoj montras al unu laborŝarĝo, gastkliento estas la honesta dezajno. Se iu el ili montras al subreto, desegnu la retan tavolon nun.