En Azure VM behöver tunneln: gästklient eller VPN-gateway?

En arbetsbelastning i en Azure VM måste nå ett privat nätverk genom en tunnel. Frågan som avgör designen är inte vilken VPN-produkt som är bättre, utan om någon annan maskin någonsin kommer att behöva den vägen. Svara på det först och resten av arkitekturen väljer sig oftast själv. Går det fel ärver du en VM som tyst blev en router som ingen dokumenterade.

Två jobb som ser likadana ut

En VM kan vara en ändpunkt eller en transitpunkt, och skillnaden är inte programvaran du installerar utan vem som använder tunneln. Som ändpunkt kör gästen en klient för sina egna processer. Som transitpunkt vidarebefordrar den paket från andra arbetsbelastningar, vilket gör den till en del av din nätverkstopologi.

De flesta förfrågningar om en enda VM är det första jobbet i den andras språk. Någon säger ”VM:en är vår VPN” när de menar att en applikation på den måste nå en databas på andra sidan.

Villkor ett: behöver något annat den bortre sidan?

Om svaret är nej, installera klienten i gästen och sluta designa. Inget i det valet kräver den hanterade gatewayen, och inget i det gör VM:en till en gateway för sina grannar. Du lägger till en rutt inuti ett operativsystem.

Om svaret är ja, eller troligen ja inom ett år, behandla det som en nätverksdesign nu. Andra VM:ar når bara en transit-VM när subnätets routtabell skickar dem dit och NIC:en accepterar vidarebefordrad trafik, så arbetet är routtabeller och vidarebefordringsbehörigheter, inte ännu en klientinstallation.

Villkor två: kan du behålla administrationsvägen?

En VPN-klient som installerar en bred rutt kan fånga upp vägen du använder för att administrera VM:en. Om tunnelns destinationslista överlappar administrationsnätet tappar din SSH- eller RDP-session anslutningen i samma stund som klienten ansluter, och rättelsen måste göras via seriekonsolen eller en återuppbyggnad.

Kontrollera före och efter. På Linux visar ip route get <management-ip> vilket gränssnitt och vilken källa kärnan skulle använda just nu; jämför det med svaret medan tunneln är uppe. En delad tunnel med en uttrycklig destinationslista är lättare att försvara än en standardrutt, och det är oftast vad arbetsbelastningen faktiskt behöver.

Villkor tre: vem patchar den vid midnatt?

En gästklient är ditt operativsystem, din klientversion och dina certifikat. Det är bra när du redan driftar VM:en och dess patchcykel. Det är en dålig affär när VM:en bara finns för att hålla tunneln. Räkna patch-timmarna innan du kallar gästklienten billigare. En klientuppgradering som kräver omstart är ett avbrott du själv har planerat för en maskin som finns för att hålla tunneln uppe.

Den hanterade gatewayen flyttar det underhållet till plattformen. Du äger fortfarande identitet, auktorisering och nätverksvägarna bakom den, men du startar inte om en maskin för att tillämpa en klientuppdatering.

Vad den hanterade gatewayen inte gör

Azure VPN Gateway är en VNet-anslutningstjänst med egna plats-till-plats- och punkt-till-punkt-lösningar. Den är inte en regel som förbjuder VPN-programvara i gästen, och den är inte en direkt ersättning för en klient som en applikation behöver.

Det den ger är en anslutning på nätverkslagret, nåbar för många arbetsbelastningar via routning. Det den inte ger är en tunnel som bara en process på en VM använder, begränsad till den processens identitet. Den begränsningen är inte en brist man måste be om ursäkt för; det är precis poängen med gästklientdesignen. En applikation, en rutt, en uppsättning autentiseringsuppgifter, ingen effekt på de andra VM:arna i subnätet.

Jämförelsen är alltså inte hanterat mot programvara. Det är nätverksomfattande anslutning mot processomfattande anslutning, och den andra är legitim när bara en process behöver den.

Planera tillväxtvägen innan du behöver den

Om kravet växer från en VM till ett subnät, bygg om designen i stället för att bredda klientens tillåtna prefix. Att återanvända en bekväm session som en odokumenterad router binder varje användare till den VM:ens livstid, dess autentiseringsuppgifter och dess patchfönster.

Rätt utgångspunkt, när anslutningen är nätverksomfattande snarare än arbetsbelastningsomfattande, är översikten över Azure VPN Gateway.

Skriv tre rader innan du väljer: vad behöver den bortre sidan, vem administrerar VM:en och vem patchar tunneln. Om alla tre svaren pekar på en arbetsbelastning är en gästklient den ärliga designen. Om något av dem pekar på ett subnät, designa nätverkslagret nu.