Aplikacioni Android refuzon të funksionojë përmes VPN: cila shtresë vendos

Kur një aplikacion Android ndalon së punuari pikërisht në momentin që tuneli ngrihet, mund të jenë përgjegjëse tri gjëra të ndryshme, dhe ato prodhojnë dështime që duken njësoj. Aplikacioni mund të lexojë gjendjen e rrjetit të vetë telefonit dhe të refuzojë lokalisht. Serveri mund të klasifikojë adresën nga e cila vini dhe ta refuzojë atë. Ose refuzimi mund të mos ketë asnjë lidhje me VPN-në. Rendi më poshtë mbledh provat përpara se të ndryshojë diçka, sepse ndryshimi i daljes është hapi më i kushtueshëm dhe më pak i mundshëm për të ndihmuar nëse kontrolli është lokal.

Hapi 1: zbuloni kur aplikacioni refuzon

Koha është dalluesi i parë. Pastroni buferin e regjistrit, riprodhoni dështimin dhe shikoni çfarë bëri aplikacioni para se të ankohej:

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

Nëse aplikacioni refuzon para çdo përpjekjeje për kërkesë dalëse, keni të bëni me një vendim lokal. Nëse lidhet, dërgon diçka dhe vetëm atëherë shfaq një gabim, refuzimi erdhi nga ana tjetër. Nëse aplikacioni dështon njësoj edhe me tunelin e fikur, VPN-ja nuk ishte kurrë variabla.

Trajtojeni atë kohë si provë, jo si vendim. Një aplikacion mund të riprodhojë një përgjigje të ruajtur në cache, dhe kërkesat në sfond mund të kenë pasur sukses ose të kenë dështuar para se të shikonit. Shënoni vulat kohore të kërkesës së fundit të suksesshme dhe të gabimit, jo vetëm momentin kur u shfaq mesazhi.

Hapi 2: lexoni si e shikon vetë telefoni rrjetin

Android e ekspozon gjendjen e VPN-së si një aftësi rrjeti, kështu që një aplikacion nuk ka nevojë për një listë ofruesish komercialë për të vënë re një tunel aktiv. I kërkon shërbimit të lidhjes cili është rrjeti aktual, dhe përgjigja përmban një bit transporti VPN:

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

Ky kontroll është lokal dhe i lirë, dhe shpjegon një klasë të tërë raportesh të tipit "ky aplikacion nuk punon përmes VPN" pa asnjë klasifikim në distancë. Ajo që aplikacioni mund të shohë varet ende nga konteksti i vetë rrjetit të tij, prandaj mos supozoni se çdo aplikacion inspekton çdo profil në pajisje.

Nga një stacion pune shihni të njëjtën gjendje në një pajisje testuese me adb shell dumpsys connectivity dhe duke kërkuar zërin e rrjetit VPN. Krahasoni një ekzekutim me tunelin lart me një ekzekutim me atë poshtë dhe ruani të dyja daljet.

Hapi 3: lexoni çfarë sheh në të vërtetë serveri

Vëzhguesi tjetër është shërbimi. Ai sheh adresën burimore që mbërrin dhe mund të veprojë mbi adresën, rrjetin e strehimit pas saj, rajonin, operatorin ose sinjalet e lidhura me llogarinë dhe pajisjen. Asnjë prej tyre nuk është identitet unik, dhe adresimi i përbashkët i bën bllokimet anësore normale: një adresë e kufizuar mund të nxjerrë nga loja përdorues të palidhur pas të njëjtit përkthim.

Merrni adresën nëpër të njëjtën rrugë që përdor aplikacioni, jo nga një shfletues në laptop. Në telefon, një kërkesë e thjeshtë drejt një shërbimi jehone adrese tregon çfarë pranon ana e largët, dhe krahasimi me një kërkesë përmes rrjetit celular ju tregon nëse adresa ndryshoi fare.

Nëse aplikacioni punon përmes rrjetit celular dhe dështon përmes tunelit me të njëjtën llogari, refuzimi është në anën e largët ose në politikën e vetë aplikacionit. Nëse dështon në të dyja, VPN-ja nuk është diferencuesi dhe duhet të ndaloni testimin e pikave fundore.

Hapi 4: përputhni provat me një nga tri verdiktet

Tri kombinime mbulojnë pothuajse çdo raport. Një refuzim pa asnjë përpjekje dalëse ndërsa një tunel është aktiv tregon një kontroll lokal transporti. Një kërkesë që del dhe kthehet me gabim, një skadim kohe në një host të caktuar ose një mesazh rajoni tregojnë anën e largët. Një dështim që përsëritet në rrjetin celular pa tunel tregon llogarinë, versionin e aplikacionit ose politikën e vetë shërbimit, dhe asnjë ndryshim VPN nuk do ta lëvizë.

Shkruani verdiktin bashkë me provat që e prodhuan. Vlera e këtij hapi është se ndalon ciklin ku dikush ndryshon nyjet e daljes katër herë për të rregulluar një kontroll që punon në vetë telefonin.

Ai gjithashtu i mban pretendimet të sinqerta. Strehimi i serverit tuaj ndryshon pikën fundore dhe daljen e saj në internet; nuk e bën Androidin të harrojë se një rrjet VPN është aktiv dhe nuk garanton pranim nga një shërbim që klasifikon adresat. Një filtër lokal mund të aktivizohet në një rrjet VPN që e zotëroni ju po aq lehtë sa në një komercial.

Hapi 5: ndiqni rrugën e mbështetur dhe verifikojeni

Filloni me politikën e dokumentuar të produktit dhe pronarin e mbështetjes së tij. Dërgoni versionin e klientit, mesazhin e saktë dhe një dritare të ngushtë dështimi; mos dërgoni kapje të plota trafiku ose kredenciale vetëm për të provuar se një gabim ekziston.

Nëse shërbimi lejon akses të drejtpërdrejtë dhe politika e pajisjes e lejon, përjashtimi për një aplikacion të vetëm është mekanizmi i mbështetur, dhe ai qëllimisht e heq atë aplikacion nga tuneli në vend që të fshehë tunelin. Trafiku i aplikacionit atëherë del në rrugën e vet, që është një vendim politike që dikush duhet ta marrë përsipër. Në një konfigurim bllokimi pa VPN, një aplikacion i përjashtuar thjesht mund të humbasë lidhjen, prandaj testojeni atë kombinim përpara se të premtoni se punon.

Pas çdo ndryshimi, përsëritni testin e kohës të hapit të parë, konfirmoni se aplikacioni punon dhe konfirmoni se çdo aplikacion tjetër vazhdon të përdorë tunelin. Pastaj rikthejeni konfigurimin e mëparshëm dhe kontrolloni nëse dështimi kthehet, sepse një rregullim që nuk mund ta riprodhoni është një rastësi me të cilën do të takoheni përsëri.