¿Se ejecutó demasiado pronto el script up de OpenVPN, o nunca estuvo listo?

El script up se ejecuta, sale con cero y la tarea que contiene no logra alcanzar un servicio privado que dos segundos después funciona perfectamente desde un terminal. El instinto es el tiempo, y la reparación habitual es una espera, que oculta la carrera sin entenderla. La lectura más útil es que “up” nombra un gancho, no una garantía de preparación. Se dispara cuando se configura el dispositivo de túnel, lo que ocurre antes que las rutas, el DNS y, sin duda, antes que cualquier aplicación detrás del túnel.

La prueba en el intérprete de órdenes tuvo éxito porque se ejecutó después de que todo se asentara. El gancho se ejecutó en un momento concreto.

Dónde se sitúa up en el orden de arranque

OpenVPN configura el dispositivo de túnel y luego ejecuta el gancho up. La instalación de rutas es una etapa posterior y tiene su propio gancho, por lo que una tarea dependiente de la ruta colocada en up puede ver un dispositivo sin una ruta útil. Ponga el trabajo de rutas en route-up y el problema de tiempo suele desaparecer.

El manual documenta este orden y el entorno que recibe cada gancho. Ese orden es toda la explicación del clásico informe “funciona desde mi intérprete de órdenes”, y también es la razón por la que el mismo script puede pasar en una máquina y fallar en otra con una etapa de rutas más lenta. Ninguno de los dos resultados dice nada sobre la calidad del script.

La preparación del DNS y de las aplicaciones llega aún más tarde. Ni siquiera las rutas instaladas son prueba de que el extremo remoto esté escuchando, de que un nombre se resuelva o de que exista una sesión de escritorio para una tarea del ámbito de un usuario.

Qué hereda realmente el gancho

Un gancho se ejecuta bajo la cuenta y el entorno del proceso OpenVPN, lo que no es lo mismo que su intérprete de órdenes interactivo. Puede carecer de un bus de sesión de usuario, de un entorno de escritorio o de una credencial que solo se desbloquea al iniciar sesión. Anote cuáles de esas cosas necesita realmente la tarea.

Eso importa para tareas que parecen de red pero dependen del contexto de usuario: montar un recurso compartido con una credencial de usuario, configurar un proxy por usuario o configurar una impresora. Un gancho de túnel privilegiado es el lugar equivocado para ellas, y ninguna cantidad de espera arregla una sesión ausente.

Cuando una tarea falla en un gancho, registre la cuenta, el entorno y la primera operación que falló. Eso separa el tiempo prematuro de un problema de permisos o de contexto, y los dos tienen reparaciones completamente distintas. Adivinar entre ellos es como una reparación de cinco minutos se convierte en una tarde entera.

Por qué añadir una espera no es una comprobación de preparación

Una espera retrasa el script y desplaza la ventana de la carrera. En un día rápido la tarea tiene éxito; en un día lento vuelve a fallar, y el fallo se vuelve más difícil de reproducir porque el retraso parece funcionar. Un retraso que solo funciona con carga ligera es una coincidencia, no una reparación.

Si la dependencia es una ruta, use el gancho que corresponde a la instalación de rutas. Si la dependencia es un servicio detrás del túnel, use una comprobación acotada que espere esa condición concreta y falle con claridad cuando nunca llega.

Mantenga el fallo explícito. Un gancho que sale con cero mientras su trabajo real ha fallado es peor que un gancho que falla, porque el gestor de servicios registra un éxito y nadie vuelve a mirar. Una línea de registro del propio script es la forma más barata de mantenerlo honesto.

La limpieza y la reconexión merecen el mismo cuidado

Un script que cambia estado compartido necesita una ruta de deshacer correspondiente. Las rutas, las entradas del resolutor y las marcas de cortafuegos que añade un gancho deben ser idempotentes y reversibles, o una reconexión apilará una segunda copia sobre la primera.

Las reconexiones también pueden ejecutar ganchos más a menudo que un inicio completo del servicio. Una interfaz persistente que restablece una sesión puede desencadenar de nuevo el ciclo up y route-up, así que un script que supone una ejecución por arranque acabará comportándose mal. Cuente las ejecuciones en el registro durante un día de oscilaciones para ver con qué frecuencia se ejecuta realmente. Luego haga que el script sea seguro para ejecutarse tantas veces.

Pruebe el ciclo de vida que falló, no un comando posterior. Reproduzca el arranque o la reconexión, observe cómo se ejecuta el gancho y confirme que la tarea tuvo éxito en el momento en que realmente se ejecuta. Un éxito desde un intérprete de órdenes interactivo después es evidencia sobre la dependencia, no prueba de que la ruta de arranque funcione.

Nombre el evento del que depende cada tarea y luego vincúlela a ese evento. Todo lo demás es un retraso que finge ser una comprobación.