La aplikaĵo ne rajtas ruliĝi dum la VPN estas ŝaltita: kio tion devigas

Kill switches kaj reguloj pri ne-overlapo montras en kontraŭajn direktojn, kio klarigas, kial ordinaraj VPN-agordoj neniam esprimas la duan. La kill switch reagas al tunelo, kiu falis, dum ĉi tiu postulo reagas al tunelo, kiu estas supre, kaj tenas aplikaĵon ekster la bildo. Unu dezajna decido solvas la plejparton: ĉu la aplikaĵo estas haltigata, malhelpata starti, aŭ nur senigata je reta aliro. Elektu tiun tavolon antaŭ ol preni fajroŝirmilan regulon aŭ proces-murda buklo, ĉar regulo devigata per observado likas fenestron ĉe ĉiu lanĉo.

La mito: kill switch malhelpas programojn starti

Kill switches estas trafikaj regiloj, kaj ili estas honestaj pri tio: ili permesas aŭ rifuzas pakaĵojn laŭ la stato de la tunelo. Neniu el ili rifuzas startigi programon, kaj neniu inspektas, kiu plenumebla dosiero malfermis konekton. Labortabla ligilo, planita tasko kaj fona helpilo ĉiuj atingas la reton sen pasi ion, kio scias la nomon de la aplikaĵo. La distanco inter tiuj du mekanismoj estas kie loĝas la plejparto de la konfuzo.

La aranĝo, kiu vere decidas ĉu programo rajtas starti, estas aplikaĵa kontrolo. En Windows tio signifas AppLocker aŭ WDAC, kaj en administrata macOS ĝi signifas permesliston devigatan de la aparata profilo. Ambaŭ estas sendependaj de la tunelo, tial la du postuloj kunfandiĝas en la sama bileto kaj poste plenumas ilin neniu.

Nomu la reĝimon antaŭ ol nomi la ilon

Skribu la regulon kiel stata aŭtomato kun tri statoj: ordinara uzo, VPN-labora seanco kaj foriro. La malpermesita overlapo apartenas al la meza stato, ne al la klienta programaro.

Kiu ŝanĝas la staton posedas tri agojn laŭorde: fini la laboron de la aplikaĵo, peti ĝian normalan malŝalton, kaj konfirmi ke la okazo malaperis antaŭ ol la tunelo supreniras. Ordo gravas ankaŭ ĉe la alia fino, ĉar VPN, kiu konektiĝas unue kaj haltigas la programon due, jam permesis la overlapon. Se la postulo kovras establado de la konekto, atendi konektitan indikilon estas tro malfrue.

Kion duflanka konflikto vere faras

Por du servoj vere administrataj de systemd, Conflicts= estas simetria: startigi unu haltigas la alian. La unua referenco dokumentas tiun konduton kaj aparte postulas eksplicitan ordon kiam unu devas fini haltadon antaŭ ol la alia startas. Sen tiuj ordaj enskriboj, halto kaj starto konkuras, kaj la rezulto dependas de tempo.

Tio ne estas malpermeslisto. Konektu la dependon inverse, kaj startigo de la aplikaĵo anstataŭe haltigas la VPN, kio estas la fuŝo suspektenda kiam tunelo mem malkonektiĝas en antaŭvidebla momento. Labortabla aplikaĵo ne estas systemd-unuo, kaj NetworkManager-konekto ankaŭ ne estas unuo, do tiu ŝablono funkcias nur por servoj, kiujn vi mem ĉirkaŭvolvas.

Testu la transirojn, ne nur la unuan lanĉon

Kvar transiroj decidas ĉu la postulo teniĝas: eniro en la seanon kun la aplikaĵo ruliĝanta, relanĉo meze de la seano, malsukcesa VPN-starto, kaj intenca malkonekto. Testu ĉiun kaj konservu la rezulton apud la unuaj dosieroj. La subaj komandoj legas la nunan rilaton kaj poste ekzercas la transiron, kiu plej gravas.

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 tria komando devus lasi la aplikaĵon neaktiva, kaj la kvara devus listigi nur la tunelan konekton dum seano ruliĝas. Malsama rezulto signifas, ke la transiro tute ne estas devigata.

La relanĉo dum la seano estas la kazo, kiu malkaŝas ĉirkaŭvolvan dezajnon, ĉar ligilo startigita de la labortablo neniam konsultas lanĉan skripton. Se tiu pretervojo gravas, devigo apartenas al aplikaĵa kontrolo kaj ne al la VPN-kliento. Dokumentu ankaŭ la finon de la seano, kaj preferu intencan daŭrigon al remalfermo de ĉiu procezo haltigita dum eniro. Notu la rezulton de ĉiu transiro en la sama noto, kiu tenas la unuajn dosierojn.