Por que um serviço VPN iniciado no boot não consegue ler o seu chaveiro
Uma VPN no boot não tem nenhum agente de segredos desbloqueado de quem tomar emprestado. Leia as flags de segredo da conexão antes de redefinir uma senha que o servidor nunca rejeitou.
Uma conexão que funciona após o login e falha antes geralmente significa que a tentativa no boot não conseguiu obter um segredo, e não que o servidor tenha rejeitado um. A credencial existe; o contexto que a pede, não. Essa única distinção poupa uma redefinição de senha desnecessária.
Siga o pedido: algo inicia a conexão antes de existir uma sessão de desktop, e o armazenamento de segredos que normalmente responde ainda não foi desbloqueado. Os dois contextos discordam sobre quem possui o segredo, e o perfil registra qual deles deve fornecê-lo.
O que o caminho de boot realmente pede
No boot, o NetworkManager inicia como serviço do sistema sem sessão de utilizador, sem D-Bus de sessão e sem chaveiro desbloqueado. Um perfil de conexão ainda pode ser levantado, mas apenas com segredos que o serviço alcance sozinho. Tudo o que pertence a um agente de segredos espera até uma pessoa iniciar sessão e o agente aparecer. O serviço faz exatamente o que diz a sua configuração; é o perfil que precisa mudar.
A falha está escrita na conexão, não escondida num chaveiro.
Ler as flags de segredo numa conexão
Pergunte à conexão o que ela espera, não o que o desktop lembra. A coluna de flags responde à pergunta diretamente, e sobrevive a reinícios no ficheiro de perfil no disco.
Comece pela lista de perfis e confirme qual conexão está configurada para subir sozinha. Depois exporte uma conexão e leia as flags de senha:
nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show nmcli connection show "Work VPN" | grep -i -E "password|secret|key" journalctl -b -u NetworkManager --grep "secret"
O primeiro comando confirma que perfis existem e se algum está configurado para ligação automática, que é como uma tentativa sem supervisão começa. O segundo expõe os valores das flags, e o terceiro mostra o serviço a queixar-se de que nenhum agente respondeu por um determinado segredo. Uma linha de registo que nomeia um segredo como propriedade de um agente é todo o diagnóstico numa frase.
| Flag value | Where the secret lives | Behaviour before login |
|---|---|---|
| 0 | Stored in the connection profile | Available to the system service |
| 1 | Owned by a secret agent | Blocks until the agent is unlocked |
| 2 | Never stored | Prompts on every activation |
| 4 | Not required | Never requested at all |
Por que mover a conexão para o âmbito do sistema muda a resposta
Uma conexão pertencente a um utilizador é ativada sob o agente desse utilizador, e é por isso que funciona perfeitamente assim que o desktop está ativo. Movê-la para o âmbito do sistema retira o agente do caminho, pelo que o mesmo perfil se comporta de forma diferente sem que uma única linha de configuração VPN mude.
Essa mudança é um desenho legítimo e traz um requisito: o segredo tem de ser acessível ao serviço do sistema. Guardá-lo no perfil, fornecê-lo através de uma credencial de âmbito de sistema ou aceitar um pedido interativo no momento certo são todas respostas válidas. Deixar a flag 1 e esperar, não.
Uma chave privada com a sua própria frase-passe acrescenta uma segunda camada. Nem uma senha de conta guardada desbloqueará uma chave que exige uma frase-passe, por isso verifique que segredo a etapa que falha está realmente a pedir antes de mudar alguma coisa.
O que não fazer e o que fazer em vez disso
Tornar cada ficheiro de credenciais legível por todos, ou desativar a autenticação para que nenhum pedido seja necessário, troca um incómodo no arranque por uma exposição permanente. Ambos também escondem a dependência em vez de a resolver, e a próxima atualização da imagem reintroduz a mesma falha.
Nessa etapa use o mecanismo que a sua distribuição documenta para ativação sem supervisão e depois confirme que as flags do perfil correspondem. Verifique o resultado a partir de um arranque limpo, não de uma shell que já tem um agente. Anote o proprietário da conexão, a origem do segredo e a etapa que tem de funcionar, para que uma alteração posterior do arranque automático não possa reintroduzir silenciosamente uma dependência de alguém desbloquear primeiro um desktop. A documentação é a diferença entre um serviço reparado e um que volta a quebrar no próximo trimestre.
Teste a partir de um arranque limpo controlado, não de uma nova tentativa manual após o login. A nova tentativa tem sucesso pelo motivo pelo qual a tentativa no boot falhou, e é exatamente essa a evidência que um teste rápido destrói.