Android-app wegeret oer VPN te wurkjen: hokker laach beslút

Wannear’t in Android-app ophâldt te wurkjen op it stuit dat de tunnel omheech komt, kinne trije ferskillende dingen ferantwurdlik wêze, en se leverje likense mislearrings. De app kin de eigen netwurksteat fan ’e telefoan lêze en lokaal wegerje. De server kin it adres dêr’t jo wei komme klassifisearje en dat wegerje. Of de wegering kin hielendal neat mei de VPN te meitsjen ha. De folchoarder hjirûnder sammelet bewiis foardat er eat feroaret, want de útgong feroarje is de djoerste stap en dejinge dy’t it minst wierskynlik helpt as de kontrôle lokaal is.

Stap 1: útfine wannear’t de app wegeret

De timing is de earste ûnderskieder. Meitsje de logbuffer leech, reprodusearje de mislearring en sjoch wat de app die foardat er klage:

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

As de app wegeret foardat der ea in útgeande oanfraach besocht is, sjogge jo in lokale besluting. As er ferbynt, eat stjoert en dan in flater toant, kaam de wegering fan ’e oare kant. As de app itselde mislearret mei de tunnel út, wie de VPN nea de fariabele.

Behannelje dy timing as bewiis en net as befêstiging. In app kin in cache-antwurd op ’e nij ôfspylje, en eftergrûnoanfragen kinne slagge of mislearre wêze foardat jo seagen. Skriuw de tiidstimpels fan ’e lêste slagge oanfraach en fan ’e flater op, net allinnich it stuit dat it berjocht ferskynde.

Stap 2: lês de eigen blik fan ’e telefoan op it netwurk

Android lit de VPN-steat sjen as in netwurkfeardigens, dus in app hat gjin list fan kommersjele leveransiers nedich om te merken dat in tunnel aktyf is. Hy freget de ferbiningstsjinst hokker netwurk it op it stuit is, en it antwurd befettet in VPN-ferfiersbit:

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

Dy kontrôle is lokaal en goedkeap, en hy ferklearret in hiele klasse fan rapporten fan it type “dizze app wurket net oer VPN” sûnder ienige klassifikaasje fan fierrens. Wat de app sjen kin, hinget noch altyd fan syn eigen netwurk-kontekst ôf, dus nim net oan dat elke app elk profyl op it apparaat ûndersiket.

Fan in wurkstasjon kinne jo deselde steat op in testapparaat sjen mei adb shell dumpsys connectivity en troch te sykjen nei de VPN-netwurkyngong. Ferlykje in run mei de tunnel omheech mei in run mei de tunnel omleech, en bewarje beide útfier.

Stap 3: lês wat de server eins sjocht

De oare waarnimmer is de tsjinst. Hy sjocht it boarne-adres dat oankomt, en hy kin hannelje op it adres, it hostingnetwurk dêrefter, de regio, de operator of sinjalen dy’t oan it akkount en it apparaat bûn binne. Net ien fan dy is in unike identiteit, en dield adressearjen makket kollaterale blokkades normaal: ien beheind adres kin net-relatearre brûkers efter deselde oersetting útskeakelje.

Krij it adres fia deselde wei dy’t de app brûkt, net út in browser op in laptop. Op ’e telefoan lit in gewoane oanfraach nei in adres-echotsjinst sjen wat de fiere kant ûntfangt, en troch dat te ferlykjen mei in oanfraach oer mobyl data witte jo oft it adres oait feroare is.

As de app oer mobyl data wurket en oer de tunnel mislearret mei itselde akkount, sit de wegering oan ’e fiere kant of yn it eigen belied fan ’e app. As er yn beide gefallen mislearret, is de VPN net de ûnderskieder en moatte jo ophâlde mei einpunten te testen.

Stap 4: ferbyn it bewiis oan ien fan trije fûnissen

Trije kombinaasjes dekke hast elk rapport. In wegering sûnder ienige útgeande poging wylst in tunnel aktyf is, wiist op in lokale ferfierskontrôle. In oanfraach dy’t fuortgiet en weromkomt mei in flater, in tiidferrin op in bepaald host of in regioberjocht wiist op ’e fiere kant. In mislearring dy’t him oer mobyl data sûnder tunnel werhellet, wiist op it akkount, de app-ferzje of it eigen belied fan ’e tsjinst, en gjin VPN-feroaring sil dat ferpleatse.

Skriuw it fûnis op tegearre mei it bewiis dat it makke hat. De wearde fan dizze stap is dat er de lus stopet wêryn’t immen fjouwer kear útgongsknooppunten feroaret om in kontrôle te reparearjen dy’t op ’e tillefoan sels rint.

Hy hâldt ek de bewearings earlik. Sels hoste feroaret it einpunt en syn internetútgong; it makket net dat Android ferjit dat in VPN-netwurk aktyf is, en it garandearret gjin akseptaasje troch in tsjinst dy’t adressen klassifisearret. In lokaal filter kin op jo eigen VPN-netwurk like maklik ôfgean as op in kommersjeel ien.

Stap 5: nim de stipe wei en ferifiearje dy

Begjin mei it dokumintearre belied fan it produkt en syn stipe-eigner. Stjoer de kliïntferzje, it krekte berjocht en in smel flaterfinster; stjoer net folsleine ferkearsopnamen of oanmeldgegevens allinnich om te bewizen dat der in flater is.

As de tsjinst direkte tagong tastiet en it apparaatbelied dat tastiet, dan is útsluting per app it stipe meganisme, en it hellet dy app bewust út ’e tunnel yn stee fan de tunnel te ferbergjen. It ferkear fan ’e app giet dan syn eigen wei, wat in beliedsbeslissing is dy’t immen hawwe moat. Yn in konfiguraasje dy’t sûnder VPN blokkearret, kin in útsletten app gewoan ferbining ferlieze, dus test dy kombinaasje foardat jo belove dat er wurket.

Werhelje nei elke feroaring de timingstest fan stap ien, befêstigje dat de app wurket en befêstigje dat elke oare app noch altyd de tunnel brûkt. Set dan de foarige konfiguraasje werom en kontrolearje oft de mislearring weromkomt, want in repaaraasje dy’t jo net reprodusearje kinne, is in tafal dy’t jo wer tsjinkomme.