sudo, &, -b o --daemon: cómo pasar un cliente OpenVPN a segundo plano

En la frase «ejecútalo en segundo plano» se esconden dos preguntas. La primera es si este usuario puede siquiera iniciar un proceso privilegiado; la segunda es si la sesión puede continuar sin que nadie escriba en una terminal. Un ampersand del shell no responde a ninguna, y un script que guarda una contraseña de sudo en una variable responde mal a la primera y deja intacta la segunda. Sepárelas y las opciones se vuelven fáciles de comparar.

Compare los tres candidatos por propiedad, no por comodidad.

Tres formas de dejar la terminal, tres dueños distintos

Añadir un ampersand a un comando pide al shell que lo ejecute como trabajo en segundo plano, y el trabajo sigue perteneciendo a ese shell. sudo puede preguntar antes de que el programa siquiera empiece, y OpenVPN puede preguntar después por una frase de contraseña de clave o un inicio de sesión. Poner en segundo plano un comando que espera entrada produce un proceso que espera una terminal que nadie mira. La terminal se libera; la interacción no.

Es la opción más barata y la que falla de forma más confusa, porque el aviso aparece en un lugar que el operador ya ha abandonado.

sudo -b no es un gestor de credenciales

sudo -b ejecuta el comando en segundo plano desde la perspectiva del propio sudo, lo que suena como la función que faltaba y no lo es. Según el manual de sudo, los comandos interactivos suelen comportarse mal en ese modo, y el control de trabajos del shell no puede gestionar los procesos que crea. Mueve el proceso sin darle una forma de responder preguntas. Nada en él proporciona una frase de contraseña de clave privada ni un inicio de sesión en la puerta de enlace.

Si la conexión necesita interacción, la solución es un mecanismo de autenticación no interactivo compatible, no otra forma de lanzar el mismo aviso.

--daemon cambia el programa, no el inicio de sesión

--daemon pide al propio OpenVPN que se separe tras la inicialización. El manual de la versión 2.6 señala que la redirección de syslog ocurre al analizar la opción, aunque la separación ocurre más tarde, así que los mensajes pueden dejar de aparecer en la terminal antes de lo esperado. El silencio después de ese punto no demuestra nada sobre el túnel. Añada un --log o --log-append para que la salida llegue a un lugar donde pueda leerla.

El modo demonio también elimina la consola de forma permanente. Una clave privada protegida necesita askpass en ese modo, y las credenciales introducidas por consola combinadas con opciones de caché pueden dejar una reautenticación posterior sin ningún lugar donde preguntar. Compruebe el modelo de autenticación con la versión instalada antes de suponer que un arranque en segundo plano sobrevivirá a su primera renovación de clave.

Qué compra la validación de sudo y qué no

sudo -v valida o renueva la credencial local en caché, autenticando si la política lo exige. No inicia OpenVPN, no se autentica con la puerta de enlace y no garantiza que se permita un comando posterior del script. sudo -n significa lo contrario: no preguntes, falla. Eso hace explícito un fallo de autorización local, lo que resulta útil, y no dice nada sobre lo que OpenVPN pedirá después.

Ninguna de las dos opciones es motivo para conceder comandos sin contraseña a todo el mundo ni para pasar una contraseña de administrador a un script.

Prefiera un dueño que pueda observarse

Para un túnel propiedad de una máquina, use la instancia de servicio que admita la distribución. Ese dueño ofrece inicio, parada, estado y registros, y sobrevive al final de su sesión. Montar la ejecución en segundo plano del shell, la demonización y un bucle de reinicio unos alrededor de otros crea tres dueños para un solo túnel y ninguna respuesta clara de cuál está funcionando.

Elija lo que elija, verifique el recurso para el que existe el túnel. Una solicitud de inicio correcta es un evento del proceso, no prueba de una conexión que funcione.