VPN laŭ aplikaĵo en Android kaj kaŝa reĝimo de Chrome: kion la regulo kovras

Iu konstruis aŭtomatigon, kiu ŝaltas la VPN kiam aperas kaŝa langeto, kaj ĝi ne funkcias fidinde. La kaŭzo estas struktura kaj indas kompreni ĝin antaŭ ol agordi la aŭtomatigon: la reguloj de Android laŭ aplikaĵo elektas pakaĵojn de aplikaĵoj, dum kaŝa reĝimo estas stato ene de unu pakaĵo. La regulo ne povas distingi la du. La sciigo ankaŭ alvenas nur post kiam la retumilo komencis labori, do eĉ ĝusta ekigilo alvenas malfrue. Trapasu la kvin kontrolojn laŭvice; malsukceso ĉe la kvara kontrolo signifas, ke la aliro, ne la agordoj, devas ŝanĝiĝi.

Kontrolo unu: kion la regulo povas elekti

Aplikaĵo VPN konstruas sian tunelon el listoj de permesitaj aŭ malpermesitaj aplikaĵoj, kaj tiuj listoj prenas pakaĵajn nomojn. Chrome en normala reĝimo kaj Chrome en kaŝa reĝimo estas la sama pakaĵo, kun la sama uzantidentigilo kaj la sama retpermeso, do regulo, kiu inkluzivas aŭ ekskluzivas Chrome, validas egale por ambaŭ. La platformo ne havas langet-nivelan identecon por kunordigi.

Tio ne estas difekto por ĉirkaŭiri; tio estas la detaleco, kiun la API ofertas. Se vi bezonas la trafikon de Chrome ene de la tunelo kaj ĉion alian ekstere, regulo laŭ aplikaĵo esprimas ĝuste tion. Se vi bezonas nur privatajn langetojn ene de la tunelo dum ordinaraj iras rekte, neniu regulo laŭ aplikaĵo povas esprimi tion, kaj neniu sciiga logiko aldonas selektilon, kiun la platformo ne havas.

Atentu la kaptilon de pakaĵa identeco: beta aŭ fabrikanta versio estas alia pakaĵo ol la stabila retumilo, do regulo, kiu kovras unu, silente maltrafas la alian:

adb shell pm list packages | grep -i chrome

Kontrolo du: ĉu la ekigilo povas iam esti sufiĉe frua

Sciiga aŭskultanto observas sciigojn, kiujn ĝi rajtas vidi. Observi ne estas interkapti: kiam la sciigo ekzistas, la retumilo jam solvis la nomon kaj malfermis la konekton, kaj nenio sur tiu vojo atendas vian aŭtomatigon. Tasko, kiu poste lanĉas la VPN-klienton, devas atendi la klientan interfacon, eblan konsentan demandon kaj la manpremon de la tunelo, kio mezuriĝas en sekundoj, dum la unua peto mezuriĝas en milisekundoj.

La detekto estas rompiĝema ankaŭ pro dua kialo. La teksto de sciigoj ŝanĝiĝas inter versioj kaj lingvoj, do ŝablono, kiu kongruis kun unu eldono, ĉesas kongrui post ĝisdatigo, kaj la malsukceso estas silenta. Mankanta sciigo ne pruvas la foreston de privata retumado; ĝi povas nur signifi, ke la ĉeno ŝanĝiĝis aŭ ke la kanalo estis silentigita.

Ekzistas laŭleĝa formo de tiu laborfluo, kaj ĝi estas ordigita anstataŭ reagema: unue konektu la aprobitan VPN, konfirmu pretecan signalon, kiu vere pruvas, ke la tunelo portas trafikon, poste malfermu la kaŝan seancon per la subtenataj regiloj de la retumilo, kaj haltu se la preteca kontrolo malsukcesas. Tio protektas la seancon, kiun vi baldaŭ komencos, sen ŝajnigi protekti tian, kiu jam funkcias.

Kontrolo tri: reviziu la permeson, kiun vi donos

Aliro al sciigoj estas delikata permeso, kiu lasas servon legi sciigojn de ĉiu aplikaĵo, ne nur de la retumilo. Doni ĝin al nekonata aŭtomatiga ilo por observi unu retumilan staton estas malbona interŝanĝo, kaj la aliro restas post la eksperimento. Tuŝoj gvidataj de alirebleco estas pli malbonaj: ili estas skripta tavolo super la interfaco, ne subtenata VPN-regilo, kaj ajna aranĝa ŝanĝo rompas ilin.

Antaŭ ol doni ion, demandu, ĉu la sama rezulto atingeblas per subtenata mekanismo. Se la respondo estas politika postulo, ĝi kutime ja atingeblas: la platformo povas devigi tunelon por aplikaĵo aŭ profilo tute sen aŭskulta servo.

Kontrolo kvar: uzu ĉiam-aktivan kaj blokadon, kiam vi bezonas devigon

Se la retumilo neniam rajtas komuniki ekster la tunelo, la devigo apartenas al la platformaj agordoj, ne al makroo. Android subtenas ĉiam-aktivan VPN kun blokada reĝimo, kiu malhelpas trafikon kiam la tunelo ne staras, kaj administrataj aparatoj povas ricevi ĝin per politiko. Konfirmu, kion la aparato nun havas, anstataŭ supozi:

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

Ne-malplena aplikaĵa valoro signifas, ke pakaĵo estas agordita kiel ĉiam-aktiva, kaj blokada valoro 1 signifas, ke konektoj ekster la tunelo estas blokitaj. La paro transformas kutimon de plej bona klopodo en garantion kaj forigas la konkuron tute, ĉar la tunelo stariĝas antaŭ ol aplikaĵa trafiko estas permesata.

Du limoj gravas ĉi tie. Laboprofiloj havas sian propran VPN-agordon, do regulo kontrolita en la persona profilo diras nenion pri la labora. Kaj aparte instalita retumilo, propra langeto malfermita de alia aplikaĵo, aŭ ena retvido estas alia pakaĵo aŭ kunteksto kun propra enkursigado, do kontrolu la realan pakaĵon anstataŭ supozi, ke alistila fenestro estas aparta domajno.

Kontrolo kvin: skribu la laborfluon kaj testu la malsukcesan vojon

Kion ajn vi elektos, dokumentu la ordon kaj la haltan kondiĉon. Por la komforta laborfluo tio signifas: tunelo supre, preteco pruvita, kaŝa langeto malfermita kaj firma halto se preteco malsukcesas. Por la deviga vojo tio signifas: ĉiam-aktiva aplikaĵo agordita, blokado ŝaltita, kaj la atendata konduto kiam la tunelo tute ne povas stariĝi, nome neniu trafiko anstataŭ neprotektita trafiko.

Poste testu la malsukceson, ne nur la sukceson. Malkonektu la tunelon dum seanco kaj rigardu, kion faras la retumilo; bloku la procezon de la VPN-aplikaĵo kaj konfirmu, ke nenio likas. Fine, tenu la du privatecajn modelojn aparte en la dokumentaro: kaŝa reĝimo regas provizoran retumilan staton kaj ne kaŝas trafikon de la reto, dum VPN portas trafikon sed ne forviŝas ensalutojn nek ion senditan en la privata seanco.