Kann ein VPN-Dienst Windows-, Mac- und Linux-Desktops abdecken?

Drei Laptops in einem Team, drei verschiedene VPN-Menüs und ein Ticket, das besagt, dass die Verbindung überall außer auf dem Mac funktioniert. Der Plan hinter diesen Clients kann identisch sein, auch wenn die Menüs es nicht sind. Was übereinstimmen muss, ist enger, als die meisten Rollouts annehmen: eine Gateway-Identität, ein Anmeldetyp, ein Routensatz und eine Resolver-Richtlinie. Schreiben Sie diese vier Punkte auf, bevor jemand ein Profil exportiert, und die Plattformarbeit wird zu einer Checkliste statt zu einer Untersuchung.

Beginnen Sie mit dem Zugangsvertrag, nicht mit der Client-Datei

Der Zugangsvertrag sind fünf Zeilen, die ein Prüfer nachvollziehen kann, ohne eine Anbieterkonsole zu öffnen. Er benennt die privaten Präfixe, die erreichbar sein müssen, die internen Namen, die aufgelöst werden müssen, den Resolver, der sie beantwortet, den Verkehr, der auf dem lokalen Pfad bleiben darf, und das Gateway-Zertifikat, das der Client erwarten sollte. Alles andere im Rollout ist eine Übersetzung dieser Zeilen in ein Dateiformat.

Ein Bürobeispiel macht die Form konkret: Anwendungsserver in 10.60.0.0/16, private Namen unter corp.example, ein interner Resolver auf 10.61.0.53 und gewöhnliches Surfen auf dem Pfad, den das Gerät bereits nutzt. Der letzte Punkt ist eine Richtlinienentscheidung und kein Client-Standard, und mehrere Clients senden alles durch den Tunnel, wenn niemand etwas anderes sagt. Halten Sie den Vertrag mit Datum und Verantwortlichem fest, denn genau dieser Eintrag sagt Ihnen später, ob sich der Tunnel geändert hat oder die Richtlinie.

Wählen Sie ein Protokoll und ein Authentifizierungspaar, das Sie verteidigen können

IKEv2 mit zertifikatsbasierter Gateway-Authentifizierung und EAP für den Benutzer ist die übliche Wahl, wenn alle drei Plattformen ohne zusätzliche Software funktionieren müssen, da Windows, macOS und NetworkManager jeweils einen IKEv2-Client mitbringen. Das Problem ist, dass die Unterstützung von IKEv2 ein Etikett beschreibt, kein Funktionspaket. EAP-Methoden, hardwaregestützte Schlüssel, die Zuordnung von Zertifikat zu Konto und automatische Wiederverbindung werden pro Plattform umgesetzt. Eine Kombination, die auf zwei von drei funktioniert, ist so verbreitet, dass Sie sie annehmen sollten, bis sie getestet ist.

Testen Sie das Paar auf jeder Zielplattform, bevor der Einführungsleitfaden geschrieben wird, nicht danach. Ein Gateway, das sowohl EAP-MSCHAPv2 als auch EAP-TLS anbietet, gibt Ihnen Spielraum für einen Rückfall, sofern dieser als unterstützt dokumentiert und nicht während eines Vorfalls entdeckt wird. Zwei unterstützte Wege sind eine günstige Versicherung; ein undokumentierter dritter Weg ist ein zukünftiges Ticket.

Wenn kein einzelnes Paar alle drei Clients abdeckt, sind die ehrlichen Optionen, einen Client hinzuzufügen, ein Gateway-Profil hinzuzufügen oder die Liste der unterstützten Plattformen zu verengen. Die Zertifikatsprüfung auf der Plattform abzuschalten, die am lautesten klagt, gehört nicht dazu. Diese Änderung verwandelt eine Kompatibilitätslücke in ein Abhörrisiko, und kein späterer Schritt im Rollout repariert sie.

Bauen Sie aus dem Vertrag ein Artefakt pro Plattform

Windows nimmt ein VPNv2-Profil, geliefert per MDM oder lokal erstellt mit Add-VpnConnection plus dessen XML-Nutzlast. Was weh tut, sind Bereich und Vertrauen. Ein gerätebezogenes Profil und ein benutzerbezogenes Profil landen in verschiedenen Speichern, deshalb muss das benötigte Zertifikat im Speicher liegen, der zum gewählten Bereich passt. Eine falsche Paarung erzeugt ein Profil, das sich sauber importieren lässt und dann beim ersten Verbindungsaufbau scheitert.

macOS nimmt ein Konfigurationsprofil mit der verwalteten VPN-Nutzlast, signiert und per MDM verteilt oder für einen Piloten von Hand installiert. Identität und CA-Kette reisen als separate Nutzlasten, weshalb sich ein Profil ohne Klage installieren und trotzdem beim Verbinden scheitern kann. Prüfen Sie die Nutzlastliste, nicht nur das Installationsergebnis.

Linux hängt vom Backend hinter NetworkManager ab, und strongSwan sowie das NetworkManager-Plugin sind getrennte Pakete. Verbindungseigenschaften sind pluginspezifisch und keine allgemeinen VPN-Schlüssel, daher wird ein aus einem anderen Plugin kopierter Schlüssel oft fehlerfrei gespeichert und scheitert dann beim Aktivieren. Bauen Sie die Verbindung auf einem sauberen Image auf, um zu bestätigen, dass das Plugin dort vorhanden ist, wo es tatsächlich läuft.

Die drei Artefakte unterscheiden sich im Format, aber jedes kodiert dieselben fünf Vertragszeilen. Das ist der Test, ob ein Artefakt fertig ist: Jede Zeile ist irgendwo vertreten, und unterwegs wurde nichts Zusätzliches erfunden.

Prüfen Sie Routen, Resolver und Wiederverbindung auf einem frischen Konto

Verbunden ist nicht der Abnahmetest. Unter Windows zeigt Get-VpnConnection das Profil, und route print zeigt, ob das private Präfix auf dem Tunnel-Interface gelandet ist. Unter macOS bestätigt scutil --nc list den aktiven Dienst, während scutil --dns die Resolver-Reihenfolge zeigt, die das System wirklich nutzt.

Unter Linux belegt nmcli connection show --active, dass die Verbindung steht, und resolvectl status zeigt DNS pro Link. Ein Resolver, der in der Verbindungsdatei steht, aber in der Ausgabe pro Link fehlt, bedeutet, dass Split-DNS nicht angewendet wird. Das ist der Unterschied zwischen Namen, die sich auflösen, und Namen, die sich durch den Tunnel auflösen, und es ändert, welches Support-Team den nächsten Schritt besitzt. Vergleichen Sie die Ausgabe pro Link vor und nach dem Hochfahren der Verbindung, nicht nur danach.

Führen Sie die gesamte Prüfung mit einem frischen Konto ohne zwischengespeicherte Anmeldedaten und ohne vom Administrator installiertes Zertifikat durch. Wiederholen Sie sie dann nach einem Standby und Aufwachen und noch einmal, nachdem Sie eine erneute Eingabe der Anmeldedaten erzwungen haben. Diese beiden Übergänge bringen die meisten Wiederverbindungsfehler ans Licht, die eine erste Verbindung nie zeigt.

Versionieren Sie das Paket und halten Sie einen Rückweg offen

Versehen Sie jedes Plattformpaket mit der Vertragsrevision, die es umsetzt, und notieren Sie die Client- und Gateway-Versionen, gegen die Sie es abgenommen haben. Wenn sich das Verhalten nach einem Client-Update ändert, zeigt das Etikett auf einen erneut zu testenden Vertrag statt auf eine zu erratende Datei.

Halten Sie das vorherige Paket für jede Plattform abrufbar und schreiben Sie dessen Entfernungskommando daneben. Das Deinstallieren eines VPN-Profils ist unter Windows, macOS oder Linux nicht das Spiegelbild der Installation, und die Unterschiede zeigen sich zum ungünstigsten Zeitpunkt. Üben Sie die Entfernung einmal auf einem Ersatzgerät, damit das Archiv ein Plan wird statt einer Hoffnung.