Android-app nektar å køyre over VPN: kva lag som avgjer

Når ein Android-app sluttar å verke i det augeblikket tunnelen kjem opp, kan tre ulike ting vere ansvarlege, og dei gjev liknande feil. Appen kan lese den eigne nettverkstilstanden til telefonen og avvise lokalt. Tenaren kan klassifisere adressa du kjem frå og avvise henne. Eller avvisinga kan ikkje ha noko med VPN å gjere i det heile. Rekkjefølgja nedanfor samlar prov før ho endrar noko, fordi det å byte utgang er det dyraste steget og det som minst sannsynleg hjelper om kontrollen er lokal.

Steg 1: finne ut når appen avviser

Tidspunktet er den første skilnaden. Tøm loggbufferen, reproduser feilen og sjå kva appen gjorde før han klaga:

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

Om appen avviser før noka utgåande førespurnad er prøvd, ser du ei lokal avgjerd. Om han koplar til, sender noko og så viser ein feil, kom avvisinga frå den andre sida. Om appen feilar likt med tunnelen nede, var VPN aldri variabelen.

Behandle det tidspunktet som prov og ikkje som stadfesting. Ein app kan spele av eit bufra svar på nytt, og bakgrunnsførespurnader kan ha lukkast eller feila før du såg etter. Noter tidsstempla for den siste vellukka førespurnaden og for feilen, ikkje berre augeblikket då meldinga dukka opp.

Steg 2: les telefonen sitt eige syn på nettverket

Android legg VPN-tilstanden fram som ei nettverksevne, så ein app treng ikkje ei liste over kommersielle leverandørar for å merke at ein tunnel er aktiv. Han spør tilkoplingstenesta kva nettverket er no, og svaret inneheld ein VPN-transportbit:

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

Den kontrollen er lokal og billeg, og han forklarar ein heil klasse rapportar om at «denne appen verkar ikkje over VPN» utan noka fjernklassifisering. Det appen kan sjå, heng framleis saman med den eigne nettverkskonteksten hans, så ikkje gå ut frå at kvar app granskar kvar profil på eininga.

Frå ein arbeidsstasjon kan du sjå same tilstanden på ei prøveeing med adb shell dumpsys connectivity og ved å leite etter VPN-nettverksoppføringa. Samanlikn ein køyring med tunnelen oppe med ein køyring med han nede, og ta vare på båe utskriftene.

Steg 3: les kva tenaren faktisk ser

Den andre observatøren er tenesta. Ho ser kjeldeadressa som kjem inn, og ho kan handle på adressa, vertsnettverket bak henne, regionen, operatøren eller signal knytte til kontoen og eininga. Ingen av desse er ein unik identitet, og delt adressering gjer sideblokkar normale: éi avgrensa adresse kan slå ut uvedkomande brukarar bak den same omsetjinga.

Hent adressa gjennom same vegen som appen nyttar, ikkje frå ein nettlesar på ein laptop. På telefonen viser ein enkel førespurnad til ei adresse-ekko-teneste kva den fjerne sida tek imot, og ved å samanlikne det med ein førespurnad over mobilnettet får du vite om adressa endra seg i det heile.

Om appen verkar over mobilnettet og feilar over tunnelen med same konto, ligg avvisinga i den fjerne enden eller i den eigne politikken til appen. Om han feilar på båe, er ikkje VPN skilnaden, og du bør slutte å prøve endepunkt.

Steg 4: knyte prova til ein av tre dommar

Tre kombinasjonar dekkjer nesten kvar rapport. Ei avvising utan noko utgåande forsøk medan ein tunnel er aktiv peikar på ein lokal transportkontroll. Ein førespurnad som går ut og kjem attende med ein feil, tidsavbrot på ein bestemd vert eller ei regionsmelding peikar på den fjerne sida. Ein feil som gentek seg over mobilnettet utan tunnel peikar på kontoen, appversjonen eller den eigen politikken til tenesta, og inga VPN-endring flyttar han.

Skriv ned dommen saman med provet som skapte han. Verdien av dette steget er at det stoppar løkka der nokon byter utgangsknutar fire gonger for å rette ein kontroll som køyrer på sjølve telefonen.

Det held òg påstandane ærlege. Eigen hosting endrar endepunktet og internettutgangen hans; det får ikkje Android til å gløyme at eit VPN-nettverk er aktivt, og det garanterer ikkje at ei teneste som klassifiserer adresser godtek det. Eit lokalt filter kan slå til på ditt eige VPN-nettverk like lett som på eit kommersielt.

Steg 5: gå den støtta vegen og stadfest han

Byrja med den dokumenterte politikken til produktet og støtteeigaren hans. Send klientversjonen, den nøyaktige meldinga og eit trongt feilvindauge; ikkje send fullstendige trafikkfangstar eller innloggingsdetaljar berre for å prove at ein feil finst.

Om tenesta tillèt direkte tilgang og eininga sin politikk tillèt det, er unntak per app den støtta mekanismen, og han tek medvite den appen ut av tunnelen i staden for å skjule tunnelen. Trafikken til appen går då sin eigen veg, noko som er ei politisk avgjerd nokon må eige. I ein konfigurasjon som blokkerer utan VPN, kan ein unnteken app rett og slett miste tilkoplinga, så prøv den kombinasjonen før du lovar at det verkar.

Etter kvar endring, gjer tidstesten frå steg ein om att, stadfest at appen verkar og stadfest at alle andre appane framleis nyttar tunnelen. Set så den førre konfigurasjonen tilbake og sjekk om feilen kjem att, fordi ein retting du ikkje kan reprodusere er eit samantreff du kjem til å møte igjen.