Um perfil do OpenVPN que funciona noutro sítio informa que o AES-256-GCM não é encontrado, ou que os pares não partilham qualquer cifra, e o primeiro impulso é editar o perfil. Essas duas mensagens descrevem falhas diferentes. Uma diz que o programa local não tem esse algoritmo; a outra, que ambos os extremos têm algoritmos mas nenhuma escolha comum. Editar o perfil não corrige nenhuma delas até saber qual tem.

Leia o texto exato do erro e o binário que o produziu.

Decida qual erro você tem

A mensagem sobre uma cifra que não é encontrada vem da análise de opções na máquina local, antes de qualquer pacote ser enviado. Significa que o executável à sua frente, ou a biblioteca a que se liga, não oferece esse algoritmo. A mensagem sobre a ausência de cifra comum chega mais tarde, durante a negociação, e implica que ambos os lados suportam cifras mas não concordam numa.

A distinção importa porque uma é um problema de versão do software e a outra de configuração. A primeira resolve-se com um número de versão. A segunda resolve-se comparando duas listas.

Uma lacuna local de capacidade

As compilações comunitárias antigas são anteriores aos valores predefinidos modernos, e uma aplicação de ambiente de trabalho pode trazer o seu próprio motor, diferente do pacote de linha de comandos instalado ao lado. Faça as verificações no executável que realmente iniciou a ligação e depois escolha uma compilação suportada em vez de ensinar um algoritmo novo a um binário antigo.

openvpn --version
openvpn --show-ciphers | grep -i gcm
openvpn --show-tls | head -5

Se o AES-256-GCM não aparecer nessa lista, nenhuma linha do perfil o acrescenta. A solução é um cliente mais recente ou outra compilação, e as restrições do extremo mais antigo passam a ser uma questão de conceção separada.

Nos clientes baseados no OpenVPN 3, o motor e as diretivas aceites diferem da linha comunitária 2.x, pelo que o mesmo texto de perfil pode falhar por razões que nada têm a ver com a lista de cifras.

Uma lacuna de negociação

Quando ambos os pares enumeram o algoritmo, resta a pergunta de que lista cada lado oferece. O OpenVPN comunitário renomeou a diretiva de negociação: ncp-ciphers em 2.4 passou a data-ciphers em 2.5, e em 2.6 a linha cipher antiga serve sobretudo para compatibilidade e recuo, não para definir o conjunto negociado.

Por isso mudar apenas uma linha cipher antiga pode deixar a lista de negociação intacta. A linha antiga ainda importa para o recuo, que é um trabalho separado. Confundir as duas produz edições que não mudam nada visível.

openvpn --version | head -2
grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn

Compare as listas dos dois extremos e a mensagem de rejeição do servidor. Se a interseção estiver vazia, alinhe as listas deliberadamente em vez de copiar um valor de um artigo escrito para outra versão. Uma lista demasiado generosa enfraquece em silêncio cada ligação. Uma lista demasiado estreita exclui o par que queria manter.

Mantenha a compatibilidade explícita

Um recuo para um par antigo é uma decisão com um custo: toda a implementação aceita uma opção mais fraca para que um dispositivo se possa ligar. Escreva-o como tal e limite-o ao par que precisa.

Duas condições decidem o resultado. Se o erro for local, substitua a compilação. Se o erro for de negociação, alinhe as listas nos dois extremos e anote que versões suporta.

Depois comunique o erro exato com a saída de versão e capacidades em anexo. Esse par separa um algoritmo em falta de uma divergência e trava a ronda seguinte de edições especulativas antes de começar.

Artigos relacionados