Android lietotne atsakās strādāt VPN: kura slānis izlemj

Kad Android lietotne pārstāj darboties tajā brīdī, kad paceļas tunelis, vainojamas var būt trīs dažādas lietas, un tās rada līdzīgi izskatāmus bojājumus. Lietotne var nolasīt paša tālruņa tīkla stāvokli un atteikt lokāli. Serveris var klasificēt adresi, no kuras jūs nākat, un to noraidīt. Vai arī atteikumam var nebūt nekāda sakara ar VPN. Zemāk esošā secība vāc pierādījumus pirms kaut kā maiņas, jo izejas maiņa ir dārgākais solis un tas, kas vismazāk ticami palīdzēs, ja pārbaude ir lokāla.

1. solis: noskaidrojiet, kad lietotne atsaka

Laiks ir pirmais atšķirējs. Notīriet žurnāla buferi, atkārtojiet bojājumu un apskatiet, ko lietotne darīja pirms sūdzēšanās:

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

Ja lietotne atsaka pirms jebkura izejoša pieprasījuma mēģinājuma, jūs redzat lokālu lēmumu. Ja tā pievienojas, kaut ko nosūta un pēc tam rāda kļūdu, atteikums nāca no otras puses. Ja lietotne neizdodas tāpat ar izslēgtu tuneli, VPN nekad nav bijis mainīgais.

Uztveriet šo laiku kā pierādījumu, nevis apstiprinājumu. Lietotne var atkārtot kešatmiņā saglabātu atbildi, un fona pieprasījumi var būt veiksmīgi vai neveiksmīgi pirms jūs apskatījāties. Pierakstiet pēdējā veiksmīgā pieprasījuma un kļūdas laika zīmogus, nevis tikai brīdi, kad parādījās ziņojums.

2. solis: nolasiet tālruņa paša skatījumu uz tīklu

Android atklāj VPN stāvokli kā tīkla iespēju, tāpēc lietotnei nav vajadzīgs komerciālo pakalpojumu sniedzēju saraksts, lai pamanītu aktīvu tuneli. Tā jautā savienojamības servisam, kāds ir pašreizējais tīkls, un atbildē ir VPN transporta bits:

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

Šī pārbaude ir lokāla un lēta, un tā izskaidro veselu ziņojumu klasi „šī lietotne nestrādā VPN” bez jebkādas attālinātas klasifikācijas. Tas, ko lietotne var redzēt, joprojām ir atkarīgs no tās pašas tīkla konteksta, tāpēc nepieņemiet, ka katra lietotne pārbauda katru ierīces profilu.

No darbstacijas jūs varat redzēt to pašu stāvokli testa ierīcē, izmantojot adb shell dumpsys connectivity un meklējot VPN tīkla ierakstu. Salīdziniet palaišanu ar paceltu tuneli ar palaišanu ar nolaistu, un saglabājiet abus izvades datus.

3. solis: nolasiet, ko serveris patiešām redz

Otrs novērotājs ir pakalpojums. Tas redz ienākošo avota adresi, un tas var rīkoties pēc adreses, aiz tās esošā mitināšanas tīkla, reģiona, operatora vai signāliem, kas saistīti ar kontu un ierīci. Neviens no tiem nav unikāla identitāte, un koplietotā adresācija padara blakusblokus normālus: viena ierobežota adrese var izsist nesaistītus lietotājus aiz tā paša tulkojuma.

Iegūstiet adresi pa to pašu ceļu, ko izmanto lietotne, nevis no pārlūka portatīvajā datorā. Tālrunī vienkāršs pieprasījums adrešu atbalss servisam parāda, ko saņem tālā puse, un salīdzinājums ar pieprasījumu mobilajā tīklā pasaka, vai adrese vispār mainījās.

Ja lietotne darbojas mobilajā tīklā un neizdodas tunelī ar to pašu kontu, atteikums ir tālajā galā vai pašas lietotnes politikā. Ja tā neizdodas abos, VPN nav atšķirējfaktors, un jums jāpārtrauc galapunktu testēšana.

4. solis: saskaņojiet pierādījumus ar vienu no trim spriedumiem

Trīs kombinācijas aptver gandrīz katru ziņojumu. Atteikums bez jebkāda izejoša mēģinājuma, kamēr tunelis ir aktīvs, norāda uz lokālu transporta pārbaudi. Pieprasījums, kas iziet un atgriežas ar kļūdu, konkrēta resursdatora taimautu vai reģiona ziņojumu, norāda uz tālo pusi. Bojājums, kas atkārtojas mobilajā tīklā bez tuneļa, norāda uz kontu, lietotnes versiju vai paša pakalpojuma politiku, un nekāda VPN maiņa to neizkustinās.

Pierakstiet spriedumu kopā ar pierādījumu, kas to radīja. Šī soļa vērtība ir tā, ka tas aptur cilpu, kurā kāds četras reizes maina izejas mezglus, lai salabotu pārbaudi, kas darbojas pašā tālrunī.

Tas arī uztur apgalvojumus godīgus. Pašu mitināšana maina galapunktu un tā interneta izeju; tas neļauj Android aizmirst, ka VPN tīkls ir aktīvs, un negarantē, ka to pieņems pakalpojums, kas klasificē adreses. Lokāls filtrs var iedarbozties jūsu paša VPN tīklā tikpat viegli kā komerciālā.

5. solis: izvēlieties atbalstīto ceļu un pārbaudiet to

Sāciet ar produkta dokumentēto politiku un tā atbalsta īpašnieku. Nosūtiet klienta versiju, precīzu ziņojumu un šauru bojājuma laika logu; nesūtiet pilnus trafika ierakstus vai akreditācijas datus tikai tāpēc, lai pierādītu, ka kļūda pastāv.

Ja pakalpojums pieļauj tiešu piekļuvi un ierīces politika to atļauj, tad izslēgšana katrai lietotnei ir atbalstītais mehānisms, un tas apzināti izņem šo lietotni no tuneļa, nevis slēpj tuneli. Tad lietotnes trafiks iziet savu ceļu, kas ir politikas lēmums, kas kādam jāuzņemas. Konfigurācijā, kas bloķē bez VPN, izslēgta lietotne var vienkārši zaudēt savienojumu, tāpēc pārbaudiet šo kombināciju pirms solīšanas, ka tā strādā.

Pēc jebkuras izmaiņas atkārtojiet pirmā soļa laika testu, apstipriniet, ka lietotne darbojas, un apstipriniet, ka visas pārējās lietotnes joprojām izmanto tuneli. Pēc tam atjaunojiet iepriekšējo konfigurāciju un pārbaudiet, vai bojājums atgriežas, jo labojums, ko nevarat atkārtot, ir nejaušība, ar ko satiksiteies vēlreiz.