Reiniciar um serviço no OpenVPN up: hooks vencem tun0.device

Conectar um serviço dependente a tun0.device parece assinar o túnel, e não é. A unidade de dispositivo reflete que a interface existe, o que pode continuar verdadeiro durante uma conexão falha e a reconexão que se segue. O serviço então age no momento errado, ou nunca, dependendo de a interface ter desaparecido nesse meio-tempo. O hook que descreve o evento que você realmente importa é o que o OpenVPN chama, não o que o systemd infere.

Decida qual condição o serviço precisa antes de escolher o gatilho, porque os três candidatos não são intercambiáveis.

O que a unidade de dispositivo realmente acompanha

O systemd cria uma unidade de dispositivo a partir da visão do kernel sobre uma interface de rede, então tun0.device fica ativa quando a interface aparece e inativa quando é removida. Com persist-tun, um reinício suave mantém a interface no lugar, então a unidade nunca oscila e nada ligado a ela é disparado. Mesmo sem persistência, a unidade não diz nada sobre rotas, DNS ou se a extremidade remota responde.

Isso a torna um mau substituto de 'a VPN está pronta'. Um ouvinte que só precisa do endereço local pode contentar-se com a existência da interface, enquanto um serviço que chama um aplicativo na rede remota precisa de rotas e acessibilidade, que a unidade de dispositivo não consegue expressar.

up, route-up e up-restart significam coisas diferentes

up é executado depois que o dispositivo TUN/TAP é aberto e a interface é configurada, que é o momento certo para um ouvinte que vincula o endereço atribuído. route-up é executado depois que as rotas são instaladas, sujeito a qualquer atraso de rota configurado, e serve para trabalho que exige a etapa de rotas completa. Nenhum dos dois prova que o aplicativo remoto responda. Escolher entre eles é uma questão do que o serviço precisa, não de qual hook soa mais acabado.

Com persist-tun, os reinícios reutilizam o dispositivo, então up não é executado de novo a menos que up-restart esteja definido. Essa opção habilita o script up para o ciclo de vida de reinício documentado, e seu ambiente é reduzido em comparação com uma primeira inicialização. Um script que assume o ambiente completo funciona na primeira conexão e falha na seguinte.

Envie a ação sem esperar por ela

Um hook que chama systemctl restart de forma síncrona pode entrar em impasse contra uma unidade cuja ordenação espera o túnel. systemctl --no-block try-restart vpn-dependent.service coloca a tarefa na fila e retorna, o que impede o hook de bloquear a conexão à qual estava reagindo. try-restart age apenas sobre uma unidade em execução, enquanto restart também inicia uma inativa; escolha deliberadamente, não por hábito.

Enfileirar não é verificar. O hook retorna sucesso assim que a tarefa é aceita, então a verificação precisa acontecer no journal da unidade de destino ou em seu estado real de escuta.

A política de reinício vive na unidade, não no hook

Uma unidade oneshot com RemainAfterExit=yes permanece ativa depois que seu comando sai, e uma segunda solicitação de início não faz nada porque o systemd a considera já iniciada. Isso é uma propriedade em torno da qual se projeta, não um defeito a contornar com chamadas de início repetidas. Se a ação precisa rodar por conexão, a unidade precisa de uma forma que o permita.

After= ordena unidades, e BindsTo= amarra tempos de vida, mas nenhum dos dois significa 'reinicie isto sempre que a VPN se reconectar'. Uma unidade ligada ao túnel para quando o túnel para; ela não se reinicia sozinha quando o túnel volta, a menos que algo a inicie de novo.

Teste três reconexões, não uma

Inicialização a frio, reinício completo do cliente e reconexão suave exercitam cada um um caminho diferente. A reconexão suave é a que expõe um up-restart ausente, um ambiente reduzido ou uma unidade de dispositivo que nunca ficou inativa. Execute as três e confirme os dois sentidos: o serviço age quando o túnel sobe, e não reinicia em mudanças de enlace não relacionadas, como roaming de Wi-Fi.

Mantenha um caminho de recuperação independente quando o serviço dependente carrega o seu próprio acesso administrativo. Um hook que reinicia aquilo por onde você está conectado é uma mudança que pode trancá-lo do lado de fora.