Én Azure VM skal have tunnelen: gæsteklient eller VPN-gateway?
Tre betingelser afgør, om en enkelt Azure VM skal køre sin egen VPN-klient, eller om forbindelsen snarere hører til på netværkslaget.
Én arbejdsbyrde i én Azure VM skal nå et privat netværk gennem en tunnel. Spørgsmålet, der afgør designet, er ikke, hvilket VPN-produkt der er bedst, men om nogen anden maskine nogensinde får brug for den vej. Svar på det først, og resten af arkitekturen vælger sig normalt selv. Går det galt, arver du en VM, der stille blev en router, som ingen dokumenterede.
To opgaver, der ligner hinanden
En VM kan være et endepunkt eller et transitpunkt, og forskellen er ikke softwaren, du installerer, men hvem der bruger tunnelen. Som endepunkt kører gæsten en klient til sine egne processer. Som transitpunkt videresender den andre arbejdsbyrders pakker, hvilket gør den til en del af din netværkstopologi.
| Opgave | Hvad VM'en gør | Hvem ejer routing |
|---|---|---|
| Endepunkt for arbejdsbyrde | Kører en understøttet klient til sine egne processer | Gæstens ruter vælger de godkendte destinationer |
| Transitapparat | Videresender andre arbejdsbyrder til siteforbindelsen | Rutetabeller for undernet, NIC-videresendelse, gæstepolitik og returveje |
De fleste anmodninger om en enkelt VM er den første opgave i den andens sprog. Nogen siger “VM'en er vores VPN”, når de mener, at én applikation på den skal nå en database på den anden side.
Betingelse et: har noget andet brug for den fjerne side?
Er svaret nej, så installer klienten i gæsten og hold op med at designe. Intet ved det valg kræver den administrerede gateway, og intet ved det gør VM'en til en gateway for dens naboer. Du tilføjer en rute inde i ét operativsystem.
Er svaret ja, eller sandsynligvis ja inden for et år, så behandl det som et netværksdesign nu. Andre VM'er når kun en transit-VM, når undernets rutetabel sender dem derhen, og NIC'en accepterer videresendt trafik, så arbejdet er rutetabeller og videresendelsestilladelser, ikke endnu en klientinstallation.
Betingelse to: kan du beholde administrationsvejen?
En VPN-klient, der installerer en bred rute, kan fange den vej, du administrerer VM'en ad. Hvis tunnelens destinationsliste overlapper administrationsnettet, falder din SSH- eller RDP-session i det øjeblik, klienten forbinder, og rettelsen skal anvendes via seriekonsollen eller en genopbygning.
Kontroller før og efter. På Linux viser ip route get <management-ip> hvilken grænseflade og kilde kernen ville bruge lige nu; sammenlign det med svaret, mens tunnelen er oppe. En delt tunnel med en eksplicit destinationsliste er lettere at forsvare end en standardrute, og det er normalt det, arbejdsbyrden faktisk har brug for.
Betingelse tre: hvem patcher den ved midnat?
En gæsteklient er dit operativsystem, din klientversion og dine certifikater. Det er fint, når du allerede driver VM'en og dens patchcyklus. Det er en dårlig handel, når VM'en kun findes for at holde tunnelen. Tæl patch-timerne, før du kalder gæsteklienten billigere. En klientopgradering, der kræver genstart, er et nedbrud, du har planlagt for en maskine, der findes for at holde tunnelen oppe.
Den administrerede gateway flytter den vedligeholdelse til platformen. Du ejer stadig identitet, autorisation og netværksvejene bag den, men du genstarter ikke en maskine for at anvende en klientopdatering.
Hvad den administrerede gateway ikke gør
Azure VPN Gateway er en VNet-forbindelsestjeneste med sine egne site-to-site- og point-to-site-arrangementer. Den er ikke en regel, der forbyder VPN-software i gæsten, og den er ikke en direkte erstatning for en klient, som én applikation har brug for.
Det, den giver, er en forbindelse på netværkslaget, som mange arbejdsbyrder kan nå via routing. Det, den ikke giver, er en tunnel, som kun én proces på én VM bruger, afgrænset til den proces' identitet. Den afgrænsning er ikke en begrænsning, man skal undskylde; det er hele pointen med gæsteklientdesignet. Én applikation, én rute, ét sæt legitimationsoplysninger, ingen effekt på de andre VM'er i undernettet.
Sammenligningen er altså ikke administreret mod software. Det er netværksafgrænset forbindelse mod procesafgrænset forbindelse, og den anden er legitim, når kun én proces har brug for den.
Planlæg vækstvejen, før du får brug for den
Hvis kravet vokser fra én VM til et undernet, så byg designet om i stedet for at udvide klientens tilladte præfikser. Genbrug af en bekvem session som en udokumenteret router binder hver bruger til den VM's levetid, dens legitimationsoplysninger og dens patchvindue.
Det rigtige udgangspunkt, når forbindelsen er netværksafgrænset snarere end arbejdsbyrdeafgrænset, er oversigten over Azure VPN Gateway.
Skriv tre linjer, før du vælger: hvad har brug for den fjerne side, hvem administrerer VM'en, og hvem patcher tunnelen. Hvis alle tre svar peger på én arbejdsbyrde, er en gæsteklient det ærlige design. Hvis bare ét af dem peger på et undernet, så design netværkslaget nu.