Como montar um perfil de cliente OpenVPN a partir dos ficheiros emitidos

O seu operador entrega um pacote de CA, um certificado de cliente e a respetiva chave, e o cliente não arranca até estarem ligados num único perfil. O perfil é configuração: aponta para esses ficheiros, não os contém, e editá-lo não o pode transformar num certificado. O percurso começa num portátil já aprovado e termina num perfil que pode iniciar a partir de um diretório conhecido. Não cria uma CA, não inscreve um certificado novo nem toca no servidor.

O objetivo aqui é um cliente de linha de comandos OpenVPN 2.6 para Linux, encaminhado com TUN sobre UDP, com autenticação por certificado.

Reúna apenas os ficheiros do lado do cliente

Trabalhe num diretório protegido e reúna o material de confiança da CA aprovado, o certificado de cliente emitido e a chave privada que lhe corresponde. Neste exemplo os nomes são ca.crt, laptop-a.crt e laptop-a.key. Os nomes dos ficheiros são apenas etiquetas; não dizem nada sobre o que cada ficheiro contém.

Se gerou a chave durante a inscrição, nunca saiu da máquina; do emissor só devem voltar o certificado assinado e a cadeia pública. Verifique se o certificado tem o papel de cliente que o serviço espera. Verifique também se a chave pertence a esse certificado e não a um anterior de uma tentativa prévia. Um par que não coincide produz uma falha TLS muito mais tarde, que parece um problema do servidor.

Deixe a chave privada de assinatura da CA, a chave privada do servidor e os parâmetros DH fora deste pacote.

Ligue os ficheiros num perfil pequeno

O perfil abaixo é deliberadamente curto. Cada linha ou escolhe o ponto final, ou restringe a identidade que o cliente aceitará, ou aponta para um dos três ficheiros.

client
dev tun
proto udp
remote vpn.example.net 1194
nobind

remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key

A linha remote escolhe o ponto final de rede. remote-cert-tls server exige que o par apresente um certificado com papel de servidor. verify-x509-name fixa o nome esperado, aqui vpn-gateway como Common Name do certificado do servidor com o campo de nome predefinido do OpenVPN. Esse valor não é inferido do nome de anfitrião DNS, por isso use o esquema de identidade fornecido pelo operador.

Não descarte essas verificações só porque um ponto final de teste mostra um certificado diferente.

Este perfil base pressupõe que não há um desafio de conta separado nem uma chave de canal de controlo. Se o serviço precisar de auth-user-pass, tls-auth ou tls-crypt, conserve a configuração e o material que lhe deram, porque um segredo de canal de controlo gerado por si não coincidirá com o que o servidor guarda. Conserve também a política de cifra do serviço em vez de importar linhas de compressão ou de cifra de um exemplo antigo.

Torne o diretório de trabalho explícito

Os caminhos relativos seguem o diretório de trabalho do processo, não a localização do ficheiro .ovpn.

Isso surpreende quem move o perfil para uma pasta nova e espera que a chave a acompanhe. Para um diretório escolhido pelo administrador, o comando abaixo muda para um caminho absoluto antes de ler o perfil e as suas referências.

sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn

Um assistente de importação de ambiente de trabalho ou um serviço de sistema podem empacotar as dependências por si e aplicar regras próprias. Também podem usar um diretório de trabalho diferente daquele em que testou. Confirme como o seu método de arranque resolve os caminhos da chave, do certificado e da CA. Mover apenas o ficheiro .ovpn não move a chave privada separada.

Mantenha a chave legível apenas para o utilizador ou a identidade de serviço previstos.

Verifique a entrega, não os nomes dos ficheiros

Antes da primeira ligação autorizada, verifique o ponto final, a identidade do certificado, o emissor e a janela de validade. Depois confirme que as referências aos ficheiros são resolvidas a partir do diretório de trabalho que vai usar realmente. Após ligar, teste o comportamento da aplicação e do DNS que a política de encaminhamento deve fornecer. Três ficheiros legíveis não provam nada sobre a autorização do servidor nem sobre um caminho de recurso utilizável.

Se aparecer um pedido de frase de acesso, pertence à chave privada, não a uma conta de VPN.

Por fim, inventarie o pacote como material de credenciais. Entregar o mesmo certificado e a mesma chave a um segundo portátil copia a identidade, e renomear o ficheiro não lhe dá uma segunda inscrição. É essa a diferença entre montar um perfil e emiti-lo.