VPN por aplikaĵo en Android: ekskludi aplikaĵon ne blokas ĝin

Du homoj faras la saman demandon kaj ricevas malkongruajn respondojn, ĉar ili staras en malsamaj lokoj. Unu havas malfermita la sistemajn VPN-agordojn kaj redaktas liston de aplikaĵoj. La alia skribas VpnService.Builder.addDisallowedApplication() en redaktilo. Ambaŭ nomas ĝin VPN-filtro por aplikaĵo. Nur unu el ili posedas la regilon, kiun ili priskribas, kaj neniu el ili blokas ion ajn.

Komencu ĉe la ekrano, kiun la uzanto vidas

Malfermu Agordojn, trovu la VPN-eron kaj rigardu la konekton, kiu efektive estas aktiva. Se la kliento proponas liston por aplikaĵo, tiu listo apartenas al la propra tunelo de la kliento. La platformo ne publikigas ĝeneralan API, per kiu fremda aplikaĵo povus legi aŭ ŝanĝi la aplikaĵan elekton de alia VPN, do dua aplikaĵo ne povas ripari tiun liston por la uzanto.

Ĉi tio estas la unua disforkiĝo de la trairo. Se la instalita VPN ne havas tian agordon, nenio ekzistas, pri kio oni kodumu: la trajto mankas en la produkto, kiu posedas la tunelon. Se ĝi havas unu, la ĝusta riparo estas en tiu ekrano, farita de la persono, kiu povas malfermi ĝin.

Sekvu la paketon en tunelon

Kiam via propra aplikaĵo konstruas tunelon, ĝi kreas TUN-interfacon kaj deklaras, kies aplikaĵa trafiko eniras ĝin. La membrigaj vokoj okazas antaŭ ol la interfaco estas starigita, kaj poste la reguloaro estas fiksita por tiu seanco:

val builder = VpnService.Builder()
builder.addAddress("10.8.0.2", 32)
builder.addRoute("0.0.0.0", 0)
builder.addDisallowedApplication("com.example.bypass")
val tun = builder.establish()   // membership decided here

Tiuj vokoj validas por la tunelo, kiun via aplikaĵo ĵus kreis, kaj por nenio alia. Ili ne estas politiko por la tuta aparato, ili ne daŭras por aliaj klientoj, kaj ili ne povas atingi en la VPN de iu alia. Kiam voko de la konstruilo ĵetas escepton ĉar la pako ne estas solvebla, la interfaco neniam stariĝas, kio estas pura malsukceso anstataŭ silenta.

Kial la ekskludo aspektis kiel blokado

Ekskludita aplikaĵo estas direktita ĉirkaŭ via tunelo al la suba reto. Tio estas la malo de blokado: la trafiko ankoraŭ lasas la aparaton, nur ekster la interfaco, kiun vi regas. Aplikaĵo de fajroŝirma stilo faras la malon. Ĝi enlasas la trafikon de la aplikaĵo en sian tunelon kaj poste forĵetas la paketojn aŭ rifuzas plusendi ilin, do la interfaco estas la sama kaj la direkto de la politiko estas inversigita.

La laboro malantaŭ tiu inversigo ne estas agorda ŝaltilo. Vi legas IP-paketojn el la tunela priskribilo, decidas laŭ fluo, kaj aŭ plusendas ilin tra protektita ingo aŭ forĵetas ilin. Ĉio, kion vi ne traktas, simple haltas, kaj tial duone finita tunelo aspektas kiel rompita reto anstataŭ kiel funkcianta filtro. Se via celo estas blokado, buĝetu paketan traktadon, antaŭplenan servon kaj skriban politikon por trafiko, kiun vi ne povas klasifiki.

Kio rompiĝas, kiam vi konstruas ĝin mem

Android ĝenerale permesas unu aktivan VPN samtempe, do via filtra tunelo kaj privateca tunelo konkuras pri la sama loko, krom se la produktoj subtenas ĉenadon. Ĉiam-aktiva VPN kun konekta blokado ŝanĝas la manieron de malsukceso tiel, kiel gravas ĉi tie: trafiko, kiu ne povas eniri la tunelon, estas forĵetita anstataŭ sendita rekte, kion volas dizajno kontraŭ likoj kaj kion sencimiga seanco malofte atendas.

Paketa videbleco estas la dua kaptilo. Solvi la pakan nomon de aplikaĵo povas malsukcesi per NameNotFoundException, kaj sur pli novaj Android-versioj la aro de pakoj, kiujn vi povas vidi, dependas de la demandoj, kiujn vi deklaris. Traktu la escepton anstataŭ supozi, ke ĉiu nomo solviĝas, kaj relegu la liston, kiam aplikaĵoj estas instalitaj aŭ forigitaj, anstataŭ kaŝmemorigi ĝin por ĉiam.

Administrataj aparatoj aldonas trian posedanton. Politiko de entreprena movebleco povas agordi VPN por aplikaĵo aŭ ĉiam-aktivan profilon, kaj ordinara aplikaĵo ne povas ĝin superregi. Kontrolu, ĉu la aparato estas administrata, antaŭ ol sencimigi vian propran kodon, ĉar tiuokaze la listo, kiun vi provas ŝanĝi, eble ne estas redaktebla de iu ajn, kiu tenas la telefonon.

Testu ĝin per aplikaĵo, kiun vi regas

Ne testu per la aplikaĵo, kiun vi provas filtri. Uzu duan aplikaĵon, kies retan konduton vi povas observi, kaj kontrolu, ĉu ĝia trafiko eliras tra via tunelo, dum tiu de la celo ne faras tion. Se ambaŭ restas interne, la politiko funkcias kaj la celo estas ekskludita; se neniu eliras, la tunelo mem estas malĝusta kaj la aplikaĵa listo ne estas la problemo.

Poste decidu, kiun el tri aferoj vi efektive konstruas. Tunelo por aplikaĵo estas la konstruila API, kun la listo kiel parto de via profilo. Aparata fajroŝirmilo estas paketa traktado plus vivociklo, kiun vi povas defendi. Ŝanĝi la VPN de iu alia tute ne estas subtenata vojo, kaj la honesta respondo tie estas, ke la agordo apartenas al tiu produkto.