Forritið má ekki keyra meðan VPN er í gangi: hvað framfylgir því

Kill switches og reglur um enga skörun benda í gagnstæðar áttir, sem útskýrir hvers vegna venjulegar VPN-stillingar tjá aldrei hina seinni. Kill switch bregst við göngum sem hafa fallið, en þessi krafa bregst við göngum sem eru uppi og heldur forriti utan við myndina. Ein hönnunarákvörðun leysir mest af því: hvort forritið sé stöðvað, komið í veg fyrir að það starti, eða það svipt nettengingu eingöngu. Veldu það lag áður en þú grípur til eldveggjarreglu eða ferilhrings sem drepur ferla, því regla sem er framfylgt með athugun lekur glugga við hverja ræsingu.

Goðsögnin: kill switch kemur í veg fyrir að forrit starti

Kill switches eru umferðarstýringar, og þau eru heiðarleg um það: þau leyfa eða hafna pökkum eftir stöðu ganganna. Ekkert þeirra neitar að ræsa forrit, og ekkert skoðar hvaða keyrsluskrá opnaði sökkul. Skjáborðsflýtileið, tímasett verk og bakgrunnsaðstoð ná öll netinu án þess að fara fram hjá einhverju sem þekkir nafn forritsins. Fjarlægðin milli þessara tveggja aðferða er staðurinn þar sem mestur ruglingur býr.

Fyrirkomulagið sem raunverulega ákveður hvort forrit megi starta er forritastýring. Í Windows þýðir það AppLocker eða WDAC, og í stýrðu macOS þýðir það leyfislista sem tækjaprófíllinn framfylgir. Bæði eru óháð göngunum, þess vegna er kröfunum tveimur steypt saman í sama miða og síðan uppfyllir hvorugt þær.

Nefndu haminn áður en þú nefnir verkfærið

Skrifaðu regluna sem stöðuvél með þremur stöðum: venjuleg notkun, VPN-vinnulota og brottför. Bannaða skörunin tilheyrir miðstöðunni, ekki biðlaraforritinu.

Sá sem skiptir um stöðu á þrjár aðgerðir í röð: klára vinnu forritsins, biðja um eðlilega lokun þess og staðfesta að eintakið sé farið áður en göngin fara upp. Röðin skiptir líka máli hinum megin, því VPN sem tengist fyrst og stöðvar forritið síðan hefur þegar leyft skörunina. Ef krafan nær yfir stofnun tengingar er of seint að bíða eftir tengdum vísbendingu.

Hvað tvíátta átök gera í raun

Fyrir tvær þjónustur sem systemd stýrir í raun er Conflicts= samhverft: að ræsa eina stöðvar hina. Unit-tilvísunin skjalfestir þá hegðun og krefst sérstaklega skýrrar röðunar þegar önnur verður að klára stöðvun áður en hin byrjar. Án þessara röðunarfærslna keppa stöðvunin og ræsingin, og niðurstaðan fer eftir tímasetningu.

Þetta er ekki bannlisti. Tengdu háðina öfugt og ræsing forritsins stöðvar VPN-ið í staðinn, sem er bilunin sem á að gruna þegar göngin aftengjast af sjálfu sér á fyrirsjáanlegri stundu. Skjáborðsforrit er ekki systemd-eining, og NetworkManager-tenging er það ekki heldur, svo þetta mynstur virkar aðeins fyrir þjónustur sem þú vefur sjálfur.

Prófaðu umskiptingarnar, ekki bara fyrstu ræsingu

Fjórar umskiptingar ákveða hvort krafan haldi: að ganga inn í lotuna með forritið keyrandi, endurræsa það mitt í lotunni, misheppnuð VPN-ræsing og viljandi aftenging. Prófaðu hverja og geymdu niðurstöðuna við unit-skrárnar. Skipanirnar hér fyrir neðan lesa núverandi samband og æfa síðan umskiptinguna sem skiptir mestu.

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

Þriðja skipunin ætti að láta forritið óvirkt, og fjórða ætti að lista aðeins göngutenginguna meðan lota er í gangi. Önnur niðurstaða þýðir að umskiptingunni er alls ekki framfylgt.

Endurræsingin í lotunni er tilfellið sem flettir ofan af umbúðamiðaðri hönnun, því flýtileið sem ræst er af skjáborðinu ráðfærir sig aldrei við ræsiakriftu. Ef þessi undanskot skipta máli tilheyrir framfylgdin forritastýringu en ekki VPN-biðlaranum. Skjalfestu einnig lok lotunnar, og veldu viljandi framhald fram yfir að opna aftur hvern feril sem stöðvaður var við inngöngu. Skráðu niðurstöðu hverrar umskiptingar í sama minnisblað og geymir unit-skrárnar.