Ficheiro DH ou clave tls-auth? Distinguir dous ficheiros de OpenVPN

Dous ficheiros, dúas directivas e o costume de nomear ambos polo que configuran. Así é como dh.pem acaba nunha liña tls-auth e o cliente falla cunha mensaxe sobre un formato de clave inesperado. A decisión que tes diante non é que ficheiro é máis forte. É que papel necesita realmente o despregamento, e tres condicións resólveno: que intercambio de claves negociará a túa pila TLS, se queres autenticación da canle de control ou non, e se o material debe permanecer secreto.

Responde esas por orde e a pregunta do ficheiro respóndese soa. Se as omites, os nomes das directivas comezan a parecer intercambiables, que é exactamente o estado do que xorde o erro.

Le a etiqueta antes do nome do ficheiro

A primeira liña do ficheiro informa máis que o seu nome, porque un nome é unha convención humana e a etiqueta prodúcea a ferramenta. Os parámetros de Diffie-Hellman levan unha etiqueta PEM BEGIN DH PARAMETERS. Unha clave estática de OpenVPN é unha estrutura completamente distinta, coa súa propia cabeceira e a súa carga hexadecimal.

Renomear non converte nada. Un ficheiro de parámetros chamado ta.key segue sendo parámetros, e unha clave estática chamada dh.pem segue sendo unha clave estática; o analizador le o contido e rexeita a discrepancia. Compróbao antes de editar o perfil:

head -n 1 dh.pem
head -n 1 ta.key

Tres condicións que deciden que ficheiro necesitas

A primeira condición é o intercambio. Un handshake Diffie-Hellman de campo finito necesita un grupo, e a directiva dh é onde o servidor nomea os parámetros para el. Un handshake de curva elíptica non necesita ese ficheiro en absoluto, porque a curva é o conxunto de parámetros. Se o teu servidor só negocia conxuntos ECDHE, un ficheiro DH é peso morto en lugar de forza adicional.

A segunda condición é a autenticación da canle de control, unha función aparte co seu propio material. Un ficheiro tls-auth é unha clave estática compartida que ambos os pares teñen, usada para asinar paquetes da canle de control para que un par non autenticado nin sequera poida completar o handshake. Existe tanto se usas DH de campo finito como se non, e non ten nada que ver cos parámetros do grupo.

A terceira condición é o secreto e a distribución. Os parámetros DH poden publicarse sen debilitar a sesión, porque os valores secretos xéranse por handshake e nunca saen dos pares. Unha clave estática non debe publicarse: son os mesmos bytes en ambos os extremos, non rota por si soa e quen a teña pode producir sinaturas válidas da canle de control. Esas dúas respostas apuntan a regras de trato completamente distintas, e por iso un ficheiro pode estar nun repositorio e o outro non.

Xera o material correcto para cada papel

Usa a ferramenta que produce o formato que a directiva espera en lugar de converter entre elas. Para a clave compartida en OpenVPN 2.6, a forma tipada do xerador declara o propósito explicitamente.

openvpn --genkey tls-auth ta.key

Ese comando crea material secreto novo; non repara nin inspecciona unha clave existente, e executalo de novo dáche unha clave distinta que os outros pares non teñen. Copia o ficheiro resultante aos pares que o necesitan por unha canle que usarías para calquera secreto compartido, e mantén a convención de dirección coherente: con tls-auth, un lado usa key-direction 0 e o outro key-direction 1.

Os parámetros DH, cando os necesitas, veñen da xeración de parámetros e non dun xerador de claves, e a súa procedencia importa aínda que a saída sexa pública. Un grupo extraído dunha fonte descoñecida non se volve fiable por ser público; aínda ten que ser un grupo co que os teus pares estean de acordo e que non quede debilitado polo seu tamaño ou construción.

Que fai dh none e que non fai

dh none é unha directiva real cun significado estreito: non se cargará ningún ficheiro de parámetros de campo finito, porque o handshake usa Diffie-Hellman de curva elíptica. Non é unha abreviatura de «saltar o paso DH» no sentido de debilitar nada, e desde logo non lle di a OpenVPN que acepte outro ficheiro como substituto.

De lela mal seguen dous erros. O primeiro é supoñer que dh none elimina a necesidade de tls-auth, cando as dúas controlan cousas distintas. O segundo é manter unha liña dh obsoleta xunto a unha configuración só de curva e logo preguntarse que ficheiro usa realmente o servidor; se a directiva está presente, o ficheiro lese, e unha ruta rota alí fai fallar o arranque por un motivo sen relación co intercambio que se negociará.

Se o ficheiro equivocado xa está despregado

Restaura o secreto previsto do propietario do perfil e non toques a verificación do certificado mentres o fas. O fallo é unha discrepancia de formato, non un fallo de confianza, e desactivar a verificación para sortear o erro substitúe un problema de arranque por un silencioso.

Logo separa os dous incidentes que a xente adoita fusionar. Publicar un ficheiro de parámetros DH é case inocuo, porque os parámetros eran públicos por deseño. Expor a clave tls-auth é outro suceso: a clave autentica paquetes da canle de control para cada par que a ten, así que a substitución debe coordinarse en todo o despregamento e non aplicarse a un só host.

Unha comprobación de cinco minutos resolve en que caso estás: le a primeira liña de cada ficheiro, confirma a directiva que o referencia e confirma que a distribución do ficheiro coincide co que esixe o material. É un traballo menor que rexenerar unha PKI funcional, e é o que as tres condicións sinalaban todo o tempo.