Erro de autenticación HMAC do paquete OpenVPN: que capa?

Dous fallos infórmase co mesmo vocabulario e case non teñen nada en común. Un é un paquete cuxa etiqueta de autenticación non se verificou; o outro é unha persoa cuxas credenciais foron rexeitadas. Tratar o primeiro como o segundo mándao buscar un contrasinal que nunca foi o problema.

A mensaxe nomea unha capa, e o traballo útil é decidir cal antes de substituír calquera material. Comparar os candidatos un xunto a outro é a forma máis rápida de ver a diferenza.

Dous fallos que comparten unha palabra

Un erro de autenticación de paquete prodúcese ao procesar tráfico: unha etiqueta ou un resumo nun paquete recibido non coincidía co que calculou o receptor. Un rexeitamento de conta ocorre despois de analizar un intercambio de inicio de sesión, e nomea un usuario en lugar dun paquete. Unha terceira mensaxe, sobre non poder localizar un HMAC nun paquete entrante, é distinta outra vez, porque alí o paquete chegou sen o elemento de autenticación agardado. O prefixo completo do rexistro dinos cal dos tres ten, e o prefixo adoita ser o primeiro que se elimina cando un erro se pega nun ticket.

A distinción cambia a reparación. Unha esixe unha configuración de canle coincidente, outra o estado da conta, e a terceira un perfil que non coincide co oínte ao que chegou.

Compare o que cargou realmente o proceso en execución

Un ficheiro correcto no disco non demostra nada sobre un proceso que comezou antes de que se editase. Comprobe o perfil seleccionado, o extremo co que contactou e se o servizo se recargou desde o cambio. Confirme tamén que o extremo pertence ao perfil, xa que outra instancia ou outro servizo pode estar escoitando onde o ficheiro antigo espera outra cousa.

Reexportar un perfil compatible desde a mesma fonte é unha comparación barata, porque elimina a deriva entre o que cre que está configurado e o que o cliente envía realmente. Xerar material de clave novo é un paso moito maior, e só axuda se ambos os extremos o adoptan á vez. Substituír un lado localmente recrea a discrepancia que intentaba eliminar.

Compare a canle de control coa canle de datos

Dous mecanismos autentican partes distintas dunha conexión e configúranse por separado, como a referencia de opcións 2.6 describe. tls-auth engade un HMAC aos paquetes da canle de control e toma un argumento de dirección que debe ser oposto nos dous pares, mentres que tls-crypt protexe a canle de control cunha clave compartida no seu lugar. Ningún dos dous é a comprobación de integridade propia da canle de datos. Cun cifrado de datos AEAD esa comprobación vai integrada no cifrado, así que o auth resumo separado non se usa como cun cifrado que non é AEAD.

O que significa que unha liña auth copiada dun despregamento non AEAD que funciona pode ser irrelevante nun AEAD, e un despregamento AEAD pode seguir fallando na canle de control se a tls-auth clave ou a súa dirección son incorrectas. Compare cada axuste co par, non cunha configuración recordada.

Compare a corrección coa propiedade que cede

Desactivar a autenticación de paquetes silencia o aviso e elimina a comprobación que atopou a discrepancia, o que non é o mesmo que reparar o perfil. Pregunte que propiedade está cedendo e se o deseño se sostén sen ela.

Lea o primeiro evento relevante nos dous extremos antes de cambiar nada, e despois cambie só a discrepancia que nomea.

Se o seguinte intento avanza ata un erro de certificado ou de inicio de sesión, iso é progreso e non regresión: a capa de paquetes xa está de acordo e a conexión avanzou. Anote a configuración que produciu o cambio, para que a seguinte persoa herde unha explicación en lugar dun misterio.