Arbets-VPN på en Raspberry Pi: ställ de här frågorna först

Fyra svar från arbetsgivaren avgör om en Pi kan ansluta till arbets-VPN: vilket gateway-protokoll den talar, vilka operativsystem och arkitekturer den stöder, hur autentisering ska gå till och om en annan klient än den officiella är tillåten. En portal-URL och ordet Linux avgör ingen av dem. Fråga innan du laddar ner något, eftersom svaren ändrar vilket paket du installerar och om en installation utan skärm alls är möjlig.

Skriv ner de fyra svaren. Resten av detta är vad var och en av dem ändrar.

Gateway-protokollet avgör klienten

Gatewayen talar ett eller flera protokoll, och klienten måste implementera det som din organisation faktiskt kör. OpenConnect är en oberoende implementering som började med Cisco AnyConnect-kompatibilitet och nu täcker flera andra företagsgatewayer; det är inte leverantörens märkesklient, och protokollkompatibilitet garanterar inte stöd för varje gatewayfunktion, posture-kontroll eller enhetspolicy. Bekräfta protokollet med nätverksteamet i stället för att härleda det från portalens URL. Bekräfta sedan att arbetsgivaren accepterar den här klienten för den här utrullningen.

Underlag för kompatibilitet måste komma från arbetsgivarens dokumentation eller från en kollega som gjort det på samma modell, inte från att ett paket finns i ett arkiv.

Arkitektur är ingen detalj

Notera Pi:ns OS-version och användarrymdens arkitektur, klientversionen du tänker använda och varifrån paketet kommer. En x86-installation blir inte lämplig för en annan arkitektur för att filnamnet har ändrats, och en leverantörsklient som bara levererar x86-byggen kan inte köra på Pi:n alls. Det enda faktumet kan avgöra hela frågan innan autentisering ens diskuteras. Kontrollera underhållet av paketkällan i stället för att installera en vilsegången binärfil från en forumtråd.

Ett 64-bitars användarutrymme på en 64-bitars kärna är det enkla fallet; ett 32-bitars användarutrymme på ett 64-bitars kort är där folk installerar fel paket. dpkg --print-architecture och uname -m svarar på båda halvorna med en rad var.

Autentiseringen avgör arbetsflödet

Lösenord, MFA och inloggning via webbläsaren tvingar var och en fram sitt eget arbetsflöde. Ett certifikat på en hårdvarutoken kan kräva en drivrutin som Pi:n inte har, medan ett SSO-flöde kan öppna ett webbläsarfönster som en session utan skärm inte kan visa. Vissa gatewayer erbjuder en enhetskod- eller manuell kopieringsväg just för det fallet, andra inte. Fråga vilken metod organisationen stöder för en Linux-värd utan skärm och testa den sedan innan du förlitar dig på den.

Frontend-integration är ett separat val från autentisering. Ett NetworkManager-plugin kan ordna en anslutning och lagra dess hemligheter, men det kan inte göra en icke-stödd autentiseringsmetod kompatibel. Håll de två frågorna åtskilda.

Bevara arbetsgivarens gräns

Om organisationen kräver sin officiella klient, en hanterad enhet eller en distribution som stöds, följ kravet eller begär ett godkänt alternativ. Att stänga av certifikatkontroller, härma posture-resultat eller stänga av slutpunktskontroller så att en annan klient verkar accepterad gör ett kompatibilitetsproblem till ett policybrott. Håll lösenord, sessionscookies och privata nycklar borta från skalkhistoriken och chatt-transkript. En fungerande challenge-response är inte tillstånd att publicera sessionsmaterialet.

Efter en godkänd registrering, bekräfta privat DNS, de avsedda resurserna, en nekad resurs och återanslutning, allt från Pi:n själv. En inloggad tunnel kan fortfarande routa fel eller sakna en behörighet.

Leveransen är ett avtal som går att stödja, med en namngiven ägare: vilken klient, vilken version, vilken registreringsväg. Det slår att installera den leverantörsnära klienten och hoppas att de återstående kraven visar sig vara valfria.