Androidi rakendusepõhine VPN ja Chrome'i inkognito: mida reegel katab

Keegi on ehitanud automaatika, mis lülitab VPN-i sisse, kui ilmub inkognito-vahekaart, ja see ei tööta usaldusväärselt. Sellel on struktuurne põhjus ja seda tasub mõista enne automaatika häälestamist. Androidi rakendusepõhised VPN-reeglid valivad rakenduste pakette ja inkognito on ühe paketi sees olev olek, seega ei suuda reegel neid kahte eristada. Teade saabub pärast seda, kui brauser on juba tööle hakanud, nii et isegi õige päästik jõuab hilja. Käige allolevad kontrollid järjest läbi; neljanda kontrolli ebaõnnestumine tähendab, et muuta tuleb lähenemist, mitte seadistust.

Esimene kontroll: kinnitage, mida rakendusepõhine reegel valida saab

Androidi VPN-rakendus ehitab oma tunnelit lubatud või keelatud rakenduste loenditega ja need loendid võtavad pakettide nimesid. Chrome tavalises režiimis ja Chrome inkognito-režiimis on sama pakett, sama kasutaja identifikaatori ja sama võrguõigusega, seega Chrome'i kaasav või välistav reegel kehtib mõlemale ühtemoodi. Platvormil ei ole vahekaardi tasandi identiteeti, millega reeglit sobitada.

See ei ole viga, millest mööda minna; see on detailsus, mida API pakub. Kui teie nõue on Chrome'i liiklus tunnelisse ja kõik muu välja, väljendab rakendusepõhine reegel seda täpselt. Kui teie nõue on ainult privaatsed vahekaardid tunnelisse, samal ajal kui tavalised vahekaardid lähevad otse, ei suuda ükski rakendusepõhine reegel seda väljendada ja ükski teavituste loogika hulk ei lisa valijat, mida platvormil ei ole.

Kontrolli ajal pöörake tähelepanu paketi identiteedi lõksule. Beeta- või tarnija koostatud versioon on stabiilsest brauserist erinev pakett, seega reegel, mis katab ühe, jätab teise vaikselt tähelepanuta:

adb shell pm list packages | grep -i chrome

Teine kontroll: kontrollige, kas päästik saab üldse kunagi piisavalt varajane olla

Teavituste kuulaja jälgib teavitusi, mida tal on lubatud näha. Jälgimine ei ole vahelesegamine: brauser on nime juba lahendanud ja ühenduse avanud selleks ajaks, kui teade tekib, ja miski selles teekonnas ei oota, kuni teie automaatika lõpetab. Ülesanne, mis seejärel VPN-kliendi käivitab, peab ootama kliendi kasutajaliidest, võimalikku nõusolekuküsimust ja tunneli kätlust, mida mõõdetakse sekundites, samal ajal kui esimest päringut mõõdetakse millisekundites.

Tuvastamine ise on hapraks ka teisel põhjusel. Teavituste tekst muutub versioonide ja lokaliseeringute vahel, seega ühe väljalaskega sobitatud muster lakkab pärast uuendust sobimast ja tõrge on vaikne. Puuduv teade ei ole tõend selle kohta, et privaatne sirvimine puudub; see võib tähendada ainult seda, et string muutus või kanal vaigistati.

Sellel töövoogudel on ka õiguspärane versioon ja see on järjestatud, mitte reaktiivne: ühendage esmalt heakskiidetud VPN, kinnitage valmidussignaal, mis tõesti tõestab, et tunnel kannab liiklust, seejärel avage inkognito-seanss toetatud brauseri juhtelementide kaudu ja lõpetage, kui valmiduskontroll ebaõnnestub. See kaitseb seanssi, mida te alles alustate, ilma et teeskleksite juba töötava seansi kaitsmist.

Kolmas kontroll: auditeerige õigust, mida kavatsete anda

Teavitustele juurdepääs on tundlik õigus, mis lubab teenusel lugeda teavitusi igast rakendusest, mitte ainult brauserist. Selle andmine tundmatule automatiseerimisvahendile ühe brauseri oleku jälgimiseks on halb vahetus ja juurdepääs püsib ka pärast katse lõppemist. Juurdepääsetavusel põhinevad puudutused on veelgi hullemad: need on kasutajaliidese kohal olev skriptikiht, mitte toetatud VPN-i juhtimisliides, ja need lähevad katki iga paigutuse muudatuse korral.

Enne millegi andmist küsige, kas sama tulemus on saavutatav toetatud mehhanismiga. Kui vastus on poliitikanõue, siis tavaliselt on: platvorm saab jõustada tunnelit rakenduse või profiili jaoks ilma ühegi kuulava teenuseta.

Neljas kontroll: kasutage alati seesolevat ja blokeerimist, kui nõue on jõustamine

Kui brauser ei tohi kunagi väljaspool tunnelit suhelda, kuulub jõustamine platvormi seadetesse, mitte makrosse. Android toetab alati seesolevat VPN-i blokeerimisrežiimiga, mis takistab liiklust, kui tunnel ei ole loodud, ja hallatavatele seadmetele saab selle poliitikaga rakendada. Kinnitage, mis seadmel praegu on, mitte ärge eeldage:

adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdown

Nullist erinev rakenduse väärtus tähendab, et pakett on seadistatud alati seesolevaks, ja blokeerimise väärtus 1 tähendab, et ühendused väljaspool tunnelit on blokeeritud. Just see paar muudab parima pingutuse harjumuse garantiiks ja kõrvaldab ka võidusõidu täielikult, sest tunnel luuakse enne, kui rakenduse liiklus on lubatud.

Kaks piiri tasub siinkohal ära märkida. Tööprofiilidel on oma VPN-i seadistus, seega isiklikus profiilis kontrollitud reegel ei ütle tööprofiili kohta midagi. Ja eraldi paigaldatud brauser, teise rakenduse avatud kohandatud vahekaart või rakendusesisene veebivaade on erinev pakett või kontekst, millel on oma marsruutimine, seega kontrollige tegelikku paketti, mitte ei eelda, et teistsuguse stiiliga aken on eraldi domeen.

Viies kontroll: kirjutage töövoog üles ja testige ebaõnnestumise teed

Ükskõik, mida valite, dokumenteerige järjekord ja katkestamistingimus. Mugavustöövoo puhul tähendab see: tunnel üles, valmidus tõestatud, inkognito avatud ja kõva peatus, kui valmidus ebaõnnestub. Jõustamise tee puhul tähendab see: alati seesolev rakendus seadistatud, blokeerimine lubatud ja oodatud käitumine, kui tunnel ei saa üldse üles tulla, mis on liikluse puudumine, mitte kaitsmata liiklus.

Testige siis ebaõnnestumist, mitte ainult õnnestumist. Katkestage tunnel seansi ajal ja vaadake, mida brauser teeb; blokeerige VPN-rakenduse protsess ja kinnitage, et midagi ei leki. Lõpuks hoidke kahte privaatsusmudelit kasutajadokumentatsioonis eraldi: inkognito juhib ajutist brauseri olekut ega peida liiklust võrgu eest, samas kui VPN kannab liiklust, kuid ei kustuta sisselogimisi ega midagi privaatses seansis esitatut.