tls-auth key-direction: 0 y 1 deben diferir, no coincidir
Con tls-auth los dos extremos necesitan direcciones opuestas, 0 y 1, o ambos deben omitir el ajuste. El mismo número falla, y tls-crypt nunca lo usa.
Un lado del túnel firma el canal de control con una ranura de clave que el otro lado nunca comprueba, y la conexión muere con un error de autenticación antes de que se intercambie un solo certificado. Así se ve un desajuste de dirección en tls-auth, y es determinista: los mismos dos archivos fallan en cada intento, desde cualquier red. Nada en el registro nombra la opción que buscas, por eso la gente reconstruye claves y reemite certificados que nunca estuvieron rotos. La solución es hacer complementarios los dos extremos, o dejar ambos bidireccionales, en lugar de debilitar la verificación.
El fallo ocurre antes de los certificados
Con tls-auth, ambos pares tienen la misma clave compartida y cada uno usa una de dos ranuras derivadas de ella: una ranura firma los paquetes de control salientes, la otra verifica los entrantes. La dirección 0 y la dirección 1 asignan esos papeles en orden opuesto, así que la pareja debe ser complementaria para que las comprobaciones HMAC coincidan. Cuando la asignación se invierte en un lado, el receptor busca una firma en la ranura equivocada y rechaza el paquete. La sesión termina ahí, por eso el error se refiere a la autenticación de paquetes y no a algo que produjera el almacén de certificados.
El determinismo importa para el diagnóstico, porque un problema de tiempo o de ruta deja una huella distinta: cortes intermitentes, un sentido que falla o una sesión que muere solo en una red concreta. Un desajuste de dirección falla en el primer saludo cada vez, y falla igual en otra máquina con los mismos dos archivos. Lee el registro en --verb 4 y encuentra el primer paquete rechazado en lugar de la última línea. Si ese rechazo ocurre antes de cualquier intercambio de certificados, la clave compartida y su dirección son las dos cosas que vale la pena comprobar.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
Dónde vive el número
El manual de OpenVPN 2.6 documenta dos lugares para la dirección: el segundo argumento de tls-auth cuando la clave está en un archivo propio, y una línea key-direction independiente cuando la clave está incrustada en el perfil. Ambos fijan el mismo valor, así que un perfil debe usar una forma u otra, nunca ambas. Omitirlo también es una opción, y pone a ambos pares en una disposición bidireccional que funciona cuando ningún lado nombra una dirección. Dos pares con el mismo número no están en esa disposición: cada uno espera firmar en una ranura y verificar en la otra, y ambos lo hacen en el mismo sentido.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
La forma incrustada es una directiva en su propia línea, no un atributo en la etiqueta de apertura del bloque de clave, y añadir un argumento a esa etiqueta es un error, no un cambio de dirección. La colocación también importa: la directiva queda fuera del bloque al que pertenece, así que un valor escrito dentro del bloque se lee como material de clave. Copia la disposición que pretendía el distribuidor del perfil en lugar de inventar una pareja, porque un perfil que funciona contra un servidor quizá ya esté reflejado en el otro lado.
Qué deja intacto la opción
No cifra el tráfico de aplicaciones. tls-auth pone un HMAC alrededor de los paquetes del canal de control, mientras que el canal de datos está protegido por claves de sesión negociadas durante el saludo, así que una pregunta de rendimiento o de cifrado no tiene nada que ver con el número de dirección. El ajuste tampoco añade una segunda capa de cifrado, y esa es la suposición que manda a la gente a buscar una clave más larga.
No se aplica a tls-crypt, otro mecanismo de canal de control con sus propias opciones y gestión de claves, y no dice nada sobre la identidad del certificado de ningún par. Por tanto, una coincidencia de dirección que funciona solo demuestra que ambos extremos coinciden en cómo autenticar el canal de control, no que se haya validado la cadena de confianza.
Alinea la pareja y vuelve a conectar
Compara las dos configuraciones antes de cambiar ninguna, porque editar el lado que ya era correcto duplica el trabajo. El grep de abajo muestra qué mecanismo elige cada archivo; la ejecución detallada muestra si el canal de control se autenticó siquiera. Guarda ambas salidas, para que el siguiente cambio se pueda comparar con un estado conocido.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
Reinicia ambos pares después de cualquier cambio, porque estas opciones se leen una vez al arrancar y recargar un lado deja la pareja inconsistente durante toda la vida de la sesión antigua. Si el despliegue funciona ahora sin dirección configurada, añadir el ajuste en un par reproduce el fallo con el que empezaste; o dejas ambos o configuras ambos. Cambia un extremo a la vez y guarda el archivo anterior, para que una regresión sea una reversión de dos minutos y no una reconstrucción.
Anota el mecanismo, el archivo de clave y la dirección de cada extremo en las notas de despliegue, porque si no la siguiente persona leerá dos archivos parecidos y supondrá que los números deben concordar entre sí. La dirección es un detalle de coordinación, no una mejora de seguridad: separa las dos direcciones del canal de control y no hace nada más.