Esborrar key-method d’un perfil d’OpenVPN no canvia res

Un perfil que ha funcionat durant anys de sobte es nega a arrencar, i el missatge esmenta una directiva que ningú no recorda haver afegit: key-method. El resultat de cerca següent suggereix afegir key-method 2 per compatibilitat, un consell d’una altra època. L’analitzador que va rebutjar la línia és actual i no té cap opció d’aquest tipus. Treure la línia arregla l’arrencada i no canvia res en com els dos iguals protegeixen la sessió.

Aquest buit entre el que conté un perfil i el que el protocol fa realment és tot el tema, i explica diverses altres edicions que la gent fa alhora. També explica per què aquestes edicions solen arribar en bloc.

El símptoma és un error d’anàlisi, no un fall de l’apretada de mans

Les opcions es llegeixen abans que s’enviï cap paquet. Un perfil amb una directiva desconeguda falla en aquesta etapa, així que el procés no arriba mai a la xarxa ni produeix mai un error d’apretada de mans. La redacció sol identificar l’opció i el fitxer, cosa que fa d’aquest un dels errors més fàcils d’atribuir. No hi intervenen cap paquet, cap ruta ni cap tallafoc.

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

Si el missatge anomena la directiva, el diagnòstic s’ha acabat: el fitxer conté una cosa que aquesta compilació no accepta. Si el missatge anomena un camí de fitxer, el problema és una inclusió o una clau que falta, que és una altra secció de la mateixa etapa d’arrencada.

El que no has de concloure és que el client o el servidor necessiti un mode de protocol més antic. Un error d’anàlisi és un problema de vocabulari entre el teu fitxer i el binari, i el binari en aquest cas simplement ha deixat caure una paraula del seu vocabulari.

Directiva i format de transmissió són dues coses diferents

L’opció antiga key-method triava com s’emmarcava l’intercanvi de claus TLS, i l’intercanvi modern és el mètode de múltiples paquets que aquesta opció sol·licitava. L’opció va desaparèixer perquè ja no triava res; el format que anomenava es va convertir en l’únic. Per tant, treure la línia deixa la sessió amb el mateix emmarcament que abans. Una edició de text no pot canviar-ho en cap direcció.

Per això reintroduir un binari antic per “restaurar” el mètode 2 és la reparació equivocada. No restaura res excepte un analitzador més antic amb valors per defecte més antics, i et costa les correccions que van venir després. El mateix raonament s’aplica a afeblir una comprovació de certificat o una llista de xifratges amb l’esperança que la connexió torni.

Una comprovació útil és la versió i la configuració analitzada, no la presència de la paraula al fitxer:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

Què cal treure, i de quin fitxer

Edita el fitxer que el procés en execució llegeix realment, i només aquest fitxer. En sistemes empaquetats normalment és el perfil del directori del client o del servidor que indica la unitat, no una còpia al teu directori personal que guardes com a referència. Un perfil generat també es pot reconstruir a partir d’una plantilla, així que un canvi fet només a la còpia desplegada tornarà després de la propera execució d’aprovisionament.

Esborra la línia obsoleta i deixa en pau el punt final, els certificats, la política de xifratge i la configuració del canal de control. Són opcions suportades que el procés necessita i no estan implicades en l’error d’anàlisi. Si el mateix perfil conté altres directives que no reconeixes, comprova cadascuna contra la versió que executes en lloc d’esborrar-ne un grup fins que el procés arrenqui.

Després arrenca la instància prevista i llegeix la seva sortida d’arrencada. Una arrencada neta amb l’oient present és la confirmació que aquesta etapa s’ha acabat; una prova de client després respon una altra pregunta.

Un perfil rebutjat i un client rebutjat semblen iguals

Dos errors produeixen fils de suport semblants i necessiten proves diferents. Un servidor que rebutja la seva pròpia configuració no arrenca mai, així que cap client no s’hi pot connectar. Un servidor que arrenca bé i rebutja un client està en marxa, i el seu registre conté el motiu: un problema de certificat, una opció empenyuda que el client no accepta, una discrepància de xifratge.

L’opció eliminada no és un diagnòstic per al segon cas, i recórrer-hi malbarata la mateixa hora dues vegades. Si el registre del client mostra el rebuig del servidor, llegeix aquest rebuig; si mostra un error local, el fitxer a inspeccionar és el perfil del client. Recórrer a una directiva que ja no existeix endarrereix totes dues investigacions en la mateixa mesura.

Preguntes de compatibilitat que la línia mai no va respondre

Els perfils que circulen amb aquesta directiva solen portar una història sobre una plataforma concreta, i la història sobreviu al motiu tècnic. Un client mòbil o d’escriptori encara necessita un perfil complet compatible: una cadena de certificats de confiança, un xifratge de dades que tots dos extrems acceptin, un mode de canal de control que tots dos extrems implementin, i cap directiva que rebutgi la compilació del client. Cap d’aquestes coses no es decideix per la presència o l’absència de la línia key-method antiga.

La compressió és una qüestió de política separada amb la mateixa forma. Treure una línia key-method no diu res sobre si una directiva de compressió és suportada o acceptable al teu desplegament, i les dues decisions s’han de prendre de manera independent. Esborrar diverses opcions rellevants per a la seguretat alhora fins que alguna cosa connecti és com un perfil que funciona es converteix en un perfil inexplicat.

Mantingues un registre breu del que has tret i per què: l’opció, la versió que la va rebutjar i l’ordre que va mostrar l’error. La propera persona que hereti el perfil necessitarà exactament aquests tres fets, i ara són més barats d’escriure que de reconstruir després.