Android se VPN per toepassing en Chrome-incognito: wat die reël werklik dek

Iemand het 'n outomatisasie gebou wat die VPN aanskakel sodra 'n incognito-oortjie verskyn, en dit werk nie betroubaar nie. Die rede is struktureel en die moeite werd om te verstaan voordat jy aan die outomatisasie stel: Android se reëls per toepassing kies pakkette, terwyl incognito 'n toestand binne een pakket is. Die reël kan die twee nie onderskei nie. 'n Kennisgewing verskyn ook eers nadat die blaaier begin werk het, so selfs 'n korrekte sneller kom te laat. Werk die vyf kontroles in volgorde deur; 'n fout by kontrole vier beteken die benadering, nie die instellings nie, moet verander.

Kontrole een: wat die reël per toepassing kan kies

Die VPN-program bou sy tonnel uit lyste van toegelate of verbode toepassings, en daardie lyste neem pakketname. Chrome in normale modus en Chrome in incognito is dieselfde pakket, met dieselfde gebruiker-id en dieselfde netwerktoestemming, so 'n reël wat Chrome insluit of uitsluit, geld vir albei identies. Die platform het geen oortjie-identiteit waarmee dit kan pas nie.

Dit is nie 'n fout om te omseil nie; dit is die korreltheid wat die API bied. Wil jy Chrome-verkeer in die tonnel en alles anders buite, dan druk 'n reël per toepassing dit presies uit. Wil jy net private oortjies in die tonnel hê terwyl gewone oortjies regstreeks gaan, dan kan geen reël per toepassing dit uitdruk nie, en geen kennisgewinglogika voeg 'n keurder by wat die platform nie het nie.

Let op die lokval van pakketidentiteit: 'n beta- of verskafferbou is 'n ander pakket as die stabiele blaaier, so 'n reël wat een dek, mis die ander stilweg:

adb shell pm list packages | grep -i chrome

Kontrole twee: kan die sneller ooit vroeg genoeg wees

'n Kennisgewingleser sien net kennisgewings wat hy mag sien. Om te sien is nie om te onderskep nie: teen die tyd dat die kennisgewing bestaan, het die blaaier die naam al opgelos en die verbinding oopgemaak, en niks op daardie pad wag vir jou outomatisasie nie. 'n Taak wat dan die VPN-kliënt begin, moet wag vir die kliënt se koppelvlak, enige toestemmingsvraag en die tonnel-handdruk, wat in sekondes gemeet word terwyl die eerste versoek in millisekondes gemeet word.

Die opsporing is om 'n tweede rede bros. Kennisgewingteks verander tussen weergawes en lokaliserings, so 'n patroon wat op een uitgawe pas, pas ná 'n opdatering nie meer nie, en die fout is stil. 'n Kennisgewing wat ontbreek, bewys nie dat private blaai afwesig is nie; dit kan net beteken die string het verander of die kanaal is gedemp.

Daar is 'n wettige vorm van hierdie werkvloei, en dit is georden eerder as reaktief: koppel eers die goedgekeurde VPN, bevestig 'n gereedheidsein wat werklik bewys die tonnel dra verkeer, maak dan die incognito-sessie oop deur die blaaier se ondersteunde kontroles, en stop as die gereedheidstoets misluk. Dit beskerm die sessie wat jy op die punt is om te begin, sonder om voor te gee dat jy een beskerm wat al loop.

Kontrole drie: keur die toestemming na wat jy gaan gee

Toegang tot kennisgewings is 'n sensitiewe toekenning wat 'n diens toelaat om kennisgewings van elke toepassing te lees, nie net die blaaier nie. Om dit aan 'n onbekende outomatiseringsinstrument te gee om een blaaierstoestand te dophou, is 'n swak ruil, en die toegang bly ná die eksperiment. Toeganklikheidgedrewe tikke is erger: dit is 'n skriplaag oor die koppelvlak, nie 'n ondersteunde VPN-beheer nie, en enige uitlegverandering breek dit.

Vra voordat jy iets gee of dieselfde uitkoms met 'n ondersteunde meganisme bereik kan word. As die antwoord 'n beleidsvereiste is, is dit gewoonlik so: die platform kan 'n tonnel vir 'n toepassing of 'n profiel afdwing sonder enige luisterdiens.

Kontrole vier: altyd-aan en blokkering wanneer jy afdwinging nodig het

As die blaaier nooit buite die tonnel mag kommunikeer nie, hoort afdwinging in die platform se instellings, nie in 'n makro nie. Android ondersteun 'n altyd-aan-VPN met 'n blokkeermodus wat verkeer verhoed wanneer die tonnel nie bestaan nie, en bestuurde toestelle kan dit per beleid kry. Bevestig wat die toestel tans het eerder as om te aanvaar:

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

'n Nie-nul toepassingwaarde beteken 'n pakket is as altyd-aan ingestel, en 'n lockdown-waarde van 1 beteken verbindings buite die tonnel word geblokkeer. Die paar maak 'n gewoonte van beste poging 'n waarborg en verwyder die wedloop heeltemal, want die tonnel bestaan voordat toepassingsverkeer toegelaat word.

Twee grense is hier belangrik. Werkprofiele hou hul eie VPN-opstelling, so 'n reël wat in die persoonlike profiel bevestig is, sê niks oor die werkprofiel nie. En 'n apart geïnstalleerde blaaier, 'n pasgemaakte oortjie wat 'n ander toepassing oopmaak, of 'n webview binne 'n toepassing is 'n ander pakket of konteks met sy eie roetering, so bevestig die werklike pakket eerder as om te aanvaar dat 'n anders gestileerde venster 'n aparte domein is.

Kontrole vyf: skryf die werkvloei neer en toets die foutpad

Wat jy ook kies, dokumenteer die volgorde en die stopvoorwaarde. Vir die geriefswerkvloei beteken dit: tonnel op, gereedheid bewys, incognito oop, en 'n harde stop as gereedheid misluk. Vir die afdwingpad beteken dit: altyd-aan-toepassing ingestel, lockdown aan, en die verwagte gedrag wanneer die tonnel glad nie kan opkom nie, naamlik geen verkeer eerder as onbeskermde verkeer.

Toets dan die fout, nie net die sukses nie. Verbreek die tonnel tydens 'n sessie en kyk wat die blaaier doen; blokkeer die VPN-program se proses en bevestig dat niks lek nie. Laastens, hou die twee privaatheidsmodelle apart in die dokumentasie: incognito beheer tydelike blaaierstoestand en verberg nie verkeer vir die netwerk nie, terwyl 'n VPN verkeer dra maar nie aanmeldings of enigiets wat in die private sessie ingedien is, uitwis nie.