Arbejds-VPN på en Raspberry Pi: stil disse spørgsmål først

Fire svar fra arbejdsgiveren afgør, om en Pi kan slutte sig til arbejds-VPN’en: hvilken gateway-protokol den taler, hvilke styresystemer og arkitekturer den understøtter, hvordan godkendelse skal foregå, og om en anden klient end den officielle er tilladt. En portal-URL og ordet Linux afgør ingen af dem. Spørg, før du henter noget, fordi svarene ændrer, hvilken pakke du installerer, og om en opsætning uden skærm overhovedet er mulig.

Skriv de fire svar ned. Resten af dette er, hvad hvert af dem ændrer.

Gateway-protokollen afgør klienten

Gatewayen taler én eller flere protokoller, og klienten skal implementere den, som din organisation faktisk kører. OpenConnect er en uafhængig implementering, der begyndte med Cisco AnyConnect-kompatibilitet og nu dækker flere andre virksomhedsgateways; den er ikke leverandørens mærkevareklient, og protokolkompatibilitet garanterer ikke støtte til hver gateway-funktion, posture-kontrol eller enhedspolitik. Bekræft protokollen med netværksteamet i stedet for at gætte den ud fra portalen URL. Bekræft derefter, at arbejdsgiveren accepterer denne klient til denne udrulning.

Dokumentation for kompatibilitet skal komme fra arbejdsgiverens dokumentation eller fra en kollega, der har gjort det på samme model, ikke fra at der findes en pakke i et lager.

Arkitektur er ikke en detalje

Notér Pi’ens OS-version og brugerrumsarkitektur, den klientversion du agter at bruge, og hvor den pakke kommer fra. En x86-installationsfil bliver ikke egnet til en anden arkitektur, fordi dens filnavn er ændret, og en leverandørklient, der kun leverer x86-byg, kan slet ikke køre på Pi’en. Den ene kendsgerning kan afgøre hele spørgsmålet, før godkendelse overhovedet diskuteres. Kontrollér pakkekildens vedligeholdelse i stedet for at installere en tilfældig binærfil fra en forumtråd.

Et 64-bit brugerrum på en 64-bit kerne er det enkle tilfælde; et 32-bit brugerrum på et 64-bit board er, hvor folk installerer den forkerte pakke. dpkg --print-architecture og uname -m besvarer begge halvdele på hver sin linje.

Godkendelse afgør arbejdsgangen

Adgangskoder, MFA og browserbaseret login pålægger hver deres arbejdsgang. Et certifikat på et hardwaretoken kan kræve en driver, som Pi’en ikke har, mens et SSO-flow kan åbne et browservindue, som en session uden skærm ikke kan vise. Nogle gateways tilbyder en enhedskode- eller manuel-kopieringsvej netop til det tilfælde, og andre gør ikke. Spørg, hvilken metode organisationen understøtter til en Linux-vært uden skærm, og test den derefter, før du afhænger af den.

Frontend-integration er et separat valg fra godkendelse. Et NetworkManager-plugin kan arrangere en forbindelse og gemme dens hemmeligheder, men det kan ikke gøre en ikke-understøttet godkendelsesmetode kompatibel. Hold de to spørgsmål adskilt.

Bevar arbejdsgiverens grænse

Hvis organisationen kræver sin officielle klient, en administreret enhed eller en understøttet distribution, skal du følge det krav eller anmode om et godkendt alternativ. At slå certifikatkontroller fra, efterligne posture-resultater eller slå endpoint-kontroller fra for at få en anden klient til at se accepteret ud gør et kompatibilitetsproblem til en politikovertrædelse. Hold adgangskoder, sessionscookies og private nøgler ude af shell-historikken og chat-transskripter. En fungerende challenge-response er ikke tilladelse til at offentliggøre sessionens materiale.

Efter en godkendt tilmelding skal du bekræfte privat DNS, de tilsigtede ressourcer, en afvist ressource og genopkobling, alt fra Pi’en selv. En tunnel, man er logget ind på, kan stadig route forkert eller mangle en autorisation.

Leverancen er en aftale, der kan understøttes, med en navngivet ejer: hvilken klient, hvilken version, hvilken tilmeldingsvej. Det slår at installere den leverandørnære klient og håbe på, at de resterende krav viser sig at være valgfrie.