Quella correzione di sicurezza di OpenVPN riguarda davvero la tua installazione?

Il consiglio di applicare una patch al client affinché convalidi i certificati è troppo vago per agire. Può descrivere un difetto software già corretto, una vecchia build di un fornitore o un profilo che non ha mai chiesto quel controllo. Sono tre modifiche diverse con tre responsabili diversi. Agire su quella frase senza sapere quale delle tre ti trovi davanti è il modo in cui un client funzionante viene modificato senza motivo.

Separa le tre affermazioni

Un difetto software ha un avviso, versioni interessate e una versione corretta. Una build di fornitore ha il proprio canale di distribuzione e il proprio ritmo di aggiornamento. Un’omissione del profilo non ha nessuna delle due, perché l’eseguibile va bene e la configurazione chiede meno di quanto supponessi. Finché l’affermazione non nomina una di queste tre, non c’è nulla da testare.

Scrivi l’affermazione in una sola frase prima di cercarla. Se la frase non riesce a nominare ciò che è rotto, la ricerca non ha bersaglio e ogni risultato sembra pertinente.

Trova l’eseguibile che gira davvero

Identifica cosa avvia la connessione prima di guardare qualsiasi versione. Un servizio di distribuzione, un plugin desktop e un’applicazione del fornitore possono usare ciascuno un eseguibile o un motore diversi. La versione stampata da qualunque binario che capiti nel percorso di ricerca della shell non è un inventario della macchina. Leggi l’unità o il processo che ha realmente effettuato la connessione.

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

L’interrogazione del pacchetto riporta ciò che i metadati locali ritengono installato e disponibile, e quella cache può essere obsoleta, quindi aggiornala prima. Non dice nulla neanche sul fatto che il servizio in esecuzione abbia caricato un binario installato cinque minuti fa. Confronta il record del pacchetto con il processo realmente connesso.

Prove dal pacchetto invece di impressioni sulla versione

La manutenzione di sicurezza delle distribuzioni spesso retroporta correzioni, quindi una versione upstream che sembra più vecchia può ancora contenere la patch. Vale anche il contrario: un pacchetto da un repository sconosciuto non ha alcun diritto automatico alla manutenzione corrente. Leggi lo stato di supporto della release, non il numero di versione.

Questa distinzione è la differenza tra una lacuna reale e un numero che sembra solo vecchio. Annota il repository da cui proviene il pacchetto, perché la stessa stringa di versione può arrivare attraverso canali molto diversi con supporti molto diversi.

La configurazione è l’altra metà

Un eseguibile mantenuto ha comunque bisogno di un profilo che chieda i controlli che credi siano presenti. Le ancore di fiducia, il ruolo previsto della controparte e il nome del server atteso sono decisioni correlate ma separate. Un controllo del ruolo non è un controllo del nome, e nessuno sostituisce l’altro. Se l’avviso riguarda la configurazione, la correzione spetta a chi possiede il profilo.

Non installare una patch arbitraria per compensare un profilo non verificato, e non aggiungere una direttiva per riparare un difetto di implementazione reale. Entrambi gli errori sembrano progresso, per questo entrambi continuano ad accadere.

Decidi con le prove nel registro

La decisione deriva da ciò che hai stabilito. Un pacchetto interessato e documentato richiede il suo aggiornamento supportato, una piattaforma non supportata ha bisogno di un percorso di migrazione, e un client del fornitore ha bisogno delle indicazioni di quel fornitore. Un’istruzione ambigua ha bisogno di un avviso e di un componente interessato prima che qualcuna di queste si applichi.

Tieni insieme il client attivo, la versione completa, l’avviso e il proprietario del profilo nel registro delle modifiche. È più solido di un riferimento a un tutorial, ed è ciò di cui la persona successiva avrà davvero bisogno.