Hvilken openvpn-binærfil kører? Kontrollér startstien

En gammel omvej flyttede OpenVPN-kørselen et andet sted hen og efterlod en shell-indpakning på den oprindelige sti. Måneder senere lander en opgradering, og det at rulle omvejen tilbage bliver et gætteri om, hvilken fil der egentlig er klienten. Kommandonavnet, den konfigurerede kørsel i tjenesten og pakkens egen filfortegnelse kan alle pege på forskellige objekter, og hvis man reparerer én af dem uden de andre, får man en vært, der ser repareret ud og opfører sig dårligere.

Begynd med den sti, tjenesten starter

En terminal og en systemd-unit fortolker ikke kørseler på samme måde. Skallen søger i PATH; uniten angiver en sti, og drop-in-tilsidesættelser kan udskifte den uden at røre den fil, du læser. Den forskel forklarer det meste af forvirringen i denne opgave. Den afgør også, hvilken fil din reparation skal ramme.

Spørg uniten, hvad den kører, inklusive de drop-in-filer der ændrer den, og læs den resulterende ExecStart-linje i stedet for det fragment, du antager er autoritativt. Følg derefter den sti gennem ethvert symbolsk link til den endelige fil. En indpakning, der slutter med exec ned i en skjult mappe, er et almindeligt arrangement fra disse gamle rettelser.

Skriv den opløste sti ned, før du ændrer noget.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Sammenlign kommandonavnet med tjenestens sti

De to svar er ofte forskellige, og den forskel er ikke automatisk en fejl. Et NetworkManager-plugin kan starte sin egen sti, og en container kan mounte endnu en.

Det vigtige er at vide, hvilken ejer der starter den proces, som betjener trafikken. Hvis uniten kører /usr/local/sbin/openvpn-wrapper, mens din skal opløser /usr/sbin/openvpn, ændrer det intet ved tjenesten at reparere den anden fil.

Spørg, hvilken pakke der ejer hver kandidat, og afgør derefter, om filen er pakkestyret eller lokalt placeret. En fil uden en ejende pakke er en fil, som nogen har lagt der med vilje, og den fortjener et navn, en ejer og en grund, før den slettes. Den omvendte fejl er også almindelig: at overskrive en pakkefil med en gammel gemt binærfil, fordi et forumindlæg brugte den samme mappe.

Lad pakkedatabasen tale om pakkefiler

Når softwaren kom fra en Debian-pakke, kan pakkedatabasen fortælle dig, om dens filer stadig matcher det, der blev installeret. Det er et snævert integritetsspørgsmål, ikke en sikkerhedsdom, og forskellen er vigtig, når du beslutter, hvad der skal repareres. Uoverensstemmelse betyder, at filen blev ændret efter installationen, hvilket kan være din gamle omvej eller en legitim lokal ændring. Outputtet afgør ikke hvilken, så læs det som en pejling og ikke som en konklusion.

Kør verifikationen og læs outputtet i stedet for at behandle et tomt resultat som bevis for noget som helst.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

dpkg-vejledningen dokumenterer, at verifikationen sammenligner installerede filer med lokalt registrerede metadata og bruger gemte kontrolsummer, hvor de findes. Den bemærker en ændret pakkefil, og den kan ikke fortælle dig, om en anden binærfil startes i stedet.

Registrér tilstanden, før du reparerer

Saml den opløste startsti, filens pakkeforhold, indpakningens placering og den ændringsregistrering, der indførte den. Kopiér indpakningen et beskyttet sted, hvis den indeholder integrationsarbejde, der bliver brug for senere.

Indsæt ikke indpakningens indhold i en supporttråd, før du har læst det, da disse scripts nogle gange bærer legitimationsoplysninger eller gateway-detaljer.

Registrér, hvilke profiler tjenesten bruger, og hvem der er forbundet, mens du arbejder, fordi en genstart af tunnelen kan afbryde den session, du administrerer værten fra.

Verificér starten, og fjern derefter indpakningen

Efter reparationen startes tjenesten, og du bekræfter, at processen kører den sti, du havde til hensigt. En versionsforespørgsel kørt i hånden beviser, at filen virker; den beviser ikke, at uniten bruger den.

Forbind derefter en klient igen, og kontrollér, at profilen stadig godkender, fordi en binærudskiftning, der ignorerer de oprindelige valgmuligheder, vil fejle på en måde, der ligner et certifikatproblem.

Fjern den fortrængte indpakning via den samme ændringsregistrering, der indførte den. Den færdige reparation angiver, hvilken kørsel der kører, hvorfor, og hvilken fil der blev fjernet; at gendanne et filnavn og håbe er ikke det samme.