Renomear uma biblioteca criptográfica não conserta um cliente antigo

Percorra o erro do carregador por ordem: qual ficheiro falta, que arquitetura o binário usa, que símbolo queria e se a falha ocorreu antes ou depois de o processo arrancar. São quatro problemas diferentes, e um link simbólico resolve apenas o primeiro. Fazê-los por ordem evita o resultado habitual em que o cliente arranca e depois falha no primeiro handshake. A lista termina com verificação através do lançador real e não com um teste manual.

Anote o caminho do executável, a sua arquitetura e o primeiro erro literalmente antes de mudar seja o que for.

Quatro falhas diferentes por trás de um erro

Um objeto partilhado em falta é um problema de resolução de ficheiros: o carregador procurou um nome e não encontrou nada. Um símbolo em falta é um problema de interface: o ficheiro existe e não exporta aquilo a que o binário faz referência. Uma divergência de versão do símbolo é a mesma classe com mais detalhe. Um algoritmo não suportado reportado depois do arranque é uma alteração de comportamento dentro de uma biblioteca que carregou com sucesso. Cada um exige uma resposta diferente, e só o primeiro é uma questão de nome.

ldd sobre o binário e readelf -d sobre a sua secção dinâmica mostram o que ele pede, o que normalmente basta para separar um problema de ficheiro de um problema de interface.

O que o OpenSSL 3 exige realmente

O guia de migração para o OpenSSL 3 é direto: as aplicações compiladas contra versões anteriores precisam de, no mínimo, recompilação, e a compatibilidade do código-fonte não é garantida. As interfaces mudaram, e algumas foram descontinuadas ou removidas. Um alias de nome de ficheiro não consegue realizar uma recompilação nem ensinar uma nova interface a um binário antigo. Ligar uma biblioteca mais recente sob um nome com aparência mais antiga produz um programa que pode arrancar e depois falhar num local muito menos óbvio.

Isso é pior do que uma falha limpa. Um erro do carregador nomeia o problema de imediato, enquanto uma falha tardia dentro de uma operação parece um problema de rede ou de credenciais e envia a investigação na direção errada.

Porque é que a biblioteca da distribuição é o local errado

Substituir uma biblioteca da distribuição para satisfazer um único cliente muda o ambiente de todos os programas da máquina, incluindo atualizações de segurança e tudo o que depende da interface existente. Copiar uma biblioteca antiga para junto do binário é mais restrito, e ainda cria uma dependência que alguém tem de manter e corrigir. Nenhuma das duas é um caminho de compatibilidade aprovado, mesmo quando parece funcionar no dia em que é aplicada. Um alias global deixado após a experiência é pior, porque ninguém se lembra porque existe.

Use o cliente e o conjunto de dependências suportados pelo fornecedor para a versão real do sistema operativo, a arquitetura e o gateway. Um formato de pacote que funcionou para uma pessoa não estabelece o caminho atual correto, e uma receita arquivada é evidência sobre o passado.

Verifique o lançador, não o arranque

Após uma substituição suportada, verifique o que o lançador normal resolve: ldd sobre o executável instalado, as versões de biblioteca que nomeia e o ambiente que o serviço transmite. Depois execute a autenticação pretendida e uma operação real. Uma invocação manual com um ambiente modificado prova apenas que a sua shell o consegue arrancar. O lançador, a entrada de ambiente de trabalho ou a unidade de serviço é o que os utilizadores realmente executam.

Se não existir uma compilação suportada, peça ao proprietário da VPN uma alternativa ou um caminho de migração. Mudar silenciosamente para outro protocolo, ou assumir que um cliente com um nome de fornecedor familiar satisfaz o gateway, move a falha em vez de a corrigir.

Onde um arranjo de compatibilidade temporário for inevitável, documente-o, limite-o a esse binário e remova-o quando a compilação suportada chegar.