Por que adicionar opt-verify não vai corrigir o seu erro de cifra do OpenVPN

Você encontra uma sugestão para adicionar opt-verify, adiciona a linha, e o erro de cifra fica exatamente onde estava. Esse resultado é previsível, porque a opção nunca negociou uma cifra. Era uma verificação de consistência de opções, obsoleta na 2.6 e removida na 2.7, e um perfil que ainda é analisado com ela não impôs nada por isso.

Ajuda saber o que a linha fazia antes de concluir que ela é a peça que falta. O histórico também explica por que ela não pode ajudar agora.

O que a opção impunha antes

O manual da 2.6 marca opt-verify como obsoleta e descreve o comportamento anterior: o servidor descarta clientes cujas opções declaradas não coincidem com as suas, comparando coisas como o tipo de dispositivo e a MTU. Essa verificação também depende de a verificação de consistência de opções continuar ativa, então um servidor que roda com disable-occ nunca a teve. Note do que a comparação é construída: texto que descreve a configuração da outra parte. Ela não diz nada sobre qual cifra o canal de dados usará.

Esse é o primeiro motivo pelo qual a flag não pode reparar um erro de cifra. A escolha da cifra é regida pela política data-ciphers e pelo que ambas as partes suportam, e uma verificação textual de consistência não amplia essa lista nem realiza a negociação. O segundo motivo é o escopo: a verificação trata de as opções declaradas parecerem compatíveis, não da qualidade do caminho que resulta.

O que a 2.7 faz quando vê a linha

Na 2.7 a opção não existe mais. O analisador ainda reconhece o nome, e é por isso que um perfil antigo carrega sem erro de sintaxe, e informa que a opção foi removida em vez de passá-la em silêncio. Reconhecer um nome e impor um comportamento são coisas diferentes, e só a primeira ainda acontece. As notas de remoção dão o motivo: uma vez que os parâmetros podem ser negociados, duas partes podem legitimamente ter cadeias de opções diferentes enquanto concordam sobre a conexão.

Um perfil que é analisado, portanto, não é prova de que qualquer verificação de admissão tenha sido executada. Se o seu único sinal é que o cliente se conectou, você aprendeu que a sintaxe foi aceita.

Onde a falha realmente está

Guarde o primeiro erro concreto antes de mudar qualquer coisa, porque as mensagens seguintes costumam ser consequências dele. Uma falha de negociação do canal de dados pertence à política de cifra aprovada e às capacidades que ambas as partes realmente anunciam. Uma falha de versão ou de conjunto TLS pertence ao canal de controle. Uma rejeição de certificado exige a identidade e a cadeia de confiança, não uma flag de compatibilidade.

Identifique também o motor nas duas pontas. Um aplicativo de desktop pode trazer uma compilação diferente do binário de linha de comando com que você testou, e o suporte a opções difere entre eles. Consulte a documentação desse motor em vez de supor que todo programa que importa um perfil se comporta da mesma forma.

Substitua a intenção, não apenas a linha

Se um servidor gerenciado mais antigo realmente dependia da verificação de consistência, registre qual restrição ele impunha antes da atualização. Manter uma opção ignorada em um perfil mais novo não pode preservar essa política, e apagar linhas indiscriminadamente também não.

Não responda a uma sugestão antiga de que todas as cifras estão desativadas habilitando todos os algoritmos históricos.

Após uma correção aprovada, examine os resultados negociados em uma conexão nova e teste o aplicativo de que o usuário realmente precisa. Mantenha a versão do servidor e a política efetiva ao lado desse resultado, para que a próxima pessoa veja o que foi acordado e não apenas o que foi aceito.

O objetivo é uma restrição suportada e um caminho autenticado que funcione, não uma flag legada que ainda é analisada.