VPN antes do login no macOS: desbloqueio, janela de login, sessão
O desbloqueio do FileVault, a janela de login e a sessão de utilizador são fases separadas. Um cliente de ambiente de trabalho que arranca no login resolve apenas a última.
Eis uma crença que custa uma semana a quem a tem: que um Mac tem um único momento chamado antes do login e que um cliente VPN ou arranca nesse momento ou não. A máquina tem, na verdade, pelo menos três momentos em que o acesso à rede importa, separados por quem pode deter credenciais nesse ponto. Um cliente lançado a partir de um item de login cobre exatamente um deles, e é o último.
O mito de que uma única definição cobre todo o arranque
Volte a ler a página do produto e procure qual fase a funcionalidade nomeia. Uma caixa com a etiqueta iniciar ao iniciar sessão significa um item de login, que corre depois de existir uma sessão de utilizador. Uma caixa com a etiqueta ligar quando necessário significa que o cliente abre uma ligação quando o tráfego corresponde a uma regra, o que ainda exige que o cliente e as suas credenciais estejam disponíveis.
Nenhuma das duas chega ao processo de arranque. Não é uma limitação que o fornecedor se tenha esquecido de remover; é o que o sistema operativo permite. Antes de o volume ser desbloqueado não há um sistema em execução a partir do qual lançar um cliente, e depois de terminar sessão os segredos do utilizador vão com a sessão. Dois muros separados, e nenhum cede perante outra caixa.
Assim que separa as fases, a pergunta original muda de forma. Em vez de perguntar se a VPN arranca antes do login, pergunta qual dos três momentos concretos tem de funcionar, e então descobre que cada um tem um dono diferente: a pilha de cifragem, a extensão de rede ou a sessão de utilizador.
O que acontece realmente em cada fase
O arranque começa com um volume cifrado que tem de ser desbloqueado antes de existir um sistema utilizável para qualquer coisa de uso geral. Esse desbloqueio ocorre num contexto restrito com um conjunto restrito de credenciais, e a Apple documenta claramente que os dados cifrados permanecem inacessíveis sem um desbloqueio válido.
Depois vem a janela de login, onde o sistema está a correr mas ainda não existe qualquer sessão de utilizador. Uma extensão em contexto de utilizador já terminou se o utilizador terminou sessão, e uma extensão global do sistema pode continuar a correr, mas correr não é o mesmo que deter as credenciais de que a sua VPN precisa.
Depois vem a sessão, onde um cliente normal pode ler o porta-chaves de login, pedir um segundo fator e aplicar as rotas empurradas. A maioria das funcionalidades que as pessoas descrevem como antes do login é, na verdade, esta fase, ativada no início da sessão e não antes.
| 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 |
Porque é que um launch daemon não consegue iniciar sessão por um utilizador ausente
O privilégio elevado parece que devia resolver o problema, e não resolve. Um launch daemon corre como processo do sistema sem qualquer sessão de utilizador por trás, portanto não há porta-chaves para desbloquear nem pessoa para responder a um pedido. Pode abrir um socket e ler um ficheiro; o que não pode é tornar-se o utilizador que possui as credenciais. O privilégio não é identidade, e é exatamente aqui que os dois se confundem.
O que as pessoas constroem nessa lacuna é um script com uma palavra-passe lá dentro, o que é um problema pior do que aquele com que começaram.
A versão honesta do requisito é mais estreita. Se a máquina tem de alcançar um recurso protegido enquanto ninguém está presente, a identidade que esse recurso aceita tem de ser uma que a máquina possa manter sem uma pessoa: um certificado de dispositivo, uma credencial no porta-chaves do sistema ou uma conta cujo segundo fator não seja uma notificação push para um telefone no bolso de alguém. Desenhe essa identidade deliberadamente, e a pergunta da fase responde-se normalmente sozinha.
A funcionalidade do Windows antes do login não se transfere
O Windows tem um mecanismo documentado de acesso antes do login para alguns produtos de acesso remoto, e o nome viaja melhor do que a capacidade. Uma funcionalidade descrita num guia de implementação do Windows não lhe diz nada sobre se o mesmo fornecedor implementa um equivalente no macOS.
Peça uma declaração que cubra o hardware do Mac, a versão do macOS, a versão do cliente e o método de autenticação que realmente utiliza. Uma afirmação genérica de suporte não basta, porque a diferença entre funcionar e não funcionar está muitas vezes num desses quatro.
Se o fornecedor não conseguir responder, é essa a resposta. Planeie a fase da sessão e conceba uma alternativa para o caso sem assistência, em vez de descobrir a lacuna durante uma implementação.
O que pedir em vez disso
Escreva o requisito na linguagem das fases. Que recurso, necessário a quem, em que contexto e com que atraso aceitável quando a ligação ainda não existe?
Se a resposta for um utilizador que inicia sessão e depois precisa do túnel, ligar quando necessário e um item de arranque são suficientes e baratos. Se a resposta for uma máquina que reinicia de noite e tem de reportar, o desenho precisa de um caminho de desbloqueio do disco suportado, de uma identidade de dispositivo e de um processo de recuperação que funcione quando a rede nunca sobe. Se a resposta for o login da organização que depende do túnel, então os desenhos de login, identidade e VPN têm de ser construídos em conjunto e não comprados separadamente.
A documentação FileVault da Apple é o ponto de partida certo para a fase de desbloqueio. Tudo o que vem depois é uma questão de cliente e identidade que uma declaração do fornecedor deve resolver antes da compra.