Handlar den där OpenVPN-säkerhetsfixen ens om din installation?

Rådet att patcha klienten så att den validerar certifikat är för vagt för att agera på. Det kan beskriva en åtgärdad mjukvarubugg, ett gammalt bygge från en leverantör, eller en profil som aldrig bad om kontrollen. Det är tre olika ändringar med tre olika ägare. Att agera på den meningen utan att veta vilken av dem du står inför är hur en fungerande klient ändras utan anledning.

Skilj på de tre påståendena

En mjukvarubugg har ett säkerhetsmeddelande, berörda versioner och en åtgärdad utgåva. Ett leverantörsbygge har sin egen distributionskanal och sin egen uppdateringstakt. En profilutelämning har ingen av dem, eftersom den körbara filen är i ordning och konfigurationen begär mindre än du antog. Tills påståendet namnger en av de tre finns det inget att testa.

Skriv påståendet i en mening innan du söker efter det. Om meningen inte kan namnge vad som är trasigt har sökningen inget mål och varje resultat verkar relevant.

Hitta den körbara filen som faktiskt körs

Identifiera vad som startar anslutningen innan du tittar på någon version. En distributionstjänst, en skrivbordsinsticksmodul och en leverantörsapp kan var och en använda en annan körbar fil eller motor. En version som skrivs ut av vilken binärfil som helst som råkar ligga i skalets sökväg är inte en inventering av maskinen. Läs den enhet eller process som faktiskt genomförde anslutningen.

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

Paketfrågan rapporterar vad lokala metadata tror är installerat och tillgängligt, och cachen kan vara inaktuell, så uppdatera den först. Den säger inte heller något om huruvida tjänsten som körs laddade en binärfil som installerades för fem minuter sedan. Jämför paketposten med den process som faktiskt är ansluten.

Paketbevis i stället för versionsintryck

Distributionernas säkerhetsunderhåll backportar ofta rättelser, så en äldre utseende upstream-version kan fortfarande innehålla patchen. Det omvända gäller också: ett paket från ett okänt arkiv har inget automatiskt anspråk på aktuellt underhåll. Läs utgåvans supportstatus, inte versionsnumret.

Den skillnaden är skillnaden mellan en verklig lucka och ett nummer som bara ser gammalt ut. Anteckna arkivet paketet kom från, eftersom samma versionssträng kan anlända via mycket olika kanaler med mycket olika stöd.

Konfigurationen är den andra halvan

En underhållen körbar fil behöver fortfarande en profil som begär de kontroller du tror är på plats. Förtroendeankare, motpartens avsedda roll och det förväntade servernamnet är besläktade men separata beslut. En rollkontroll är inte en namnkontroll, och ingen av dem ersätter den andra. Om varningen handlar om konfiguration tillhör rättelsen den som äger profilen.

Installera inte en godtycklig patch för att kompensera för en overifierad profil, och lägg inte till ett direktiv för att reparera en verklig implementeringsbrist. Båda felen känns som framsteg, vilket är varför båda fortsätter att hända.

Besluta med bevis i registret

Beslutet följer av det du har fastställt. Ett dokumenterat berört paket kräver sin stödda uppdatering, en plattform utan stöd behöver en migreringsväg, och en leverantörsklient behöver den leverantörens vägledning. En tvetydig instruktion behöver ett säkerhetsmeddelande och en berörd komponent innan något av detta gäller.

Håll den aktiva klienten, den fullständiga versionen, säkerhetsmeddelandet och profilägaren tillsammans i ändringsregistret. Det är starkare än en handledningsreferens, och det är vad nästa person faktiskt kommer att behöva.