VPN före inloggning på macOS: upplåsning, inloggningsfönster, session
FileVault-upplåsning, inloggningsfönstret och en användarsession är separata steg. En skrivbordsklient som startar vid inloggning löser bara det sista av dem.
Här är en övertygelse som kostar folk en vecka: att en Mac har ett enda ögonblick som kallas före inloggning och att en VPN-klient antingen startar då eller inte. Maskinen har faktiskt minst tre ögonblick där nätverksåtkomst spelar roll, åtskilda av vem som har rätt att hålla autentiseringsuppgifter vid den punkten. En klient som startas från ett inloggningsobjekt täcker exakt ett av dem, och det är det sista.
Myten att en inställning täcker hela uppstarten
Läs produktsidan igen och leta efter vilket steg funktionen namnger. En kryssruta märkt starta vid inloggning betyder ett inloggningsobjekt, som körs efter att en användarsession finns. En kryssruta märkt anslut vid behov betyder att klienten öppnar en anslutning när trafiken matchar en regel, vilket fortfarande kräver att klienten och dess autentiseringsuppgifter är tillgängliga.
Ingen av dem når uppstartsprocessen. Det är inte en begränsning som leverantören glömde ta bort; det är vad operativsystemet tillåter. Innan volymen är upplåst finns det inget körande system att starta en klient från, och efter utloggning lämnar användarens hemligheter sessionen. Två separata väggar, och ingen av dem viker för en annan kryssruta.
När du skiljer stegen åt byter den ursprungliga frågan form. I stället för att fråga om VPN startar före inloggning frågar du vilket av tre konkreta ögonblick som måste fungera, och då upptäcker du att var och en har en annan ägare: krypteringsstacken, nätverksutökningen eller användarsessionen.
Vad som faktiskt händer i varje steg
Uppstarten börjar med en krypterad volym som måste låsas upp innan det finns ett användbart system för något allmänt. Den upplåsningen sker i en begränsad kontext med en begränsad uppsättning autentiseringsuppgifter, och Apple dokumenterar tydligt att krypterade data förblir oåtkomliga utan en giltig upplåsning.
Sedan kommer inloggningsfönstret, där systemet körs men det ännu inte finns någon användarsession. En utökning i användarkontext är redan avslutad om användaren loggade ut, och en global systemutökning kan fortfarande köra, men att köra är inte samma sak som att hålla de autentiseringsuppgifter som din VPN behöver.
Sedan kommer sessionen, där en vanlig klient kan läsa inloggningsnyckelringen, begära en andra faktor och tillämpa skickade rutter. De flesta funktioner som folk beskriver som före inloggning är faktiskt detta steg, utlöst tidigt i sessionen och inte före den.
| 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 |
Varför en launch daemon inte kan logga in för en frånvarande användare
Förhöjda rättigheter känns som om de borde lösa problemet, och det gör de inte. En launch daemon körs som en systemprocess utan en användarsession bakom sig, så det finns ingen nyckelring att låsa upp och ingen människa som svarar på en begäran. Den kan öppna en socket och läsa en fil; det den inte kan är att bli användaren som äger autentiseringsuppgifterna. Rättighet är inte identitet, och det är precis här de två blandas ihop.
Det folk bygger i den luckan är ett skript med ett lösenord i, vilket är ett värre problem än det de började med.
Den ärliga versionen av kravet är snävare. Om maskinen måste nå en skyddad resurs medan ingen är närvarande, måste identiteten som resursen accepterar vara en som maskinen kan hålla utan en person: ett enhetscertifikat, en autentiseringsuppgift i systemnyckelringen eller ett konto vars andra faktor inte är en push till en telefon i någons ficka. Designa den identiteten medvetet, och stegfrågan svarar vanligtvis sig själv.
Windows-funktionen före inloggning överförs inte
Windows har en dokumenterad åtkomstmekanism före inloggning för vissa fjärråtkomstprodukter, och namnet reser bättre än förmågan. En funktion som beskrivs i en Windows-distributionsguide säger dig ingenting om huruvida samma leverantör implementerar en motsvarighet på macOS.
Be om en förklaring som täcker Mac-hårdvaran, macOS-versionen, klientversionen och den autentiseringsmetod du faktiskt använder. Ett allmänt påstående om stöd räcker inte, eftersom skillnaden mellan att fungera och inte fungera ofta ligger i en av de fyra.
Om leverantören inte kan svara är det svaret. Planera sessionssteget och designa ett alternativ för det obemannade fallet, i stället för att upptäcka luckan under en utrullning.
Vad du bör be om i stället
Skriv kravet i stegens språk. Vilken resurs, nödvändig för vem, i vilken kontext, och med vilken acceptabel fördröjning när anslutningen ännu inte finns?
Om svaret är en användare som loggar in och sedan behöver tunneln, räcker anslut vid behov och ett startobjekt, och det är billigt. Om svaret är en maskin som startar om på natten och måste rapportera, behöver designen en stödd väg för att låsa upp disken, en enhetsidentitet och en återställningsprocess som fungerar när nätverket aldrig kommer upp. Om svaret är organisationsinloggning som beror på tunneln, måste designerna för inloggning, identitet och VPN byggas tillsammans i stället för att köpas separat.
Apples FileVault-dokumentation är rätt utgångspunkt för upplåsningssteget. Allt efter det är en klient- och identitetsfråga som en leverantörsförklaring bör avgöra före köpet.