Aplikacija Android noče delovati prek VPN: katera plast odloča

Ko aplikacija Android preneha delovati v trenutku, ko se tunel dvigne, so lahko odgovorne tri različne stvari, njihove napake pa so si videti podobne. Aplikacija lahko prebere stanje omrežja samega telefona in zavrne lokalno. Strežnik lahko razvrsti naslov, s katerega prihajate, in ga zavrne. Ali pa zavrnitev nima nobene zveze z VPN. Spodnji vrstni red najprej zbere dokaze in šele nato kaj spremeni, ker je menjava izhoda najdražji korak in najmanj verjetno pomaga, če je preverjanje lokalno.

Korak 1: ugotovite, kdaj aplikacija zavrne

Čas je prvi razlikovalec. Počistite medpomnilnik dnevnika, ponovite napako in poglejte, kaj je aplikacija storila, preden se je pritožila:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

Če aplikacija zavrne, preden je poskusila katero koli odhodno zahtevo, imate opravka z lokalno odločitvijo. Če se poveže, nekaj pošlje in šele nato pokaže napako, je zavrnitev prišla z druge strani. Če aplikacija odpove enako tudi z izklopljenim tunelom, VPN nikoli ni bil spremenljivka.

Ta čas obravnavajte kot dokaz, ne kot razsodbo. Aplikacija lahko predvaja odgovor iz predpomnilnika, zahteve v ozadju pa so morda uspele ali spodletele, preden ste pogledali. Zapišite časovne žige zadnje uspešne zahteve in napake, ne le trenutka, ko se je sporočilo pojavilo.

Korak 2: preberite, kako omrežje vidi sam telefon

Android izpostavi stanje VPN kot zmožnost omrežja, zato aplikacija ne potrebuje seznama komercialnih ponudnikov, da bi opazila aktiven tunel. Vpraša storitev povezljivosti, katero omrežje je trenutno, in odgovor vsebuje bit prenosa VPN:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

To preverjanje je lokalno in poceni ter pojasni cel razred poročil "ta aplikacija ne deluje prek VPN" brez kakršne koli oddaljene razvrstitve. Kaj lahko aplikacija vidi, je še vedno odvisno od njenega lastnega omrežnega konteksta, zato ne predpostavljajte, da vsaka aplikacija pregleda vsak profil v napravi.

Z delovne postaje vidite isto stanje na testni napravi z adb shell dumpsys connectivity in iskanjem vnosa omrežja VPN. Primerjajte izvajanje z dvignjenim tunelom in izvajanje s spuščenim ter oba izhoda shranite.

Korak 3: preberite, kaj strežnik res vidi

Drugi opazovalec je storitev. Vidi izvorni naslov, ki prihaja, in lahko ukrepa glede na naslov, gostiteljsko omrežje za njim, regijo, operaterja ali signale, vezane na račun in napravo. Nobeno od tega ni edinstvena identiteta, skupno naslavljanje pa naredi stranske blokade običajne: en omejen naslov lahko izloči nepovezane uporabnike za isto pretvorbo.

Naslov pridobite po isti poti, kot jo uporablja aplikacija, ne iz brskalnika na prenosniku. Na telefonu preprosta zahteva na storitev odmeva naslova pokaže, kaj prejme oddaljena stran, primerjava z zahtevo prek mobilnega omrežja pa pove, ali se je naslov sploh spremenil.

Če aplikacija deluje prek mobilnega omrežja in odpove prek tunela z istim računom, je zavrnitev na oddaljeni strani ali v politiki same aplikacije. Če odpove v obeh primerih, VPN ni razlika in prenehajte preizkušati končne točke.

Korak 4: uskladite dokaze z eno od treh razsodb

Tri kombinacije pokrijejo skoraj vsako poročilo. Zavrnitev brez odhodnega poskusa, medtem ko je tunel aktiven, kaže na lokalno preverjanje prenosa. Zahteva, ki odide in se vrne z napako, potek časa na določenem gostitelju ali sporočilo o regiji kažejo na oddaljeno stran. Napaka, ki se ponovi v mobilnem omrežju brez tunela, kaže na račun, različico aplikacije ali politiko same storitve in nobena sprememba VPN je ne bo premaknila.

Razsodbo zapišite skupaj z dokazi, ki so jo dali. Vrednost tega koraka je, da ustavi zanko, v kateri nekdo štirikrat zamenja izhodna vozlišča, da bi popravil preverjanje, ki teče na samem telefonu.

Prav tako ohranja trditve poštene. Lastno gostovanje spremeni končno točko in njen internetni izhod; ne naredi, da bi Android pozabil, da je omrežje VPN aktivno, in ne zagotavlja sprejema pri storitvi, ki razvršča naslove. Lokalni filter se lahko sproži na omrežju VPN, ki ga imate v lasti, prav tako zlahka kot na komercialnem.

Korak 5: izberite podprto pot in jo preverite

Začnite z dokumentirano politiko izdelka in njegovim lastnikom podpore. Pošljite različico odjemalca, natančno sporočilo in ozko okno napake; ne pošiljajte popolnih zajemov prometa ali poverilnic samo zato, da bi dokazali, da napaka obstaja.

Če storitev dovoljuje neposreden dostop in politika naprave to dopušča, izključitev posamezne aplikacije je podprt mehanizem, ki namenoma odstrani to aplikacijo iz tunela, namesto da bi tunel skrila. Promet aplikacije nato odide po lastni poti, kar je politična odločitev, ki jo mora nekdo prevzeti. V konfiguraciji blokiranja brez VPN lahko izključena aplikacija preprosto izgubi povezljivost, zato to kombinacijo preizkusite, preden obljubite, da deluje.

Po vsaki spremembi ponovite časovni preizkus iz prvega koraka, potrdite, da aplikacija deluje, in da vse druge aplikacije še vedno uporabljajo tunel. Nato obnovite prejšnjo konfiguracijo in preverite, ali se napaka vrne, ker je popravek, ki ga ne morete ponoviti, naključje, s katerim se boste še srečali.