Perfil .ovpn antigo falha no Ubuntu 24.04: quais linhas excluir

O perfil é baixado, importado e então para na linha 12 do arquivo com uma mensagem Unrecognized option que nomeia keysize. Nada na conta mudou, e o servidor continua aceitando outros clientes. O que mudou foi o próprio cliente: o Ubuntu 24.04 instala OpenVPN 2.6, enquanto a exportação foi escrita para o 2.4. O conserto é uma curta série de exclusões, e a ordem importa porque cada opção obsoleta aborta o parsing antes que a próxima chegue a ser lida.

Leia a linha do erro antes de tocar no arquivo

O OpenVPN nomeia o arquivo e a linha em que o parsing parou, então você só consegue corrigir um problema por execução. Inicie o perfil pelo terminal em vez de um applet de área de trabalho, porque o applet costuma engolir o stderr e o número da linha é a única referência confiável que você recebe: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Corrija essa linha, execute de novo e espere que a próxima falha nomeie uma opção diferente.

Um erro de parsing sempre aparece antes de qualquer handshake TLS, então uma mensagem que menciona um certificado já passou da etapa de sintaxe. Essa distinção evita que você edite um arquivo que só está falhando na autenticação. Leia a primeira palavra da mensagem, e não o meio dela.

Três classes de falha, três consertos diferentes

Exportações antigas falham de três maneiras distinguíveis, e juntá-las num único problema é o motivo pelo qual as pessoas reinstalam pacotes que nunca estavam quebrados. O texto da mensagem diz em qual classe você está antes de abrir o arquivo.

• Erros de parsing nomeiam um arquivo e uma linha e param antes que exista qualquer tráfego.
• Erros de negociação conectam e depois relatam que as duas pontas não conseguiram concordar sobre uma cifra compartilhada ou um canal de dados aceitável.
• Erros de autenticação chegam mais longe e nomeiam um certificado, um usuário ou uma credencial rejeitada.

Uma edição de perfil só corrige a primeira classe. A negociação exige uma decisão nas duas pontas do túnel, e uma credencial rejeitada não é problema de sintaxe nenhum. Se a sua mensagem menciona uma cifra compartilhada ou um canal de dados, as exclusões abaixo não mudarão nada.

Exclua as opções que o 2.6 removeu, nesta ordem

Cada uma dessas linhas interrompe o parsing sozinha, então o cliente as relata uma de cada vez. Percorra a lista e execute de novo após cada exclusão.

Remova keysize primeiro, porque não tem equivalente moderno e sua presença costuma marcar uma cifra que o cliente atual recusa de qualquer forma. Depois remova ncp-disable, que controlava a negociação de cifras, foi descontinuado no 2.5 e sumiu no 2.6. Substitua ns-cert-type server por remote-cert-tls server, que declara a mesma intenção por meio de uma verificação suportada.Histórico de mudanças do 2.6 lista as remoções restantes ao lado de suas substituições, então tudo o que o parser ainda recusa tem uma resposta documentada.

Guarde uma cópia do perfil original antes da primeira edição. Os provedores regeneram exportações, e um diff contra o arquivo intocado é a forma mais rápida de separar suas mudanças das deles. Se uma exclusão deixa o cliente iniciar mas o túnel ainda falha,você passou para a classe de negociação e as linhas restantes não são a causa. Coloque a versão do cliente no nome do arquivo para que a próxima pessoa saiba para qual versão as edições apontam.

Mantenha o BF-CBC funcionando apenas como fallback limitado

Alguns provedores ainda terminam em BF-CBC, que o OpenVPN 2.6 não negocia sem ajuda porque a cifra tem um bloco de 64 bits. O conserto estreito é uma lista de fallback mais o provedor legacy do OpenSSL, não um downgrade do cliente inteiro.

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

A primeira linha carrega o provedor legacy para que o OpenSSL ainda consiga instanciar essa cifra, a segunda mantém a negociação moderna para pares que a suportam, e a terceira se aplica só quando o servidor não oferece nada melhor. Isso é um enfraquecimento deliberado do túnel, então registre por que ele existe ao lado do arquivo. Peça ao provedor uma exportação regenerada ao mesmo tempo, já que o fallback é uma ponte e não um destino.

Não recorra a --compat-mode como resposta universal. Ele muda vários comportamentos de uma vez, incluindo os padrões de negociação e renegociação, então você nunca descobre qual mudança importou. Prefira as três linhas explícitas acima, porque cada uma declara seu próprio efeito.

Verifique com o perfil que o cliente realmente carrega

Conexões importadas costumam ser copiadas para um diretório do sistema, então editar o arquivo na sua pasta de downloads pode não mudar nada. Encontre a cópia que roda: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Depois inicie o túnel e leia a linha de log que informa a cifra de canal de dados realmente escolhida. Uma conexão que conclui o handshake no fallback diz que o servidor nunca ofereceu nada moderno.

Teste a partir de uma rede que não seja a que o provedor espera, para que um portal cativo ou uma rede de convidados filtrada não se passe por falha do perfil. Registre a versão do cliente junto com qualquer pedido de suporte.

Com o túnel no ar, envie uma requisição que precise atravessá-lo e uma que não deva, depois confirme que a resposta do resolvedor mudou como você esperava. Se o perfil agora faz parsing mas a conexão ainda falha, você deixou o problema de sintaxe para trás e o texto do erro nomeará a nova classe. Mantenha o arquivo editado em controle de versão ao lado de uma nota que nomeie a versão do OpenVPN que ele visa.