tls-auth key-direction: 0 e 1 deben diferir, non coincidir
Con tls-auth os dous extremos necesitan direccións opostas, 0 e 1, ou ambos deben omitir o axuste. O mesmo número falla, e tls-crypt nunca o usa.
Un lado do túnel asina o canal de control cunha ranura de clave que o outro lado nunca comproba, e a conexión morre cun erro de autenticación antes de que se intercambie un só certificado. Así se ve un desaxuste de dirección en tls-auth, e é determinista: os mesmos dous ficheiros fallan en cada intento, desde calquera rede. Nada no rexistro nomea a opción que buscas, por iso a xente reconstrúe claves e reemite certificados que nunca estiveran rotos. A solución é facer complementarios os dous extremos, ou deixar ambos bidireccionais, en lugar de debilitar a verificación.
O fallo ocorre antes dos certificados
Con tls-auth, ambos pares teñen a mesma clave compartida e cada un usa unha de dúas ranuras derivadas dela: unha ranura asina os paquetes de control saíntes, a outra verifica os entrantes. A dirección 0 e a dirección 1 asignan eses papeis en orde oposta, así que a parella debe ser complementaria para que as comprobacións HMAC coincidan. Cando a asignación se inverte nun lado, o receptor busca unha sinatura na ranura equivocada e rexeita o paquete. A sesión remata aí, por iso o erro se refire á autenticación de paquetes e non a algo que producise o almacén de certificados.
O determinismo importa para o diagnóstico, porque un problema de tempo ou de ruta deixa unha pegada distinta: cortes intermitentes, un sentido que falla ou unha sesión que morre só nunha rede concreta. Un desaxuste de dirección falla no primeiro aperto de man cada vez, e falla igual noutra máquina cos mesmos dous ficheiros. Le o rexistro en --verb 4 e atopa o primeiro paquete rexeitado en lugar da última liña. Se ese rexeitamento ocorre antes de calquera intercambio de certificados, a clave compartida e a súa dirección son as dúas cousas que paga a 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 |
Onde vive o número
O manual de OpenVPN 2.6 documenta dous lugares para a dirección: o segundo argumento de tls-auth cando a clave está nun ficheiro propio, e unha liña key-direction independente cando a clave está incrustada no perfil. Ambos fixan o mesmo valor, así que un perfil debe usar unha forma ou a outra, nunca ambas. Omitilo tamén é unha opción, e pon ambos pares nunha disposición bidireccional que funciona cando ningún lado nomea unha dirección. Dous pares co mesmo número non están nesa disposición: cada un espera asinar nunha ranura e verificar na outra, e ambos o fan no mesmo 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
A forma incrustada é unha directiva na súa propia liña, non un atributo na etiqueta de apertura do bloque de clave, e engadir un argumento a esa etiqueta é un erro, non un cambio de dirección. A colocación tamén importa: a directiva queda fóra do bloque ao que pertence, así que un valor escrito dentro do bloque lese como material de clave. Copia a disposición que pretendía o distribuidor do perfil en lugar de inventar unha parella, porque un perfil que funciona contra un servidor quizais xa estea reflectido no outro lado.
Que deixa intacto a opción
Non cifra o tráfico de aplicacións. tls-auth pon un HMAC arredor dos paquetes do canal de control, mentres que o canal de datos está protexido por claves de sesión negociadas durante o aperto de man, así que unha pregunta de rendemento ou de cifrado non ten nada que ver co número de dirección. O axuste tampouco engade unha segunda capa de cifrado, e esa é a suposición que manda a xente buscar unha clave máis longa.
Non se aplica a tls-crypt, outro mecanismo de canal de control coas súas propias opcións e xestión de claves, e non di nada sobre a identidade do certificado de ningún par. Por tanto, unha coincidencia de dirección que funciona só demostra que ambos extremos coinciden en como autenticar o canal de control, non que se validase a cadea de confianza.
Aliña a parella e volve conectar
Compara as dúas configuracións antes de cambiar ningunha, porque editar o lado que xa era correcto duplica o traballo. O grep de abaixo mostra que mecanismo escolle cada ficheiro; a execución detallada mostra se o canal de control se autenticou. Garda ambas saídas, para que o seguinte cambio se poida comparar cun estado coñecido.
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 despois de calquera cambio, porque estas opcións se len unha vez ao arrincar e recargar un lado deixa a parella inconsistente durante toda a vida da sesión antiga. Se o despregamento funciona agora sen dirección configurada, engadir o axuste nun par reproduce o fallo co que comezaches; ou deixas ambos ou configuras ambos. Cambia un extremo á vez e garda o ficheiro anterior, para que unha regresión sexa unha reversión de dous minutos e non unha reconstrución.
Anota o mecanismo, o ficheiro de clave e a dirección de cada extremo nas notas de despregamento, porque se non a seguinte persoa lerá dous ficheiros parecidos e suporá que os números deben concordar entre si. A dirección é un detalle de coordinación, non unha mellora de seguridade: separa as dúas direccións do canal de control e non fai nada máis.