Como o OpenVPN data-ciphers escolhe a cifra do canal de dados

O túnel sobe, o registro mostra uma cifra e a revisão do perfil continua. Depois chega uma atualização num par e o mesmo perfil falha com uma mensagem sobre nenhuma cifra compartilhada, o que manda as pessoas procurar uma diretiva a eliminar. O útil a entender é que data-ciphers descreve uma negociação, não um ajuste. Um lado oferece uma lista, o outro escolhe dela, e o resultado é um único algoritmo que ambos suportam. Ler essa troca explica a maioria dessas falhas antes de você mudar uma linha.

Dois canais, duas configurações

Uma OpenVPN sessão tem um canal de controle e um canal de dados. O canal de controle executa o aperto de mão TLS que autentica os pares e negocia as chaves. O canal de dados criptografa os pacotes que transportam o seu tráfego.

data-ciphers configura o segundo. O canal de controle tem as suas próprias opções, e as verificações de identidade do perfil são uma terceira questão, separada. Alterar um não corrige o outro, e é por isso que um perfil pode parecer correto e falhar mesmo assim numa etapa específica.

Mantenha os três em caixas separadas quando ler um ficheiro de configuração.

Leia a negociação no registro

O registro do cliente nomeia ambos os resultados quando a conexão tem êxito. Uma linha relata o canal de controle e os seus detalhes TLS, e outra relata a cifra do canal de dados que foi selecionada.

Leia os dois, porque respondem a perguntas diferentes. Uma falha do canal de controle para a conexão antes de qualquer cifra de dados importar. Uma divergência do canal de dados aparece após um aperto de mão bem-sucedido, com uma mensagem sobre nenhuma cifra compartilhada.

Depois compare as listas oferecidas dos dois lados. Um nome que a versão de um par ou o seu back-end criptográfico não fornece não pode ser selecionado, por mais cedo que apareça na lista do outro par.

Como a seleção acontece de fato

O servidor empurra a sua lista data-ciphers para o cliente durante o aperto de mão, e o cliente seleciona a primeira entrada dessa lista que também suporta. A ordem pertence, portanto, à configuração do servidor, não à do cliente.

Esse detalhe explica uma classe de resultados confusos. Reordenar a lista do cliente não muda nada enquanto a lista do servidor decide. Acrescentar uma cifra que o cliente não consegue fornecer também não muda nada, porque o cliente tem de conseguir usar a entrada que escolhe.

Versões mais recentes mudaram a lista padrão e renomearam a opção que a costumava conter, de modo que dois pares em versões diferentes podem discordar sem que ninguém edite um perfil. Verifique a versão de cada lado antes de supor um erro de digitação.

Uma lista não é uma classificação de força em abstrato. É um conjunto de candidatos, e o selecionado é a primeira entrada mutuamente suportada na ordem do servidor. É por isso que duas listas que parecem diferentes podem negociar a mesma cifra. É também por isso que duas listas que parecem idênticas podem falhar.

Os pares mais antigos precisam de uma reserva deliberada

Um par que não consegue negociar de todo, porque é anterior ao mecanismo ou o tem desativado, precisa de um acordo de compatibilidade documentado. A opção de reserva existe exatamente para esse caso e aplica-se aos pares que não participam na negociação.

Isso não é o mesmo que ativar todas as cifras herdadas para fazer desaparecer uma mensagem. Uma lista ampla enfraquece a sessão para cada par, incluindo os que teriam negociado algo forte.

Coordene os dois lados em vez de editar nomes de algoritmos não relacionados. Se uma atualização do servidor removeu uma opção antiga, a correção pertence ao plano de versões, não a uma correria no cliente.

Mantenha a verificação intacta

Uma divergência do canal de dados não é motivo para aceitar um servidor não verificado. A verificação do certificado, o nome de servidor esperado e as definições de proteção do canal de controle são separados da escolha da cifra e devem sobreviver a qualquer mudança de compatibilidade.

Registe em conjunto a cifra de dados negociada, a versão do cliente e a versão do servidor, para que a próxima comparação parta de fatos e não do ficheiro de perfil.

Após uma correção suportada, teste a conexão inicial e uma renegociação, porque uma sessão que se estabelece uma vez ainda pode falhar quando as chaves são renovadas.

Se o túnel se estabelece e os sites continuam a falhar, a cifra já não é a suspeita. Continue com o encaminhamento e o DNS. Ordem de trabalho: leia as duas linhas do registro, compare as duas listas, verifique as versões, acrescente uma reserva apenas para um par que a necessite e volte a testar o caminho de renovação.