La aplicación no debe ejecutarse con la VPN activa: qué lo hace cumplir

Los kill switches y las reglas de no solapamiento apuntan en direcciones opuestas, lo que explica por qué la configuración normal de la VPN nunca expresa la segunda. El kill switch reacciona a un túnel que ha caído, mientras que este requisito reacciona a un túnel que está activo y mantiene una aplicación fuera de la imagen. Una decisión de diseño resuelve la mayor parte: si la aplicación se detiene, se le impide arrancar o simplemente se le retira el acceso a la red. Elija esa capa antes de recurrir a una regla de cortafuegos o a un bucle que mate procesos, porque una regla impuesta por observación deja una ventana en cada arranque.

El mito: un kill switch impide que los programas arranquen

Los kill switches son controles de tráfico y lo dicen sin rodeos: permiten o deniegan paquetes según el estado del túnel. Ninguno se niega a iniciar un programa y ninguno inspecciona qué ejecutable abrió un socket. Un acceso directo del escritorio, una tarea programada y un ayudante en segundo plano llegan todos a la red sin pasar por nada que conozca el nombre de la aplicación. La distancia entre esos dos mecanismos es donde vive la mayor parte de la confusión.

La disposición que sí decide si un programa puede arrancar es el control de aplicaciones. En Windows eso significa AppLocker o WDAC, y en macOS gestionado significa una lista de permitidos impuesta por el perfil del dispositivo. Ambos son independientes del túnel, y por eso los dos requisitos se fusionan en el mismo ticket y luego no los cumple ninguno.

Nombre el modo antes de nombrar la herramienta

Escriba la regla como una máquina de estados con tres estados: uso ordinario, sesión de trabajo con VPN y salida. El solapamiento prohibido pertenece al estado intermedio, no al software cliente.

Quien cambia el estado posee tres acciones en orden: terminar el trabajo de la aplicación, solicitar su apagado normal y confirmar que la instancia se ha ido antes de que suba el túnel. El orden también importa en el otro extremo, porque una VPN que se conecta primero y detiene el programa después ya ha permitido el solapamiento. Si el requisito cubre el establecimiento de la conexión, esperar un indicador de conectado llega tarde.

Qué hace realmente un conflicto bidireccional

Para dos servicios gestionados de verdad por systemd, Conflicts= es simétrico: iniciar uno detiene el otro. La referencia de unidades documenta ese comportamiento y exige por separado un orden explícito cuando uno debe terminar de detenerse antes de que el otro arranque. Sin esas entradas de orden, la parada y el arranque compiten y el resultado depende del momento.

Eso no es una lista de denegación. Conecte la dependencia al revés y arrancar la aplicación detendrá la VPN, que es el fallo que hay que sospechar cuando un túnel se desconecta solo en un momento predecible. Una aplicación de escritorio no es una unidad de systemd, y una conexión de NetworkManager tampoco lo es, así que este patrón solo funciona para servicios que usted mismo envuelve.

Compruebe las transiciones, no solo el primer arranque

Cuatro transiciones deciden si el requisito se mantiene: entrar en la sesión con la aplicación en marcha, relanzarla a mitad de sesión, un arranque fallido de la VPN y una desconexión deliberada. Pruebe cada una y guarde el resultado junto a los archivos de unidad. Los comandos siguientes leen la relación actual y luego ejercitan la transición que más 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

El tercer comando debería dejar la aplicación inactiva, y el cuarto debería listar solo la conexión del túnel mientras hay una sesión en marcha. Un resultado distinto significa que la transición no se impone en absoluto.

El relanzamiento durante la sesión es el caso que expone un diseño basado en envoltorio, porque un acceso directo iniciado desde el escritorio nunca consulta un script de lanzamiento. Si esa elusión importa, la imposición pertenece al control de aplicaciones y no al cliente VPN. Documente también el final de la sesión y prefiera una reanudación deliberada a reabrir cada proceso que se detuvo al entrar. Registre el resultado de cada transición en la misma nota que guarda los archivos de unidad.