Eine Azure-VM braucht den Tunnel: Gastclient oder VPN Gateway?
Drei Bedingungen entscheiden, ob eine einzelne Azure-VM ihren eigenen VPN-Client betreiben sollte oder ob die Verbindung stattdessen in die Netzwerkschicht gehört.
Eine Workload in einer Azure-VM muss ein privates Netzwerk über einen Tunnel erreichen. Die Frage, die das Design entscheidet, ist nicht, welches VPN-Produkt besser ist, sondern ob jemals eine andere Maschine diesen Pfad brauchen wird. Beantwortet man das zuerst, ergibt sich der Rest der Architektur meist von selbst. Macht man es falsch, erbt man eine VM, die still zu einem Router wurde, den niemand dokumentiert hat.
Zwei Jobs, die ähnlich aussehen
Eine VM kann Endpunkt oder Transitpunkt sein, und der Unterschied liegt nicht in der installierten Software, sondern darin, wer den Tunnel nutzt. Als Endpunkt betreibt der Gast einen Client für seine eigenen Prozesse. Als Transitpunkt leitet er die Pakete anderer Workloads weiter, womit er Teil Ihrer Netzwerktopologie wird.
| Aufgabe | Was die VM tut | Wer das Routing verantwortet |
|---|---|---|
| Workload-Endpunkt | Betreibt einen unterstützten Client für die eigenen Prozesse | Gast-Routen wählen die freigegebenen Ziele |
| Transit-Appliance | Leitet andere Workloads in die Standortverbindung weiter | Subnetz-Routentabellen, NIC-Weiterleitung, Gastrichtlinie und Rückwege |
Die meisten Anfragen für eine einzelne VM sind der erste Job im Sprachgewand des zweiten. Jemand sagt „die VM ist unser VPN“, meint aber, dass eine Anwendung darauf eine Datenbank auf der anderen Seite erreichen muss.
Bedingung eins: Braucht sonst noch etwas die Gegenseite?
Lautet die Antwort nein, installieren Sie den Client im Gast und hören Sie mit dem Entwerfen auf. Nichts an dieser Wahl verlangt das verwaltete Gateway, und nichts daran macht die VM zu einem Gateway für ihre Nachbarn. Sie fügen eine Route innerhalb eines Betriebssystems hinzu.
Lautet die Antwort ja, oder wahrscheinlich ja innerhalb eines Jahres, behandeln Sie es jetzt als Netzwerkdesign. Andere VMs erreichen eine Transit-VM nur, wenn die Subnetz-Routentabelle sie dorthin schickt und die NIC weitergeleiteten Datenverkehr annimmt; die Arbeit besteht also aus Routentabellen und Weiterleitungsberechtigungen, nicht aus einer weiteren Client-Installation.
Bedingung zwei: Können Sie den Administrationspfad behalten?
Ein VPN-Client, der eine breite Route installiert, kann den Pfad vereinnahmen, über den Sie die VM administrieren. Überschneidet sich die Zielliste des Tunnels mit dem Managementnetz, bricht Ihre SSH- oder RDP-Sitzung in dem Moment ab, in dem der Client verbindet, und die Korrektur muss über die serielle Konsole oder einen Neuaufbau erfolgen.
Prüfen Sie vorher und nachher. Unter Linux zeigt ip route get <management-ip>, welche Schnittstelle und Quelle der Kernel gerade verwenden würde; vergleichen Sie das mit der Antwort, während der Tunnel aktiv ist. Ein Split-Tunnel mit expliziter Zielliste ist leichter zu begründen als eine Default-Route, und meist ist es das, was die Workload tatsächlich braucht.
Bedingung drei: Wer patcht um Mitternacht?
Ein Gastclient bedeutet: Ihr Betriebssystem, Ihre Client-Version und Ihre Zertifikate. Das ist in Ordnung, wenn Sie die VM ohnehin betreiben und ihren Patchzyklus haben. Ein schlechtes Geschäft ist es, wenn die VM nur existiert, um den Tunnel zu halten. Zählen Sie die Patchstunden, bevor Sie den Gastclient als günstiger bezeichnen. Ein Client-Upgrade, das einen Neustart braucht, ist eine Ausfallzeit, die Sie für eine Maschine eingeplant haben, die den Tunnel aufrechterhalten soll.
Das verwaltete Gateway verlagert diese Wartung auf die Plattform. Identität, Autorisierung und die Netzwerkpfade dahinter bleiben Ihre Sache, aber Sie starten keine Maschine neu, um ein Client-Update einzuspielen.
Was das verwaltete Gateway nicht leistet
Azure VPN Gateway ist ein Konnektivitätsdienst für VNets mit eigenen Site-to-Site- und Point-to-Site-Varianten. Es ist keine Vorschrift, die VPN-Software im Gast verbietet, und kein direkter Ersatz für einen Client, den eine einzelne Anwendung braucht.
Es liefert eine Verbindung auf der Netzwerkschicht, die viele Workloads über Routing erreichen. Es liefert keinen Tunnel, den nur ein Prozess auf einer VM nutzt und der auf die Identität dieses Prozesses beschränkt ist. Diese Beschränkung ist kein Mangel, für den man sich entschuldigen müsste; sie ist der Kern des Gastclient-Designs. Eine Anwendung, eine Route, ein Satz Anmeldedaten, keine Auswirkung auf die anderen VMs im Subnetz.
Der Vergleich lautet also nicht verwaltet gegen Software, sondern netzwerkweite Konnektivität gegen prozessbezogene Konnektivität, und Letztere ist legitim, wenn nur ein Prozess sie braucht.
Planen Sie den Wachstumspfad, bevor Sie ihn brauchen
Wächst die Anforderung von einer VM auf ein Subnetz, entwerfen Sie das Design neu, statt die erlaubten Präfixe des Clients zu erweitern. Eine bequeme Sitzung als undokumentierten Router weiterzuverwenden, bindet jeden Nutzer an die Lebensdauer dieser VM, ihre Anmeldedaten und ihr Patchfenster.
Die Übersicht zu Azure VPN Gateway ist der richtige Ausgangspunkt, sobald die Verbindung netzwerkweit statt workloadbezogen ist.
Schreiben Sie vor der Wahl drei Zeilen: Was braucht die Gegenseite, wer administriert die VM, und wer patcht den Tunnel. Zeigen alle drei Antworten auf eine Workload, ist ein Gastclient das ehrliche Design. Zeigt eine davon auf ein Subnetz, entwerfen Sie jetzt die Netzwerkschicht.