Pracovní VPN na Raspberry Pi: nejprve si položte tyto otázky

Čtyři odpovědi od zaměstnavatele rozhodují, zda se Pi může připojit k pracovní VPN: jakým protokolem brána mluví, které operační systémy a architektury podporuje, jak má probíhat autentizace a zda je povolen jiný klient než oficiální. URL portálu a slovo Linux nerozhodnou ani jednu z nich. Ptejte se, než cokoli stáhnete, protože odpovědi mění, který balíček nainstalujete a zda je nastavení bez obrazovky vůbec proveditelné.

Zapište si čtyři odpovědi. Zbytek tohoto textu je to, co každá z nich mění.

Protokol brány určuje klienta

Brána mluví jedním nebo více protokoly a klient musí implementovat ten, který vaše organizace skutečně provozuje. OpenConnect je nezávislá implementace, která začala kompatibilitou s Cisco AnyConnect a nyní pokrývá několik dalších podnikových bran; není to značkový klient výrobce a kompatibilita protokolu nezaručuje podporu každé funkce brány, kontroly stavu zařízení ani zásady pro zařízení. Potvrďte protokol u síťového týmu, místo abyste ho odvozovali z URL portálu. Poté potvrďte, že zaměstnavatel tohoto klienta pro toto nasazení přijímá.

Důkazy o kompatibilitě musí pocházet z dokumentace zaměstnavatele nebo od kolegy, který to udělal na stejném modelu, ne z toho, že v repozitáři existuje balíček.

Architektura není detail

Zaznamenejte verzi operačního systému Pi a architekturu uživatelského prostoru, verzi klienta, kterou hodláte použít, a odkud tento balíček pochází. Instalační program x86 se nestane vhodným pro jinou architekturu jen proto, že se změnil název souboru, a klientský program výrobce, který dodává jen sestavení x86, na Pi vůbec nemůže běžet. Tento jediný fakt může vyřešit celou otázku ještě předtím, než se začne mluvit o autentizaci. Zkontrolujte údržbu zdroje balíčku, místo abyste instalovali zbloudilý binární soubor z vlákna fóra.

64bitový uživatelský prostor na 64bitovém jádru je jednoduchý případ; 32bitový uživatelský prostor na 64bitové desce je místo, kde lidé instalují špatný balíček. dpkg --print-architecture a uname -m odpovídají na obě poloviny jedním řádkem.

Autentizace určuje postup

Hesla, MFA a přihlášení přes prohlížeč každé vnucují vlastní postup. Certifikát na hardwarovém tokenu může vyžadovat ovladač, který Pi nemá, zatímco tok SSO může otevřít okno prohlížeče, které relace bez obrazovky neumí zobrazit. Některé brány pro přesně tento případ nabízejí cestu s kódem zařízení nebo ručním kopírováním, jiné ne. Zeptejte se, kterou metodu organizace pro headless hostitele s Linuxem podporuje, a pak ji otestujte, než na ni spolehnete.

Integrace rozhraní je samostatná volba od autentizace. Plugin NetworkManageru může zařídit připojení a uložit jeho tajemství, ale nedokáže nepodporovanou metodu autentizace udělat kompatibilní. Držte tyto dvě otázky oddělené.

Zachovejte hranici zaměstnavatele

Pokud organizace vyžaduje svého oficiálního klienta, spravované zařízení nebo podporovanou distribuci, dodržte tento požadavek nebo požádejte o schválenou alternativu. Vypnutí kontrol certifikátů, napodobování výsledků stavu nebo vypnutí kontrol koncových bodů, aby se jiný klient jevil jako přijatý, mění problém kompatibility v porušení zásad. Držte hesla, cookies relace a soukromé klíče mimo historii shellu a přepisy chatů. Fungující výzva-odpověď není povolení zveřejnit materiály relace.

Po schválené registraci potvrďte soukromé DNS, zamýšlené prostředky, odmítnutý prostředek a opětovné připojení, a to vše přímo z Pi. Přihlášený tunel může stále směrovat nesprávně nebo mu chybět oprávnění.

Výsledkem je udržitelná dohoda s jmenovaným vlastníkem: který klient, která verze, která cesta registrace. To je lepší než instalovat klienta blízkého výrobci a doufat, že zbývající požadavky se ukážou jako volitelné.