O erro de segredo inválido vem do contêiner, não da regra de senha

Ver «segredo inválido» costuma produzir uma conclusão: a VPN não gosta de pontuação. Essa conclusão costuma estar errada, porque a mensagem vem muitas vezes do tratamento local antes de qualquer gateway olhar para a conta. Dois desenhos entregam a mesma senha, um campo gráfico e um arquivo de credenciais, e falham em locais diferentes. Compare os contêineres antes de simplificar uma senha que estava correta o tempo todo.

O erro vem antes do gateway

Validação local, um armazenamento de segredos bloqueado, um agente ausente e um arquivo de credenciais malformado produzem falhas que o usuário vive como uma única rejeição. Nenhuma delas envolve o servidor de autenticação. A rejeição do próprio gateway é um evento distinto e costuma chegar com outra mensagem e outro tempo. Ela acontece depois que existe um túnel e as credenciais foram transmitidas.

Então a primeira pergunta não é quais caracteres são legais, mas onde a tentativa parou. Um cliente que nunca abriu uma conexão não foi rejeitado por ninguém. Anote o estágio observado, porque cada passo seguinte depende dessa classificação.

A distinção também muda quem conserta. Um problema de contêiner pertence ao dispositivo e ao dono, enquanto uma rejeição de conta pertence a quem opera o backend de autenticação.

Compare os contêineres, não os caracteres

Um campo de senha gráfico, uma entrada de chaveiro, um arquivo de credenciais de duas linhas e um segredo de automação carregam o mesmo valor em envelopes diferentes. O envelope tem regras próprias, e são essas regras que costumam quebrar. O valor raramente é o problema; o transporte do valor é. Mantenha as duas ideias separadas e o diagnóstico fica mais curto.

Opções do cliente Community OpenVPN 2.6 descrevem esse arquivo de duas linhas para auth-user-pass, incluindo o comportamento quando a linha da senha está ausente: o cliente pede em vez disso. Esse único detalhe explica uma classe de relatos de que ele pede uma senha que já foi fornecida. Também mostra que uma segunda linha vazia é um estado significativo e não uma escolha inofensiva de formatação.

A citação é outra camada: aspas dentro de um arquivo de credenciais comum são armazenadas como dados, enquanto um shell as remove antes de o programa ver qualquer coisa. O mesmo caractere é inofensivo num lugar e estrutural no outro. Uma tabela não pode dizer qual contêiner o cliente usou, então leia a configuração do próprio cliente antes de escolher uma linha.

Quebras de linha também são estruturais. Um arquivo com campos delimitados por linha não pode carregar um valor que contenha uma nova linha, e isso é uma limitação do formato, não um julgamento sobre a força da senha. Use o mecanismo de entrega suportado pela implantação em vez de aparar o segredo para caber num arquivo improvisado.

Construa o arquivo de credenciais sem dano do shell

O caminho local mais seguro mantém o segredo fora do histórico do shell e da lista de argumentos do processo. Leia os dois campos interativamente e depois grave as duas linhas que o cliente espera. Todo o resto pode ficar num arquivo de configuração fácil de revisar.

read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/creds

Os dois primeiros comandos leem o nome de usuário e depois a senha sem ecoá-la, o terceiro grava as duas linhas, o quarto restringe o arquivo e o último inicia o cliente com esse arquivo. Note que read -r preserva barras invertidas, que é exatamente o tipo de detalhe que transforma uma senha que funciona numa que falha quando é omitido.

Evite construir o arquivo com uma variável sem aspas ou um documento here cheio de expansões de shell. Ambos podem transformar caracteres antes de chegarem ao arquivo, e a falha resultante parece uma rejeição da VPN porque a senha no disco é realmente diferente da senha que você conhece. Compare o tamanho do arquivo em bytes com o valor esperado se suspeitar disso, sem imprimir o segredo. Uma diferença de um ou dois bytes é a assinatura de um acidente de citação.

Leia o estágio a partir do primeiro erro

Guarde a primeira mensagem específica de uma tentativa e classifique-a. Um erro de validação local, uma chave privada ausente, um agente de segredos indisponível e uma falha de autenticação do gateway são quatro resultados diferentes com quatro donos diferentes. Apenas um deles é sobre a conta.

Se o gateway está realmente rejeitando uma credencial entregue corretamente, verifique a conta, o backend de autenticação e qualquer desafio exigido com o administrador. Uma falha de autenticação genérica não nomeia um caractere proibido.

Restaure o valor aprovado pelo mecanismo correto em vez de reduzi-lo a letras e dígitos. A política de senhas pertence ao operador, e um contorno que a derrota em silêncio não é uma correção. Ele também esconde o defeito real da próxima pessoa, que encontrará o mesmo erro com uma senha mais fraca e nenhuma ideia melhor.