openvpn3 session-start ignora o seu arquivo de credenciais
O cliente 3.x recebe as credenciais no início da sessão e não lê um arquivo salvo. Use o prompt ou o caminho autoload, e saiba o que cada um armazena.
Conecte com o cliente 2.x e o perfil funciona; entregue o mesmo arquivo ao cliente 3.x e ele para num prompt de senha. Entregue --auth-user-pass creds.txt a openvpn3 session-start e o resultado é o mesmo, porque o cliente mais novo não tem um estágio que leia o arquivo. A recusa é deliberada: as credenciais pertencem a uma sessão, e uma sessão é criada por um serviço, não pelo processo no seu terminal. Escolha entre o prompt interativo e o auxiliar autoload, e saiba o que cada um armazena.
Por que o arquivo salvo não tem para onde ir
No projeto mais novo, o gerenciamento de configuração e o de sessões são serviços separados que conversam pelo barramento do sistema. É essa separação que permite a um usuário comum iniciar uma sessão sem que um daemon privilegiado leia em seu nome um arquivo de senha protegido. Credenciais baseadas em arquivo não têm lugar nesse modelo, porque não há uma inicialização do lado do daemon que as leia. A recusa é consequência da arquitetura, não uma funcionalidade ausente.
Vale nomear o padrão antigo para ficar mais fácil desaprendê-lo: um perfil referencia um arquivo de credenciais, e o daemon o lê quando o túnel inicia. No modelo novo, as credenciais pertencem a uma sessão e são fornecidas quando essa sessão começa. openvpn3 session-start --config work.ovpn pede por elas, e --auth-user-pass creds.txt é rejeitado porque nada nesse caminho abriria o arquivo. Toda receita 2.x que você encontrar pressupõe um estágio que não existe mais.
A configuração e as definições locais do site também são separadas, o que explica uma segunda surpresa. Um perfil pode parecer completo enquanto a conexão que ele produz não tem configuração de roteamento e de resolvedor. Essas partes são aplicadas como definições locais do site, separadamente do arquivo importado.
O caminho do prompt e a sessão que ele deixa
Fornecer a senha quando a sessão começa é o fluxo de trabalho pretendido. O cliente pergunta uma vez, entrega as credenciais ao backend da sessão e continua:
openvpn3 session-start --config work.ovpn
openvpn3 sessions-list
Nada é gravado no disco por esse caminho. A sessão também continua rodando depois que o terminal fecha, o que surpreende quem espera que o processo morra com o shell. Esse é o ponto de mover o tratamento de sessões para um serviço. A sessão sobrevive ao terminal que a pediu, e precisa ser parada explicitamente.
Para uma estação de trabalho com uma pessoa na frente, esta também é a opção mais segura, porque não há segredo armazenado a proteger ou esquecer. Ela só é inadequada onde não há ninguém presente para digitar.
Automação sem uma pessoa no teclado
Onde uma máquina precisa se conectar sem uma pessoa, o projeto fornece openvpn3-autoload. Ele lê um diretório de perfis e um descritor correspondente para cada perfil, e o descritor fornece as credenciais em texto simples. O auxiliar é um binário separado, geralmente em /usr/sbin/openvpn3-autoload, não uma opção de session-start. Configurá-lo significa criar o diretório, copiar o perfil com o nome que o descritor espera e escrever o descritor.
Uma configuração por usuário é assim, executada como a conta que será dona da sessão. O modo do diretório mantém outros usuários locais fora:
mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload
O descritor nomeia as credenciais e pede uma inicialização automática. Mantenha o valor da senha fora do controle de versão:
{
"autostart": true,
"user-auth": {
"autologin": true,
"username": "svc-vpn",
"password": "change-this-value"
}
}
Depois invoque o auxiliar uma vez e confirme que a sessão aparece. O segundo comando é a verificação, não outro passo de configuração:
/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list
Na inicialização, uma unidade empacotada chamada openvpn3-autoload.service usa o diretório de todo o sistema /etc/openvpn3/autoload, não o por usuário. Esse local precisa de propriedade de root e de um modo mais restrito, e o descritor ainda guarda a senha em texto claro. A troca é explícita: a senha agora fica no disco, então trate esse diretório como um segredo, exclua-o de backups fora do host e escolha o caminho interativo sempre que houver uma pessoa presente.
Falhas de barramento que parecem falhas de senha
Algumas falhas atribuídas às credenciais não são nada disso. Um erro de permissão que nomeia o caminho de ativação do serviço significa uma de duas coisas: o backend não está ativo, ou o chamador não tem permissão para ativá-lo. Nenhuma edição de perfil mudará nenhuma das duas. Verifique o estado do serviço e a política de barramento fornecida antes de tocar na configuração.
Os comandos abaixo separam as duas. O primeiro informa se o backend está rodando; o segundo mostra erros recentes do barramento:
systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20
A outra leitura errada frequente é uma sessão que aparece e desaparece na hora. Esse padrão geralmente significa que as definições locais do site nunca foram aplicadas, então o túnel subiu sem as rotas e as mudanças de resolvedor que o tornam útil. Leia a sequência em vez da última linha: se a sessão foi criada, se chegou a um estado conectado e se sobreviveu são três fatos separados.
Quando o cliente mais antigo ainda está em uso
O cliente 2.x ainda aceita um arquivo de credenciais, e um chaveiro pode responder ao seu prompt sem que o segredo chegue ao disco. Um wrapper resolve a entrada, então o arquivo nomeia a consulta em vez da senha. Esse arranjo depende de um chaveiro destravado, que um contêiner sem sessão de login ou uma unidade que inicia antes de alguém entrar não podem fornecer. A ferramenta de consulta então relata uma coleção em que não consegue escrever, então o erro parece uma falha de credenciais quando é uma falha de chaveiro.
Antes de construir qualquer coisa disso, verifique se uma definição de keepalive no perfil elimina totalmente a necessidade de reiniciar. Uma sessão que fica no ar nunca chega ao prompt que você está tentando automatizar.