Werk-VPN op een Raspberry Pi: stel eerst deze vragen

Vier antwoorden van de werkgever bepalen of een Pi kan deelnemen aan de werk-VPN: welk gatewayprotocol hij spreekt, welke besturingssystemen en architecturen hij ondersteunt, hoe authenticatie moet verlopen, en of een andere client dan de officiële is toegestaan. Een portal-URL en het woord Linux beslissen geen van alle. Vraag het voordat je iets downloadt, want de antwoorden veranderen welk pakket je installeert en of een headless opstelling überhaupt haalbaar is.

Schrijf de vier antwoorden op. De rest hiervan is wat elk ervan verandert.

Het gatewayprotocol bepaalt de client

De gateway spreekt een of meer protocollen, en de client moet degene implementeren die jouw organisatie daadwerkelijk draait. OpenConnect is een onafhankelijke implementatie die begon met Cisco AnyConnect-compatibiliteit en nu meerdere andere bedrijfsgateways dekt; het is niet de merkclient van de leverancier, en protocolcompatibiliteit garandeert geen ondersteuning voor elke gatewayfunctie, posturecontrole of apparaatbeleid. Bevestig het protocol met het netwerkteam in plaats van het af te leiden uit de URL van het portaal. Bevestig daarna dat de werkgever deze client voor deze uitrol accepteert.

Compatibiliteitsbewijs moet uit de documentatie van de werkgever komen of van een collega die het op hetzelfde model heeft gedaan, niet uit het bestaan van een pakket in een repository.

Architectuur is geen detail

Noteer de OS-versie en de userspace-architectuur van de Pi, de clientversie die je wilt gebruiken en waar dat pakket vandaan komt. Een x86-installer wordt niet geschikt voor een andere architectuur omdat de bestandsnaam is veranderd, en een leveranciersclient die alleen x86-builds levert, kan helemaal niet op de Pi draaien. Dat ene feit kan de hele vraag beslechten voordat authenticatie zelfs maar ter sprake komt. Controleer het onderhoud van de pakketbron in plaats van een verdwaalde binary uit een forumpost te installeren.

Een 64-bits userspace op een 64-bits kernel is het eenvoudige geval; een 32-bits userspace op een 64-bits board is waar mensen het verkeerde pakket installeren. dpkg --print-architecture en uname -m beantwoorden beide helften in één regel elk.

Authenticatie bepaalt de workflow

Wachtwoorden, MFA en inloggen via de browser dwingen elk hun eigen workflow af. Een certificaat op een hardwaretoken kan een driver vereisen die de Pi niet heeft, terwijl een SSO-stroom een browservenster opent dat een headless sessie niet kan tonen. Sommige gateways bieden precies daarvoor een apparaatcode- of handmatig kopieerpad, andere niet. Vraag welke methode de organisatie voor een headless Linux-host ondersteunt, en test die dan voordat je erop vertrouwt.

Frontend-integratie is een aparte keuze van authenticatie. Een NetworkManager-plugin kan een verbinding regelen en de geheimen ervan opslaan, maar hij kan een niet-ondersteunde authenticatiemethode niet compatibel maken. Houd die twee vragen gescheiden.

Houd de grens van de werkgever intact

Als de organisatie haar officiële client, een beheerd apparaat of een ondersteunde distributie vereist, volg die eis of vraag om een goedgekeurd alternatief. Certificaatcontroles uitschakelen, postureresultaten nabootsen of endpointcontroles uitzetten zodat een andere client geaccepteerd lijkt, verandert een compatibiliteitsprobleem in een beleidsschending. Houd wachtwoorden, sessiecookies en privésleutels buiten de shellgeschiedenis en chattranscripten. Een werkende challenge-response is geen toestemming om het sessiomateriaal te publiceren.

Bevestig na een goedgekeurde inschrijving privé-DNS, de bedoelde bronnen, een geweigerde bron en herverbinding, alles vanaf de Pi zelf. Een ingelogde tunnel kan nog steeds verkeerd routeren of een autorisatie missen.

Het resultaat is een ondersteunbare afspraak met een genoemde eigenaar: welke client, welke versie, welk inschrijvingspad. Dat is beter dan de leveranciersnabije client installeren en hopen dat de resterende eisen optioneel blijken.