La VPN de la red doméstica no tiene nada que hacer cuando el portátil ya está en esa red. El atajo tentador es un comando de preparación que sale con un código distinto de cero; eso hace fallar la unidad y que todos los paneles parezcan rotos. systemd tiene una directiva para exactamente esta forma de decisión, y separa una omisión deliberada de un fallo real. Hacerlo bien consiste sobre todo en escribir qué significa cada código de salida.

Por qué una precondición fallida es la forma equivocada

ExecStartPre trata una salida distinta de cero como un fallo de arranque, lo cual es correcto para un comando que prepara el servicio. Usarlo como condición hace que una decisión de política sea indistinguible de una dependencia rota. ExecCondition existe para que una unidad pueda negarse a arrancar sin marcarse como fallida.

Esa distinción importa a las tres de la madrugada, cuando nadie quiere clasificar una unidad roja que se comportaba según lo diseñado. Una unidad fallida también oculta los fallos reales entre los intencionados.

Escriba primero el contrato de códigos de salida

Escriba el contrato antes del script. La salida cero significa continuar, la salida uno significa omitir los comandos de arranque restantes y la salida 255 significa que la propia condición no pudo ejecutarse. Los códigos entre dos y 254 normalmente también significan omitir, algo fácil de olvidar cuando un ayudante devuelve un código de error aleatorio. El drop-in de abajo vincula el ayudante al nombre real de la unidad.

[Service]
ExecCondition=/usr/local/libexec/should-start-home-vpn

Revise la unidad efectiva por si tiene valores heredados de SuccessExitStatus o stop-post antes de suponer la semántica predeterminada. Después pruebe deliberadamente cada uno de los tres resultados.

Una pista de red no es prueba de ubicación

Una dirección de router accesible o una MAC conocida pueden sugerir la red correcta, y ninguna de las dos lo demuestra. Otra red puede reutilizar la misma dirección, los datos ARP pueden estar obsoletos y los identificadores se pueden imitar. Trate la sonda como una optimización coherente con la política, no como un resultado de autenticación.

Decida de antemano qué significa la incertidumbre. Iniciar la VPN cuando no está seguro es seguro para un cliente que simplemente no lograría conectarse; omitirla cuando no está seguro no lo es. Haga que la sonda esté acotada y lea la interfaz activa en lugar de suponer la primera de la lista. Una sonda que se cuelga es peor que una que responde que no, porque la unidad la espera.

Anote esas suposiciones junto al archivo de la unidad para que la siguiente persona sepa qué cree el ayudante. Un comentario al principio del script es el lugar más barato para guardarlas.

Gestione el movimiento entre redes

La condición se ejecuta cuando arranca el servicio y no se reevalúa después. Una unidad omitida sigue omitida después de que el portátil se traslade a una cafetería, y un túnel activo sigue levantado después de que el portátil vuelva a casa. Conecte el ciclo de vida del cambio de red con la decisión de arranque y parada mediante un mecanismo aparte.

systemctl cat home-vpn.service

Pruebe cuatro casos: arranque en casa, arranque fuera, una sonda que no puede ejecutarse y un movimiento entre redes mientras la unidad está activa. Mantenga el motivo de la omisión visible en el registro para que una decisión intencionada nunca parezca un fallo de autenticación. La referencia del servicio documenta la semántica de salida y la versión mínima.

Artículos relacionados