VPN før pålogging på macOS: opplåsing, påloggingsvindu, økt
FileVault-opplåsing, påloggingsvinduet og en brukerøkt er separate stadier. En skrivebordsklient som starter ved pålogging løser bare det siste av dem.
Her er en overbevisning som koster folk en uke: at en Mac har ett øyeblikk som heter før pålogging, og at en VPN-klient enten starter da eller ikke. Maskinen har faktisk minst tre øyeblikk der nettverkstilgang betyr noe, atskilt av hvem som har lov til å holde legitimasjon på det punktet. En klient som startes fra et påloggingselement dekker nøyaktig ett av dem, og det er det siste.
Myten om at én innstilling dekker hele oppstarten
Les produktsiden på nytt og se etter hvilket stadium funksjonen nevner. En avkrysningsboks merket start ved pålogging betyr et påloggingselement, som kjører etter at en brukerøkt finnes. En avkrysningsboks merket koble til ved behov betyr at klienten åpner en forbindelse når trafikken samsvarer med en regel, noe som fortsatt krever at klienten og legitimasjonen er tilgjengelig.
Ingen av dem når oppstartsprosessen. Det er ikke en begrensning leverandøren har glemt å fjerne; det er det operativsystemet tillater. Før volumet er låst opp finnes det ikke et kjørende system å starte en klient fra, og etter utlogging forlater brukerens hemmeligheter økten. To separate vegger, og ingen av dem viker for en annen avkrysningsboks.
Når du skiller stadiene, endrer det opprinnelige spørsmålet form. I stedet for å spørre om VPN starter før pålogging, spør du hvilket av tre konkrete øyeblikk som må virke, og da oppdager du at hvert av dem har en annen eier: krypteringsstakken, nettverksutvidelsen eller brukerøkten.
Hva som faktisk skjer i hvert stadium
Oppstarten begynner med et kryptert volum som må låses opp før det finnes et brukbart system for noe allment. Den opplåsingen skjer i en begrenset kontekst med et begrenset sett legitimasjon, og Apple dokumenterer tydelig at krypterte data forblir utilgjengelige uten en gyldig opplåsing.
Deretter kommer påloggingsvinduet, der systemet kjører men det ennå ikke finnes noen brukerøkt. En utvidelse i brukerkontekst er allerede avsluttet hvis brukeren logget ut, og en global systemutvidelse kan fortsatt kjøre, men å kjøre er ikke det samme som å holde legitimasjonen VPN-en din trenger.
Så kommer økten, der en vanlig klient kan lese påloggingsnøkkelringen, be om en andre faktor og bruke dyttede ruter. De fleste funksjonene folk beskriver som før pålogging er faktisk dette stadiet, utløst tidlig i økten og ikke før 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 |
Hvorfor en launch daemon ikke kan logge på for en fraværende bruker
Forhøyede rettigheter føles som om de burde løse problemet, og det gjør de ikke. En launch daemon kjører som en systemprosess uten en brukerøkt bak seg, så det er ingen nøkkelring å låse opp og ingen person som svarer på en forespørsel. Den kan åpne en socket og lese en fil; det den ikke kan, er å bli brukeren som eier legitimasjonen. Rettigheter er ikke identitet, og det er nettopp her de to blandes sammen.
Det folk bygger i det gapet, er et skript med et passord i, noe som er et verre problem enn det de begynte med.
Den ærlige versjonen av kravet er smalere. Hvis maskinen må nå en beskyttet ressurs mens ingen er til stede, må identiteten ressursen godtar være en maskinen kan holde uten en person: et enhetssertifikat, en legitimasjon i systemnøkkelringen eller en konto der andre faktor ikke er et push til en telefon i noens lomme. Design den identiteten med vilje, og stadiumsspørsmålet svarer vanligvis seg selv.
Windows-funksjonen før pålogging overføres ikke
Windows har en dokumentert tilgangsmekanisme før pålogging for noen fjernaksessprodukter, og navnet reiser bedre enn evnen. En funksjon beskrevet i en Windows-distribusjonsveiledning forteller deg ingenting om hvorvidt samme leverandør implementerer en tilsvarende på macOS.
Be om en erklæring som dekker Mac-maskinvaren, macOS-versjonen, klientversjonen og autentiseringsmetoden du faktisk bruker. En generell støttepåstand er ikke nok, fordi forskjellen mellom å virke og ikke virke ofte ligger i en av de fire.
Hvis leverandøren ikke kan svare, er det svaret. Planlegg øktstadiet og design et alternativ for det ubemannede tilfellet, i stedet for å oppdage gapet under en utrulling.
Hva du bør be om i stedet
Skriv kravet i stadienes språk. Hvilken ressurs, nødvendig for hvem, i hvilken kontekst, og med hvilken akseptabel forsinkelse når forbindelsen ennå ikke er der?
Hvis svaret er en bruker som logger på og deretter trenger tunnelen, er koble til ved behov og et oppstartselement tilstrekkelig og billig. Hvis svaret er en maskin som starter på nytt om natten og må rapportere, trenger designet en støttet vei for å låse opp disken, en enhetsidentitet og en gjenopprettingsprosess som virker når nettverket aldri kommer opp. Hvis svaret er organisasjonspålogging som avhenger av tunnelen, må designene for pålogging, identitet og VPN bygges sammen i stedet for å kjøpes separat.
Apples FileVault-dokumentasjon er det riktige utgangspunktet for opplåsingsstadiet. Alt etter det er et klient- og identitetsspørsmål som en leverandørerklæring bør avgjøre før du kjøper.