Aprovisionar un cliente de OpenVPN con etapas que se detienen ante un error

Los scripts de aprovisionamiento que informan de un error y siguen adelante son peores que los que nunca se ejecutan. La configuración del cliente toca claves protegidas, una identidad en la pasarela y un servicio que puede estar ya sirviendo tráfico. Cada uno de esos elementos necesita una condición de parada, y el script debe saber a qué etapa llegó cuando se detuvo.

Trata todo el asunto como una transacción con cinco puntos de control, y haz que cada punto de control se niegue a continuar por su cuenta.

Corrige las entradas antes de tocar el sistema de archivos

Empieza con un contrato explícito: una identidad, una fuente de perfil, un propietario de servicio previsto. Verifica que el perfil existe, que el certificado y la clave a los que hace referencia son legibles y que el directorio de destino pertenece al paquete esperado. Una ruta que se resuelve no es prueba de que el material que hay detrás esté completo.

Rechaza las variables vacías pronto. Una $DEVICE sin definir que se expande a nada convierte install -m 400 $KEY /etc/openvpn/client/ en una copia dirigida a un directorio, y el fallo llega más tarde como un servicio que no puede leer su clave.

Monta el conjunto de perfiles en un directorio de preparación

Construye primero el conjunto completo en un lugar privado: perfil, CA, certificado de cliente, clave y cualquier auxiliar que llame el perfil. Copia con install -m 400 -o root -g root para que los permisos se fijen al crear y no después. Luego revisa las referencias dentro del perfil, porque una línea relativa ca o key se resuelve contra el directorio de trabajo de la unidad en cuanto arranca el servicio. No debe escribirse nada en el directorio activo hasta que todo el conjunto valide.

Registra una huella no secreta de lo que ha producido esta ejecución, por ejemplo sha256sum office.conf guardado junto a una marca de versión. Ese único valor es lo que permite a una reejecución distinguir una actualización de una no-operación.

Intercambia de forma atómica y conserva el conjunto anterior

Mueve el conjunto preparado a su sitio como una sola operación allí donde el sistema de archivos lo permita, y conserva el conjunto anterior revisado bajo un nombre con marca de tiempo. Una copia parcial que deja un perfil nuevo junto a una clave vieja produce un servicio que se autentica con la identidad equivocada y no registra nada útil sobre el motivo. Si el intercambio no puede ser atómico, ordena los movimientos para que el perfil llegue el último.

Cuando el destino ya existe, decide explícitamente si esta ejecución es una actualización, una reejecución idéntica o un conflicto con el perfil de otro dispositivo. Sobrescribir en silencio un perfil que pertenece a otra identidad es como dos máquinas acaban compartiendo un solo certificado. Rechaza la ejecución y nombra al propietario en conflicto.

Activa un solo propietario y demuéstralo

Elige una sola vía de activación, o la instancia de systemd o NetworkManager, y úsala de forma coherente. Arrancar un proceso openvpn no gestionado junto a una unidad habilitada da dos túneles, actualizaciones DNS competidoras y ninguna respuesta clara sobre a cuál apunta una orden de parada. Tras la activación, comprueba systemctl is-active openvpn-client@office, luego la ruta al prefijo remoto y luego resolvectl status para el resolutor que instaló el túnel. Termina alcanzando un recurso para el que existe el túnel.

Un proceso en marcha y un icono verde en la bandeja son hechos del proceso, no pruebas de que la identidad y la política de tráfico sobrevivieran al traspaso.

La reejecución y la retirada son flujos de trabajo separados

Una segunda ejecución debería converger en los mismos archivos revisados y el mismo propietario, no crear una segunda cuenta ni un segundo demonio. La retirada es su propio procedimiento: detén al propietario exacto, archiva o borra el perfil local según la política y revoca la identidad en la pasarela. Borrar un archivo de clave local no revoca una copia que ya ha salido de la máquina.

Mantén una vía de recuperación que no dependa del túnel, como acceso a la consola o una segunda ruta de gestión. Un cambio de aprovisionamiento que te deja fuera de la máquina es un cambio fallido aunque cada etapa haya informado de éxito.

El script que merece conservarse es una transacción en torno a la propiedad y la evidencia. Una lista corta de órdenes de copia privilegiadas no es lo mismo.