O serviço OpenVPN falha num perfil que a GUI abre: cinco verificações

Dois lançadores abrem o mesmo perfil numa máquina, e só a GUI se liga. O ficheiro está intacto e o instalador está provavelmente bem; o que difere é o contexto que cada lançador dá ao openvpn.exe. O diretório de trabalho, a identidade da conta e os atributos do ficheiro viajam todos com esse contexto. Verifique-os nessa ordem e pare no primeiro que explicar o erro.

Confirme qual lançador falha

Comece por provar a divisão. Se a GUI se liga e o serviço não, com o mesmo caminho de perfil, o ficheiro é legível por alguém e a pergunta passa a ser quem o lê e de onde. Se ambos falham, o perfil está corrompido e nada disto se aplica. Anote o nome do serviço e o perfil exato que lhe foi indicado carregar.

Um serviço apontado à sua própria pasta de arranque automático pode não estar a carregar o ficheiro que tem aberto num editor. Compare o caminho na configuração do serviço com o caminho na GUI, caráter a caráter, porque um nome de pasta no fim ou uma letra de unidade diferente basta para o levar ao ramo errado.

Onde os caminhos relativos são resolvidos

Um perfil que refere ca.crt ou um script auxiliar apenas pelo nome pede uma pesquisa relativa ao local onde o processo está. A GUI começa na pasta de configuração, por isso esses nomes são resolvidos. Um serviço iniciado pelo gestor de serviços não tem esse ponto de partida, e a pesquisa falha antes de qualquer certificado ser lido. É por isso que o mesmo perfil funciona num lançador e não no outro.

Dê ao wrapper um diretório onde começar, ou torne absoluta cada referência. Reproduzir o contexto da GUI numa linha de comandos é assim:

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

Aumentar a verbosidade desse comando mostra o caminho exato que foi tentado. Faça-o antes de alterar permissões, porque um ficheiro em falta e uma leitura negada exigem correções diferentes. O registo predefinido não os distingue. Um sinalizador extra poupa uma hora de conjeturas.

Quando a identidade do serviço não consegue ler

Um serviço corre como identidade de sistema, não como você. Uma ACL que dá controlo total ao seu utilizador e a mais ninguém falha ali enquanto funciona perfeitamente na sua sessão. Um perfil guardado numa unidade mapeada ou numa partilha autenticada falha pelo mesmo motivo. Confirme as permissões do ficheiro antes de olhar para qualquer outra coisa.

A verificação é uma leitura das permissões efetivas mais uma leitura tentada como a identidade do serviço. Execute a primeira parte a partir de uma linha de comandos elevada:

icacls "C:\VPN\profiles\office\office.ovpn"

Depois tente a mesma leitura como a identidade do serviço, por exemplo com psexec -s -i do Sysinternals, e observe se o ficheiro abre. Se não abrir, nenhuma correção de caminho ajudará. Corrija a ACL ou mova o perfil para um local que a identidade do serviço consiga ler.

A cifragem ao nível do ficheiro é o segundo caso, mais raro. Um perfil marcado com o atributo Encrypting File System é decifrado de forma transparente para o utilizador que o cifrou e permanece ilegível para uma conta de serviço. É por isso que o mesmo ficheiro abre no seu editor e não sob o serviço.

O atributo é visível a partir de uma linha de comandos elevada, e verificá-lo não abre o perfil. Execute os dois comandos e leia a saída:

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

Apagar o atributo torna o ficheiro legível, e também remove a proteção que ele transportava. Se o perfil tiver de ficar protegido, coloque o material secreto onde a identidade do serviço tenha uma concessão explícita em vez de confiar na cifragem por utilizador. Essa disposição sobrevive a uma mudança de palavra-passe, e torna o acesso verificável por alguém diferente da pessoa que cifrou o ficheiro.

Decidir quem é dono do túnel

A GUI pode pedir uma palavra-passe e pode ler um certificado do seu armazenamento de utilizador. O serviço não consegue fazer nenhuma das duas coisas, por isso um perfil que dependa de um segredo interativo nunca arrancará sem supervisão, por muito que os caminhos sejam corrigidos. Esse limite é uma decisão de conceção, não um defeito a contornar. Escolha um único proprietário antes de mudar mais alguma coisa.

Se o túnel tiver de estar ativo antes do início de sessão, dê ao serviço uma fonte de credenciais sem supervisão e a sua própria cópia do perfil. Se só precisar de existir enquanto está à secretária, mantenha-o na GUI e remova a cópia do serviço. Ambos ao mesmo tempo é a configuração que produz conflitos de adaptador e rotas duplicadas.

Esse conflito é normalmente diagnosticado como um erro de configuração em vez de dois proprietários a lutar por um adaptador. O registo de eventos mostrará um processo a falhar a abertura do dispositivo TAP, o que parece um problema de permissões e não é. Conte primeiro os proprietários.

O que o wrapper do serviço lança realmente

O ponto de entrada do serviço é um pequeno wrapper que lê os seus próprios parâmetros guardados e depois inicia openvpn.exe. Quando a linha de comandos no registo de eventos não corresponde à sua expectativa, são esses valores que devem ser inspecionados. Reinstalar repõe-nos nos valores predefinidos e destrói a evidência. Leia-os primeiro.

Os valores vivem no registo sob a chave própria do serviço, e sc qc mostra o caminho do binário que o gestor de serviços vai lançar. Compare esse caminho com a configuração guardada do wrapper antes de editar qualquer um deles.

Substituir o wrapper por um script que controla é mais invasivo, mas dobra a linha de comandos efetiva num único ficheiro legível. Termine com um reinício, e depois leia o registo por perfil até aparecer a primeira linha de arranque bem-sucedida. Um estado de serviço em execução significa apenas que o wrapper não saiu, o que também é verdade quando o seu filho morreu de imediato.