El aviso de OpenVPN sobre varios scripts --up: solo se ejecuta uno

El aviso de varios scripts suena a queja de planificación, así que la solución obvia es reordenar las líneas hasta que desaparezca. No es una queja de planificación. Una definición posterior de --up sustituye la orden ya almacenada para esa etapa, y el analizador lo dice, lo que significa que de sus dos scripts solo se ha ejecutado exactamente uno. El otro no está en cola detrás; ha desaparecido.

Por eso el aviso merece atención aunque no sea fatal: lo que predice es una actualización de DNS o un cambio de ruta que dejó de ocurrir en silencio.

El aviso no va de ordenación

OpenVPN guarda una sola orden de script de usuario para la etapa up. Cuando el analizador encuentra otra definición, del perfil, de un archivo incluido o de la línea de comandos, sustituye lo que ya tenía y emite el aviso. Nada se concatena, nada se ejecuta dos veces y no existe ninguna cuestión de orden. La orden que sobrevive es la que el analizador vio al final, por eso mover una línea puede cambiar el ganador mientras el otro script queda muerto.

El mismo patrón se aplica a las demás etapas de script: una orden cada una. Si dos tareas deben ocurrir ambas, necesitan un único punto de entrada, no dos directivas que parezcan una lista.

Encuentre las dos definiciones en el arranque real

Empiece por lo que el demonio recibió realmente, no por el perfil que editó. ps -ef y la ExecStart de la unidad muestran la línea de comandos, que puede añadir --up desde un punto de entrada de contenedor o un envoltorio; un archivo init de la distribución puede hacer lo mismo. systemctl cat openvpn-server@server revela qué aporta el propio servicio, y un grep recursivo por el directorio de configuración encuentra las definiciones a nivel de archivo. Los duplicados suelen venir de capas distintas, y por eso editar un solo archivo no cambia nada.

Copiar un script a otro directorio o renombrarlo tampoco elimina una directiva. El analizador cuenta definiciones, no archivos.

Que un solo hook se encargue del trabajo

La solución duradera es un único despachador que ejecute ambas acciones en un orden deliberado. Un script de shell corto con set -eu que llama a la integración necesaria y luego a la acción local, pasando "$@" para que sobrevivan los límites de los argumentos, mantiene el comportamiento en un solo lugar auditable. Pasar argumentos solo los conserva; no demuestra que los dos ayudantes esperen la misma interfaz, así que lea el contrato de cada uno. Decida qué debe hacer un fallo y si los cambios parciales deben revertirse.

Si el lanzador ofrece un hook de extensión compatible, prefíeralo al encadenamiento hecho a mano. Una imagen de contenedor o un paquete de proveedor suele tener un lugar documentado para trabajo adicional, y usarlo evita que una actualización sobrescriba su despachador.

La limpieza pertenece a la etapa down correspondiente. Una acción up que reescribe DNS o añade rutas necesita una reversión documentada, y un despachador que solo gestiona el arranque es medio diseño.

Confirme la integración, no solo el silencio

Quitar el aviso de duplicado es la parte fácil; la integración todavía tiene que funcionar. Compruebe el estado del resolutor tras conectarse con resolvectl status o leyendo /etc/resolv.conf, y confirme las rutas con ip route. Luego desconecte y vuelva a conectar, porque un hook encadenado con prisa suele dejar algo de la sesión anterior. journalctl -u openvpn-server@server -b muestra si se ejecutó su despachador y qué imprimió.

Mantenga los privilegios del hook donde corresponden. Elevar script-security o ejecutar el demonio con más derechos no es una solución para un hook sustituido; amplía lo que puede hacer cada script futuro, incluido uno que un atacante llegue a nombrar.

La señal de que la solución es real no es el silencio en el registro. Es la respuesta DNS, la entrada de ruta y la limpieza funcionando tras dos reconexiones.