Error de autenticación HMAC del paquete OpenVPN: ¿qué capa?

Dos fallos se reportan con el mismo vocabulario y casi no tienen nada en común. Uno es un paquete cuya etiqueta de autenticación no se verificó; el otro es una persona cuyas credenciales fueron rechazadas. Tratar el primero como el segundo le manda a buscar una contraseña que nunca fue el problema.

El mensaje nombra una capa, y el trabajo útil es decidir cuál antes de sustituir cualquier material. Comparar los candidatos uno junto a otro es la forma más rápida de ver la diferencia.

Dos fallos que comparten una palabra

Un error de autenticación de paquete se produce al procesar tráfico: una etiqueta o un resumen en un paquete recibido no coincidía con lo que calculó el receptor. Un rechazo de cuenta ocurre después de analizar un intercambio de inicio de sesión, y nombra a un usuario en lugar de un paquete. Un tercer mensaje, sobre no poder localizar un HMAC en un paquete entrante, es distinto otra vez, porque ahí el paquete llegó sin el elemento de autenticación esperado. El prefijo completo del registro le dice cuál de los tres tiene, y el prefijo suele ser lo primero que se elimina cuando un error se pega en un ticket.

La distinción cambia la reparación. Una exige una configuración de canal coincidente, otra el estado de la cuenta, y la tercera un perfil que no coincide con el oyente al que llegó.

Compare qué cargó realmente el proceso en ejecución

Un archivo correcto en el disco no demuestra nada sobre un proceso que se inició antes de que se editara. Compruebe el perfil seleccionado, el extremo con el que contactó y si el servicio se ha recargado desde el cambio. Confirme también que el extremo pertenece al perfil, ya que otra instancia u otro servicio puede estar escuchando donde el archivo antiguo espera otra cosa.

Reexportar un perfil compatible desde la misma fuente es una comparación barata, porque elimina la deriva entre lo que usted cree configurado y lo que el cliente envía realmente. Generar material de clave nuevo es un paso mucho mayor, y solo ayuda si ambos extremos lo adoptan a la vez. Sustituir un lado localmente recrea la discrepancia que intentaba eliminar.

Compare el canal de control con el canal de datos

Dos mecanismos autentican partes distintas de una conexión y se configuran por separado, como la referencia de opciones 2.6 describe. tls-auth añade un HMAC a los paquetes del canal de control y toma un argumento de dirección que debe ser opuesto en los dos pares, mientras que tls-crypt protege el canal de control con una clave compartida en su lugar. Ninguno de los dos es la comprobación de integridad propia del canal de datos. Con un cifrado de datos AEAD esa comprobación va integrada en el cifrado, así que el auth resumen separado no se usa como con un cifrado que no es AEAD.

Lo que significa que una línea auth copiada de un despliegue no AEAD que funciona puede ser irrelevante en uno AEAD, y un despliegue AEAD puede seguir fallando en el canal de control si la tls-auth clave o su dirección son incorrectas. Compare cada ajuste con el par, no con una configuración recordada.

Compare la corrección con la propiedad que cede

Desactivar la autenticación de paquetes silencia el aviso y elimina la comprobación que encontró la discrepancia, lo que no es lo mismo que reparar el perfil. Pregunte qué propiedad está cediendo y si el diseño se sostiene sin ella.

Lea el primer evento relevante en ambos extremos antes de cambiar nada, y luego cambie solo la discrepancia que nombra.

Si el siguiente intento avanza hasta un error de certificado o de inicio de sesión, eso es progreso y no regresión: la capa de paquetes ya está de acuerdo y la conexión ha avanzado. Anote la configuración que produjo el cambio, para que la siguiente persona herede una explicación en lugar de un misterio.