Werks-VPN op ’n Raspberry Pi: vra eers hierdie vrae

Vier antwoorde van die werkgewer bepaal of ’n Pi by die werks-VPN kan aansluit: watter protokol die poort praat, watter bedryfstelsels en argitekture dit ondersteun, hoe verifikasie moet geskied, en of ’n ander kliënt as die amptelike een toegelaat word. ’n Portaal-URL en die woord Linux beslis nie een daarvan nie. Vra voordat jy enigiets aflaai, want die antwoorde verander watter pakket jy installeer en of ’n koplose opstelling hoegenaamd haalbaar is.

Skryf die vier antwoorde neer. Die res hiervan is wat elkeen verander.

Die poort se protokol bepaal die kliënt

Die poort praat een of meer protokolle, en die kliënt moet die een implementeer wat jou organisasie werklik gebruik. OpenConnect is ’n onafhanklike implementering wat met Cisco AnyConnect-versoenbaarheid begin het en nou verskeie ander ondernemingspoorte dek; dit is nie die verskaffer se handelsmerk-kliënt nie, en protokolversoenbaarheid waarborg nie ondersteuning vir elke poortfunksie, toestandstoets of toestelbeleid nie. Bevestig die protokol by die netwerkspan eerder as om dit uit die portaal se URL af te lei. Bevestig dan dat die werkgewer hierdie kliënt vir hierdie ontplooiing aanvaar.

Versoenbaarheidsbewyse moet uit die werkgewer se dokumentasie kom of van ’n kollega wat dit op dieselfde model gedoen het, nie uit ’n pakket wat in ’n bewaarplek bestaan nie.

Argitektuur is nie ’n detail nie

Teken die Pi se bedryfstelselweergawe en gebruikerspasie-argitektuur aan, die kliëntweergawe wat jy van plan is om te gebruik, en waar daardie pakket vandaan kom. ’n x86-installeerder word nie geskik vir ’n ander argitektuur omdat sy lêernaam verander het nie, en ’n verskafferkliënt wat net x86-bouwe lewer, kan glad nie op die Pi loop nie. Daardie enkele feit kan die hele vraag besleg nog voordat verifikasie ter sprake kom. Kyk na die instandhouding van die pakketbron eerder as om ’n verdwaalde binêre lêer uit ’n forumdraad te installeer.

Al 64-bis gebruikerspasie op ’n 64-bis kern is die eenvoudige geval; ’n 32-bis gebruikerspasie op ’n 64-bis bord is waar mense die verkeerde pakket installeer. dpkg --print-architecture en uname -m beantwoord albei helftes in een reël elk.

Verifikasie bepaal die werkstroom

Wagwoorde, MFA en aanmelding deur die blaaier het elkeen ’n eie werkstroom. ’n Sertifikaat op ’n hardewaretoken kan ’n drywer nodig hê wat die Pi nie het nie, terwyl ’n SSO-vloei ’n blaaiervenster kan oopmaak wat ’n koplose sessie nie kan wys nie. Sommige poorte bied ’n toestelkode- of handmatige-kopieëerpad juis vir daardie geval, en sommige nie. Vra watter metode die organisasie vir ’n koplose Linux-gasheer ondersteun, en toets dit dan voordat jy daarop staatmaak.

Voorkantintegrasie is ’n aparte keuse van verifikasie. ’n NetworkManager-inprop kan ’n verbinding reël en sy geheime stoor, maar dit kan nie ’n onondersteunde verifikasiemetode versoenbaar maak nie. Hou daardie twee vrae apart.

Hou die werkgewer se grens ongeskonde

As die organisasie sy amptelike kliënt, ’n bestuurde toestel of ’n ondersteunde verspreiding vereis, volg daardie vereiste of vra ’n goedgekeurde alternatief. Om sertifikaattoetse af te skakel, toestandresultate na te maak of eindpuntbeheermaatreëls af te skakel sodat ’n ander kliënt aanvaar lyk, verander ’n versoenbaarheidsprobleem in ’n beleidsoortreding. Hou wagwoorde, sessiekoekies en private sleutels uit die dopgeskiedenis en kletsnotas. ’n Werkende uitdaging-respons is nie toestemming om die sessiemateriaal te publiseer nie.

Ná ’n goedgekeurde inskrywing, bevestig private DNS, die beoogde hulpbronne, ’n geweierde hulpbron en herverbinding, alles van die Pi self af. ’n Aangemelde tonnel kan steeds verkeerd roeteer of ’n magtiging kortkom.

Die lewering is ’n ondersteunbare ooreenkoms met ’n genoemde eienaar: watter kliënt, watter weergawe, watter inskrywingspad. Dit is beter as om die verskaffer-aanpalende kliënt te installeer en te hoop die oorblywende vereistes blyk opsioneel te wees.