tls-auth frente a tls-crypt: qué protege cada uno en OpenVPN

Ambas opciones usan un archivo de clave compartido y ambas dificultan la falsificación del tráfico del saludo, por eso se tratan como dos nombres de la misma función. No lo son. Una firma los paquetes de control, la otra también los cifra, y ninguna tiene relación con el cifrado que protege tus datos.

Esa distinción importa cuando un perfil no logra conectarse, cuando una revisión de seguridad pregunta qué protege la clave y cuando alguien supone que el archivo adicional hace que el túnel esté cifrado de alguna forma indefinida.

Qué protege realmente la clave compartida

La clave que usan estas opciones pertenece al canal de control: el intercambio que negocia parámetros, demuestra identidades y deriva las claves de datos. Es un secreto precompartido que ambos extremos deben tener antes de que el saludo pueda continuar. Como se sitúa antes de las comprobaciones de identidad, una clave incorrecta detiene la conversación antes de lo que lo haría una contraseña incorrecta. Ese orden explica por qué el modo de fallo es tan silencioso.

tls-auth usa ese secreto para calcular un HMAC sobre los paquetes de control. Un paquete sin una firma válida se descarta antes de llegar al procesamiento TLS, más costoso, y por eso la opción se describe a menudo como un primer filtro y no como un sustituto de TLS.

tls-crypt va más allá al cifrar el tráfico de control protegido además de autenticarlo. El contenido de los certificados, los nombres de cifrado negociados y otros detalles del saludo ya no son visibles en la red, y un observador sin la clave ni siquiera puede ver qué versión de TLS se está intentando. Para un despliegue preocupado por revelar su huella VPN, esa propiedad es el motivo principal para elegirlo. Sigue siendo un secreto de grupo, no una credencial por usuario.

Ninguno de los mecanismos emite identidades. La clave compartida es un secreto de grupo, y cualquiera que la tenga puede satisfacer esa capa de la comprobación.

Dónde difieren las dos opciones

La diferencia observable es lo que ve un observador. Con tls-auth el saludo es visible pero no verificable sin la clave. Con tls-crypt el saludo es opaco para quien no tenga la clave.

La configuración también difiere. tls-auth se usa con un valor de dirección, así que un lado usa una mitad del material de clave y el otro lado usa la otra mitad. tls-crypt usa una sola clave en ambas direcciones, por lo que la directiva de dirección no forma parte de su esquema.

Las dos opciones son mutuamente excluyentes en las versiones modernas. Un perfil debe llevar una de ellas, no ambas, y el servidor y el cliente deben acordar cuál, con material de clave idéntico. Mantener una directiva antigua junto a una nueva es un residuo habitual de migración. Elimina la inactiva para que el siguiente lector sepa qué capa está realmente en vigor.

Una variante más reciente, tls-crypt-v2, vincula cada cliente con su propia clave envuelta, de modo que revocar un cliente no exige reemitir la clave de grupo. Vale la pena conocerla, pero es una opción distinta y no un sinónimo de ninguna de las dos de aquí.

Por qué un desajuste parece que no pasa nada

Cuando el material compartido no coincide, el otro extremo descarta los paquetes sin decir al remitente por qué. No hay ningún error de autenticación que leer, porque el paquete nunca llegó a la capa que lo produciría.

El cliente reintenta, el servidor no dice nada y el síntoma parece un problema de red. Entonces la gente reinicia el servicio, vuelve a escribir la contraseña de la cuenta o quita la directiva de protección para «probarla», lo que cambia el despliegue en lugar de diagnosticarlo.

Lee en el registro del servidor la primera queja a nivel de paquete en lugar de la última línea de reintento. Confirma que ambos lados llevan la misma opción con material de clave idéntico y que el archivo de clave no se regeneró solo en un lado.

Quitar la directiva no es una reparación segura. Desactiva una capa de protección para cada cliente, y un túnel que funcione después solo demuestra que esa capa era el desajuste.

Qué todavía hay que configurar por separado

Estas opciones no verifican quién es el otro extremo. La validación de certificados, el ancla de confianza y el nombre de servidor esperado siguen siendo requisitos separados, y ninguno se vuelve opcional porque haya una clave compartida.

Tampoco eligen el cifrado de datos. Eso es una negociación separada controlada por los ajustes del canal de datos en ambos extremos, y un túnel protegido con tls-crypt puede seguir usando un cifrado que no pretendías.

Por último, la propia clave compartida necesita manejo. Trátala como un secreto, distribúyela por un canal aprobado y sustitúyela cuando se vaya cualquiera que la tuviera. Como es compartida, su exposición es la exposición de cada extremo que la usa.