Falha na autenticação HMAC do pacote OpenVPN: qual camada?

Duas falhas são relatadas com o mesmo vocabulário e quase não têm nada em comum. Uma é um pacote cuja tag de autenticação não foi verificada; a outra é uma pessoa cujas credenciais foram recusadas. Tratar a primeira como a segunda manda você procurar uma senha que nunca foi o problema.

A mensagem nomeia uma camada, e o trabalho útil é decidir qual antes de substituir qualquer material. Comparar os candidatos lado a lado é a forma mais rápida de ver a diferença.

Duas falhas que compartilham uma palavra

Um erro de autenticação de pacote surge durante o processamento do tráfego: uma tag ou um resumo em um pacote recebido não correspondia ao que o receptor havia calculado. Uma recusa de conta acontece depois que uma troca de login é analisada, e ela nomeia um usuário em vez de um pacote. Uma terceira mensagem, sobre não conseguir localizar um HMAC em um pacote de entrada, é diferente de novo, porque ali o pacote chegou sem o elemento de autenticação esperado. O prefixo completo do log informa qual dos três você tem, e o prefixo costuma ser a primeira coisa removida quando um erro é colado em um ticket.

A distinção muda o reparo. Uma exige configurações de canal correspondentes, outra o estado da conta, e a terceira um perfil que não corresponde ao listener alcançado.

Compare o que o processo em execução realmente carregou

Um arquivo correto no disco não prova nada sobre um processo iniciado antes de sua edição. Verifique o perfil selecionado, o endpoint contatado e se o serviço foi recarregado desde a mudança. Confirme também que o endpoint pertence ao perfil, pois outra instância ou outro serviço pode estar escutando onde o arquivo antigo espera outra coisa.

Reexportar um perfil compatível da mesma fonte é uma comparação barata, porque elimina a divergência entre o que você acredita estar configurado e o que o cliente realmente envia. Gerar material de chave novo é um passo muito maior, e só ajuda se as duas pontas o adotarem juntas. Substituir um lado localmente recria a divergência que você tentava remover.

Compare o canal de controle com o canal de dados

Dois mecanismos autenticam partes diferentes de uma conexão e são configurados separadamente, como a referência de opções 2.6 descreve. tls-auth adiciona um HMAC aos pacotes do canal de controle e recebe um argumento de direção que deve ser oposto nos dois pares, enquanto tls-crypt protege o canal de controle com uma chave compartilhada em vez disso. Nenhum dos dois é a verificação de integridade própria do canal de dados. Com uma cifra de dados AEAD essa verificação está embutida na cifra, então o auth resumo separado não é usado como com uma cifra que não seja AEAD.

O que significa que uma linha auth copiada de uma implantação não AEAD que funciona pode ser irrelevante em uma AEAD, e uma implantação AEAD ainda pode falhar no canal de controle se a tls-auth chave ou sua direção estiverem erradas. Compare cada ajuste com o par, não com uma configuração lembrada.

Compare a correção com a propriedade que você abre mão

Desativar a autenticação de pacotes silencia o aviso e remove a verificação que encontrou a divergência, o que não é o mesmo que reparar o perfil. Pergunte de que propriedade você abre mão e se o desenho ainda se sustenta sem ela.

Leia o primeiro evento relevante nas duas pontas antes de mudar qualquer coisa, e então mude apenas a divergência que ele nomeia.

Se a próxima tentativa avançar até um erro de certificado ou de login, isso é progresso e não regressão: a camada de pacotes agora concorda e a conexão seguiu adiante. Anote as configurações que produziram a mudança, para que a próxima pessoa herde uma explicação em vez de um mistério.