Per què afegir opt-verify no arreglarà l’error de xifratge d’OpenVPN

Trobeu un suggeriment per afegir opt-verify, afegiu la línia i l’error de xifratge es queda exactament on era. Aquest resultat és previsible, perquè l’opció mai va negociar cap xifratge. Era una comprovació de coherència d’opcions, obsoleta a la 2.6 i eliminada a la 2.7, i un perfil que encara es parseja amb ella no ha imposat res per això.

Ajuda saber què feia abans la línia abans de concloure que és la peça que falta. La història també explica per què ara no pot ajudar.

Què imposava abans l’opció

El manual de la 2.6 marca opt-verify com a obsoleta i descriu el comportament anterior: el servidor descarta els clients les opcions declarades dels quals no coincideixen amb les seves, comparant coses com el tipus de dispositiu i l’MTU. Aquesta comprovació també depèn que la comprovació de coherència d’opcions segueixi activada, així que un servidor que funciona amb disable-occ mai la va tenir. Fixeu-vos de què es construeix la comparació: text que descriu la configuració de l’altra banda. No diu res sobre quin xifratge utilitzarà el canal de dades.

Aquesta és la primera raó per la qual l’indicador no pot reparar un error de xifratge. La selecció de xifratge es regeix per la política data-ciphers i pel que ambdues bandes admeten, i una comprovació textual de coherència no amplia aquesta llista ni fa la negociació. La segona raó és l’abast: la comprovació tracta de si les opcions declarades semblen compatibles, no de la qualitat del camí que en resulta.

Què fa la 2.7 quan veu la línia

A la 2.7 l’opció ja no hi és. L’analitzador encara reconeix el nom, per això un perfil antic es carrega sense error de sintaxi, i informa que l’opció s’ha eliminat en lloc de passar-la per alt en silenci. Reconeixer un nom i imposar un comportament són coses diferents, i només la primera encara passa. Les notes d’eliminació donen la raó: un cop els paràmetres es poden negociar, dues bandes poden legítimament tenir cadenes d’opcions diferents mentre acorden la connexió.

Un perfil que es parseja, doncs, no és prova que s’hagi executat cap comprovació d’admissió. Si el vostre únic senyal és que el client s’ha connectat, heu après que la sintaxi s’ha acceptat.

On viu realment la fallada

Conserveu el primer error concret abans de canviar res, perquè els missatges posteriors solen ser-ne conseqüències. Una fallada de negociació del canal de dades pertany a la política de xifratge aprovada i a les capacitats que ambdues bandes anuncien realment. Una fallada de versió o de conjunt TLS pertany al canal de control. Un rebuig de certificat necessita la identitat i la cadena de confiança, no un indicador de compatibilitat.

Identifiqueu també el motor a les dues bandes. Una aplicació d’escriptori pot incloure una compilació diferent del binari de línia d’ordres amb què vau provar, i el suport d’opcions difereix entre ells. Consulteu la documentació d’aquell motor en lloc de suposar que tots els programes que importen un perfil es comporten igual.

Substituïu la intenció, no només la línia

Si un servidor gestionat més antic depenia de debò de la comprovació de coherència, anoteu quina restricció imposava abans de l’actualització. Mantenir una opció ignorada en un perfil més nou no pot preservar aquesta política, i esborrar línies indiscriminadament tampoc.

No respongueu a un suggeriment antic que tots els xifratges estan desactivats habilitant tots els algorismes històrics.

Després d’una correcció aprovada, reviseu els resultats negociats en una connexió nova i proveu l’aplicació que l’usuari realment necessita. Manteniu la versió del servidor i la política efectiva al costat d’aquest resultat, perquè la següent persona vegi què es va acordar i no només què es va acceptar.

L’objectiu és una restricció suportada i un camí autenticat que funcioni, no un indicador heretat que encara es parseja.