Fitxer DH o clau tls-auth? Com distingir dos fitxers d’OpenVPN

Dos fitxers, dues directives i el costum de batejar tots dos pel que configuren. Així és com dh.pem acaba en una línia tls-auth i el client falla amb un missatge sobre un format de clau inesperat. La decisió que tens al davant no és quin fitxer és més fort. És quin paper necessita realment el desplegament, i tres condicions ho resolen: quin intercanvi de claus negociarà la teva pila TLS, si vols autenticació del canal de control o no, i si el material ha de romandre secret.

Respon aquestes per ordre i la pregunta del fitxer es respondrà sola. Si les saltes, els noms de les directives comencen a semblar intercanviables, que és exactament l’estat del qual sorgeix l’error.

Llegeix l’etiqueta abans que el nom del fitxer

La primera línia del fitxer és més informativa que el seu nom, perquè un nom és una convenció humana i l’etiqueta la produeix l’eina. Els paràmetres de Diffie-Hellman porten una etiqueta PEM BEGIN DH PARAMETERS. Una clau estàtica d’OpenVPN és una estructura completament diferent, amb la seva pròpia capçalera i càrrega hexadecimal.

Canviar el nom no converteix res. Un fitxer de paràmetres anomenat ta.key continua sent paràmetres, i una clau estàtica anomenada dh.pem continua sent una clau estàtica; l’analitzador llegeix el contingut i rebutja la discrepància. Comprova-ho abans d’editar el perfil:

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

Tres condicions que decideixen quin fitxer necessites

La primera condició és l’intercanvi. Un handshake Diffie-Hellman de camp finit necessita un grup, i la directiva dh és on el servidor nomena els paràmetres per a ell. Un handshake de corba el·líptica no necessita aquell fitxer gens, perquè la corba és el conjunt de paràmetres. Si el teu servidor només negocia conjunts ECDHE, un fitxer DH és pes mort i no força addicional.

La segona condició és l’autenticació del canal de control, una funció separada amb el seu propi material. Un fitxer tls-auth és una clau estàtica compartida que tenen tots dos parells, feta servir per signar paquets del canal de control perquè un parell no autenticat no pugui ni tan sols completar el handshake. Existeix tant si uses DH de camp finit com si no, i no té res a veure amb els paràmetres del grup.

La tercera condició és el secret i la distribució. Els paràmetres DH es poden publicar sense debilitar la sessió, perquè els valors secrets es generen per a cada handshake i mai no surten dels parells. Una clau estàtica no s’ha de publicar: són els mateixos bytes als dos extrems, no rotan per si sols i qui la tingui pot produir signatures vàlides del canal de control. Aquestes dues respostes apunten a regles de tracte completament diferents, i per això un fitxer pot estar en un repositori i l’altre no.

Genera el material correcte per a cada paper

Fes servir l’eina que produeix el format que la directiva espera en lloc de convertir entre elles. Per a la clau compartida a OpenVPN 2.6, la forma tipada del generador declara l’objectiu explícitament.

openvpn --genkey tls-auth ta.key

Aquesta ordre crea material secret nou; no repara ni inspecciona una clau existent, i tornar-la a executar et dona una clau diferent que els altres parells no tenen. Copia el fitxer resultant als parells que el necessiten per un canal que faries servir per a qualsevol secret compartit, i mantén la convenció de direcció coherent: amb tls-auth, un costat fa servir key-direction 0 i l’altre key-direction 1.

Els paràmetres DH, quan els necessites, vénen de la generació de paràmetres i no d’un generador de claus, i la seva procedència importa encara que la sortida sigui pública. Un grup extret d’una font desconeguda no es fa fiable pel fet de ser públic; encara ha de ser un grup amb què els teus parells estiguin d’acord i que no quedi debilitat per la seva mida o construcció.

Què fa dh none i què no fa

dh none és una directiva real amb un significat estret: no es carregarà cap fitxer de paràmetres de camp finit, perquè el handshake fa servir Diffie-Hellman de corba el·líptica. No és una abreviatura de «salta el pas DH» en el sentit de debilitar res, i de cap manera diu a OpenVPN que accepti un altre fitxer com a substitut.

Dues errades se segueixen de llegir-la malament. La primera és suposar que dh none elimina la necessitat de tls-auth, quan les dues controlen coses diferents. La segona és mantenir una línia dh obsoleta al costat d’una configuració només de corba i després preguntar-se quin fitxer fa servir realment el servidor; si la directiva hi és, el fitxer es llegeix, i un camí trencat allà fa fallar l’arrencada per un motiu sense relació amb l’intercanvi que es negociarà.

Si el fitxer equivocat ja s’ha desplegat

Restaura el secret previst del propietari del perfil i no toquis la verificació del certificat mentre ho fas. La fallada és una discrepància de format, no una fallada de confiança, i desactivar la verificació per passar l’error substitueix un problema d’arrencada per un de silenciós.

Després separa els dos incidents que la gent sol fusionar. Publicar un fitxer de paràmetres DH és gairebé inofensiu, perquè els paràmetres eren públics per disseny. Exposar la clau tls-auth és un altre esdeveniment: la clau autentica paquets del canal de control per a cada parell que la té, així que la substitució s’ha de coordinar a tot el desplegament i no aplicar-se a un sol amfitrió.

Una comprovació de cinc minuts resol en quin cas ets: llegeix la primera línia de cada fitxer, confirma la directiva que hi fa referència i confirma que la distribució del fitxer coincideix amb el que el material exigeix. És una feina més petita que regenerar una PKI funcional, i és la que les tres condicions assenyalaven tot el temps.