Ce correctif de sécurité OpenVPN concerne-t-il vraiment votre installation ?

Le conseil de corriger le client pour qu’il valide les certificats est trop vague pour agir. Il peut décrire un défaut logiciel corrigé, une ancienne compilation d’un fournisseur ou un profil qui n’a jamais demandé cette vérification. Ce sont trois changements différents avec trois responsables différents. Agir sur cette phrase sans savoir lequel des trois vous est présent, c’est ainsi qu’un client qui fonctionne se fait modifier sans raison.

Séparez les trois affirmations

Un défaut logiciel a un avis, des versions affectées et une version corrigée. Une compilation de fournisseur a son propre canal de distribution et son propre rythme de mise à jour. Une omission de profil n’a ni l’un ni l’autre, car l’exécutable est correct et la configuration demande moins que ce que vous supposiez. Tant que l’affirmation ne nomme pas l’une de ces trois, il n’y a rien à tester.

Écrivez l’affirmation en une seule phrase avant de la chercher. Si la phrase ne peut pas nommer ce qui est cassé, la recherche n’a pas de cible et chaque résultat semble pertinent.

Trouvez l’exécutable qui s’exécute réellement

Identifiez ce qui démarre la connexion avant de regarder la moindre version. Un service de distribution, un greffon de bureau et une application de fournisseur peuvent chacun utiliser un exécutable ou un moteur différents. Une version affichée par n’importe quel binaire présent dans le chemin de recherche du shell n’est pas un inventaire de la machine. Lisez l’unité ou le processus qui a réellement établi la connexion.

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

La requête de paquet indique ce que les métadonnées locales croient installé et disponible, et ce cache peut être périmé, alors rafraîchissez-le d’abord. Elle ne dit rien non plus sur le fait que le service en cours a chargé ou non un binaire installé il y a cinq minutes. Comparez l’enregistrement du paquet au processus réellement connecté.

Des preuves de paquet plutôt que des impressions de version

La maintenance de sécurité des distributions rétroporte souvent des correctifs, si bien qu’une version amont qui paraît plus ancienne peut encore contenir le correctif. L’inverse est vrai aussi : un paquet d’un dépôt inconnu n’a aucun droit automatique à une maintenance à jour. Lisez l’état de support de la version, pas le numéro de version.

Cette distinction est la différence entre une vraie lacune et un numéro qui paraît seulement ancien. Notez le dépôt d’où vient le paquet, car la même chaîne de version peut arriver par des canaux très différents avec des supports très différents.

La configuration est l’autre moitié

Un exécutable maintenu a encore besoin d’un profil qui demande les vérifications que vous croyez en place. Les ancres de confiance, le rôle prévu du pair et le nom de serveur attendu sont des décisions liées mais distinctes. Une vérification de rôle n’est pas une vérification de nom, et aucune ne remplace l’autre. Si l’avertissement porte sur la configuration, le correctif revient à qui possède le profil.

N’installez pas un correctif arbitraire pour compenser un profil non vérifié, et n’ajoutez pas de directive pour réparer un véritable défaut d’implémentation. Les deux erreurs donnent l’impression d’un progrès, c’est pourquoi les deux persistent.

Décidez avec les preuves du dossier

La décision découle de ce que vous avez établi. Un paquet affecté documenté appelle sa mise à jour prise en charge, une plateforme non prise en charge a besoin d’un chemin de migration, et un client de fournisseur a besoin des conseils de ce fournisseur. Une instruction ambiguë a besoin d’un avis et d’un composant affecté avant que l’une de ces mesures s’applique.

Gardez le client actif, la version complète, l’avis et le propriétaire du profil ensemble dans le registre des changements. C’est plus solide qu’une référence à un tutoriel, et c’est ce dont la personne suivante aura réellement besoin.