Handlar den OpenVPN-tryggleiksfiksen eigentleg om installasjonen din?

Rådet om å patche klienten slik at han validerer sertifikat, er for vagt til å handle på. Det kan skildre ein retta programvarefeil, eit gammalt bygg frå éin leverandør, eller ein profil som aldri bad om kontrollen. Det er tre ulike endringar med tre ulike eigarar. Å handle på den setninga utan å vite kva av dei du står ovanfor, er korleis ein fungerande klient blir endra utan grunn.

Skil dei tre påstandane

Ein programvarefeil har eit varsel, råka versjonar og ei retta utgåve. Eit leverandørbygg har sin eigen distribusjonskanal og sin eigen oppdateringstakt. Ei profilutelating har ingen av delane, fordi den køyrande fila er i orden og konfigurasjonen ber om mindre enn du antok. Inntil påstanden nemner éin av dei tre, er det ingenting å teste.

Skriv påstanden i éi setning før du søkjer etter han. Viss setninga ikkje kan nemne kva som er øydelagt, har søket ingen mål og kvart resultat ser relevant ut.

Finn den køyrande fila som faktisk køyrer

Identifiser kva som startar tilkoplinga før du ser på nokon versjon. Ein distribusjonsteneste, eit skrivebordsprogramtillegg og ein leverandørapplikasjon kan kvar bruke ei anna køyrande fil eller motor. Ein versjon som blir skriven ut av kva binærfil som helst som tilfeldigvis ligg i søkjestien til skalet, er ikkje ei oversikt over maskinen. Les eininga eller prosessen som faktisk utførte tilkoplinga.

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

Pakkespørjinga rapporterer kva lokale metadata meiner er installert og tilgjengeleg, og hurtiglageret kan vere utdatert, så oppdater det først. Ho seier heller ingenting om korvidt tenesta som køyrer lasta inn ein binærfil som vart installert for fem minutt sidan. Samanlikn pakkeregisteret med prosessen som faktisk er tilkopla.

Pakkebevis i staden for versjonsinntrykk

Tryggleiksvedlikehaldet til distribusjonane tilbakefører ofte rettingar, så ein eldre utsjånad upstream-versjon kan framleis innehalde lappen. Det motsette gjeld òg: ein pakke frå eit ukjent lager har inga automatisk rett til gjeldande vedlikehald. Les støttestatusen til utgåva i staden for versjonsnummeret.

Den skilnaden er skilnaden mellom eit reelt hol og eit tal som berre ser gammalt ut. Noter lageret pakken kom frå, fordi den same versjonsstrengen kan kome gjennom svært ulike kanalar med svært ulik støtte.

Konfigurasjonen er den andre halvdelen

Ei vedlikehalden køyrande fil treng framleis ein profil som ber om kontrollane du trur er på plass. Tillitsanker, den tiltenkte rolla til motparten og det forventa servernamnet er slektande, men åtskilde avgjerder. Ein rollekontroll er ikkje ein namnekontroll, og ingen av dei erstattar den andre. Viss åtvaringa handlar om konfigurasjon, høyrer rettinga til den som eig profilen.

Ikkje installer ein vilkårleg lapp for å kompensere for ein uverifisert profil, og ikkje legg til eit direktiv for å reparere ein ekte implementeringsfeil. Begge feila kjennest som framgang, og difor held begge fram med å skje.

Avgjer med bevis i registeret

Avgjerda følgjer av det du har fastslått. Ein dokumentert råka pakke krev den støtta oppdateringa si, ein ikkje-støtta plattform treng ein migrasjonsveg, og ein leverandørklient treng rettleiinga til den leverandøren. Ein tvitydig instruksjon treng eit varsel og ein råka komponent før noko av dette gjeld.

Hald den aktive klienten, den fulle versjonen, varselet og profileigaren saman i endringsregisteret. Det er sterkare enn ein opplæringsreferanse, og det er det neste person faktisk vil trenge.