VPN vóór het inloggen op macOS: ontgrendelen, inlogvenster, sessie

Hier is een overtuiging die mensen een week kost: dat een Mac één moment heeft dat vóór het inloggen heet, en dat een VPN-client dan ofwel start of niet. De machine heeft in werkelijkheid minstens drie momenten waarop netwerktoegang ertoe doet, gescheiden door wie op dat punt inloggegevens mag vasthouden. Een client die vanuit een inlogitem start, dekt er precies één van, en het is de laatste.

De mythe dat één instelling de hele opstart dekt

Lees de productpagina opnieuw en zoek op welke fase de functie doelt. Een selectievakje met start bij inloggen betekent een inlogitem, dat loopt nadat een gebruikerssessie bestaat. Een selectievakje met verbind indien nodig betekent dat de client een verbinding opent wanneer verkeer aan een regel voldoet, wat nog steeds vereist dat de client en zijn inloggegevens beschikbaar zijn.

Geen van beide bereikt het opstartproces. Dat is geen beperking die de leverancier vergat te verwijderen; het is wat het besturingssysteem toestaat. Voordat het volume ontgrendeld is, is er geen draaiend systeem om een client uit te starten, en na uitloggen vertrekken de geheimen van de gebruiker met de sessie. Twee aparte muren, en geen enkele wijkt voor een ander selectievakje.

Zodra je de fasen scheidt, verandert de oorspronkelijke vraag van vorm. In plaats van te vragen of de VPN vóór het inloggen start, vraag je welk van drie specifieke momenten moet werken, en dan ontdek je dat elk een andere eigenaar heeft: de versleutelingsstack, de netwerkextensie of de gebruikerssessie.

Wat er in elke fase werkelijk gebeurt

Het opstarten begint met een versleuteld volume dat ontgrendeld moet worden voordat er een bruikbaar systeem is voor wat dan ook algemeen. Die ontgrendeling gebeurt in een beperkte context met een beperkte set inloggegevens, en Apple documenteert duidelijk dat versleutelde gegevens ontoegankelijk blijven zonder geldige ontgrendeling.

Daarna komt het inlogvenster, waar het systeem draait maar er nog geen gebruikerssessie bestaat. Een extensie in gebruikerscontext is al beëindigd als de gebruiker is uitgelogd, en een globale systeemextensie draait mogelijk nog, maar draaien is niet hetzelfde als de inloggegevens vasthouden die je VPN nodig heeft.

Dan komt de sessie, waar een normale client de inlogsleutelhanger kan lezen, om een tweede factor kan vragen en de gepushte routes kan toepassen. De meeste functies die mensen als vóór het inloggen beschrijven, zijn in feite deze fase, vroeg in de sessie geactiveerd en niet ervoor.

Waarom een launch daemon niet kan inloggen voor een afwezige gebruiker

Verhoogde rechten voelen alsof ze het probleem moeten oplossen, en dat doen ze niet. Een launch daemon draait als systeemproces zonder gebruikerssessie erachter, dus er is geen sleutelhanger om te ontgrendelen en geen mens om een verzoek te beantwoorden. Hij kan een socket openen en een bestand lezen; wat hij niet kan, is de gebruiker worden die de inloggegevens bezit. Recht is geen identiteit, en precies hier raken de twee verward.

Wat mensen in dat gat bouwen, is een script met een wachtwoord erin, wat een erger probleem is dan dat waarmee ze begonnen.

De eerlijke versie van de eis is smaller. Als de machine een beschermde resource moet bereiken terwijl niemand aanwezig is, moet de identiteit die die resource accepteert er een zijn die de machine zonder persoon kan vasthouden: een apparaatcertificaat, een inloggegeven in de systeemsleutelhanger of een account waarvan de tweede factor geen push naar een telefoon in iemands zak is. Ontwerp die identiteit bewust, en de fasevraag beantwoordt zich meestal zelf.

De Windows-functie vóór het inloggen gaat niet over

Windows heeft een gedocumenteerd mechanisme voor toegang vóór het inloggen voor sommige producten voor toegang op afstand, en de naam reist beter dan het vermogen. Een functie die in een Windows-implementatiehandleiding wordt beschreven, zegt niets over de vraag of dezelfde leverancier een equivalent op macOS implementeert.

Vraag om een verklaring die de Mac-hardware, de macOS-versie, de clientversie en de authenticatiemethode die je werkelijk gebruikt, dekt. Een algemene bewering van ondersteuning is niet genoeg, omdat het verschil tussen werken en niet werken vaak in een van die vier zit.

Als de leverancier niet kan antwoorden, is dat het antwoord. Plan de sessiefase en ontwerp een alternatief voor het geval zonder toezicht, in plaats van het gat tijdens een uitrol te ontdekken.

Wat je in plaats daarvan moet vragen

Schrijf de eis in de taal van de fasen. Welke resource, nodig voor wie, in welke context, en met welke aanvaardbare vertraging wanneer de verbinding er nog niet is?

Als het antwoord een gebruiker is die inlogt en dan de tunnel nodig heeft, zijn verbinden indien nodig en een opstartitem voldoende en goedkoop. Als het antwoord een machine is die 's nachts opnieuw opstart en moet rapporteren, heeft het ontwerp een ondersteund pad voor het ontgrendelen van de schijf, een apparaatidentiteit en een herstelproces nodig dat werkt wanneer het netwerk nooit opkomt. Als het antwoord organisatie-inloggen is dat van de tunnel afhangt, moeten de ontwerpen voor inloggen, identiteit en VPN samen worden gebouwd in plaats van apart gekocht.

Apple's FileVault-documentatie is het juiste startpunt voor de ontgrendelfase. Alles daarna is een client- en identiteitsvraag die een verklaring van de leverancier vóór de aankoop zou moeten beslechten.