VPN no Mac no arranque: o launchd supervisiona a tarefa, não o túnel

A tarefa corre no início de sessão, o registo mostra o cliente a arrancar, mas o túnel nunca sobe. Ou sobe e desaparece uns segundos depois. Em ambos os casos a lista de propriedades estava provavelmente correta. O launchd fez duas promessas quando aceitou a tarefa: vai supervisionar um processo, e esse processo continuará a correr. A VPN precisa de ambas, e um ficheiro XML correto não fornece nenhuma.

Uma lista de propriedades válida não é um serviço a funcionar

O plutil -lint verifica a estrutura. Não consegue dizer se o binário existe, se os argumentos são suportados por esta versão do cliente, ou se a tarefa arranca num contexto onde as credenciais estão disponíveis. São questões semânticas, e explicam a maioria das falhas que parecem problemas do launchd.

plutil -lint /Library/LaunchDaemons/com.example.vpn.plist
launchctl print system/com.example.vpn

Leia a saída do segundo comando em vez de assumir que a tarefa foi carregada. Ela reporta o último estado de saída e se o serviço está a correr, o que distingue «nunca arrancou» de «arrancou e morreu» antes de tocar no perfil.

Os agentes herdam uma sessão de utilizador, os daemons não

A documentação da Apple sobre o launchd separa os agentes por utilizador dos daemons de sistema. Um agente corre no contexto do utilizador com sessão iniciada, com o porta-chaves e o ambiente desse utilizador. Um daemon corre sem essa sessão, e mover uma tarefa para um diretório de sistema não recria as credenciais interativas do utilizador.

É esta distinção que decide o desenho. Se a ligação exige que uma pessoa inicie sessão ou aprove um pedido MFA, o arranjo suportado é uma tarefa na sessão do utilizador que corre após o início de sessão. Se tiver de funcionar sem ninguém com sessão iniciada, o cliente precisa de uma identidade não assistida aprovada, com o seu próprio processo de renovação e revogação. Escolher a linha errada produz uma tarefa que arranca limpa e falha no primeiro passo de autenticação.

Não disfarce a diferença com uma palavra-passe no array de argumentos nem desativando as verificações de certificados. Ambas transformam um requisito de autenticação num segredo permanente num ficheiro legível, e a segunda significa que o túnel autentica tudo o que responde.

A supervisão só funciona se o processo permanecer em primeiro plano

Um cliente que se transforma em daemon devolve o controlo ao launchd de imediato, e o supervisor passa a vigiar um processo que já terminou. O túnel pode estar ativo, mas o launchd pensa que a tarefa falhou, e a sua política de reinício fará algo que não pretendia.

Use o modo de primeiro plano ou de serviço documentado pelo cliente. Se o produto tem a sua própria funcionalidade de arranque suportada, essa funcionalidade já sabe como permanecer em primeiro plano e como entregar a pilha de rede; uma tarefa personalizada é um desenho separado, não uma melhoria dela.

Dê à tarefa um rótulo único, o executável pretendido e um array de argumentos deliberado. Um array não é uma linha de comandos da shell, pelo que pipes e redirecionamentos não funcionam ali, e as aspas comportam-se de forma diferente. Um comando que tem sucesso no terminal de um administrador é, na melhor das hipóteses, uma verificação preliminar.

As credenciais têm de funcionar sem pedido

O funcionamento não assistido desloca o problema das credenciais em vez de o eliminar. Alguém tem de ser dono da identidade, decidir quanto tempo vive e documentar como é substituída. Um certificado sem monitorização de expiração torna-se uma falha com uma data no calendário.

Mantenha os segredos fora dos argumentos e fora da saída padrão da tarefa. Se o cliente suporta ler uma credencial de um armazenamento protegido, use esse caminho, e verifique se o contexto de execução da tarefa consegue chegar ao armazenamento. Um daemon a correr como root normalmente não consegue ler um item do porta-chaves de início de sessão, e é o tipo de detalhe que só aparece no contexto de sistema.

Defina o que significa pronta e teste aí

Um arranque bem-sucedido prova que o processo começou. Não prova que a rede está ativa, que o gateway aceitou a identidade ou que a aplicação privada está acessível. Se outra coisa depende do túnel, precisa de um sinal de prontidão que reflita a ligação, não a hora de arranque da tarefa.

As novas tentativas devem ser limitadas e devem distinguir uma rede ausente de uma credencial rejeitada. Reiniciar a cada falha não repara um certificado expirado e produz um registo cheio de tentativas idênticas que esconde a real.

Aceite a tarefa no contexto em que vai realmente correr: sem rede no arranque, um início de sessão normal, um despertar da suspensão e uma paragem controlada. Depois registe o rótulo da tarefa, a versão do cliente e a revisão do perfil em conjunto, para que a pessoa seguinte herde um serviço atribuível em vez de um ficheiro que outrora funcionou.