Porque é que o OpenVPN deixou de ligar após uma atualização do Ubuntu?

Os perfis VPN que funcionavam na semana passada quebram após uma atualização de versão do Ubuntu, e o registo raramente menciona a atualização. O que nomeia é a camada que falhou: o aperto de mão TLS, a cifra negociada para o canal de dados, o pacote instalado ou a cópia do OpenSSL que o binário carrega no arranque. Cada camada tem a sua forma de erro e a sua reparação, pelo que a classificação é o primeiro trabalho e a edição o segundo. Trate o perfil como inocente até o registo o nomear.

Que camada falhou: aperto de mão, cifra, pacote ou biblioteca

Leia o registo do cliente antes de tocar no perfil. O primeiro erro na saída é o que identifica a camada; tudo o que é impresso depois costuma ser consequência dessa primeira falha. Quando o cliente não arranca de todo, o registo VPN é o ficheiro errado a abrir.

As queixas sobre certificados e assinaturas, ou uma mensagem sobre o comprimento da chave, vêm do canal de controlo e da política de biblioteca que o rege. Um aviso que começa por DEPRECATED OPTION pertence, em vez disso, à negociação do canal de dados.

Uma linha como Unrecognized option é uma terceira categoria: o novo binário já não aceita uma diretiva que o antigo tolerava, por isso o perfil tem de ser reescrito e não a biblioteca relaxada. As falhas de empacotamento parecem ainda diferentes porque acontecem antes de qualquer código de túnel correr. Um binário ausente, um plugin que não carrega ou um repositório a apontar para o nome de código errado produzem todos essa forma. Quatro sintomas, quatro locais a ver e quase nenhuma sobreposição entre as reparações.

Quando o aperto de mão falha, a política TLS rejeita o certificado

O Ubuntu 22.04 passou o sistema para OpenSSL 3, e o nível de segurança predefinido desse ramo é mais rigoroso com assinaturas de certificados e tamanhos de chave do que o 20.04 era. Um certificado CA assinado com um digest mais antigo, ou uma chave abaixo do limite atual, falham agora durante o aperto de mão. Como ainda nada foi autenticado, o erro lê-se como uma palavra-passe errada ou um servidor morto.

A reparação estreita associa uma cadeia de cifra apenas a esta ligação. No editor de ambiente de trabalho, abra o perfil, vá às definições avançadas e coloque DEFAULT:@SECLEVEL=0 no campo de cifra TLS. O ficheiro de chaves do NetworkManager recebe o mesmo valor em [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Reinicie o NetworkManager e volte a ligar, porque o daemon faz cache dos perfis analisados e, caso contrário, continuará a usar a cópia que já possui. Saiba o que a linha faz antes de a manter: essa definição é um limite sobre vários parâmetros de certificados e chaves, não um nome de cifra, pelo que baixá-la alarga o que o perfil individual aceita. Anote qual servidor a exigiu e retire a definição quando o operador reemitir material atual. Alterar /etc/ssl/openssl.cnf atinge o mesmo limite para todos os programas que leiam esse ficheiro, o que vai muito além da VPN.

O OpenVPN 2.6 exige a cifra listada para a negociação

O Ubuntu 22.10 trouxe o OpenVPN 2.6, e nessa versão --cipher deixa de escolher sozinho o canal de dados. A cifra também tem de estar na lista data-ciphers negociada, senão o cliente imprime um aviso de descontinuação e depois não consegue levantar o túnel.

O plugin do NetworkManager do mesmo período ainda só escrevia a diretiva antiga. Esse detalhe divide o diagnóstico, porque um perfil corrigido à mão pode ligar a partir de uma shell e continuar a falhar a partir do applet do ambiente de trabalho. Acrescente a lista ao ficheiro de ligação em [vpn]:

data-ciphers=AES-256-CBC

Use o valor anunciado pelo servidor, não o de que se lembra; um servidor que oferece AES-256-GCM não negociará com uma lista de cliente que nomeie apenas CBC. Reinicie o gestor e volte a ligar, depois repita a tentativa a partir de uma shell com a cifra passada explicitamente tanto para a negociação como para a alternativa:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Se esse comando levantar o túnel, o servidor, os certificados e as credenciais estão todos sãos, e a única falha restante é a opção guardada do gestor. Um aviso sobre a diretiva keysize pertence à mesma limpeza: comente-a e guarde o ficheiro original ao lado do perfil.

Falhas de pacotes e plugins parecem falhas de VPN

Nem toda a falha após a atualização é criptográfica. Um repositório OpenVPN acrescentado sob um nome de código que a versão não usa produz um pacote que nunca é instalado, por isso compare o que lsb_release -a relata com o ficheiro de lista que acrescentou. Um componente universe em falta ou um bolso de segurança produzem um pacote que não pode ser encontrado de todo. Ambos os casos deixam o perfil intacto e o túnel impossível.

Leia o erro do gestor de pacotes antes do registo VPN. Se o cliente nunca foi instalado, nenhuma edição do perfil produzirá um aperto de mão.

Os perfis de dois fatores que deixam de pedir são a versão em plugin da mesma história. O desafio vem de um plugin de autenticação, e uma atualização que o removeu ou substituiu deixa o perfil intacto enquanto o pedido desaparece. Reinstale o plugin suportado em vez de apagar o segundo fator para a ligação funcionar.

Uma biblioteca de fornecedor pode esconder-se atrás de um erro de política

Um padrão merece reconhecimento porque derrota qualquer reparação de política. Uma ferramenta de configuração de um fornecedor de hardware pode instalar as suas próprias bibliotecas OpenSSL e colocá-las à frente das cópias do sistema no caminho de procura do carregador. O cliente arranca então contra uma biblioteca que ninguém atualizou, e a falha de arranque parece exatamente um certificado rejeitado.

Reinstalar o pacote VPN não altera qual biblioteca é encontrada primeiro, e baixar o nível TLS não alcança uma biblioteca que nunca veio do sistema. Pergunte ao carregador que objetos criptográficos o binário resolve realmente:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Remova ou redirecione a cópia do fornecedor e volte a executar a mesma verificação. A versão esperada tem de ser a que está em uso antes de voltar ao perfil.

Fixar um cliente mais antigo compra tempo, não uma solução

Manter a versão anterior do cliente restaura o túnel enquanto a retenção durar. Também congela as atualizações de segurança desse pacote e agenda a mesma quebra para a próxima atualização, por isso trate-o como uma solução temporária datada e não como uma resolução.

Se mesmo assim o fixar, retenha o pacote explicitamente para que uma atualização não vigiada não possa desfazer a fixação, anote o motivo e a data de revisão e defina um lembrete para a próxima versão de perfil do fornecedor. A condição que vale a pena vigiar é um perfil de servidor que negoceie uma cifra atual; assim que exista, a fixação deixa de ter justificação. Uma fixação não registada, em contrapartida, torna-se numa interrupção que ninguém consegue explicar seis meses depois, porque a pessoa que a aplicou já seguiu em frente e o ficheiro não regista nada.

A próxima vez que uma VPN morrer após uma atualização de versão, faça cinco perguntas por ordem: que camada produziu o primeiro erro, a política TLS rejeitou o certificado, a cifra é negociável nos dois sentidos, o pacote e o seu plugin instalaram-se de facto, e que biblioteca carrega o processo. Só quando as cinco voltarem limpas faz sentido um downgrade.