Android lietotņu līmeņa VPN un Chrome inkognito: ko aptver noteikums
Lietotņu līmeņa noteikumi izvēlas pakotnes, nevis pārlūka cilnes, un paziņojums nāk pēc pirmā pieprasījuma. Pārbaudiet tvērumu, laiku un nepieciešamo izpildi.
Kāds ir izveidojis automatizāciju, kas ieslēdz VPN, kad parādās inkognito cilne, un tā nedarbojas uzticami. Tam ir strukturāls iemesls, un ir vērts to saprast pirms automatizācijas pielāgošanas. Android lietotņu līmeņa VPN noteikumi izvēlas lietotņu pakotnes, un inkognito ir stāvoklis vienas pakotnes ietvaros, tāpēc noteikums nevar atšķirt abus. Paziņojums parādās pēc tam, kad pārlūks jau ir sācis strādāt, tāpēc pat pareizs trigeris nāk par vēlu. Veiciet tālāk minētās pārbaudes secīgi; neveiksme ceturtajā pārbaudē nozīmē, ka jāmaina ir pieeja, nevis konfigurācija.
Pirmā pārbaude: apstipriniet, ko lietotņu līmeņa noteikums var izvēlēties
Android VPN lietotne veido savu tuneli ar atļauto vai aizliegto lietotņu sarakstiem, un šie saraksti ņem pakotņu nosaukumus. Chrome parastajā režīmā un Chrome inkognito režīmā ir viena un tā pati pakotne ar vienu un to pašu lietotāja ID un vienām un tām pašām tīkla atļaujām, tāpēc noteikums, kas iekļauj vai izslēdz Chrome, abiem attiecas vienādi. Platformai nav ar cilni saistītas identitātes, ar ko salīdzināt.
Tas nav defekts, no kā izvairīties; tas ir detalizācijas līmenis, ko piedāvā API. Ja jūsu prasība ir Chrome trafiks caur tuneli un viss pārējais ārpusē, lietotņu līmeņa noteikums to izsaka precīzi. Ja jūsu prasība ir tikai privātās cilnes caur tuneli, bet parastās cilnes iet tieši, tad neviens lietotņu līmeņa noteikums to nevar izteikt, un nekāds paziņojumu loģikas apjoms nepievienos selektoru, kura platformai nav.
Pārbaudot pievērsiet uzmanību pakotnes identitātes slazdam. Beta vai ražotāja būvējums ir cita pakotne nekā stabilais pārlūks, tāpēc noteikums, kas aptver vienu, klusi palaiž garām otru:
adb shell pm list packages | grep -i chrome
Otrā pārbaude: pārbaudiet, vai trigeris kādreiz var būt pietiekami agrs
Paziņojumu klausītājs novēro paziņojumus, kurus tam ir atļauts redzēt. Novērošana nav pārtveršana: pārlūks jau ir atrisinājis nosaukumu un atvēris savienojumu, kad paziņojums pastāv, un nekas šajā ceļā negaida jūsu automatizācijas pabeigšanu. Uzdevums, kas pēc tam palaiž VPN klientu, ir jāgaida klienta saskarne, jebkurš piekrišanas pieprasījums un tuneļa rokasspiediens, kas tiek mērīti sekundēs, kamēr pirmais pieprasījums tiek mērīts milisekundēs.
Pati noteikšana ir trausla arī otrā iemesla dēļ. Paziņojuma teksts mainās starp versijām un lokalizācijām, tāpēc modelis, kas saskaņots ar vienu laidienu, pēc atjauninājuma vairs nesakrīt, un neveiksme ir klusa. Trūkstošs paziņojums nav pierādījums, ka nav privātas pārlūkošanas; tas var nozīmēt tikai to, ka virkne mainījās vai kanāls tika izslēgts.
Šai darbplūsmai ir likumīga versija, un tā ir sakārtota, nevis reaģējoša: vispirms pievienojiet apstiprināto VPN, apstipriniet gatavības signālu, kas patiešām pierāda, ka tunelis pārvadā trafiku, pēc tam atveriet inkognito sesiju ar atbalstītajām pārlūka vadīklām un apstājieties, ja gatavības pārbaude neizdodas. Tas aizsargā sesiju, kuru tikko sākat, neizliekoties, ka aizsargājat jau esošu.
Trešā pārbaude: auditējiet atļauju, kuru gatavojaties piešķirt
Piekļuve paziņojumiem ir jutīga atļauja, kas ļauj pakalpojumam lasīt paziņojumus no katras lietotnes, ne tikai pārlūka. Piešķirt to nepazīstamam automatizācijas rīkam viena pārlūka stāvokļa uzraudzībai ir slikts darījums, un piekļuve saglabājas pēc eksperimenta beigām. Pieejamības vadīti pieskārieni ir sliktāki: tie ir skriptu slānis virs saskarnes, nevis atbalstīta VPN vadības saskarne, un tie salūzt pie katras izkārtojuma izmaiņas.
Pirms kaut ko piešķirat, pajautājiet, vai to pašu rezultātu var sasniegt ar atbalstītu mehānismu. Ja atbilde ir politikas prasība, parasti var: platforma var piespiest tuneli lietotnei vai profilam bez jebkāda klausīšanās pakalpojuma.
Ceturtā pārbaude: kad prasība ir izpilde, izmantojiet vienmēr ieslēgtu un bloķēšanu
Ja pārlūkam nekad nav jāsazinās ārpus tuneļa, izpilde pieder platformas iestatījumiem, nevis makro. Android atbalsta vienmēr ieslēgtu VPN ar bloķēšanas režīmu, kas novērš trafiku, kad tunelis nav izveidots, un pārvaldītās ierīces to var saņemt ar politiku. Apstipriniet, kas ierīcei tagad ir, tā vietā lai pieņemtu:
adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdown
Lietotnes vērtība, kas nav nulle, nozīmē, ka pakotne ir konfigurēta kā vienmēr ieslēgta, un bloķēšanas vērtība 1 nozīmē, ka savienojumi ārpus tuneļa ir bloķēti. Tieši šis pāris pārvērš labāko pūļu ieradumu garantijā un arī pilnībā novērš sacensību, jo tunelis tiek izveidots pirms lietotnes trafika atļaušanas.
Šeit ir vērts minēt divas robežas. Darba profiliem ir sava VPN konfigurācija, tāpēc personīgajā profilā pārbaudīts noteikums neko nepasaka par darba profilu. Un atsevišķi instalēts pārlūks, citas lietotnes atvērta pielāgota cilne vai lietotnes iekšējais webview ir cita pakotne vai konteksts ar savu maršrutēšanu, tāpēc pārbaudiet faktisko pakotni, nevis pieņemiet, ka citāda stila logs ir atsevišķs domēns.
Piektā pārbaude: pierakstiet darbplūsmu un pārbaudiet neveiksmes ceļu
Lai ko jūs izvēlētos, dokumentējiet secību un pārtraukšanas nosacījumu. Ērtības darbplūsmai tas nozīmē: tunelis augšā, gatavība pierādīta, inkognito atvērts un ciets apstājums, ja gatavība neizdodas. Izpildes ceļam tas nozīmē: vienmēr ieslēgta lietotne konfigurēta, bloķēšana iespējota un sagaidāmā uzvedība, kad tunelis vispār nevar pacelties, tas ir, nekāda trafika nevis neaizsargāta trafika.
Pēc tam pārbaudiet neveiksmi, ne tikai panākumus. Sesijas laikā atvienojiet tuneli un vērojiet, ko dara pārlūks; bloķējiet VPN lietotnes procesu un apstipriniet, ka nekas nenoplūst. Visbeidzot, lietotāja dokumentācijā turiet divus privātuma modeļus atsevišķi: inkognito kontrolē pagaidu pārlūka stāvokli un neslēpj trafiku no tīkla, bet VPN pārvadā trafiku, taču neizdzēš pieteikumus vai neko privātajā sesijā nosūtīto.