Апликација не сме да ради док је VPN укључен: шта то спроводи

Kill switch и правила забране преклапања показују у супротним смеровима, што објашњава зашто уобичајене VPN поставке никад не изражавају друго. Kill switch реагује на тунел који је пао, док овај захтев реагује на тунел који је подигнут и држи апликацију изван слике. Једна дизајнерска одлука решава већину: да ли се апликација зауставља, блокира њено покретање или јој се само одузима мрежни приступ. Изаберите тај слој пре него што посегнете за правилом заштитног зида или петљом за убијање процеса, јер правило спроведено посматрањем пропушта прозор при сваком покретању.

Мит: kill switch спречава програме да се покрену

Kill switch је контрола саобраћаја и искрени су у вези с тим: дозвољавају или одбијају пакете према стању тунела. Ниједан од њих не одбија покретање програма и ниједан не проверава која је извршна датотека отворила сокет. Пречица на радној површини, заказани задатак и позадински помоћник сви долазе до мреже не пролазећи кроз нешто што зна име апликације. Размак између та два механизма место је где живи већина забуне.

Поставка која заиста одлучује сме ли програм почети јесте контрола апликација. На Windows-у то значи AppLocker или WDAC, а на управљаном macOS-у списак дозвољених који спроводи профил уређаја. Оба су независна од тунела, зато се два захтева спајају у исти тикет и онда их не задовољава ниједан.

Именујте режим пре него што именујете алат

Напишите правило као машину стања с три стања: обична употреба, радна сесија VPN-а и излазак. Забрањено преклапање припада средњем стању, а не клијентском софтверу.

Ко мења стање, поседује три радње по реду: завршити рад апликације, затражити њено нормално искључивање и потврдити да је инстанца нестала пре него што се тунел подигне. Редослед је важан и на другом крају, јер VPN који се прво повеже и затим заустави програм већ је допустио преклапање. Ако захтев покрива успостављање везе, чекање на индикатор повезаности је прекасно.

Шта двосмерни сукоб заиста ради

За две услуге које стварно управља systemd, Conflicts= је симетричан: покретање једне зауставља другу. Референца за unit документује то понашање и засебно захтева изричит редослед када једна мора да заврши заустављање пре него што друга почне. Без тих уноса редоследа заустављање и покретање се утркују, а исход зависи од времена.

То није списак забрана. Спојите зависност наопако и покретање апликације уместо тога зауставља VPN, што је квар који треба сумњичити када се тунел сам прекине у предвидивом тренутку. Столна апликација није systemd unit, а ни NetworkManager веза није unit, па овај образац ради само за услуге које сами обавијате.

Проверите прелазе, не само прво покретање

Четири прелаза одлучују држи ли захтев: улазак у сесију с покренутом апликацијом, њено поновно покретање усред сесије, неуспело покретање VPN-а и намерно прекидање. Тестирајте сваки и чувајте резултат уз unit датотеке. Наредбе испод читају тренутни однос и затим вежбају прелаз који је најважнији.

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

Трећа наредба треба да остави апликацију неактивном, а четврта да наведе само тунелску везу док сесија траје. Другачији резултат значи да прелаз уопште није спроведен.

Поновно покретање током сесије случај је који разоткрива дизајн заснован на омотачу, јер пречица покренута с радне површине никад не консултује скрипту за покретање. Ако је тај заобилазак важан, спровођење припада контроли апликација, а не VPN клијенту. Документујте и крај сесије и радије изаберите намерно настављање него поновно отварање сваког процеса заустављеног при уласку. Забележите резултат сваког прелаза у истој белешци која чува unit датотеке.