VPN před přihlášením na macOS: odemčení, přihlašovací okno, relace
Odemčení FileVaultu, přihlašovací okno a uživatelská relace jsou oddělené fáze. Klientská aplikace pro počítač, která se spouští při přihlášení, řeší jen poslední z nich.
Tady je přesvědčení, které lidi stojí týden: že Mac má jediný okamžik zvaný před přihlášením a že VPN klient buď tehdy startuje, nebo ne. Stroj má ve skutečnosti nejméně tři okamžiky, kdy záleží na přístupu k síti, a odděluje je to, kdo v daném bodě smí držet přihlašovací údaje. Klient spuštěný z položky přihlášení pokrývá přesně jeden z nich, a to ten poslední.
Mýtus, že jedno nastavení pokrývá celé spouštění
Přečtěte si znovu stránku produktu a hledejte, kterou fázi funkce pojmenovává. Zaškrtávací pole s popisem spustit při přihlášení znamená položku přihlášení, která běží až po existenci uživatelské relace. Zaškrtávací pole s popisem připojit na vyžádání znamená, že klient otevře spojení, když provoz odpovídá pravidlu, což stále vyžaduje, aby byl klient a jeho údaje dostupné.
Ani jedno z toho nedosáhne na proces spouštění. To není omezení, které by výrobce zapomněl odstranit; to je to, co operační systém dovoluje. Dokud není svazek odemčen, neexistuje běžící systém, ze kterého by šel klient spustit, a po odhlášení uživatelova tajemství odcházejí s relací. Dvě oddělené zdi a ani jedna neustoupí jinému zaškrtávacímu poli.
Když fáze oddělíte, původní otázka mění tvar. Místo abyste se ptali, zda VPN startuje před přihlášením, ptáte se, který ze tří konkrétních okamžiků musí fungovat, a pak zjistíte, že každý má jiného vlastníka: vrstvu šifrování, síťové rozšíření nebo uživatelskou relaci.
Co se ve skutečnosti děje v každé fázi
Spouštění začíná zašifrovaným svazkem, který je třeba odemknout, než existuje použitelný systém pro cokoli obecného. Toto odemčení probíhá v omezeném kontextu s omezenou sadou údajů a Apple jasně dokumentuje, že šifrovaná data zůstávají nedostupná bez platného odemčení.
Dále přichází přihlašovací okno, kde systém běží, ale uživatelská relace ještě neexistuje. Rozšíření v uživatelském kontextu už skončilo, pokud se uživatel odhlásil, a globální systémové rozšíření může stále běžet, ale běžet není totéž jako držet údaje, které vaše VPN potřebuje.
Pak přichází relace, kde normální klient může přečíst klíčenku přihlášení, vyžádat druhý faktor a použít vložené trasy. Většina funkcí, které lidé popisují jako před přihlášením, je ve skutečnosti tato fáze, spuštěná brzy v relaci, nikoli před ní.
| Stage | What it can use | What it cannot do |
|---|---|---|
| FileVault unlock | Credentials supplied at the console to unlock the volume | Run an ordinary VPN app or read a user keychain |
| Login window | System context, possibly a joined network | Use a user secret that only exists after login |
| User session | Login keychain, interactive MFA, full client features | Exist before the volume unlocks |
Proč se launch daemon nemůže přihlásit za nepřítomného uživatele
Zvýšená oprávnění vypadají, že by měla problém vyřešit, ale neřeší. Launch daemon běží jako systémový proces bez uživatelské relace za sebou, takže není co odemknout a není nikdo, kdo by odpověděl na výzvu. Může otevřít socket a přečíst soubor; to, co nedokáže, je stát se uživatelem, kterému údaje patří. Oprávnění není identita a přesně v tomto bodě se obojí plete.
Co lidé v této mezeře staví, je skript s heslem uvnitř, což je horší problém než ten, se kterým začali.
Poctivá verze požadavku je užší. Pokud se stroj musí dostat k chráněnému zdroji, když nikdo není přítomen, musí být identita, kterou tento zdroj přijímá, taková, kterou stroj udrží bez člověka: certifikát zařízení, údaj v systémové klíčence nebo účet, jehož druhý faktor není push na telefon v něčí kapse. Navrhněte tuto identitu záměrně a otázka fáze obvykle odpoví sama.
Funkce Windows před přihlášením se nepřenáší
Windows má dokumentovaný mechanismus přístupu před přihlášením pro některé produkty vzdáleného přístupu a název cestuje lépe než schopnost. Funkce popsaná v příručce k nasazení Windows vám neřekne nic o tom, zda stejný výrobce implementuje ekvivalent na macOS.
Požadujte prohlášení pokrývající hardware Macu, verzi macOS, verzi klienta a metodu ověřování, kterou skutečně používáte. Obecné tvrzení o podpoře nestačí, protože rozdíl mezi funkčním a nefunkčním často leží v jedné z těch čtyř.
Pokud výrobce nemůže odpovědět, to je odpověď. Plánujte fázi relace a navrhněte alternativu pro případ bez dohledu, místo abyste mezeru objevili během zavádění.
O co žádat místo toho
Napište požadavek jazykem fází. Který zdroj, komu je potřeba, v jakém kontextu a s jakým přijatelným zpožděním, když spojení ještě není?
Pokud je odpovědí uživatel, který se přihlásí a pak potřebuje tunel, připojení na vyžádání a položka při spuštění stačí a jsou levné. Pokud je odpovědí stroj, který se v noci restartuje a musí se hlásit, návrh potřebuje podporovanou cestu odemčení disku, identitu zařízení a proces obnovy, který funguje, když se síť nikdy nezvedne. Pokud je odpovědí přihlášení do organizace, které závisí na tunelu, musí se návrhy přihlášení, identity a VPN stavět společně, ne kupovat odděleně.
Dokumentace Applu k FileVaultu je správný výchozí bod pro fázi odemčení. Vše po ní je otázka klienta a identity, kterou by mělo prohlášení výrobce vyřešit před nákupem.