Per-toepassing-tydschakelaar vs. toesluiting van die hele toestel: wat verander
Besluit op grond van die beskermde versameling, nie die etiket nie: wat stop vir uitgeslote toepassings, agtergrondhulpprogramme en nuwe verbindings, en hoe om elke geval te toets.
'n Per-toepassing-tydschakelaar klink na die versigtige keuse: net die werkkliënt verloor sy netwerk wanneer die tonnel val, en alles anders bly werk. Dan sien iemand dat die persoonlike blaaier steeds 'n bladsy gelaai het, die sinkroniseringshulpprogram wat saam met dieselfde pakket kom het aanhou probeer, en 'n gekasde naam het steeds na 'n adres opgelos wat nooit die tonnel geraak het nie. Die etiket op die funksie en die stel verbindings wat dit werklik beskerm, is twee verskillende dinge. Bepaal eers die beskermde stel, want daardie stel besluit of per-toepassing-afdwinging of 'n toestelwye toesluiting die eerlike beskrywing is.
Begin met die stel, nie die etiket nie
'n Per-toepassing-beleid beskerm gekose toepassings. 'n Toesteltoesluiting mik op 'n wyer netwerkgrens, gewoonlik met gedokumenteerde uitsonderings vir plaaslike drukwerk, bestuursverkeer of vasvangportale. Nie een van die twee etikette is volledig voordat jy drie vrae kan antwoord nie: wat met uitgeslote toepassings gebeur, wat met die hulpprogramme gebeur wat daardie toepassings begin, en wat met verbindings gebeur wat oopgemaak word terwyl beskerming onbeskikbaar is.
Skryf daardie antwoorde neer voordat jy aan 'n kliëntinstelling raak. As die vereiste is "hierdie betaalstaatkliënt mag nooit buite die tonnel met die internet praat nie, en my blaaier mag", is die stel klein en pas per-toepassing-afdwinging. As die vereiste is "niks op hierdie toestel bereik die internet onbeskermd nie, behalwe die opdateringsdiens", sal geen per-toepassing-beleid dit lewer nie, want die toepassings wat jy nie genoem het nie, is die probleem.
Per-toepassing-afdwinging pas by identifiseerders, nie by programname nie
Android stel per-toepassing-VPN deur pakkette beskikbaar, en sy VpnService-dokumentasie beskryf hoe dit met altyd-aan-werking en blokkering saamwerk. iOS stel per-toepassing-VPN deur 'n bestuursprofiel op en pas by app of by domein. Windows en Linux het glad geen per-proses-roete nie, so dieselfde idee word benader met 'n firewallreël wat op 'n program gerig is of met 'n reël wat by die eienaar-gebruiker pas.
Die grens is die identifiseerder, en dit is maklik om identifiseerders te omseil. 'n Toepassing wat 'n URL aan die stelselblaaier oorhandig, of 'n dokument in 'n kyker oopmaak, beweeg in 'n proses in wat jou beleid nooit genoem het nie. 'n Beëindig-by-val-opsie is ook nie 'n pakkiefilter nie: dit maak die toepassing dood wat jy opgestel het, terwyl 'n kindproses, 'n wagry-werker of 'n blaaier-oortjie 'n bestaande sokkie aan die lewe kan hou.
Toesluiting dek wat 'n per-toepassing-beleid nie kan sien nie
'n Toestelwye toesluiting verwyder die keuse. Elke uitgaande pakket wat nie aan die tonnel behoort nie, word laat val, insluitend verkeer van prosesse waarvan jou toepassingbeleid nooit geweet het nie. Op Android is dit altyd-aan-VPN gekombineer met die instelling wat verbindings blokkeer, en die afdwinging gebeur in die stelsel, nie in die kliëntvenster nie. Op 'n rekenaar is dit 'n blywende firewallreël of 'n verstekroete wat na 'n onbereikbare poort wys.
Die koste is dat alles anders stop, so die vrystellings word deel van die ontwerp eerder as 'n nagedagte. Plaaslike drukkers, diensontdekking, aanmelding by vasvangportale, bestuursagente en bedryfstelselopdaterings het elkeen 'n gedokumenteerde gat nodig, want elkeen is 'n pad wat oop bly wanneer die tonnel af is. Die toesluiting is net so sterk soos die kortste inskrywing op daardie lys.
DNS, IPv6 en agtergrondhulpprogramme verberg die lekke
As 'n beskermde toepassing nie 'n naam kan oplos nie, bewys dit nie dat gekasde antwoorde of direkte-IP-verkeer geblokkeer is nie. As die oplosser steeds buite die tonnel bereikbaar is, los die naam op en misluk die verbinding, wat soos 'n werkende tydschakelaar lyk en dit nie is nie. Erger: 'n gekasde rekord kan na 'n adres wys wat die tonnel nie dra nie, so die verbinding gaan direk uit terwyl die toepassing 'n VPN-fout rapporteer.
IPv6 het sy eie reël nodig op elke platform wat dit gebruik, want 'n v4-valreël dek nie 'n v6-roete nie. Op selfone kan 'n private-DNS-instelling die oplossing binne 'n geënkripteerde kanaal skuif wat die toestelbeleid nie ondersoek nie. En agtergrondhulpprogramme is die gewone skuldige op rekenaars: 'n opdatering- of sinchroniseerproses begin voor die VPN-kliënt en hou sy eie verbinding, so dit sien nooit die veranderde roete nie.
Toets drie toepassings en twee oorgange
| 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 |
Voer elke ry twee keer uit, een keer met 'n gasheernaam en een keer met 'n letterlike adres, en nog een keer oor IPv6 as die netwerk dit bied. 'n Slaag beteken die ingeslote toepassing het gestop, die uitgeslote toepassing het opgetree soos jy neergeskryf het, en die hulpprogram het nie uitgeglip nie. Teken die direkte gedrag aan wat jy as aanvaarbaar besluit het, sodat die volgende administrateur 'n doelbewuste vrystelling van 'n fout kan onderskei.
Beskryf dan die resultaat in een sin wat die toepassings en die voorwaardes noem, byvoorbeeld: die betaalstaatkliënt het geen roete buite die tonnel nie, die blaaier is volgens ontwerp direk, en alles anders stop wanneer die tonnel af is. As daardie sin moeilik is om te skryf, is die beleid steeds twee beleide wat mekaar beveg.