Ĉu ekskludita aplikaĵo restas interrete? Reguloj por aplikaĵoj kaj itineroj malsamas

Ekskludi pakaĵon estas instrukcio pri enkursigado, ne blokado, do la paĝoj, kiuj ŝargiĝas post kiam la VPN konektiĝas, estas atenditaj kaj ne pruvo de misfunkcio. La ekskludo forigas la aplikaĵon el la tunelo anstataŭ bloki ĝin, kaj la ordinara reto portas ĝian trafikon. Ĉi tie renkontiĝas du apartaj politikoj: unu elektas procezojn, la alia elektas celojn. Legi ilin en tiu ordo klarigas, kial konektita ikono kaj funkcianta aplikaĵo ne estas kontraŭdiro.

Kial ekskludo lasas la reton malfermita

VpnService.Builder akceptas aŭ permesliston aŭ malpermesliston, neniam ambaŭ. Nur pakaĵoj en permeslisto estas enkursigataj tra la tunelo. Malpermeslisto inversigas tion: ĉiu pakaĵo krom la listigitaj uzas la tunelon, kaj la listigitaj konservas la fizikan vojon. Nelistigita pakaĵo sub permeslisto ankaŭ estas ekster la tunelo, do ekskludo estas la normala stato por la plej multaj aplikaĵoj en tiu reĝimo.

Tio faras lokan malpermesan enskribon decido pri enkursigado, ne regulo de fajroŝirmilo. Se la postulo estas malhelpi aplikaĵon atingi gastiganton, la tunelo devas kovri ĝin kaj la servilo aŭ loka politiko devas rifuzi la trafikon. Forigi aplikaĵon el la tunelo nur ŝanĝas, kiu interfaco portas ĝiajn pakaĵojn.

La kazo Play Store estas la kutima intenca ekzemplo. Ekskludi la pakaĵon de la butiko lasas elŝutojn uzi la suban konekton kiam la VPN-eliro ĝenas transigojn, kaj ĝi montras, ke ekskludo signifas preterpason, ne blokadon.

Unu profilo, unu listo

La konstruanto ĵetas eraron se ambaŭ vokoj estas uzataj, do la profilo antaŭ vi estas aŭ permeslisto aŭ malpermeslisto. Tiu sola fakto difinas kiel legi ĉiun postan observon. Kontrolu la kodon aŭ la administritan agordon antaŭ la enkursiga tabelo, ĉar la listo decidas, kion signifas la resto de la eligo. Hibrida profilo ne estas stato, kiun vi povas rigardi.

La distingo ankaŭ antaŭdiras, kion faros ĵus instalita aplikaĵo. Sub permeslisto ĝi restas ekstere ĝis iu aldonas ĝin, dum sub malpermeslisto ĝi aliĝas al la tunelo defaŭlte.

Administritaj agordoj montras la saman elekton sub malsamaj ŝlosilnomoj, kaj iuj konzoloj priskribas ĝin kiel VPN-reĝimon por unuopa aplikaĵo anstataŭ kiel liston. La konduto tamen reduktiĝas al tiuj du vokoj, do spuru la agordon reen al la pakaĵlisto anstataŭ fidi la etikedon. Se la etikedo kaj la listo malkonsentas, la listo venkas.

Sekvu la UID-regulon al la tunela tabelo

Android donas al ĉiu aplikaĵo sian propran Linux-uzantidentigilon, kaj la VPN-servo instalas politikajn regulojn, kiuj kongruas kun UID-intervaloj. Kongrua trafiko estas sendata al enkursiga tabelo, kies defaŭlta itinero montras al la tun-aparato. La tabelnumero estas atribuata por ĉiu VPN-kazo, do ĝi ŝanĝiĝas post rekonekto aŭ post kreado de dua VPN-profilo.

La eligo de la reguloj estas la mapo. Ĉiu linio nomas serĉtabelon, kaj tiu tabelo tenas la defaŭltan itineron, kiu decidas, ĉu kongruaj pakaĵoj eniras la tunelon.

adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>

Rulu la trian komandon unue por akiri la UID, poste trovu la regulon, kies intervalo enhavas ĝin. Tiu regulo montras al tabelnumero, kaj ip route show table <n> kun tiu numero montras, ĉu ekzistas defaŭlta itinero tra la tun-aparato. Se la tabelo ne havas defaŭlton, la aplikaĵo estas elektita sed havas neniun vojon, kio estas alia misfunkcio.

Ĉi tiuj komandoj bezonas senerarigeblan konstruaĵon aŭ aparaton, kie adb shell povas legi la retan staton. Sur produktada telefono la pakaĵadministrilo ankoraŭ respondas, sed la enkursiga inspektado povas esti rifuzata, do notu tion, kion vi povas, kaj traktu la reston kiel nekonfirmita.

Itinero postulas prefikson, ne aplikaĵon

Builder.addRoute postulas celprefiksojn por la tunelo. Profilo, kiu aldonas nur 10.0.0.0/8 sendas tiun prefikson tra la tunelo kaj lasas ĉiun alian celon sur la fizika vojo. Tio estas ordinara dividita tunelado, kaj ĝi estas sendependa de tio, kiujn aplikaĵojn la reguloj elektis.

Servile puŝita agordo spegulas la saman modelon. Unuopaj itinero-puŝoj aldonas prefiksojn, dum direktivo redirect-gateway anstataŭigas la defaŭltan itineron kaj kaptas ĉion por la aplikaĵoj, kiujn la tunelo kovras. Forigi tiun direktivon povas malgrandigi funkciantan tunelon al unu subreto sen ia ajn ŝanĝo sur la aparato.

Puŝita itinero kun nekutima pordego aŭ metrika kvalifikilo ankaŭ eble ne instaliĝos. Preferu la simplan prefiksformon kaj lasu la servilon trakti plusendadon kaj NAT.

Legu la komunaĵon antaŭ ol ŝanĝi agordon

La tunelo portas la komunaĵon de la kovritaj procezoj kaj la postulataj celoj. Kovrita aplikaĵo, kiu petas adreson ekster la publikigitaj prefiksoj, eliras per la fizika reto. Malpermesita pakaĵo restas ekstere eĉ kiam ĝi petas adreson ene de tiuj prefiksoj. Neniu el la du kazoj estas cimo; ambaŭ estas la du politikoj farantaj sian laboron.

VPN por unuopa aplikaĵo ankaŭ povas lasi asociitan aplikaĵon sen konektebleco. Kiam on-demand estas malŝaltita kaj la tunelo estas malsupren, la aplikaĵo restas ligita al la por-aplikaĵa VPN kaj havas neniun rezervan vojon, kio aspektas kiel rompita aplikaĵo anstataŭ kiel politika stato. Ŝalti on-demand aŭ forigi la asocion per administrado ŝanĝas tion.

Diagnozu unu akson samtempe. Konfirmu permeson aŭ malpermeson unue, legu la instalitajn UID-regulojn kaj tabelojn due, kaj testu duan aplikaĵon kontraŭ la sama celo laste. La dua aplikaĵo apartigas procezo-elekton de cel-elekto en unu peto.

Notu la rezulton kiel aplikaĵo, celo kaj tabelnumero. Ĝuste tiun triopon la sekva ŝanĝo devas konservi.