Quin binari d'openvpn s'executa? Comprova la ruta d'inici

Una solució antiga va moure l'executable d'OpenVPN a un altre lloc i va deixar un embolcall de shell a la ruta original. Mesos després arriba una actualització, i desfer la solució es converteix en un joc d'endevinalles sobre quin fitxer és realment el client. El nom de l'ordre, l'executable configurat del servei i l'inventari de fitxers del propi paquet poden apuntar a objectes diferents, i reparar-ne un sense els altres produeix un amfitrió que sembla arreglat i es comporta pitjor.

Comença per la ruta que llança el servei

Un terminal i una unitat de systemd no resolen els executables de la mateixa manera. L'intèrpret d'ordres cerca al PATH; la unitat anomena una ruta, i les sobreposicions drop-in poden substituir-la sense tocar el fitxer que estàs llegint. Aquesta diferència explica la major part de la confusió d'aquesta tasca. També decideix a quin fitxer ha d'apuntar la teva reparació.

Pregunta a la unitat què executa, incloent-hi les sobreposicions drop-in que la modifiquen, i llegeix la línia ExecStart resultant en lloc del fragment que assumeixes com a autoritatiu. Després segueix aquesta ruta per qualsevol enllaç simbòlic fins al fitxer final. Un embolcall que acaba amb exec en un directori ocult és una disposició habitual d'aquestes solucions antigues.

Anota la ruta resolta abans de canviar res.

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

Compara el nom de l'ordre amb la ruta del servei

Les dues respostes sovint són diferents, i aquesta diferència no és automàticament un defecte. Un connector de NetworkManager pot llançar la seva pròpia ruta, i un contenidor pot muntar-ne una altra.

El que importa és saber quin propietari llança el procés que serveix el trànsit. Si la unitat executa /usr/local/sbin/openvpn-wrapper mentre el teu intèrpret resol /usr/sbin/openvpn, reparar el segon fitxer no canvia res del servei.

Pregunta quin paquet posseeix cada candidat i després decideix si el fitxer el gestiona el paquet o hi és col·locat localment. Un fitxer sense cap paquet propietari és un fitxer que algú hi va posar deliberadament, i mereix un nom, un propietari i una raó abans de ser esborrat. L'error invers també és habitual: sobreescriure un fitxer de paquet amb un binari antic desat perquè una publicació del fòrum va fer servir el mateix directori.

Deixa que la base de dades de paquets parli dels fitxers de paquet

Quan el programari prové d'un paquet Debian, la base de dades de paquets et pot dir si els seus fitxers encara coincideixen amb el que es va instal·lar. És una pregunta estreta d'integritat, no un veredicte de seguretat, i la diferència importa quan decideixes què reparar. Una discrepància significa que el fitxer va canviar després de la instal·lació, cosa que podria ser la teva solució antiga o una edició local legítima. La sortida no resol quina de les dues, així que llegeix-la com un indici i no com una conclusió.

Executa la verificació i llegeix la sortida en lloc de tractar un resultat buit com a prova de res.

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

El manual de dpkg documenta que la verificació compara els fitxers instal·lats amb les metadades registrades localment, fent servir les sumes de verificació desades quan n'hi ha. Detecta un fitxer de paquet canviat, i no et pot dir si en lloc seu s'executa un altre binari.

Registra l'estat abans de reparar

Recull la ruta d'inici resolta, la relació del fitxer amb el paquet, la ubicació de l'embolcall i el registre de canvis que el va introduir. Copia l'embolcall en un lloc protegit si conté feina d'integració que caldrà més endavant.

No enganxis el contingut de l'embolcall en un fil d'assistència abans de llegir-lo, perquè aquests scripts de vegades porten credencials o detalls de la passarel·la.

Anota quins perfils fa servir el servei i qui hi ha connectat mentre treballes, perquè reiniciar el túnel pot interrompre la sessió amb què administres l'amfitrió.

Verifica l'inici i després retira l'embolcall

Després de la reparació, inicia el servei i confirma que el procés s'executa a la ruta que volies. Una consulta de versió feta a mà demostra que el fitxer funciona; no demostra que la unitat el faci servir.

Després torna a connectar un client i comprova que el perfil encara s'autentica, perquè un canvi de binari que ignora les opcions originals fallarà d'una manera que sembla un problema de certificat.

Retira l'embolcall desplaçat mitjançant el mateix registre de canvis que el va introduir. La reparació acabada indica quin executable s'executa, per què i quin fitxer s'ha eliminat; restaurar un nom de fitxer i esperar que funcioni no és el mateix.