A aplicación non debe executarse coa VPN activa: que o fai cumprir
Deter unha aplicación mentres o túnel está activo non é un kill switch. Decida quen posúe o cambio de modo, que bloquea un relanzamento e que pode facer systemd e que non.
Os kill switches e as regras de non solapamento apuntan en direccións opostas, o que explica por que a configuración normal da VPN nunca expresa a segunda. O kill switch reacciona a un túnel que caeu, mentres que este requisito reacciona a un túnel que está activo e mantén unha aplicación fóra da imaxe. Unha decisión de deseño resolve a maior parte: se a aplicación se detén, se lle impide arrincar ou simplemente se lle retira o acceso á rede. Escolla esa capa antes de botar man dunha regra de cortalumes ou dun bucle que mata procesos, porque unha regra imposta por observación deixa unha xanela en cada arrinque.
O mito: un kill switch impide que os programas arrinquen
Os kill switches son controis de tráfico e din iso sen rodeos: permiten ou denegan paquetes segundo o estado do túnel. Ningún deles négase a iniciar un programa e ningún inspecciona que executable abriu un socket. Un atallo de escritorio, unha tarefa programada e un axudante en segundo plano chegan todos á rede sen pasar por nada que coñeza o nome da aplicación. A distancia entre eses dous mecanismos é onde vive a maior parte da confusión.
A disposición que si decide se un programa pode arrincar é o control de aplicacións. En Windows iso significa AppLocker ou WDAC, e en macOS xestionado significa unha lista de permitidos imposta polo perfil do dispositivo. Ambos son independentes do túnel, e por iso os dous requisitos fusiónanse no mesmo ticket e despois non os cumpre ningún.
Nomee o modo antes de nomear a ferramenta
Escriba a regra como unha máquina de estados con tres estados: uso ordinario, sesión de traballo con VPN e saída. O solapamento prohibido pertence ao estado intermedio, non ao software cliente.
Quen cambia o estado posúe tres accións en orde: rematar o traballo da aplicación, solicitar o seu apagado normal e confirmar que a instancia desapareceu antes de que suba o túnel. A orde tamén importa no outro extremo, porque unha VPN que se conecta primeiro e detén o programa despois xa permitiu o solapamento. Se o requisito cobre o establecemento da conexión, esperar un indicador de conectado chega tarde.
Que fai realmente un conflito bidireccional
Para dous servizos xestionados de verdade por systemd, Conflicts= é simétrico: iniciar un detén o outro. A referencia de unidades documenta ese comportamento e esixe por separado unha orde explícita cando un debe rematar de deterse antes de que o outro arrinque. Sen esas entradas de orde, a parada e o arrinque compiten e o resultado depende do momento.
Iso non é unha lista de denegación. Conecte a dependencia ao revés e arrincar a aplicación deterá a VPN, que é o fallo que hai que sospeitar cando un túnel se desconecta só nun momento previsible. Unha aplicación de escritorio non é unha unidade de systemd, e unha conexión de NetworkManager tampouco o é, así que este patrón só funciona para servizos que vostede mesmo envolve.
Comprobe as transicións, non só o primeiro arrinque
Catro transicións deciden se o requisito se mantén: entrar na sesión coa aplicación en marcha, relanzala a metade da sesión, un arrinque fallido da VPN e unha desconexión deliberada. Probe cada unha e garde o resultado xunto aos ficheiros de unidade. Os comandos seguintes len a relación actual e despois exercitan a transición que máis 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 debería deixar a aplicación inactiva, e o cuarto debería listar só a conexión do túnel mentres hai unha sesión en marcha. Un resultado distinto significa que a transición non se impón en absoluto.
O relanzamento durante a sesión é o caso que expón un deseño baseado en envoltorio, porque un atallo iniciado desde o escritorio nunca consulta un script de lanzamento. Se esa evasión importa, a imposición pertence ao control de aplicacións e non ao cliente VPN. Documente tamén o final da sesión e prefira unha reanudación deliberada a reabrir cada proceso que se detivo ao entrar. Rexistre o resultado de cada transición na mesma nota que garda os ficheiros de unidade.