Que binario de openvpn está en execución? Comproba a ruta de arranque

Unha solución antiga moveu o executábel de OpenVPN a outro sitio e deixou un envoltorio de shell na ruta orixinal. Meses despois chega unha actualización, e desfacer a solución convértese nun xogo de adiviñas sobre que ficheiro é realmente o cliente. O nome do comando, o executábel configurado no servizo e o propio inventario de ficheiros do paquete poden apuntar a obxectos distintos, e reparar un sen os demais produce un host que parece arranxado e compórtase peor.

Comeza pola ruta que lanza o servizo

Un terminal e unha unidade de systemd non resolven os executábeis do mesmo xeito. A shell busca nun PATH; a unidade nomea unha ruta, e as anulacións drop-in poden substituíla sen tocar o ficheiro que estás a ler. Esa diferenza explica a maior parte da confusión nesta tarefa. Tamén decide a que ficheiro debe apuntar a túa reparación.

Pregunta á unidade que executa, incluídas as anulacións drop-in que a modifican, e le a liña ExecStart resultante en lugar do fragmento que supoñas autoritativo. Despois segue esa ruta por calquera ligazón simbólica ata o ficheiro final. Un envoltorio que remata con exec cara a un directorio oculto é unha disposición habitual destas reparacións antigas.

Anota a ruta resolvida antes de cambiar nada.

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

Compara o nome do comando coa ruta do servizo

As dúas respostas adoitan ser distintas, e esa diferenza non é automaticamente un fallo. Un complemento de NetworkManager pode lanzar a súa propia ruta, e un contedor pode montar outra.

O importante é saber que propietario lanza o proceso que serve o tráfico. Se a unidade executa /usr/local/sbin/openvpn-wrapper mentres a túa shell resolve /usr/sbin/openvpn, reparar o segundo ficheiro non cambia nada no servizo.

Pregunta que paquete posúe cada candidato e despois decide se o ficheiro o xestiona o paquete ou está colocado localmente. Un ficheiro sen ningún paquete propietario é un ficheiro que alguén puxo alí a propósito, e merece un nome, un propietario e un motivo antes de borrarse. O erro inverso tamén é común: sobrescribir un ficheiro de paquete cun binario antigo gardado porque unha publicación do foro usou o mesmo directorio.

Deixa que a base de datos de paquetes fale dos ficheiros do paquete

Cando o software veu dun paquete Debian, a base de datos de paquetes pode dicirche se os seus ficheiros aínda coinciden co instalado. É unha pregunta estreita de integridade, non un veredicto de seguridade, e a diferenza importa cando decides que reparar. Unha discrepancia significa que o ficheiro cambiou despois da instalación, o que podería ser a túa solución antiga ou unha edición local lexítima. A saída non resolve cal das dúas, así que léaa como un indicio e non como unha conclusión.

Executa a verificación e le a saída en lugar de tratar un resultado baleiro como proba de algo.

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

O manual de dpkg documenta que a verificación compara os ficheiros instalados cos metadatos rexistrados localmente, usando as sumas de comprobación gardadas cando existen. Detecta un ficheiro de paquete modificado, e non pode dicirche se no seu lugar se está a lanzar outro binario.

Rexistra o estado antes de reparar

Reúne a ruta de arranque resolvida, a relación do ficheiro co paquete, a localización do envoltorio e o rexistro de cambios que o introduciu. Copia o envoltorio a un lugar protexido se contén traballo de integración que fará falta despois.

Non peques o contido do envoltorio nun fío de asistencia antes de lelo, porque estes scripts ás veces levan credenciais ou detalles da pasarela.

Anota que perfís usa o servizo e quen está conectado mentres traballas, porque reiniciar o túnel pode interromper a sesión coa que administras o host.

Verifica o arranque e despois retira o envoltorio

Despois da reparación, inicia o servizo e confirma que o proceso executa a ruta que pretendías. Unha consulta de versión feita a man demostra que o ficheiro funciona; non demostra que a unidade o use.

Despois volve conectar un cliente e comproba que o perfil aínda autentica, porque un cambio de binario que ignora as opcións orixinais fallará dun xeito que parece un problema de certificado.

Retira o envoltorio desprazado mediante o mesmo rexistro de cambios que o introduciu. A reparación rematada indica que executábel se executa, por que e que ficheiro se eliminou; restaurar un nome de ficheiro e esperar non é o mesmo.