Essa correção de segurança do OpenVPN tem sequer a ver com a sua instalação?

O conselho de aplicar um patch ao cliente para que valide certificados é vago demais para agir. Pode descrever um defeito de software já corrigido, uma compilação antiga de um fornecedor ou um perfil que nunca pediu essa verificação. São três mudanças diferentes com três responsáveis diferentes. Agir com base nessa frase sem saber qual das três enfrenta é como um cliente que funciona acaba modificado sem motivo.

Separe as três afirmações

Um defeito de software tem um aviso, versões afetadas e uma versão corrigida. Uma compilação de fornecedor tem o seu próprio canal de distribuição e o seu próprio ritmo de atualização. Uma omissão no perfil não tem nenhuma das duas, porque o executável está bem e a configuração pede menos do que supunha. Até que a afirmação nomeie uma dessas três, não há nada para testar.

Escreva a afirmação numa única frase antes de a procurar. Se a frase não conseguir nomear o que está quebrado, a busca não tem alvo e todos os resultados parecem relevantes.

Encontre o executável que realmente corre

Identifique o que inicia a ligação antes de olhar para qualquer versão. Um serviço de distribuição, um plugin de ambiente de trabalho e uma aplicação do fornecedor podem usar cada um um executável ou motor diferentes. A versão impressa por qualquer binário que esteja por acaso no caminho de pesquisa da shell não é um inventário da máquina. Leia a unidade ou o processo que realmente efetuou a ligação.

systemctl cat openvpn-client@*.service
ps -o pid,cmd -C openvpn
apt-cache policy openvpn network-manager-openvpn

A consulta ao pacote informa o que os metadados locais consideram instalado e disponível, e essa cache pode estar desatualizada, pelo que deve refrescá-la primeiro. Também não diz nada sobre se o serviço em execução carregou um binário instalado há cinco minutos. Compare o registo do pacote com o processo que está realmente ligado.

Provas do pacote em vez de impressões da versão

A manutenção de segurança das distribuições frequentemente retroporta correções, por isso uma versão upstream que parece mais antiga pode ainda conter o patch. Também acontece o contrário: um pacote de um repositório desconhecido não tem direito automático à manutenção atual. Leia o estado de suporte da versão, não o número da versão.

Essa distinção é a diferença entre uma lacuna real e um número que apenas parece antigo. Registe o repositório de onde veio o pacote, porque a mesma cadeia de versão pode chegar por canais muito diferentes com apoios muito diferentes.

A configuração é a outra metade

Um executável mantido continua a precisar de um perfil que peça as verificações que julga estarem em vigor. As âncoras de confiança, o papel pretendido do par e o nome de servidor esperado são decisões relacionadas mas separadas. Uma verificação de papel não é uma verificação de nome, e nenhuma substitui a outra. Se o aviso for sobre configuração, a correção pertence a quem possui o perfil.

Não instale um patch arbitrário para compensar um perfil não verificado, e não acrescente uma diretiva para reparar um defeito de implementação genuíno. Ambos os erros parecem progresso, e é por isso que ambos continuam a acontecer.

Decida com provas no registo

A decisão decorre do que estabeleceu. Um pacote afetado documentado exige a sua atualização suportada, uma plataforma não suportada precisa de um caminho de migração, e um cliente de fornecedor precisa da orientação desse fornecedor. Uma instrução ambígua precisa de um aviso e de um componente afetado antes de qualquer dessas coisas se aplicar.

Mantenha o cliente ativo, a versão completa, o aviso e o proprietário do perfil juntos no registo de alterações. Isso é mais forte do que uma referência a um tutorial, e é o que a próxima pessoa realmente vai precisar.