Android-a aplikaĵo rifuzas funkcii tra VPN: kiu tavolo decidas

Kiam Android-a aplikaĵo ĉesas funkcii en la momento, kiam la tunelo leviĝas, tri malsamaj aferoj povas esti respondecaj, kaj ili produktas similspecajn fiaskojn. La aplikaĵo povas legi la propran retan staton de la telefono kaj rifuzi loke. La servilo povas klasifiki la adreson, de kiu vi venas, kaj malakcepti ĝin. Aŭ la rifuzo povas havi nenian rilaton al la VPN. La ordo sube kolektas pruvojn antaŭ ol ŝanĝi ion ajn, ĉar ŝanĝi la eliron estas la plej multekosta paŝo kaj la malplej verŝajne helpa, se la kontrolo estas loka.

Paŝo 1: ekscii, kiam la aplikaĵo rifuzas

Tempo estas la unua distingilo. Malplenigu la protokolan bufron, reproduktu la fiaskon kaj rigardu, kion la aplikaĵo faris antaŭ ol plendi:

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

Se la aplikaĵo rifuzas antaŭ ol iu ajn elira peto estas provita, vi rigardas lokan decidon. Se ĝi konektiĝas, sendas ion kaj poste montras eraron, la malakcepto venis de la alia flanko. Se la aplikaĵo same fiaskas kun la tunelo malŝaltita, la VPN neniam estis la variablo.

Traktu tiun tempon kiel pruvon, ne kiel konfirmon. Aplikaĵo povas reludi kaŝmemoran respondon, kaj fonaj petoj eble sukcesis aŭ fiaskis antaŭ ol vi rigardis. Notu la tempomarkojn de la lasta sukcesa peto kaj de la eraro, ne nur la momenton, kiam la mesaĝo aperis.

Paŝo 2: legi la propran vidon de la telefono pri la reto

Android malkaŝas la VPN-staton kiel retan kapablon, do aplikaĵo ne bezonas liston de komercaj provizantoj por rimarki, ke tunelo estas aktiva. Ĝi demandas la konektecan servon, kiu estas la nuna reto, kaj la respondo enhavas VPN-transportan biton:

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

Tiu kontrolo estas loka kaj malmultekosta, kaj ĝi klarigas tutan klason de raportoj «ĉi tiu aplikaĵo ne funkcias tra VPN» sen ia fora klasifiko. Kion la aplikaĵo povas vidi, ankoraŭ dependas de ĝia propra reta kunteksto, do ne supozu, ke ĉiu aplikaĵo inspektas ĉiun profilon en la aparato.

De laborejo vi povas vidi la saman staton sur testa aparato per adb shell dumpsys connectivity kaj serĉante la VPN-retan enskribon. Komparu kuradon kun la tunelo levita al kurado kun ĝi mallevita, kaj konservu ambaŭ eligojn.

Paŝo 3: legi, kion la servilo fakte vidas

La alia observanto estas la servo. Ĝi vidas la fontan adreson, kiu alvenas, kaj ĝi povas agi laŭ la adreso, la gastiga reto malantaŭ ĝi, la regiono, la funkciigisto aŭ signaloj ligitaj al la konto kaj aparato. Neniu el tiuj estas unika identeco, kaj dividita adresado igas flankajn blokadojn normalaj: unu limigita adreso povas forpreni nerilatajn uzantojn malantaŭ la sama traduko.

Prenu la adreson per la sama vojo, kiun uzas la aplikaĵo, ne per retumilo sur tekkomputilo. Sur la telefono, simpla peto al adresa eĥa servo montras, kion ricevas la fora flanko, kaj komparo kun peto tra poŝtelefona reto diras al vi, ĉu la adreso entute ŝanĝiĝis.

Se la aplikaĵo funkcias tra poŝtelefona reto kaj fiaskas tra la tunelo kun identa konto, la malakcepto estas ĉe la fora fino aŭ en la propra politiko de la aplikaĵo. Se ĝi fiaskas en ambaŭ, la VPN ne estas la distingilo kaj vi devus ĉesi testi finpunktojn.

Paŝo 4: kongruigi la pruvojn kun unu el tri verdiktoj

Tri kombinaĵoj kovras preskaŭ ĉiun raporton. Rifuzo sen ia elira provo dum tunelo estas aktiva montras lokan transportan kontrolon. Peto, kiu eliras kaj revenas kun eraro, tempolimo ĉe specifa gastiganto aŭ regiona mesaĝo montras la foran flankon. Fiasko, kiu ripetiĝas tra poŝtelefona reto sen tunelo, montras la konton, la aplikaĵversion aŭ la propran politikon de la servo, kaj neniu VPN-ŝanĝo movos ĝin.

Skribu la verdikton kune kun la pruvo, kiu ĝin produktis. La valoro de ĉi tiu paŝo estas, ke ĝi haltigas la buklon, en kiu iu ŝanĝas elirajn nodojn kvar fojojn por ripari kontrolon, kiu ruliĝas sur la telefono mem.

Ĝi ankaŭ tenas la asertojn honestaj. Memgastigado ŝanĝas la finpunkton kaj ĝian interretan eliron; ĝi ne igas Android forgesi, ke VPN-reto estas aktiva, kaj ĝi ne garantias akcepton fare de servo, kiu klasifikas adresojn. Loka filtrilo povas ekagi sur via propra VPN-reto same facile kiel sur komerca.

Paŝo 5: sekvi la subtenatan vojon kaj kontroli ĝin

Komencu per la dokumentita politiko de la produkto kaj ĝia subtenposedanto. Sendu la klientversion, la precizan mesaĝon kaj mallarĝan fiaskan fenestron; ne sendu plenajn trafikajn kaptaĵojn aŭ akreditaĵojn nur por pruvi, ke eraro ekzistas.

Se la servo permesas rektan aliron kaj la aparata politiko permesas ĝin, tiam elsluso po aplikaĵo estas la subtenata mekanismo, kaj ĝi intence forigas tiun aplikaĵon el la tunelo anstataŭ kaŝi la tunelon. La trafiko de la aplikaĵo tiam eliras per sia propra vojo, kio estas politika decido, kiun iu devas posedi. En agordo, kiu blokas sen VPN, elslusita aplikaĵo povas simple perdi konektecon, do testu tiun kombinaĵon antaŭ ol promesi, ke ĝi funkcias.

Post ĉiu ŝanĝo, ripetu la tempan teston de la unua paŝo, konfirmu, ke la aplikaĵo funkcias, kaj konfirmu, ke ĉiu alia aplikaĵo ankoraŭ uzas la tunelon. Poste restarigu la antaŭan agordon kaj kontrolu, ĉu la fiasko revenas, ĉar riparo, kiun vi ne povas reprodukti, estas koincido, kiun vi renkontos denove.