Rastrear paquetes de control de OpenVPN: tls-auth antes de TLS

Un fallo de tls-auth suele notificarse como un problema de handshake, y nunca lo fue. El HMAC se comprueba en el paquete de control antes de que ocurra cualquier procesamiento TLS, así que una clave o una dirección desajustada produce un fallo que parece un problema de certificado y se decide dos capas antes. Tratar la envoltura como un objeto propio acorta el diagnóstico: lea los campos, confirme que la comprobación se dispara pronto y luego compare las tres cosas que ambos extremos deben acordar.

Lea la envoltura en el orden en que se construye

Un paquete de control lleva un identificador de sesión, el HMAC opcional de tls-auth, información de repetición y acuse de recibo, y un identificador de mensaje fiable, y después viene la carga del tipo de mensaje. Cuando el mensaje es un mensaje de handshake, la carga resulta ser texto cifrado TLS. Esa es toda la relación: el material TLS viaja dentro de un mensaje que la envoltura ya protege. La referencia del protocolo de red de OpenVPN enumera los campos del canal de control en ese orden.

La capa de fiabilidad se confunde fácilmente con criptografía. Los acuses de recibo, la retransmisión y el identificador de mensaje existen para que los mensajes de control lleguen una vez y en orden por un transporte no fiable. No son autenticación, y un identificador de mensaje correcto no demuestra nada sobre quién envió el paquete.

Mantenga esta agrupación como concepto. No es un diagrama de orden de bytes y no basta para calcular una etiqueta, porque los campos que entran en el HMAC dependen de la implementación, la versión y el modo.

Demuestre que la comprobación se dispara antes del handshake

Un receptor que tiene la clave compartida puede verificar el HMAC y descartar un paquete falsificado de inmediato, sin asignar estado de handshake ni hacer trabajo de clave pública. La protección cubre también los paquetes iniciales del handshake, y por eso mismo una clave incorrecta aparece como una conexión fallida y no como un error de autenticación tardío.

Suba la verbosidad del demonio y observe el canal de control en lugar del dispositivo tun:

openvpn --config /etc/openvpn/server.conf --verb 6

Lo que busca es un fallo de verificación HMAC del canal de control notificado a nivel de paquete, antes de cualquier alerta TLS. Una alerta TLS en el registro significa que la envoltura se aceptó y el fallo se desplazó hacia dentro, lo que es otra investigación con otra solución.

El manejo de la dirección también está aquí. Cuando se usa un archivo de clave estática con tls-auth, los dos extremos toman direcciones de clave opuestas, y el protocolo usa esa división para que un paquete capturado no pueda reflejarse de vuelta a su emisor. Invertir la dirección mantiene la clave idéntica y aun así hace fallar cada paquete. Cambie un extremo cada vez y luego reinicie ambos demonios para que la pareja se cargue junta.

Ajuste clave, dirección y digest en ambos extremos

Tres valores deben coincidir y solo uno de ellos es el archivo. El contenido de la clave estática debe ser idéntico en ambos extremos, la dirección debe ser opuesta y el digest usado para el HMAC debe coincidir. Compruebe la configuración antes de tocar el material de clave, porque una sola dirección invertida explica más fallos que un archivo dañado:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Genere el secreto compartido con la herramienta y no con un editor, y mantenga los permisos estrictos:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Las versiones antiguas aceptaban un orden de opciones ligeramente distinto para generar claves, y los perfiles escritos para esas versiones aún circulan. El archivo generado es el mismo tipo de objeto en ambos casos, así que la comprobación es si ambos extremos tienen bytes idénticos, no qué ortografía los produjo.

No confunda tls-auth con tls-crypt. Ambos protegen el canal de control, pero tls-crypt también lo cifra y oculta el handshake a los observadores, y sustituye la división de direcciones por su propio manejo de claves. Un perfil que usa uno no interoperará con un par configurado para el otro, y ningún ajuste de digest cierra esa brecha.

Reproduzca una etiqueta solo a partir del formato real

La reproducción exacta a nivel de byte es una tarea distinta de ejecutar una VPN, y solo funciona con las entradas reales: la implementación y la versión que construyeron el paquete, el digest seleccionado, la dirección y los bytes reales, incluidos el identificador de sesión y la matriz de acuse de recibo. Una representación textual de la lista de campos no son esos bytes.

La longitud de la etiqueta se deriva del digest, así que una suposición de longitud fija se rompe en el momento en que alguien la cambia. Calcule el hash del paquete como lo hace la implementación, no como lo presenta una tabla en una entrada de blog, y compare con una captura tomada del mismo par en lugar de con una expectativa deducida a mano.

Mantenga ese ejercicio lejos de los perfiles de producción. Nada de reproducir una etiqueta le dice si un despliegue debería activar la protección.

Revierta un desajuste sin retirar la protección

La prueba tentadora es borrar tls-auth, ver que la conexión funciona y concluir que la clave era incorrecta. Esa respuesta le cuesta la protección y no enseña nada sobre cuál de los tres valores discrepaba. En su lugar, obtenga la configuración coincidente aprobada del lado del servidor y compare con ella.

Prepare el cambio para que sea reversible. Conserve la configuración y el archivo de clave anteriores del servidor, aplique la pareja corregida, verifique que un cliente completa el handshake y solo entonces elimine la copia de seguridad. Si los clientes fallan después del cambio, restaure los archivos anteriores en lugar de improvisar una tercera variante durante una caída. La restauración debería ser una orden que ya conozca antes de empezar.

Por último, recuerde qué significa una comprobación superada. Demuestra que el par tiene la clave compartida, no que su certificado o cuenta esté autorizado, y no dice nada sobre el cifrado negociado del canal de datos. La autorización y la protección de datos se establecen más tarde, así que una comprobación limpia de la envoltura es un punto de partida y no un veredicto.