Hvilken openvpn-binærfil kjører? Kontroller oppstartsstien

En gammel workaround flyttet OpenVPN-kjørbarheten et annet sted og lot en shell-innpakning ligge på den opprinnelige stien. Måneder senere kommer en oppgradering, og det å rulle tilbake workarounden blir en gjetningslek om hvilken fil som egentlig er klienten. Kommandonavnet, den konfigurerte kjørbarheten i tjenesten og pakkens egen filliste kan alle peke på forskjellige objekter, og å reparere én av dem uten de andre gir en vert som ser reparert ut og oppfører seg verre.

Begynn med stien tjenesten starter

En terminal og en systemd-enhet løser ikke kjørbare filer på samme måte. Skallet søker i en PATH; enheten navngir en sti, og drop-in-overstyringer kan erstatte den uten å røre filen du leser. Den forskjellen forklarer det meste av forvirringen i denne oppgaven. Den avgjør også hvilken fil reparasjonen din må rette seg mot.

Spør enheten hva den kjører, inkludert drop-in-filene som endrer den, og les den resulterende ExecStart-linjen i stedet for fragmentet du antar er autoritativt. Følg deretter den stien gjennom enhver symbolsk lenke til den endelige filen. En innpakning som ender med exec ned i en skjult mappe, er en vanlig ordning fra disse gamle rettelsene.

Skriv ned den løste stien før du endrer noe.

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

Sammenlign kommandonavnet med tjenestestien

De to svarene er ofte forskjellige, og den forskjellen er ikke automatisk en feil. En NetworkManager-plugin kan starte sin egen sti, og en container kan montere enda en.

Det viktige er å vite hvilken eier som starter prosessen som betjener trafikken. Hvis enheten kjører /usr/local/sbin/openvpn-wrapper mens skallet ditt løser /usr/sbin/openvpn, endrer reparasjonen av den andre filen ingenting på tjenesten.

Spør hvilken pakke som eier hver kandidat, og avgjør deretter om filen er pakkestyrt eller plassert lokalt. En fil uten en eierpakke er en fil noen har lagt der med vilje, og den fortjener et navn, en eier og en grunn før den slettes. Den motsatte feilen er også vanlig: å overskrive en pakkefil med en gammel lagret binærfil fordi et foruminnlegg brukte samme mappe.

La pakkedatabasen snakke om pakkefiler

Når programvaren kom fra en Debian-pakke, kan pakkedatabasen fortelle deg om filene fortsatt samsvarer med det som ble installert. Det er et snevert integritetsspørsmål, ikke en sikkerhetsdom, og forskjellen er viktig når du bestemmer hva som skal repareres. Et avvik betyr at filen ble endret etter installasjonen, noe som kan være den gamle workarounden din eller en legitim lokal endring. Utdataene avgjør ikke hvilken, så les dem som en pekepinn og ikke som en konklusjon.

Kjør verifiseringen og les utdataene i stedet for å behandle et tomt resultat som bevis for noe som helst.

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

dpkg-veiledningen dokumenterer at verifiseringen sammenligner installerte filer med lokalt registrerte metadata og bruker lagrede kontrollsummer der de finnes. Den merker en endret pakkefil, og den kan ikke fortelle deg om en annen binærfil startes i stedet.

Registrer tilstanden før du reparerer

Samle den løste oppstartsstien, filens pakkeforhold, plasseringen av innpakningen og endringsregistreringen som innførte den. Kopier innpakningen til et beskyttet sted hvis den inneholder integreringsarbeid som trengs senere.

Ikke lim inn innholdet i innpakningen i en støttetråd før du har lest det, siden disse skriptene noen ganger bærer påloggingsinformasjon eller gateway-detaljer.

Registrer hvilke profiler tjenesten bruker og hvem som er tilkoblet mens du arbeider, fordi en omstart av tunnelen kan avbryte økten du administrerer verten fra.

Verifiser oppstarten og fjern deretter innpakningen

Etter reparasjonen starter du tjenesten og bekrefter at prosessen kjører den stien du hadde tenkt. En versjonsforespørsel som kjøres for hånd beviser at filen virker; den beviser ikke at enheten bruker den.

Koble deretter til en klient igjen og kontroller at profilen fortsatt autentiserer, fordi en binærbytte som ignorerer de opprinnelige valgene vil feile på en måte som ser ut som et sertifikatproblem.

Fjern den fortrengte innpakningen via den samme endringsregistreringen som innførte den. Den ferdige reparasjonen angir hvilken kjørbar fil som kjører, hvorfor, og hvilken fil som ble fjernet; å gjenopprette et filnavn og håpe er ikke det samme.