O aviso do OpenVPN sobre vários scripts --up: só um é executado

O aviso sobre vários scripts soa como uma queixa de agendamento, então a correção óbvia é reordenar as linhas até ele desaparecer. Não é uma queixa de agendamento. Uma definição posterior de --up substitui o comando já armazenado para essa etapa, e o analisador diz isso, o que significa que dos seus dois scripts exatamente um já foi executado alguma vez. O outro não está na fila atrás dele; ele sumiu.

É por isso que o aviso merece atenção mesmo não sendo fatal: o que ele prevê é uma atualização de DNS ou uma mudança de rota que parou silenciosamente de acontecer.

O aviso não é sobre ordenação

OpenVPN guarda um único comando de script de usuário para a etapa up. Quando o analisador encontra outra definição, do perfil, de um arquivo incluído ou da linha de comando, ele substitui o que já tinha e emite o aviso. Nada é concatenado, nada é executado duas vezes, e não existe nenhuma questão de ordem. O comando que sobrevive é o que o analisador viu por último, por isso mover uma linha pode mudar o vencedor enquanto o outro script fica morto.

O mesmo padrão vale para as outras etapas de script: um comando cada. Se dois trabalhos precisam os dois acontecer, precisam de um único ponto de entrada, não de duas diretivas que parecem uma lista.

Encontre as duas definições no arranque real

Comece pelo que o daemon realmente recebeu, não pelo perfil que você editou. ps -ef e o ExecStart da unidade mostram a linha de comando, que pode adicionar --up a partir de um ponto de entrada de contêiner ou de um wrapper; um arquivo init de uma distribuição pode fazer o mesmo. systemctl cat openvpn-server@server revela o que o próprio serviço acrescenta, e um grep recursivo no diretório de configuração encontra as definições no nível de arquivo. As duplicatas costumam vir de camadas diferentes, e é exatamente por isso que editar um único arquivo não muda nada.

Copiar um script para outro diretório ou renomeá-lo também não remove uma diretiva. O analisador conta definições, não arquivos.

Deixe um único hook assumir o trabalho

A solução duradoura é um único despachante que executa as duas ações numa ordem deliberada. Um script shell curto com set -eu que chama a integração necessária e depois a ação local, passando "$@" para que os limites dos argumentos sobrevivam, mantém o comportamento num único lugar auditável. Passar argumentos apenas os preserva; não estabelece que os dois auxiliares esperem a mesma interface, então leia o contrato de cada um. Decida o que deve fazer uma falha e se as mudanças parciais precisam ser revertidas.

Se o iniciador oferece um hook de extensão suportado, prefira-o ao encadeamento feito à mão. Uma imagem de contêiner ou um pacote de fornecedor costuma ter um local documentado para trabalho extra, e usá-lo impede que uma atualização sobrescreva o seu despachante.

A limpeza pertence à etapa down correspondente. Uma ação up que reescreve DNS ou adiciona rotas precisa de uma reversão documentada, e um despachante que só trata do arranque é meio design.

Confirme a integração, não apenas o silêncio

Remover o aviso de duplicata é a parte fácil; a integração ainda tem de funcionar. Verifique o estado do resolvedor após conectar com resolvectl status ou lendo /etc/resolv.conf, e confirme as rotas com ip route. Depois desconecte e reconecte, porque um hook encadeado com pressa costuma deixar algo da sessão anterior. journalctl -u openvpn-server@server -b mostra se o seu despachante foi executado e o que imprimiu.

Mantenha os privilégios do hook onde pertencem. Elevar script-security ou executar o daemon com mais direitos não é uma correção para um hook substituído; amplia o que cada script futuro pode fazer, incluindo um que um atacante chegue a nomear.

O sinal de que a correção é real não é o silêncio no registo. É a resposta DNS, a entrada de rota e a limpeza funcionando após duas reconexões.