¿Qué binario de openvpn se está ejecutando? Comprueba la ruta de arranque

Un apaño antiguo movió el ejecutable de OpenVPN a otro sitio y dejó un envoltorio de shell en la ruta original. Meses después llega una actualización, y deshacer el apaño se convierte en un juego de adivinanzas sobre qué archivo es realmente el cliente. El nombre del comando, el ejecutable configurado en el servicio y el propio inventario de archivos del paquete pueden apuntar a objetos distintos, y reparar uno sin los demás produce un host que parece arreglado y se comporta peor.

Empieza por la ruta que lanza el servicio

Un terminal y una unidad de systemd no resuelven los ejecutables de la misma forma. El shell busca en un PATH; la unidad nombra una ruta, y las anulaciones drop-in pueden sustituirla sin tocar el archivo que estás leyendo. Esa diferencia explica la mayor parte de la confusión de esta tarea. También decide a qué archivo debe apuntar tu reparación.

Pregunta a la unidad qué ejecuta, incluidas las anulaciones drop-in que la modifican, y lee la línea ExecStart resultante en lugar del fragmento que supones autoritativo. Después sigue esa ruta por cualquier enlace simbólico hasta el archivo final. Un envoltorio que termina con exec hacia un directorio oculto es una disposición habitual de estos arreglos antiguos.

Anota la ruta resuelta antes de cambiar nada.

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

Compara el nombre del comando con la ruta del servicio

Las dos respuestas suelen ser distintas, y esa diferencia no es automáticamente un fallo. Un complemento de NetworkManager puede lanzar su propia ruta, y un contenedor puede montar otra.

Lo importante es saber qué propietario lanza el proceso que sirve el tráfico. Si la unidad ejecuta /usr/local/sbin/openvpn-wrapper mientras tu shell resuelve /usr/sbin/openvpn, reparar el segundo archivo no cambia nada del servicio.

Pregunta qué paquete posee cada candidato y luego decide si el archivo lo gestiona el paquete o está colocado localmente. Un archivo sin ningún paquete propietario es un archivo que alguien puso ahí a propósito, y merece un nombre, un propietario y un motivo antes de borrarse. El error inverso también es común: sobrescribir un archivo de paquete con un binario antiguo guardado porque una publicación del foro usó el mismo directorio.

Deja que la base de datos de paquetes hable de los archivos del paquete

Cuando el software vino de un paquete Debian, la base de datos de paquetes puede decirte si sus archivos siguen coincidiendo con lo instalado. Es una pregunta estrecha de integridad, no un veredicto de seguridad, y la diferencia importa cuando decides qué reparar. Una discrepancia significa que el archivo cambió después de la instalación, lo que podría ser tu apaño antiguo o una edición local legítima. La salida no resuelve cuál de las dos, así que léela como una pista y no como una conclusión.

Ejecuta la verificación y lee la salida en lugar de tratar un resultado vacío como prueba de algo.

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

El manual de dpkg documenta que la verificación compara los archivos instalados con los metadatos registrados localmente, usando las sumas de comprobación guardadas cuando existen. Detecta un archivo de paquete modificado, y no puede decirte si en su lugar se está lanzando otro binario.

Registra el estado antes de reparar

Reúne la ruta de arranque resuelta, la relación del archivo con el paquete, la ubicación del envoltorio y el registro de cambios que lo introdujo. Copia el envoltorio a un lugar protegido si contiene trabajo de integración que hará falta después.

No pegues el contenido del envoltorio en un hilo de soporte antes de leerlo, porque estos scripts a veces llevan credenciales o detalles de la puerta de enlace.

Anota qué perfiles usa el servicio y quién está conectado mientras trabajas, porque reiniciar el túnel puede interrumpir la sesión con la que administras el host.

Verifica el arranque y luego retira el envoltorio

Después de la reparación, inicia el servicio y confirma que el proceso ejecuta la ruta que pretendías. Una consulta de versión hecha a mano demuestra que el archivo funciona; no demuestra que la unidad lo use.

Luego vuelve a conectar un cliente y comprueba que el perfil sigue autenticando, porque un cambio de binario que ignora las opciones originales fallará de una forma que parece un problema de certificado.

Retira el envoltorio desplazado mediante el mismo registro de cambios que lo introdujo. La reparación terminada indica qué ejecutable se ejecuta, por qué y qué archivo se eliminó; restaurar un nombre de archivo y confiar en la suerte no es lo mismo.