Rakendusepõhine kill switch vs kogu seadme lukustus: mis muutub
Otsustage kaitstud hulga, mitte sildi järgi: mis peatub välistatud rakendustel, taustaabilistel ja uutel ühendustel ning kuidas iga juhtumit testida.
Rakendusepõhine kill switch kõlab ettevaatliku valikuna: kui tunnel katkeb, kaotab võrgu ainult tööklient ja kõik muu jätkab tööd. Siis märkab keegi, et isiklik brauser laadis ikkagi lehe, sama paketiga tulnud sünkroonimisabiline jätkas proovimist ja vahemällu salvestatud nimi lahenes endiselt aadressile, mis tunnelit kunagi ei puudutanud. Funktsiooni silt ja ühenduste hulk, mida see tegelikult kaitseb, on kaks eri asja. Määrake esmalt kaitstud hulk, sest see hulk otsustab, kas aus kirjeldus on rakendusepõhine jõustamine või kogu seadme lukustus.
Alustage hulgast, mitte sildist
Rakendusepõhine poliitika kaitseb valitud rakendusi. Seadme lukustus sihib laiemat võrgupiiri, tavaliselt dokumenteeritud eranditega kohaliku printimise, haldusliikluse või captive portalide jaoks. Kumbki silt ei ole täielik enne, kui suudate vastata kolmele küsimusele: mis juhtub välistatud rakendustega, mis juhtub abilistega, mille need rakendused käivitavad, ja mis juhtub ühendustega, mis avatakse siis, kui kaitse pole saadaval.
Kirjutage need vastused üles enne, kui puudutate kliendi seadet. Kui nõue on "see palgaarvestuse klient ei tohi kunagi tunnelist väljaspool internetiga suhelda ja minu brauser võib", on hulk väike ja rakendusepõhine jõustamine sobib. Kui nõue on "miski selles seadmes ei jõua internetti kaitseta, välja arvatud värskendusteenus", ei anna ükski rakendusepõhine poliitika seda, sest probleemiks on rakendused, mida te ei nimetanud.
Rakendusepõhine jõustamine vastab identifikaatoritele, mitte programminimedele
Android pakub rakendusepõhist VPN-i pakettide kaudu ja selle VpnService'i dokumentatsioon kirjeldab, kuidas see koostoimib alati sisse lülitatud režiimi ja blokeerimisega. iOS seadistab rakendusepõhise VPN-i haldusprofiili kaudu ja vastab rakenduse või domeeni järgi. Windowsil ja Linuxil puudub protsessipõhine marsruut täiesti, seega lähendatakse sama ideed programmiga piiratud tulemüürireegliga või reegliga, mis vastab omanikust kasutajale.
Piiriks on identifikaator ja identifikaatoritest on lihtne mööda minna. Rakendus, mis annab URL-i süsteemsele brauserile või avab dokumendi vaaturis, liigub protsessi, mida teie poliitika kunagi ei nimetanud. Katkemisel lõpetamise valik ei ole samuti paketifilter: see tapab seadistatud rakenduse, samal ajal kui alamprotsess, järjekorratöötaja või brauseri vahekaart võib olemasoleva sokli elus hoida.
Lukustus katab selle, mida rakendusepõhine poliitika ei näe
Kogu seadme lukustus võtab valiku ära. Iga väljuv pakett, mis tunnelisse ei kuulu, visatakse kõrvale, sealhulgas liiklus protsessidelt, millest teie rakendusepoliitika kunagi ei teadnud. Androidis on see alati sisse lülitatud VPN koos ühenduste blokeerimise seadega ja jõustamine toimub süsteemis, mitte kliendi aknas. Lauaarvutis on see püsiv tulemüürireegel või vaikimisi marsruut kättesaamatusse lüüsi.
Hind on see, et kõik muu peatub, nii et erandid saavad disaini osaks, mitte hilisemaks mõtteks. Kohalikud printerid, teenuseavastus, captive portalide sisselogimine, haldusagendid ja OS-i värskendused vajavad igaüks dokumenteeritud auku, sest igaüks on tee, mis jääb lahtiseks, kui tunnel on maas. Lukustus on ainult nii tugev kui selle nimekirja lühim kirje.
DNS, IPv6 ja taustaabilised varjavad lekkeid
See, et kaitstud rakendus ei suuda nime lahendada, ei tõesta, et vahemällu salvestatud vastused või otsepõhine IP-liiklus on blokeeritud. Kui lahendaja on tunnelist väljaspool endiselt kättesaadav, laheneb nimi ja ühendus ebaõnnestub, mis näeb välja nagu töötav kill switch ja ei ole seda. Hullemini: vahemällu salvestatud kirje võib osutada aadressile, mida tunnel ei kanna, nii et ühendus läheb otse välja, samal ajal kui rakendus teatab VPN-veast.
IPv6 vajab oma reeglit igal platvormil, mis seda kasutab, sest v4 jaoks mõeldud kõrvalejätmise reegel ei kata v6 marsruuti. Mobiilis võib privaatse DNS-i seade viia lahendamise krüpteeritud kanalisse, mida seadme poliitika ei kontrolli. Ja taustaabilised on lauaarvutis tavaline süüdlane: värskendaja või sünkroonimisprotsess algab enne VPN-klienti ja hoiab oma ühendust, nii et see ei näe kunagi muutunud marsruuti.
Testige kolme rakendust ja kahte üleminekut
| Test | What it proves |
|---|---|
| Included app, by name and by direct IP | the policy is applied, not just the resolver |
| Excluded app, same checks | the exclusion is intentional and documented |
| Helper or updater process | nothing inherited an older route |
| Tunnel drop, then Wi-Fi to cellular | the block survives the transition |
Käivitage iga rida kaks korda, üks kord hostinime ja üks kord otsese aadressiga, ja veel kord IPv6 kaudu, kui võrk seda pakub. Läbimine tähendab, et kaasatud rakendus peatus, välistatud käitus nii, nagu kirjutasite, ja abiline ei libisenud välja. Kirjutage üles otsene käitumine, mille otsustasite vastuvõetavaks, et järgmine administraator eristaks tahtlikku erandit rikkest.
Seejärel kirjeldage tulemust ühe lausega, mis nimetab rakendused ja tingimused, näiteks: palgaarvestuse kliendil pole tunnelist väljaspool marsruuti, brauser on disaini järgi otsene ja kõik muu peatub, kui tunnel on maas. Kui seda lauset on raske kirjutada, on poliitika endiselt kaks poliitikat, mis omavahel võitlevad.