¿Esa corrección de seguridad de OpenVPN tiene siquiera que ver con su instalación?

El consejo de parchear el cliente para que valide certificados es demasiado vago para actuar en consecuencia. Puede describir un defecto de software ya corregido, una compilación antigua de un proveedor o un perfil que nunca pidió la comprobación. Son tres cambios distintos con tres responsables distintos. Actuar según esa frase sin saber cuál de los tres afronta es cómo se modifica un cliente que funciona sin motivo alguno.

Separe las tres afirmaciones

Un defecto de software tiene un aviso, unas versiones afectadas y una versión corregida. Una compilación de proveedor tiene su propio canal de distribución y su propio ritmo de actualización. Una omisión del perfil no tiene ninguna de las dos cosas, porque el ejecutable está bien y la configuración pide menos de lo que suponía. Hasta que la afirmación nombre una de esas tres, no hay nada que probar.

Escriba la afirmación en una sola frase antes de buscarla. Si la frase no puede nombrar qué está roto, la búsqueda no tiene objetivo y todos los resultados parecen relevantes.

Encuentre el ejecutable que realmente se ejecuta

Identifique qué inicia la conexión antes de mirar cualquier versión. Un servicio de distribución, un complemento de escritorio y una aplicación de proveedor pueden usar cada uno un ejecutable o un motor distintos. La versión que imprime cualquier binario que caiga en la ruta de búsqueda del intérprete no es un inventario de la máquina. Lea la unidad o el proceso que realmente realizó la conexión.

systemctl cat openvpn-client@*.service
ps -o pid,cmd -C openvpn
apt-cache policy openvpn network-manager-openvpn

La consulta del paquete informa de lo que los metadatos locales creen instalado y disponible, y esa caché puede estar obsoleta, así que actualícela primero. Tampoco dice nada sobre si el servicio en ejecución cargó un binario instalado hace cinco minutos. Compare el registro del paquete con el proceso que realmente está conectado.

Pruebas del paquete en lugar de impresiones de versión

El mantenimiento de seguridad de las distribuciones a menudo retroporta correcciones, así que una versión upstream que parece más antigua aún puede contener el parche. También ocurre lo contrario: un paquete de un repositorio desconocido no tiene derecho automático al mantenimiento actual. Lea el estado de soporte de la versión, no el número de versión.

Esa distinción es la diferencia entre un hueco real y un número que solo parece antiguo. Anote el repositorio del que vino el paquete, porque la misma cadena de versión puede llegar por canales muy distintos con soportes muy distintos.

La configuración es la otra mitad

Un ejecutable mantenido sigue necesitando un perfil que pida las comprobaciones que usted cree que están en su sitio. Los anclajes de confianza, el rol previsto del par y el nombre de servidor esperado son decisiones relacionadas pero separadas. Una comprobación de rol no es una comprobación de nombre, y ninguna sustituye a la otra. Si el aviso es sobre la configuración, la corrección corresponde a quien posee el perfil.

No instale un parche arbitrario para compensar un perfil no verificado, y no añada una directiva para reparar un defecto de implementación genuino. Ambos errores parecen progreso, y por eso ambos siguen ocurriendo.

Decida con pruebas en el registro

La decisión se desprende de lo que haya establecido. Un paquete afectado y documentado exige su actualización soportada, una plataforma no soportada necesita una ruta de migración, y un cliente de proveedor necesita la orientación de ese proveedor. Una instrucción ambigua necesita un aviso y un componente afectado antes de que cualquiera de esas cosas se aplique.

Mantenga el cliente activo, la versión completa, el aviso y el propietario del perfil juntos en el registro de cambios. Eso es más sólido que una referencia a un tutorial, y es lo que la siguiente persona realmente necesitará.