Una tarea programada que se ejecutó sin la VPN parece correcta

El estado de la tarea dice éxito, el registro muestra una ejecución completada y los datos están obsoletos o ausentes. Esa combinación suele significar que la tarea programada arrancó sin la ruta que necesitaba, y que algo más abajo se tragó el fallo. Una programación que se dispara a tiempo no dice nada sobre si la red estaba lista. La brecha entre esos dos hechos es donde vive este fallo.

La admisión pertenece a la ejecución, no a la existencia de un archivo cron.

Una ejecución verde no es una tarea completada

Un planificador anota que un proceso arrancó y luego salió; no tiene idea de si ese proceso llegó al recurso para el que existe. Un script que trata una conexión fallida como un resultado vacío, o que captura un error y sale con cero, parecerá sano para siempre. El síntoma no es un estado rojo; es un estado plausible adherido a trabajo ausente.

Nombre lo que la ejecución necesita realmente antes de decidir cómo comprobarlo. Una copia de seguridad puede necesitar DNS privado y un extremo autenticado, no solo un proceso de túnel.

Compruebe la conexión, no el nombre de la interfaz

Una interfaz llamada tun0 puede existir sin la sesión que importa, y otra conexión puede poseer ese nombre. Compruebe el objeto concreto del que depende la tarea: una identidad de perfil, una instancia de servicio o una pequeña operación aprobada contra el recurso. Mantenga la comprobación acotada en el tiempo y mantenga las credenciales fuera de los argumentos del proceso y de los registros de diagnóstico.

Defina también el resultado desconectado. Un salto ordinario, un reintento dentro de una ventana corta y un plazo incumplido visible para el operador son tres respuestas distintas, y una programación recurrente no elige entre ellas.

Los saltos y los fallos son resultados distintos

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

En un despliegue systemd, ExecCondition= ejecuta ese comprobador antes de la carga de trabajo. Su comportamiento de salida es específico: cero continúa, los códigos del uno al 254 saltan las órdenes de arranque restantes sin marcar la unidad como fallida, y 255 o una terminación anormal la hacen fallar. Eso da tres señales distintas, útiles solo si el contrato del comprobador se asigna deliberadamente a ellas. Los ajustes que redefinen el éxito pueden cambiar la imagen, así que documente la asignación.

Registrar los saltos es lo que hace honesto el diseño. Una ejecución saltada que no aparece en ningún sitio es indistinguible de una ejecución que tuvo éxito, y tratar cada error del comprobador como un salto silencioso oculta un despliegue roto indefinidamente.

Proteja toda la ejecución, no solo el inicio

Una comprobación de preparación observa el mundo antes del lanzamiento; no vigila cada socket después. Cuando una ruta directa nunca es aceptable para esta tarea, adjunte una política de salida aprobada que se aplique de forma continua y cubra DNS, IPv6 y el propio transporte del túnel. Alternar el estado global de IPv6 del host no sustituye una política limitada a la tarea.

Decida si un evento nuevo puede solaparse con una tarea que sigue ejecutándose, mantenga esa regla con el propietario de la carga de trabajo y haga seguro el reintento para la operación de datos. Detener una tarea al desconectarse limita el trabajo sin garantizar nada sobre el tráfico de reserva.

Acepte el flujo de trabajo en tres casos: ruta lista, ruta no disponible y pérdida durante la ejecución. Cualquier cosa menos prueba la programación, no la tarea.