Eén Azure VM heeft de tunnel nodig: gastclient of VPN-gateway?
Drie voorwaarden bepalen of één Azure VM zijn eigen VPN-client moet draaien of dat de verbinding eerder op de netwerklaag thuishoort.
Eén workload in één Azure VM moet via een tunnel een privénetwerk bereiken. De vraag die het ontwerp bepaalt is niet welk VPN-product beter is, maar of ooit een andere machine dat pad nodig heeft. Beantwoord dat eerst en de rest van de architectuur kiest zich meestal zelf. Ga je de fout in, dan erf je een VM die stil een router werd die niemand documenteerde.
Twee taken die op elkaar lijken
Een VM kan een eindpunt of een transietpunt zijn, en het verschil is niet de software die je installeert maar wie de tunnel gebruikt. Als eindpunt draait de gast een client voor zijn eigen processen. Als transietpunt stuurt hij pakketten van andere workloads door, waardoor hij deel wordt van je netwerktopologie.
| Taak | Wat de VM doet | Wie het routeren bezit |
|---|---|---|
| Eindpunt van workload | Draait een ondersteunde client voor zijn eigen processen | Gastroutes kiezen de goedgekeurde bestemmingen |
| Transietapparaat | Stuurt andere workloads de siteverbinding in | Subnetroutetabellen, NIC-doorsturing, gastbeleid en terugpaden |
De meeste aanvragen voor één VM zijn de eerste taak in de taal van de tweede. Iemand zegt “de VM is ons VPN” terwijl hij bedoelt dat één applicatie erop een database aan de andere kant moet bereiken.
Voorwaarde één: heeft iets anders de verre kant nodig?
Is het antwoord nee, installeer de client in de gast en stop met ontwerpen. Niets aan die keuze vereist de beheerde gateway, en niets eraan maakt de VM een gateway voor zijn buren. Je voegt een route toe binnen één besturingssysteem.
Is het antwoord ja, of waarschijnlijk ja binnen een jaar, behandel het dan nu als netwerkontwerp. Andere VM's bereiken een transiet-VM alleen wanneer de subnetroutetabel ze daarheen stuurt en de NIC doorgestuurd verkeer accepteert, dus het werk is routetabellen en doorstuurrechten, niet nog een clientinstallatie.
Voorwaarde twee: kun je het beheerpad houden?
Een VPN-client die een brede route installeert, kan het pad kapen waarmee je de VM beheert. Als de bestemmingenlijst van de tunnel overlapt met het beheernetwerk, valt je SSH- of RDP-sessie weg op het moment dat de client verbindt, en de correctie moet via de seriële console of een herbouw worden toegepast.
Controleer voor en na. Op Linux laat ip route get <management-ip> zien welke interface en bron de kernel nu zou gebruiken; vergelijk dat met het antwoord terwijl de tunnel actief is. Een gesplitste tunnel met een expliciete bestemmingenlijst is makkelijker te verdedigen dan een standaardroute, en het is meestal wat de workload echt nodig heeft.
Voorwaarde drie: wie patcht hem om middernacht?
Een gastclient is jouw besturingssysteem, jouw clientversie en jouw certificaten. Dat is prima als je de VM en zijn patchcyclus al draait. Het is een slechte ruil als de VM alleen bestaat om de tunnel te dragen. Tel de patchuren voordat je de gastclient goedkoper noemt. Een clientupgrade die een herstart vereist, is een storing die je zelf hebt gepland voor een machine die bestaat om de tunnel in de lucht te houden.
De beheerde gateway verplaatst dat onderhoud naar het platform. Je bezit nog steeds identiteit, autorisatie en de netwerkpaden erachter, maar je start geen machine opnieuw op om een clientupdate toe te passen.
Wat de beheerde gateway niet doet
Azure VPN Gateway is een VNet-connectiviteitsservice met eigen site-naar-site- en punt-naar-puntregelingen. Het is geen regel die VPN-software in de gast verbiedt, en het is geen directe vervanging voor een client die één applicatie nodig heeft.
Wat het geeft is een verbinding op de netwerklaag, bereikbaar voor veel workloads via routering. Wat het niet geeft is een tunnel die alleen één proces op één VM gebruikt, afgestemd op de identiteit van dat proces. Die afbakening is geen beperking om je voor te verontschuldigen; het is precies het punt van het gastclientontwerp. Eén applicatie, één route, één set inloggegevens, geen effect op de andere VM's in het subnet.
De vergelijking is dus niet beheerd tegen software. Het is netwerkgebonden connectiviteit tegen procesgebonden connectiviteit, en de tweede is legitiem wanneer alleen één proces die nodig heeft.
Plan het groeipad voordat je het nodig hebt
Als de behoefte groeit van één VM naar een subnet, herbouw het ontwerp dan in plaats van de toegestane prefixen van de client te verbreden. Een handige sessie hergebruiken als ongedocumenteerde router bindt elke gebruiker aan de levensduur van die VM, zijn inloggegevens en zijn patchvenster.
Het juiste startpunt, zodra de verbinding netwerkgebonden is in plaats van workloadgebonden, is het overzicht van Azure VPN Gateway.
Schrijf voor je kiest drie regels: wat heeft de verre kant nodig, wie beheert de VM, en wie patcht de tunnel. Als alle drie de antwoorden op één workload wijzen, is een gastclient het eerlijke ontwerp. Wijst een van hen op een subnet, ontwerp dan nu de netwerklaag.