A aplicação não deve correr com a VPN ligada: o que o impõe
Parar uma aplicação enquanto o túnel está ativo não é um kill switch. Decida quem detém a mudança de modo, o que bloqueia um relançamento e o que o systemd pode e não pode fazer.
Os kill switches e as regras de não sobreposição apontam em direções opostas, o que explica por que as configurações normais de VPN nunca exprimem a segunda. O kill switch reage a um túnel que caiu, enquanto este requisito reage a um túnel ativo e mantém uma aplicação fora da imagem. Uma decisão de projeto resolve a maior parte: se a aplicação é parada, impedida de arrancar ou apenas privada do acesso à rede. Escolha essa camada antes de recorrer a uma regra de firewall ou a um ciclo que mata processos, porque uma regra imposta por observação deixa escapar uma janela em cada arranque.
O mito: um kill switch impede os programas de arrancar
Os kill switches são controlos de tráfego, e são honestos quanto a isso: permitem ou negam pacotes conforme o estado do túnel. Nenhum deles recusa iniciar um programa, e nenhum inspeciona que executável abriu um socket. Um atalho do ambiente de trabalho, uma tarefa agendada e um assistente em segundo plano chegam todos à rede sem passar por algo que conheça o nome da aplicação. A distância entre esses dois mecanismos é onde vive a maior parte da confusão.
A disposição que realmente decide se um programa pode arrancar é o controlo de aplicações. No Windows isso significa AppLocker ou WDAC, e no macOS gerido significa uma lista de permitidos imposta pelo perfil do dispositivo. Ambos são independentes do túnel, e é por isso que os dois requisitos se fundem no mesmo ticket e depois não são satisfeitos por nenhum.
Nomeie o modo antes de nomear a ferramenta
Escreva a regra como uma máquina de estados com três estados: uso comum, sessão de trabalho com VPN e saída. A sobreposição proibida pertence ao estado intermédio, não ao software cliente.
Quem muda o estado detém três ações por ordem: terminar o trabalho da aplicação, pedir o seu encerramento normal e confirmar que a instância desapareceu antes de o túnel subir. A ordem também importa no outro extremo, porque uma VPN que se liga primeiro e para o programa depois já permitiu a sobreposição. Se o requisito abrange o estabelecimento da ligação, esperar por um indicador de ligado chega tarde.
O que um conflito bidirecional realmente faz
Para dois serviços realmente geridos pelo systemd, Conflicts= é simétrico: iniciar um para o outro. A referência de unidades documenta esse comportamento e exige separadamente uma ordem explícita quando um tem de terminar a paragem antes de o outro arrancar. Sem essas entradas de ordem, a paragem e o arranque competem e o resultado depende do momento.
Isso não é uma lista de proibição. Ligue a dependência ao contrário e arrancar a aplicação para a VPN em vez disso, que é a falha que se deve suspeitar quando um túnel se desliga sozinho num momento previsível. Uma aplicação de ambiente de trabalho não é uma unidade systemd, e uma ligação do NetworkManager também não é, pelo que este padrão só funciona para serviços que você mesmo envolve.
Teste as transições, não só o primeiro arranque
Quatro transições decidem se o requisito se mantém: entrar na sessão com a aplicação em execução, relançá-la a meio da sessão, um arranque falhado da VPN e uma desconexão deliberada. Teste cada uma e guarde o resultado ao lado dos ficheiros de unidade. Os comandos seguintes leem a relação atual e depois exercitam a transição que mais importa.
systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active
O terceiro comando deve deixar a aplicação inativa, e o quarto deve listar apenas a ligação do túnel enquanto uma sessão decorre. Um resultado diferente significa que a transição não é imposta de todo.
O relançamento durante a sessão é o caso que expõe um projeto baseado em invólucro, porque um atalho iniciado a partir do ambiente de trabalho nunca consulta um script de arranque. Se essa evasão importa, a imposição pertence ao controlo de aplicações e não ao cliente VPN. Documente também o fim da sessão, e prefira uma retomada deliberada a reabrir cada processo que foi parado à entrada. Registe o resultado de cada transição na mesma nota que guarda os ficheiros de unidade.