Arbeits-VPN auf einem Raspberry Pi: Stellen Sie zuerst diese Fragen
Eine Portal-URL und das Wort Linux sind kein Client-Vertrag. Holen Sie die Antworten zu Protokoll, Architektur, Authentifizierung und Richtlinie, bevor Sie etwas installieren.
Vier Antworten des Arbeitgebers entscheiden, ob ein Pi dem Arbeits-VPN beitreten kann: welches Gateway-Protokoll er spricht, welche Betriebssysteme und Architekturen er unterstützt, wie die Authentifizierung erfolgen muss und ob ein anderer Client als der offizielle erlaubt ist. Eine Portal-URL und das Wort Linux klären keine davon. Fragen Sie, bevor Sie etwas herunterladen, denn die Antworten ändern, welches Paket Sie installieren und ob ein Headless-Setup überhaupt machbar ist.
Schreiben Sie die vier Antworten auf. Der Rest dieses Textes ist, was jede davon ändert.
Das Gateway-Protokoll entscheidet über den Client
Das Gateway spricht ein oder mehrere Protokolle, und der Client muss dasjenige implementieren, das Ihre Organisation tatsächlich betreibt. OpenConnect ist eine unabhängige Implementierung, die mit Cisco-AnyConnect-Kompatibilität begann und inzwischen mehrere andere Enterprise-Gateways abdeckt; sie ist nicht der Markenclient des Herstellers, und Protokollkompatibilität garantiert keine Unterstützung jeder Gateway-Funktion, Posture-Prüfung oder Geräterichtlinie. Bestätigen Sie das Protokoll mit dem Netzwerkteam, statt es aus der URL des Portals abzuleiten. Bestätigen Sie dann, dass der Arbeitgeber diesen Client für diese Bereitstellung akzeptiert.
Kompatibilitätsnachweise müssen aus der Dokumentation des Arbeitgebers oder von einer Kollegin stammen, die es auf demselben Modell gemacht hat, nicht aus der Existenz eines Pakets in einem Repository.
Architektur ist kein Detail
Halten Sie die OS-Version und die Userspace-Architektur des Pi, die Client-Version, die Sie verwenden wollen, und die Herkunft dieses Pakets fest. Ein x86-Installer wird nicht dadurch für eine andere Architektur geeignet, dass sich sein Dateiname geändert hat, und ein Herstellerclient, der nur x86-Builds liefert, kann auf dem Pi überhaupt nicht laufen. Diese eine Tatsache kann die ganze Frage klären, bevor überhaupt über Authentifizierung gesprochen wird. Prüfen Sie die Pflege der Paketquelle, statt ein zufälliges Binary aus einem Forenthread zu installieren.
Ein 64-Bit-Userspace auf einem 64-Bit-Kernel ist der einfache Fall; ein 32-Bit-Userspace auf einem 64-Bit-Board ist der Fall, in dem Leute das falsche Paket installieren. dpkg --print-architecture und uname -m beantworten beide Hälften mit je einer Zeile.
Die Authentifizierung entscheidet über den Ablauf
Passwörter, MFA und browsergestützte Anmeldung erzwingen jeweils einen eigenen Ablauf. Ein Zertifikat auf einem Hardware-Token kann einen Treiber brauchen, den der Pi nicht hat, während ein SSO-Flow ein Browserfenster öffnet, das eine Headless-Sitzung nicht anzeigen kann. Manche Gateways bieten für genau diesen Fall einen Gerätecode- oder manuellen Kopierpfad an, andere nicht. Fragen Sie, welche Methode die Organisation für einen Headless-Linux-Host unterstützt, und testen Sie sie, bevor Sie sich darauf verlassen.
Die Frontend-Integration ist eine eigene Entscheidung, getrennt von der Authentifizierung. Ein NetworkManager-Plugin kann eine Verbindung einrichten und ihre Geheimnisse speichern, aber es kann eine nicht unterstützte Authentifizierungsmethode nicht kompatibel machen. Halten Sie diese beiden Fragen getrennt.
Wahren Sie die Grenze des Arbeitgebers
Wenn die Organisation ihren offiziellen Client, ein verwaltetes Gerät oder eine unterstützte Distribution verlangt, halten Sie sich daran oder beantragen Sie eine genehmigte Alternative. Zertifikatsprüfungen abzuschalten, Posture-Ergebnisse nachzuahmen oder Endpoint-Kontrollen auszuschalten, damit ein anderer Client akzeptiert erscheint, macht aus einem Kompatibilitätsproblem einen Richtlinienverstoß. Halten Sie Passwörter, Session-Cookies und private Schlüssel aus der Shell-Historie und aus Chat-Protokollen heraus. Eine funktionierende Challenge-Response ist keine Erlaubnis, das Sitzungsmaterial zu veröffentlichen.
Bestätigen Sie nach einer genehmigten Registrierung privates DNS, die vorgesehenen Ressourcen, eine verweigerte Ressource und die erneute Verbindung, und zwar alles vom Pi selbst aus. Ein angemeldeter Tunnel kann trotzdem falsch routen oder eine Berechtigung vermissen lassen.
Das Ergebnis ist eine belastbare Vereinbarung mit einem benannten Verantwortlichen: welcher Client, welche Version, welcher Registrierungspfad. Das ist besser, als den herstellernahen Client zu installieren und zu hoffen, dass die übrigen Anforderungen optional sind.