Esa corrección de seguridade de OpenVPN ten algo que ver coa túa instalación?

O consello de parchear o cliente para que valide certificados é demasiado vago para actuar en consecuencia. Pode describir un defecto de software xa corrixido, unha compilación antiga dun provedor ou un perfil que nunca pediu a comprobación. Son tres cambios distintos con tres responsables distintos. Actuar segundo esa frase sen saber cal dos tres afrontas é como se modifica un cliente que funciona sen motivo ningún.

Separa as tres afirmacións

Un defecto de software ten un aviso, unhas versións afectadas e unha versión corrixida. Unha compilación de provedor ten o seu propio canal de distribución e o seu propio ritmo de actualización. Unha omisión do perfil non ten ningunha das dúas cousas, porque o executable está ben e a configuración pide menos do que supuñas. Ata que a afirmación nomee unha desas tres, non hai nada que probar.

Escribe a afirmación nunha soa frase antes de buscala. Se a frase non pode nomear que está roto, a busca non ten obxectivo e todos os resultados parecen relevantes.

Atopa o executable que realmente se executa

Identifica que inicia a conexión antes de mirar calquera versión. Un servizo de distribución, un complemento de escritorio e unha aplicación de provedor poden usar cada un un executable ou un motor distintos. A versión que imprime calquera binario que caia na ruta de busca do intérprete non é un inventario da máquina. Le a unidade ou o proceso que realmente realizou a conexión.

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

A consulta do paquete informa do que os metadatos locais cren instalado e dispoñible, e esa caché pode estar obsoleta, así que actualízaa primeiro. Tampouco di nada sobre se o servizo en execución cargou un binario instalado hai cinco minutos. Compara o rexistro do paquete co proceso que realmente está conectado.

Probas do paquete en lugar de impresións de versión

O mantemento de seguridade das distribucións adoita retroportar correccións, así que unha versión upstream que parece máis antiga aínda pode conter o parche. Tamén ocorre o contrario: un paquete dun repositorio descoñecido non ten dereito automático ao mantemento actual. Le o estado de soporte da versión, non o número de versión.

Esa distinción é a diferenza entre un oco real e un número que só parece antigo. Anota o repositorio de onde veu o paquete, porque a mesma cadea de versión pode chegar por canles moi distintas con soportes moi distintos.

A configuración é a outra metade

Un executable mantido segue necesitando un perfil que pida as comprobacións que cres que están no seu sitio. As áncoras de confianza, o rol previsto do par e o nome de servidor esperado son decisións relacionadas pero separadas. Unha comprobación de rol non é unha comprobación de nome, e ningunha substitúe a outra. Se o aviso é sobre a configuración, a corrección corresponde a quen posúe o perfil.

Non instales un parche arbitrario para compensar un perfil non verificado, e non engadas unha directiva para reparar un defecto de implementación xenuíno. Ambos os erros parecen progreso, e por iso ambos seguen ocorrendo.

Decide con probas no rexistro

A decisión despréndese do que estableciches. Un paquete afectado e documentado esixe a súa actualización soportada, unha plataforma non soportada necesita unha ruta de migración, e un cliente de provedor necesita a orientación dese provedor. Unha instrución ambigua necesita un aviso e un compoñente afectado antes de que calquera desas cousas se aplique.

Mantén o cliente activo, a versión completa, o aviso e o propietario do perfil xuntos no rexistro de cambios. Iso é máis sólido que unha referencia a un titorial, e é o que a seguinte persoa realmente necesitará.