Rakendus ei tohi VPN-i ajal töötada: mis seda tagab

Kill switchid ja kattumiskeelu reeglid osutavad vastassuundadesse, mis selgitab, miks tavalised VPN-i seaded ei väljenda kunagi teist. Kill switch reageerib tunnelile, mis on maha läinud, samal ajal kui see nõue reageerib tunnelile, mis on üleval, ja hoiab rakenduse pildist väljas. Üks disainiotsus lahendab suurema osa: kas rakendus peatatakse, takistatakse selle käivitamist või võetakse lihtsalt võrguühendus ära. Valige see kiht enne, kui haarasite tulemüürireegli või protsesse tapva tsükli järele, sest vaatlusega jõustatud reegel lekitab igal käivitamisel akna.

Müüt: kill switch takistab programmide käivitumist

Kill switchid on liikluskontroll ja on selles ausad: nad lubavad või keelavad pakette tunneliseisundi järgi. Ükski neist ei keeldu programmi käivitamast ja ükski ei uuri, milline täitmisfail soketi avas. Töölaua otsetee, ajastatud ülesanne ja taustapõrse jõuavad kõik võrku ilma millegi juures peatumata, mis teab rakenduse nime. Nende kahe mehhanismi vaheline kaugus on koht, kus elab suurem osa segadusest.

Korraldus, mis tegelikult otsustab, kas programm tohib käivituda, on rakenduste kontroll. Windowsis tähendab see AppLockerit või WDAC-i, hallatud macOS-is aga seadme profiili poolt jõustatud lubatud loendit. Mõlemad on tunnelist sõltumatud, seetõttu liidetakse kaks nõuet samasse piletisse ja siis ei täida neid kumbki.

Nimetage režiim enne, kui nimetate tööriista

Kirjutage reegel olekumasinana kolme olekuga: tavakasutus, VPN-i tööseanss ja lahkumine. Keelatud kattumine kuulub keskmise oleku juurde, mitte klienditarkvara juurde.

Kes olekut muudab, omab kolme toimingut järjekorras: lõpetada rakenduse töö, taotleda selle tavaline sulgemine ja kinnitada, et eksemplar on kadunud, enne kui tunnel tõuseb. Järjekord on oluline ka teises otsas, sest VPN, mis ühendub esimesena ja peatab programmi teisena, on kattumise juba lubanud. Kui nõue hõlmab ühenduse loomist, on ühendatud indikaatori ootamine liiga hilja.

Mida kahesuunaline konflikt tegelikult teeb

Kahe tõeliselt systemd poolt hallatava teenuse puhul on Conflicts= sümmeetriline: ühe käivitamine peatab teise. Unit-viide dokumenteerib selle käitumise ja nõuab eraldi selget järjekorda, kui üks peab lõpetama peatamise enne, kui teine käivitub. Ilma nende järjekordade kirjeteta võistlevad peatumine ja käivitamine ning tulemus sõltub ajastusest.

See ei ole keeluloend. Ühendage sõltuvus valetpidi ja rakenduse käivitamine peatab hoopis VPN-i, mis on tõrge, mida tasub kahtlustada, kui tunnel ennast ettearvataval hetkel lahti ühendab. Töölauarakendus ei ole systemd unit ja NetworkManageri ühendus ei ole samuti unit, seega see muster töötab ainult teenuste puhul, mida te ise mähite.

Kontrollige üleminekuid, mitte ainult esimest käivitust

Neli üleminekut otsustavad, kas nõue peab: sessiooni sisenemine rakenduse töötamise ajal, selle taaskäivitamine sessiooni keskel, ebaõnnestunud VPN-i käivitamine ja teadlik lahtiühendamine. Testige igaüht ja hoidke tulemus unit-failide kõrval. Allolevad käsud loevad praegust seost ja harjutavad seejärel üleminekut, mis kõige rohkem loeb.

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

Kolmas käsk peaks jätma rakenduse mitteaktiivseks ja neljas peaks loetlema ainult tunnelühenduse, kui seanss töötab. Teistsugune tulemus tähendab, et üleminekut ei jõustata üldse.

Taaskäivitamine seansi ajal on juhtum, mis paljastab mähisele tugineva disaini, sest töölaualt käivitatud otsetee ei konsulteeri kunagi käivituskriptiga. Kui see möödasõit loeb, kuulub jõustamine rakenduste kontrolli, mitte VPN-kliendi juurde. Dokumenteerige ka seansi lõpp ja eelistage teadlikku jätkamist selle asemel, et uuesti avada iga sisenemisel peatatud protsess. Märkige iga ülemineku tulemus samasse märkmesse, mis hoiab unit-faile.