Care binar openvpn rulează? Verificați calea de lansare

O soluție veche a mutat executabilul OpenVPN în altă parte și a lăsat un ambalaj shell pe calea originală. Luni mai târziu apare o actualizare, iar anularea soluției devine un joc de ghicit care fișier este cu adevărat clientul. Numele comenzii, executabilul configurat în serviciu și propria listă de fișiere a pachetului pot indica obiecte diferite, iar repararea unuia fără celelalte produce o gazdă care pare reparată și se comportă mai rău.

Începeți cu calea pe care o lansează serviciul

Un terminal și o unitate systemd nu rezolvă executabilele la fel. Shell-ul caută într-un PATH; unitatea numește o cale, iar suprascrierile drop-in o pot înlocui fără a atinge fișierul pe care îl citiți. Această diferență explică cea mai mare parte a confuziei din această sarcină. Ea decide și asupra cărui fișier trebuie să țintească reparația dumneavoastră.

Întrebați unitatea ce execută, inclusiv suprascrierile drop-in care o modifică, și citiți linia ExecStart rezultată în locul fragmentului pe care îl presupuneți autoritar. Apoi urmăriți acea cale prin orice legătură simbolică până la fișierul final. Un ambalaj care se termină cu exec într-un director ascuns este o configurație obișnuită din aceste corecturi vechi.

Notați calea rezolvată înainte de a schimba ceva.

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

Comparați numele comenzii cu calea serviciului

Cele două răspunsuri sunt adesea diferite, iar diferența nu este automat o defecțiune. Un plugin NetworkManager poate lansa propria cale, iar un container poate monta alta.

Important este să știți ce proprietar lansează procesul care deservește traficul. Dacă unitatea rulează /usr/local/sbin/openvpn-wrapper în timp ce shell-ul dumneavoastră rezolvă /usr/sbin/openvpn, repararea celui de-al doilea fișier nu schimbă nimic la serviciu.

Întrebați ce pachet deține fiecare candidat, apoi decideți dacă fișierul este administrat de pachet sau plasat local. Un fișier fără pachet care îl deține este un fișier pe care cineva l-a pus acolo intenționat, și merită un nume, un proprietar și un motiv înainte de a fi șters. Greșeala inversă este și ea obișnuită: suprascrierea unui fișier de pachet cu un binar vechi salvat pentru că o postare pe forum a folosit același director.

Lăsați baza de date a pachetelor să vorbească despre fișierele pachetului

Când software-ul provine dintr-un pachet Debian, baza de date a pachetelor vă poate spune dacă fișierele sale mai corespund cu ce s-a instalat. Este o întrebare îngustă de integritate, nu o sentință de securitate, iar diferența contează când decideți ce reparați. O nepotrivire înseamnă că fișierul s-a schimbat după instalare, ceea ce ar putea fi vechea soluție sau o modificare locală legitimă. Rezultatul nu decide care, așa că citiți-l ca indiciu și nu ca concluzie.

Rulați verificarea și citiți rezultatul în loc să tratați un rezultat gol ca dovadă a ceva.

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

Manualul dpkg documentează că verificarea compară fișierele instalate cu metadatele înregistrate local, folosind sumele de control salvate acolo unde există. Observă un fișier de pachet modificat și nu vă poate spune dacă în locul lui este lansat un alt binar.

Înregistrați starea înainte de reparație

Adunați calea de lansare rezolvată, relația fișierului cu pachetul, locația ambalajului și înregistrarea modificării care l-a introdus. Copiați ambalajul într-un loc protejat dacă conține muncă de integrare de care veți avea nevoie mai târziu.

Nu lipiți conținutul ambalajului într-un fir de suport înainte de a-l citi, deoarece aceste scripturi poartă uneori acreditări sau detalii despre poartă.

Înregistrați ce profiluri folosește serviciul și cine este conectat în timp ce lucrați, deoarece repornirea tunelului poate întrerupe sesiunea cu care administrați gazda.

Verificați lansarea, apoi retrageți ambalajul

După reparație, porniți serviciul și confirmați că procesul rulează calea dorită. O interogare de versiune făcută manual dovedește că fișierul funcționează; nu dovedește că unitatea îl folosește.

Apoi reconectați un client și verificați dacă profilul se mai autentifică, deoarece o schimbare de binar care ignoră opțiunile originale va eșua într-un mod care pare o problemă de certificat.

Retrageți ambalajul deplasat prin aceeași înregistrare a modificării care l-a introdus. Reparația încheiată indică ce executabil rulează, de ce și ce fișier a fost eliminat; restaurarea unui nume de fișier și speranța nu sunt același lucru.