Android aplikacija odbija rad preko VPN-a: koji sloj odlučuje
Aplikacija može odbiti VPN zbog lokalne provjere transporta, pravila adresa na strani servera ili vlastite politike. Razlikujte ta tri slučaja prije nego što mijenjate izlaze.
Kada Android aplikacija prestane raditi u trenutku kad se tunel podigne, mogu biti odgovorne tri različite stvari i one daju slične kvarove. Aplikacija može pročitati vlastito stanje mreže telefona i odbiti lokalno. Server može klasificirati adresu s koje dolazite i odbaciti je. Ili odbijanje može uopće nemati veze s VPN-om. Redoslijed ispod prikuplja dokaze prije nego što bilo što promijeni, jer je promjena izlaza najskuplji korak i onaj koji najmanje vjerojatno pomaže ako je provjera lokalna.
Korak 1: saznajte kada aplikacija odbija
Vrijeme je prvi razlikovni faktor. Očistite međuspremnik dnevnika, reproducirajte kvar i pogledajte što je aplikacija radila prije nego što se požalila:
adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60
Ako aplikacija odbije prije nego što je uopće pokušan odlazni zahtjev, gledate lokalnu odluku. Ako se poveže, nešto pošalje i zatim pokaže grešku, odbijanje je došlo s druge strane. Ako aplikacija jednako zakaže i kad je tunel isključen, VPN nikada nije bio varijabla.
Tretirajte to vrijeme kao dokaz, a ne kao potvrdu. Aplikacija može ponovno odigrati keširani odgovor, a pozadinski zahtjevi su možda uspjeli ili propali prije nego što ste pogledali. Zabilježite vremenske oznake posljednjeg uspješnog zahtjeva i greške, a ne samo trenutak kad se poruka pojavila.
Korak 2: pročitajte kako telefon sam vidi mrežu
Android izlaže VPN stanje kao mrežnu mogućnost, pa aplikaciji nije potreban popis komercijalnih pružatelja da bi primijetila da je tunel aktivan. Pita uslugu povezivosti koja je trenutna mreža, a odgovor uključuje bit VPN transporta:
val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true
Ta provjera je lokalna i jeftina, i objašnjava čitavu klasu izvještaja tipa „ova aplikacija ne radi preko VPN-a“ bez ikakve udaljene klasifikacije. Ono što aplikacija može vidjeti i dalje ovisi o njezinom vlastitom mrežnom kontekstu, pa nemojte pretpostavljati da svaka aplikacija pregleda svaki profil na uređaju.
S radne stanice isti status možete vidjeti na testnom uređaju pomoću adb shell dumpsys connectivity i traženjem unosa VPN mreže. Usporedite pokretanje s podignutim tunelom s pokretanjem s isključenim tunelom i sačuvajte oba izlaza.
Korak 3: pročitajte što poslužitelj doista vidi
Drugi promatrač je usluga. Ona vidi izvornu adresu koja dolazi, a može djelovati na temelju adrese, hosting mreže iza nje, regije, operatera ili signala vezanih uz račun i uređaj. Ništa od toga nije jedinstven identitet, a dijeljeno adresiranje čini popratne blokade uobičajenima: jedna ograničena adresa može izbaciti nepovezane korisnike iza istog prijevoda.
Nabavite adresu istim putem koji koristi aplikacija, a ne iz preglednika na prijenosnom računalu. Na telefonu običan zahtjev usluzi za vraćanje adrese pokazuje što prima daleka strana, a usporedba sa zahtjevom preko mobilne mreže kaže vam je li se adresa uopće promijenila.
Ako aplikacija radi preko mobilne mreže, a zakaže preko tunela s istim računom, odbijanje je na dalekoj strani ili u vlastitoj politici aplikacije. Ako zakaže na oba načina, VPN nije razlikovni faktor i trebali biste prestati testirati krajnje točke.
Korak 4: uskladite dokaze s jednom od tri presude
Tri kombinacije pokrivaju gotovo svaki izvještaj. Odbijanje bez ikakvog odlaznog pokušaja dok je tunel aktivan upućuje na lokalnu provjeru transporta. Zahtjev koji izađe i vrati se s greškom, istekom vremena na određenom hostu ili porukom o regiji upućuje na daleku stranu. Kvar koji se ponavlja preko mobilne mreže bez tunela upućuje na račun, verziju aplikacije ili vlastitu politiku usluge i nikakva promjena VPN-a ga neće pomaknuti.
Zapišite presudu zajedno s dokazom koji ju je proizveo. Vrijednost ovog koraka je u tome što zaustavlja petlju u kojoj netko četiri puta mijenja izlazne čvorove da bi popravio provjeru koja se izvodi na samom telefonu.
To također održava tvrdnje iskrenima. Vlastito hostanje mijenja krajnju točku i njezin internetski izlaz; ne čini da Android zaboravi da je VPN mreža aktivna i ne jamči prihvaćanje kod usluge koja klasificira adrese. Lokalni filtar može se aktivirati na vašoj vlastitoj VPN mreži jednako lako kao i na komercijalnoj.
Korak 5: idite podržanim putem i provjerite ga
Počnite s dokumentiranom politikom proizvoda i njegovim vlasnikom podrške. Pošaljite verziju klijenta, točnu poruku i uski vremenski okvir kvara; ne šaljite potpune snimke prometa ni vjerodajnice samo da biste dokazali da greška postoji.
Ako usluga dopušta izravan pristup i politika uređaja to dopušta, onda je izuzimanje po aplikaciji podržani mehanizam i ono namjerno uklanja tu aplikaciju iz tunela umjesto da skriva tunel. Promet aplikacije tada izlazi vlastitim putem, što je politička odluka koju netko mora preuzeti. U konfiguraciji koja blokira bez VPN-a izuzeta aplikacija može jednostavno izgubiti povezivost, pa testirajte tu kombinaciju prije nego što obećate da radi.
Nakon svake promjene ponovite vremenski test prvog koraka, potvrdite da aplikacija radi i potvrdite da sve ostale aplikacije i dalje koriste tunel. Zatim vratite prethodnu konfiguraciju i provjerite vraća li se kvar, jer je popravak koji ne možete reproducirati slučajnost koju ćete ponovno sresti.