VPN avant l’ouverture de session sur macOS : déverrouillage, fenêtre de connexion, session

Voici une croyance qui coûte une semaine : qu’un Mac possède un seul moment appelé avant l’ouverture de session et qu’un client VPN démarre alors ou pas. La machine a en réalité au moins trois moments où l’accès au réseau compte, séparés par qui est autorisé à détenir des identifiants à cet instant. Un client lancé depuis un élément d’ouverture de session ne couvre exactement qu’un seul d’entre eux, et c’est le dernier.

Le mythe selon lequel un seul réglage couvre tout le démarrage

Relisez la page produit et cherchez quelle étape la fonction nomme. Une case intitulée démarrer à l’ouverture de session désigne un élément d’ouverture de session, qui s’exécute après l’existence d’une session utilisateur. Une case intitulée se connecter à la demande signifie que le client ouvre une connexion lorsque le trafic correspond à une règle, ce qui exige encore que le client et ses identifiants soient disponibles.

Ni l’une ni l’autre n’atteint le processus de démarrage. Ce n’est pas une limite que l’éditeur a oublié de retirer ; c’est ce que le système d’exploitation autorise. Avant le déverrouillage du volume, il n’existe aucun système en cours d’exécution depuis lequel lancer un client, et après la fermeture de session les secrets de l’utilisateur partent avec la session. Deux murs distincts, et aucun ne cède devant une autre case à cocher.

Dès que vous séparez les étapes, la question initiale change de forme. Au lieu de demander si le VPN démarre avant l’ouverture de session, vous demandez lequel des trois moments précis doit fonctionner, puis vous découvrez que chacun a un propriétaire différent : la pile de chiffrement, l’extension réseau ou la session utilisateur.

Ce qui se passe réellement à chaque étape

Le démarrage commence par un volume chiffré qu’il faut déverrouiller avant qu’existe un système utilisable pour quoi que ce soit de général. Ce déverrouillage se produit dans un contexte restreint avec un ensemble restreint d’identifiants, et Apple documente clairement que les données chiffrées restent inaccessibles sans un déverrouillage valide.

Vient ensuite la fenêtre de connexion, où le système fonctionne mais où aucune session utilisateur n’existe encore. Une extension en contexte utilisateur a déjà pris fin si l’utilisateur s’est déconnecté, et une extension système globale peut encore tourner, mais tourner n’est pas la même chose que détenir les identifiants dont votre VPN a besoin.

Puis vient la session, où un client normal peut lire le trousseau de connexion, demander un second facteur et appliquer les routes poussées. La plupart des fonctions que les gens décrivent comme avant l’ouverture de session sont en réalité cette étape, déclenchée tôt dans la session et non avant elle.

Pourquoi un launch daemon ne peut pas se connecter à la place d’un utilisateur absent

Le privilège élevé semble devoir résoudre le problème, et il ne le fait pas. Un launch daemon s’exécute comme un processus système sans session utilisateur derrière lui, donc il n’y a pas de trousseau à déverrouiller et personne pour répondre à une invite. Il peut ouvrir une socket et lire un fichier ; ce qu’il ne peut pas faire, c’est devenir l’utilisateur qui possède les identifiants. Le privilège n’est pas l’identité, et c’est exactement là que les deux se confondent.

Ce que les gens construisent dans cet écart, c’est un script contenant un mot de passe, ce qui est un problème pire que celui avec lequel ils ont commencé.

La version honnête de l’exigence est plus étroite. Si la machine doit atteindre une ressource protégée alors que personne n’est présent, l’identité que cette ressource accepte doit être une identité que la machine peut porter sans personne : un certificat d’appareil, un identifiant dans le trousseau système ou un compte dont le second facteur n’est pas une notification vers un téléphone dans la poche de quelqu’un. Concevez cette identité délibérément, et la question de l’étape se répond généralement d’elle-même.

La fonction Windows avant ouverture de session ne se transpose pas

Windows dispose d’un mécanisme documenté d’accès avant ouverture de session pour certains produits d’accès distant, et le nom voyage mieux que la capacité. Une fonction décrite dans un guide de déploiement Windows ne vous dit rien sur la question de savoir si le même éditeur implémente un équivalent sur macOS.

Demandez une déclaration couvrant le matériel Mac, la version de macOS, la version du client et la méthode d’authentification que vous utilisez réellement. Une affirmation générale de prise en charge ne suffit pas, car la différence entre fonctionner et ne pas fonctionner se situe souvent dans l’un de ces quatre.

Si l’éditeur ne peut pas répondre, c’est la réponse. Planifiez l’étape de session et concevez une alternative pour le cas sans surveillance, plutôt que de découvrir l’écart pendant un déploiement.

Ce qu’il faut demander à la place

Écrivez l’exigence dans la langue des étapes. Quelle ressource, nécessaire à qui, dans quel contexte et avec quel délai acceptable lorsque la connexion n’est pas encore là ?

Si la réponse est un utilisateur qui ouvre une session puis a besoin du tunnel, la connexion à la demande et un élément de démarrage suffisent et coûtent peu. Si la réponse est une machine qui redémarre la nuit et doit rendre compte, la conception a besoin d’un chemin de déverrouillage du disque pris en charge, d’une identité d’appareil et d’un processus de récupération qui fonctionne lorsque le réseau ne monte jamais. Si la réponse est une ouverture de session d’organisation qui dépend du tunnel, alors les conceptions d’ouverture de session, d’identité et de VPN doivent être construites ensemble et non achetées séparément.

La documentation FileVault d’Apple est le bon point de départ pour l’étape de déverrouillage. Tout ce qui suit est une question de client et d’identité qu’une déclaration de l’éditeur devrait trancher avant l’achat.