L’aplicació no ha de funcionar amb la VPN activa: què ho fa complir

Els kill switches i les regles de no-solapament apunten en direccions oposades, cosa que explica per què la configuració normal de la VPN mai no expressa la segona. El kill switch reacciona a un túnel que ha caigut, mentre que aquest requisit reacciona a un túnel que és actiu i manté una aplicació fora de la imatge. Una decisió de disseny en resol la major part: si l’aplicació s’atura, se li bloqueja l’inici o simplement se la desposseeix de l’accés a la xarxa. Trieu aquesta capa abans d’agafar una regla de tallafocs o un bucle que mati processos, perquè una regla aplicada per observació deixa una finestra a cada inici.

El mite: un kill switch impedeix que els programes s’iniciïn

Els kill switches són controls de trànsit i ho diuen sense embuts: permeten o deneguen paquets segons l’estat del túnel. Cap d’ells no es nega a iniciar un programa i cap no inspecciona quin executable ha obert un sòcol. Una drecera d’escriptori, una tasca programada i un assistent en segon pla arriben a la xarxa sense passar per res que conegui el nom de l’aplicació. La distància entre aquests dos mecanismes és on viu la major part de la confusió.

La disposició que sí que decideix si un programa pot iniciar-se és el control d’aplicacions. A Windows això vol dir AppLocker o WDAC, i a macOS gestionat vol dir una llista d’autoritzats aplicada pel perfil del dispositiu. Tots dos són independents del túnel, i per això els dos requisits s’ajunten en un mateix tiquet i després no els compleix cap dels dos.

Poseu nom al mode abans de posar-lo a l’eina

Escriviu la regla com una màquina d’estats amb tres estats: ús ordinari, sessió de treball amb VPN i sortida. El solapament prohibit pertany a l’estat central, no al programari client.

Qui canvia l’estat posseeix tres accions en ordre: acabar la feina de l’aplicació, demanar-ne l’aturada normal i confirmar que la instància ha desaparegut abans que el túnel pugi. L’ordre també importa a l’altre extrem, perquè una VPN que es connecta primer i atura el programa després ja ha permès el solapament. Si el requisit cobreix l’establiment de la connexió, esperar un indicador de connectat arriba tard.

Què fa realment un conflicte bidireccional

Per a dos serveis realment gestionats per systemd, Conflicts= és simètric: iniciar-ne un atura l’altre. La referència d’unitats documenta aquest comportament i exigeix per separat un ordre explícit quan un ha d’acabar d’aturar-se abans que l’altre comenci. Sense aquestes entrades d’ordre, l’aturada i l’inici competeixen i el resultat depèn del moment.

Això no és una llista de denegació. Connecteu la dependència al revés i iniciar l’aplicació atura la VPN, que és la fallada que cal sospitar quan un túnel es desconnecta tot sol en un moment previsible. Una aplicació d’escriptori no és una unitat de systemd, i una connexió de NetworkManager tampoc no ho és, així que aquest patró només funciona per a serveis que emboliqueu vosaltres mateixos.

Comproveu les transicions, no només el primer inici

Quatre transicions decideixen si el requisit es manté: entrar a la sessió amb l’aplicació en marxa, tornar-la a iniciar a mig camí, un inici fallit de la VPN i una desconnexió deliberada. Proveu cadascuna i deseu el resultat al costat dels fitxers d’unitat. Les ordres següents llegeixen la relació actual i després exerceixen la transició 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

La tercera ordre hauria de deixar l’aplicació inactiva, i la quarta hauria de llistar només la connexió del túnel mentre una sessió està en marxa. Un resultat diferent vol dir que la transició no s’aplica gens.

El reinici durant la sessió és el cas que exposa un disseny basat en embolcall, perquè una drecera iniciada des de l’escriptori no consulta mai un script de llançament. Si aquesta evasió importa, l’aplicació forçosa pertany al control d’aplicacions i no al client de VPN. Documenteu també el final de la sessió, i preferiu una represa deliberada a reobrir cada procés que es va aturar en entrar. Enregistreu el resultat de cada transició a la mateixa nota que guarda els fitxers d’unitat.