Apagar key-method de um perfil OpenVPN não muda nada

Um perfil que funcionou durante anos de repente recusa-se a arrancar, e a mensagem nomeia uma diretiva que ninguém se lembra de ter adicionado: key-method. O resultado de pesquisa seguinte sugere adicionar key-method 2 por compatibilidade, um conselho de outra época. O analisador que rejeitou a linha é atual e não tem essa opção de todo. Remover a linha corrige o arranque e não muda nada na forma como os dois pares protegem a sessão.

É precisamente essa lacuna entre o que um perfil contém e o que o protocolo faz realmente que é todo o tema aqui, e explica várias outras edições que as pessoas fazem ao mesmo tempo. Explica também porque é que essas edições costumam chegar em bloco.

O sintoma é um erro de análise, não uma falha do aperto de mão

As opções são lidas antes de qualquer pacote ser enviado. Um perfil com uma diretiva desconhecida falha nessa fase, pelo que o processo nunca chega à rede e nunca produz um erro de aperto de mão. A redação costuma identificar a opção e o ficheiro, o que torna esta uma das falhas mais fáceis de atribuir. Não estão envolvidos pacotes, rotas nem firewalls.

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

Se a mensagem nomear a diretiva, o diagnóstico está concluído: o ficheiro contém algo que esta compilação não aceita. Se a mensagem nomear um caminho de ficheiro, o problema é uma inclusão ou uma chave em falta, o que é outra secção da mesma fase de arranque.

O que não deve concluir é que o cliente ou o servidor precisam de um modo de protocolo mais antigo. Uma falha de análise é um problema de vocabulário entre o seu ficheiro e o binário, e o binário neste caso simplesmente deixou cair uma palavra do seu vocabulário.

Diretiva e formato de transmissão são duas coisas diferentes

A antiga opção key-method escolhia como o intercâmbio de chaves TLS era enquadrado, e o intercâmbio moderno é o método de vários pacotes que essa opção outrora pedia. A opção desapareceu porque já não escolhia nada; o formato que nomeava tornou-se o único. Remover a linha deixa, portanto, a sessão com o mesmo enquadramento de antes. Uma edição de texto não pode mudar isso em nenhuma direção.

É por isso que reintroduzir um binário antigo para «restaurar» o método 2 é a reparação errada. Não restaura nada além de um analisador mais antigo com valores predefinidos mais antigos, e custa-lhe as correções que vieram depois. O mesmo raciocínio se aplica a enfraquecer uma verificação de certificado ou uma lista de cifras na esperança de que a ligação volte.

Uma verificação útil é a versão e a configuração analisada, não a presença da palavra no ficheiro:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

O que remover, e de que ficheiro

Edite o ficheiro que o processo em execução lê realmente, e apenas esse ficheiro. Em sistemas empacotados é normalmente o perfil no diretório do cliente ou do servidor indicado pela unidade, não uma cópia no seu diretório pessoal que guarda como referência. Um perfil gerado também pode ser reconstruído a partir de um modelo, pelo que uma alteração feita apenas na cópia implementada voltará após a próxima execução de aprovisionamento.

Apague a linha obsoleta e deixe em paz o ponto final, os certificados, a política de cifras e as definições do canal de controlo. São opções suportadas de que o processo precisa e não estão implicadas no erro de análise. Se o mesmo perfil contiver outras diretivas que não reconhece, verifique cada uma contra a versão que executa em vez de apagar um grupo delas até o processo arrancar.

Depois inicie a instância pretendida e leia a sua saída de arranque. Um arranque limpo com o ouvinte presente é a confirmação de que esta fase terminou; um teste de cliente a seguir responde a outra pergunta.

Um perfil rejeitado e um cliente rejeitado parecem-se

Duas falhas produzem fios de suporte semelhantes e exigem provas diferentes. Um servidor que rejeita a sua própria configuração nunca arranca, pelo que nenhum cliente se lhe pode ligar. Um servidor que arranca bem e recusa um cliente está em execução, e o seu registo contém o motivo: um problema de certificado, uma opção empurrada que o cliente não aceita, uma discrepância de cifra.

A opção removida não é um diagnóstico para o segundo caso, e recorrer a ela desperdiça a mesma hora duas vezes. Se o registo do cliente mostrar a recusa do servidor, leia essa recusa; se mostrar um erro local, o ficheiro a inspecionar é o perfil do cliente. Recorrer a uma diretiva que já não existe atrasa ambas as investigações na mesma medida.

Perguntas de compatibilidade a que a linha nunca respondeu

Os perfis que circulam com esta diretiva costumam trazer uma história sobre uma plataforma concreta, e a história sobrevive ao motivo técnico. Um cliente móvel ou de secretária continua a precisar de um perfil completo suportado: uma cadeia de certificados fidedigna, uma cifra de dados aceite por ambos os extremos, um modo de canal de controlo implementado por ambos os extremos e nenhuma diretiva que a compilação do cliente rejeite. Nada disso é decidido pela presença ou ausência da antiga linha key-method.

A compressão é uma questão de política separada com a mesma forma. Remover uma linha key-method não diz nada sobre se uma diretiva de compressão é suportada ou aceitável na sua implementação, e as duas decisões devem ser tomadas de forma independente. Apagar várias definições relevantes para a segurança de uma vez até algo ligar é a forma como um perfil que funciona se torna um perfil sem explicação.

Mantenha um registo breve do que removeu e porquê: a opção, a versão que a rejeitou e o comando que mostrou o erro. A próxima pessoa que herdar o perfil vai precisar exatamente desses três factos, e é mais barato escrevê-los agora do que reconstruí-los depois.