Por que engadir opt-verify non arranxará o erro de cifrado de OpenVPN

Atopas unha suxestión para engadir opt-verify, engades a liña e o erro de cifrado queda exactamente onde estaba. Ese resultado é previsible, porque a opción nunca negociou un cifrado. Era unha comprobación de coherencia de opcións, obsoleta na 2.6 e eliminada na 2.7, e un perfil que aínda se analiza con ela non impuxo nada por iso.

Axuda saber que facía antes a liña antes de concluír que é a peza que falta. A historia tamén explica por que agora non pode axudar.

Que impoñía antes a opción

O manual da 2.6 marca opt-verify como obsoleta e describe o comportamento anterior: o servidor descarta os clientes cuxas opcións declaradas non coinciden coas súas, comparando cousas como o tipo de dispositivo e a MTU. Esa comprobación tamén depende de que a comprobación de coherencia de opcións siga activada, así que un servidor que funciona con disable-occ nunca a tivo. Fíxate en de que se constrúe a comparación: texto que describe a configuración da outra parte. Non di nada sobre que cifrado usará a canle de datos.

Esa é a primeira razón pola que o indicador non pode reparar un erro de cifrado. A selección de cifrado réxese pola política data-ciphers e polo que ambas as partes admiten, e unha comprobación textual de coherencia nin amplía esa lista nin realiza a negociación. A segunda razón é o alcance: a comprobación trata de se as opcións declaradas parecen compatibles, non da calidade do camiño que resulta.

Que fai a 2.7 cando ve a liña

Na 2.7 a opción xa non está. O analizador aínda recoñece o nome, por iso un perfil antigo se carga sen erro de sintaxe, e informa de que a opción se eliminou en lugar de pasala por alto en silencio. Recoñecer un nome e impoñer un comportamento son cousas distintas, e só a primeira segue a ocorrer. As notas de eliminación dan a razón: unha vez que os parámetros se poden negociar, dúas partes poden lexitimamente ter cadeas de opcións distintas mentres acordan a conexión.

Un perfil que se analiza, por tanto, non é proba de que se executase ningunha comprobación de admisión. Se o teu único sinal é que o cliente se conectou, aprendiches que a sintaxe foi aceptada.

Onde vive realmente o fallo

Conserva o primeiro erro concreto antes de cambiar nada, porque as mensaxes posteriores adoitan ser consecuencias del. Un fallo de negociación da canle de datos pertence á política de cifrado aprobada e ás capacidades que ambas as partes anuncian realmente. Un fallo de versión ou de conxunto TLS pertence á canle de control. Un rexeitamento de certificado necesita a identidade e a cadea de confianza, non un indicador de compatibilidade.

Identifica tamén o motor nos dous extremos. Unha aplicación de escritorio pode incluír unha compilación distinta do binario de liña de ordes co que probaches, e o soporte de opcións difire entre eles. Consulta a documentación dese motor en lugar de supor que todos os programas que importan un perfil se comportan igual.

Substitúe a intención, non só a liña

Se un servidor xestionado máis antigo dependía de verdade da comprobación de coherencia, anota que restrición impoñía antes da actualización. Manter unha opción ignorada nun perfil máis novo non pode preservar esa política, e borrar liñas indiscriminadamente tampouco.

Non respondas a unha suxestión antiga de que todos os cifrados están desactivados habilitando todos os algoritmos históricos.

Tras unha corrección aprobada, revisa os resultados negociados nunha conexión nova e proba a aplicación que o usuario realmente necesita. Mantén a versión do servidor e a política efectiva xunto a ese resultado, para que a seguinte persoa vexa que se acordou e non só que se aceptou.

O obxectivo é unha restrición admitida e un camiño autenticado que funcione, non un indicador herdado que aínda se analiza.