Vilken openvpn-binärfil körs? Kontrollera startvägen

En gammal lösning flyttade OpenVPN-körbara filen någon annanstans och lämnade ett shell-omslag på den ursprungliga vägen. Månader senare kommer en uppgradering, och att rulla tillbaka lösningen blir en gissningslek om vilken fil som egentligen är klienten. Kommandonamnet, den körbara filen som konfigurerats i tjänsten och paketets egen fillista kan alla peka på olika objekt, och att reparera en av dem utan de andra ger en värd som ser reparerad ut och beter sig sämre.

Börja med vägen som tjänsten startar

En terminal och en systemd-enhet löser inte körbara filer på samma sätt. Skalet söker i en PATH; enheten namnger en väg, och drop-in-överstyrningar kan ersätta den utan att röra filen du läser. Den skillnaden förklarar det mesta av förvirringen i den här uppgiften. Den avgör också vilken fil din reparation måste rikta in sig på.

Fråga enheten vad den kör, inklusive de drop-in-filer som ändrar den, och läs den resulterande ExecStart-raden i stället för det fragment du antar är auktoritativt. Följ sedan den vägen genom vilken symbolisk länk som helst till den slutliga filen. Ett omslag som slutar med exec i en dold katalog är en vanlig konstruktion från dessa gamla korrigeringar.

Skriv ned den upplösta vägen innan du ändrar något.

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

Jämför kommandonamnet med tjänstevägen

De två svaren är ofta olika, och den skillnaden är inte automatiskt ett fel. Ett NetworkManager-insticksprogram kan starta sin egen väg, och en container kan montera ännu en.

Det viktiga är att veta vilken ägare som startar processen som betjänar trafiken. Om enheten kör /usr/local/sbin/openvpn-wrapper medan ditt skal löser /usr/sbin/openvpn, ändrar reparationen av den andra filen ingenting i tjänsten.

Fråga vilket paket som äger varje kandidat och avgör sedan om filen hanteras av paketet eller placerats lokalt. En fil utan ägande paket är en fil som någon lagt dit med avsikt, och den förtjänar ett namn, en ägare och en anledning innan den raderas. Det omvända felet är också vanligt: att skriva över en paketfil med en gammal sparad binärfil eftersom ett foruminlägg använde samma katalog.

Låt paketdatabasen tala om paketfiler

När programvaran kom från ett Debian-paket kan paketdatabasen berätta om dess filer fortfarande stämmer med det som installerades. Det är en snäv integritetsfråga, inte en säkerhetsdom, och skillnaden spelar roll när du bestämmer vad som ska repareras. En avvikelse betyder att filen ändrades efter installationen, vilket kan vara din gamla lösning eller en legitim lokal ändring. Utdata avgör inte vilket, så läs dem som en antydan och inte som en slutsats.

Kör verifieringen och läs utdata i stället för att behandla ett tomt resultat som bevis för något.

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

dpkg-handboken dokumenterar att verifieringen jämför installerade filer med lokalt registrerade metadata och använder sparade kontrollsummor där sådana finns. Den märker en ändrad paketfil, och den kan inte säga om en annan binärfil startas i stället.

Registrera tillståndet innan du reparerar

Samla den upplösta startvägen, filens paketrelation, omslagets placering och ändringsprotokollet som införde det. Kopiera omslaget till en skyddad plats om det innehåller integrationsarbete som behövs senare.

Klistra inte in omslagets innehåll i en supporttråd innan du läst det, eftersom dessa skript ibland bär inloggningsuppgifter eller gateway-detaljer.

Registrera vilka profiler tjänsten använder och vem som är ansluten medan du arbetar, eftersom en omstart av tunneln kan avbryta sessionen du administrerar värden från.

Verifiera starten och ta sedan bort omslaget

Efter reparationen startar du tjänsten och bekräftar att processen kör den väg du avsåg. En versionsförfrågan som körs för hand bevisar att filen fungerar; den bevisar inte att enheten använder den.

Anslut sedan en klient igen och kontrollera att profilen fortfarande autentiserar, eftersom ett binärbyte som ignorerar de ursprungliga alternativen kommer att misslyckas på ett sätt som ser ut som ett certifikatproblem.

Ta bort det undanträngda omslaget via samma ändringsprotokoll som införde det. Den färdiga reparationen anger vilken körbar fil som körs, varför och vilken fil som togs bort; att återställa ett filnamn och hoppas är inte samma sak.