Execute as tarefas pós-VPN pelo dispatcher, não pelo if-up

Um script que deve rodar depois que a VPN sobe precisa de um evento do componente que possui a conexão. Um arquivo colocado em um diretório antigo de hooks de rede não é callback para toda VPN que NetworkManager, pppd ou um processo OpenVPN autônomo possam criar. Cada um desses donos relata um evento diferente com um ambiente diferente, então o dono precisa ser identificado antes de escolher o hook. Caso contrário, o script está correto e simplesmente nunca roda.

Para uma VPN gerenciada pelo NetworkManager, o dispatcher é o lugar certo, e vpn-up é a ação certa.

Use vpn-up, não o evento da interface

O dispatcher distingue up de vpn-up. O primeiro relata uma interface ativada; o segundo relata uma conexão VPN ativada. O Wi-Fi subir significa apenas que o enlace subjacente existe; o túnel pode ainda estar negociando, ou pode nunca autenticar.

O script recebe a interface e a ação, enquanto os detalhes da conexão chegam pelo ambiente, incluindo o UUID do perfil e a interface IP da VPN. Leia essas variáveis em vez de inferir identidade pelos nomes dos dispositivos.

Limite a correspondência a uma conexão

Combine pelo UUID da conexão, ou por outra identidade fornecida pelo dispatcher, em vez de um prefixo tun ou ppp0. Nomes de interface não são estáveis, mais de um túnel pode existir ao mesmo tempo, e dois perfis podem ter o mesmo nome de exibição. Combinar um prefixo tun significa que o script acabará disparando para uma conexão que ninguém queria tocar. Ele também pode disparar duas vezes para um perfil quando uma reconexão reconstrói o dispositivo.

Torne a tarefa idempotente. Um callback que adiciona uma rota a cada invocação acaba enchendo a tabela de duplicatas, e a segunda cópia é a que quebra o roteamento.

Saiba o que a ativação não prova

vpn-pre-up roda antes que o NetworkManager informe a VPN como totalmente ativada, e o gerenciador espera esses scripts. Use um estágio bloqueante apenas quando a tarefa realmente pertence ali, porque uma verificação lenta atrasa a ativação que todos os outros componentes esperam ver.

A existência de rotas não prova que um aplicativo esteja escutando, que um nome privado resolva ou que exista uma sessão de usuário. Verifique isso separadamente com um tempo limite limitado, e informe qual camada falhou em vez de repetir toda a cadeia.

Respeite o contexto em que o script roda

Scripts do dispatcher rodam como root, fora de qualquer sessão de usuário. Não presuma que o ambiente do usuário conectado, a sessão gráfica ou um chaveiro desbloqueado estejam disponíveis. Ninguém deveria responder a um contexto de desktop ausente tornando cada credencial legível para cada processo. Mantenha o trabalho da sessão de usuário em um serviço de usuário ou em um auxiliar de sessão que o callback possa sinalizar sem se passar pelo usuário.

A propriedade e as permissões do script também importam. Um arquivo executado como root que qualquer usuário pode substituir é um caminho de escalada de privilégios, e é uma constatação independente de a lógica da VPN estar correta.

Planeje a desconexão que nunca dispara

O NetworkManager documenta que vpn-pre-down não é emitido para desconexões forçadas, como um encerramento inesperado ou perda de conectividade. Por isso, uma limpeza construída apenas em torno de um pre-down tranquilo é incompleta por construção. Qualquer estado compartilhado que o script altere precisa de outro dono capaz de restaurá-lo após uma queda, e esse caminho de recuperação deve ser testado em vez de presumido.

Teste o hook com uma conexão normal, uma reconexão, uma desconexão intencional e um cabo arrancado. Registre o UUID, a ação e a interface que disparou, sem registrar segredos. Esse registro é a única prova confiável de que o hook rodou para a conexão que você pretendia, e é o que torna a próxima mudança segura.