O aviso de OpenVPN sobre varios scripts --up: só se executa un

O aviso de varios scripts soa a queixa de planificación, así que a solución obvia é reordenar as liñas ata que desapareza. Non é unha queixa de planificación. Unha definición posterior de --up substitúe a orde xa almacenada para esa etapa, e o analizador dixo, o que significa que dos seus dous scripts só se executou exactamente un. O outro non está na cola detrás; desapareceu.

Por iso o aviso merece atención aínda que non sexa fatal: o que predí é unha actualización de DNS ou un cambio de ruta que deixou de ocorrer en silencio.

O aviso non vai de ordenación

OpenVPN garda unha soa orde de script de usuario para a etapa up. Cando o analizador atopa outra definición, do perfil, dun ficheiro incluído ou da liña de ordes, substitúe o que xa tiña e emite o aviso. Nada se concatena, nada se executa dúas veces e non existe ningunha cuestión de orde. A orde que sobrevive é a que o analizador viu ao final, por iso mover unha liña pode cambiar o gañador mentres o outro script queda morto.

O mesmo patrón vale para as demais etapas de script: unha orde cada unha. Se dous traballos deben ocorrer ambos, necesitan un único punto de entrada, non dúas directivas que parezan unha lista.

Atope as dúas definicións no arranque real

Comece polo que o daemon recibiu realmente, non polo perfil que editou. ps -ef e a ExecStart da unidade mostran a liña de ordes, que pode engadir --up desde un punto de entrada de contedor ou un envoltorio; un ficheiro init dunha distribución pode facer o mesmo. systemctl cat openvpn-server@server revela que achega o propio servizo, e un grep recursivo polo directorio de configuración atopa as definicións a nivel de ficheiro. Os duplicados veñen habitualmente de capas distintas, e é exactamente por iso que editar un só ficheiro non cambia nada.

Copiar un script a outro directorio ou renomealo tampouco elimina unha directiva. O analizador conta definicións, non ficheiros.

Que un só hook se encargue do traballo

A solución duradeira é un único despachador que execute as dúas accións nunha orde deliberada. Un script de shell curto con set -eu que chama a integración necesaria e despois a acción local, pasando "$@" para que sobrevivan os límites dos argumentos, mantén o comportamento nun único lugar auditable. Pasar argumentos só os conserva; non demostra que os dous axudantes esperen a mesma interface, así que lea o contrato de cada un. Decida que debe facer un fallo e se os cambios parciais deben reverterse.

Se o lanzador ofrece un hook de extensión compatible, prefírao ao encadeamento feito a man. Unha imaxe de contedor ou un paquete de provedor adoita ter un lugar documentado para traballo adicional, e usalo evita que unha actualización sobrescriba o seu despachador.

A limpeza pertence á etapa down correspondente. Unha acción up que reescribe DNS ou engade rutas necesita unha reversión documentada, e un despachador que só xestiona o arranque é medio deseño.

Confirme a integración, non só o silencio

Quitar o aviso de duplicado é a parte fácil; a integración aínda ten que funcionar. Comprobe o estado do resolutor tras conectarse con resolvectl status ou lendo /etc/resolv.conf, e confirme as rutas con ip route. Despois desconecte e volva conectar, porque un hook encadeado con présa adoita deixar algo da sesión anterior. journalctl -u openvpn-server@server -b mostra se se executou o seu despachador e que imprimiu.

Manteña os privilexios do hook onde corresponden. Elevar script-security ou executar o daemon con máis dereitos non é unha solución para un hook substituído; amplía o que pode facer cada script futuro, incluído un que un atacante chegue a nomear.

O sinal de que a solución é real non é o silencio no rexistro. É a resposta DNS, a entrada de ruta e a limpeza funcionando tras dúas reconexións.