Android-app nekter å kjøre over VPN: hvilket lag avgjør

Når en Android-app slutter å virke i det øyeblikket tunnelen kommer opp, kan tre forskjellige ting være ansvarlige, og de gir liknende feil. Appen kan lese telefonens egen nettverkstilstand og avvise lokalt. Serveren kan klassifisere adressen du kommer fra og avvise den. Eller avvisningen kan ikke ha noe med VPN å gjøre i det hele tatt. Rekkefølgen nedenfor samler bevis før den endrer noe, fordi det å bytte utgang er det dyreste trinnet og det som minst sannsynlig hjelper hvis kontrollen er lokal.

Trinn 1: finn ut når appen avviser

Tidspunktet er den første skilleren. Tøm loggbufferen, reproduser feilen og se på hva appen gjorde før den klaget:

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

Hvis appen avviser før noen utgående forespørsel er forsøkt, ser du en lokal beslutning. Hvis den kobler til, sender noe og deretter viser en feil, kom avvisningen fra den andre siden. Hvis appen feiler likt med tunnelen nede, var VPN aldri variabelen.

Behandle det tidspunktet som bevis og ikke som bekreftelse. En app kan spille av et bufret svar på nytt, og bakgrunnsforespørsler kan ha lyktes eller feilet før du så etter. Noter tidsstemplene for den siste vellykkede forespørselen og for feilen, ikke bare øyeblikket da meldingen dukket opp.

Trinn 2: les telefonens eget syn på nettverket

Android eksponerer VPN-tilstanden som en nettverksevne, så en app trenger ikke en liste over kommersielle leverandører for å merke at en tunnel er aktiv. Den spør tilkoblingstjenesten hva det gjeldende nettverket er, og svaret inneholder en 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 billig, og den forklarer en hel klasse rapporter om at «denne appen virker ikke over VPN» uten noen fjernklassifisering. Det appen kan se, avhenger fortsatt av dens egen nettverkskontekst, så ikke anta at hver app undersøker hver profil på enheten.

Fra en arbeidsstasjon kan du se samme tilstand på en testenhet med adb shell dumpsys connectivity og ved å lete etter VPN-nettverksoppføringen. Sammenlign en kjøring med tunnelen oppe med en kjøring med den nede, og ta vare på begge utdataene.

Trinn 3: les hva serveren faktisk ser

Den andre observatøren er tjenesten. Den ser kildeadressen som ankommer, og den kan handle på adressen, vertsnettverket bak den, regionen, operatøren eller signaler knyttet til kontoen og enheten. Ingen av disse er en unik identitet, og delt adressering gjør sideblokkeringer normale: én begrenset adresse kan slå ut uvedkommende brukere bak den samme oversettelsen.

Hent adressen via samme vei som appen bruker, ikke fra en nettleser på en laptop. På telefonen viser en enkel forespørsel til en adresse-ekko-tjeneste hva den fjerne siden mottar, og ved å sammenligne det med en forespørsel over mobilnettet får du vite om adressen endret seg i det hele tatt.

Hvis appen virker over mobilnettet og feiler over tunnelen med samme konto, ligger avvisningen i den fjerne enden eller i appens egen policy. Hvis den feiler på begge, er VPN ikke skilleren, og du bør slutte å teste endepunkter.

Trinn 4: knytt bevisene til en av tre dommer

Tre kombinasjoner dekker nesten hver rapport. En avvisning uten noe utgående forsøk mens en tunnel er aktiv peker på en lokal transportkontroll. En forespørsel som går ut og kommer tilbake med en feil, en tidsavbrudd på en bestemt vert eller en regionsmelding peker på den fjerne siden. En feil som gjentas over mobilnettet uten tunnel peker på kontoen, appversjonen eller tjenestens egen policy, og ingen VPN-endring flytter den.

Skriv ned dommen sammen med beviset som skapte den. Verdien av dette trinnet er at det stopper løkken der noen bytter utgangsnoder fire ganger for å rette en kontroll som kjører på selve telefonen.

Det holder også påstandene ærlige. Egen hosting endrer endepunktet og dets internettutgang; det får ikke Android til å glemme at et VPN-nettverk er aktivt, og det garanterer ikke aksept hos en tjeneste som klassifiserer adresser. Et lokalt filter kan utløses på ditt eget VPN-nettverk like lett som på et kommersielt.

Trinn 5: gå den støttede veien og verifiser den

Begynn med produktets dokumenterte policy og dets støtteeier. Send klientversjonen, den nøyaktige meldingen og et smalt feilvindu; ikke send fullstendige trafikkfangster eller påloggingsinformasjon bare for å bevise at en feil finnes.

Hvis tjenesten tillater direkte tilgang og enhetspolicyen tillater det, er unntak per app den støttede mekanismen, og den tar bevisst den appen ut av tunnelen i stedet for å skjule tunnelen. Appens trafikk går da sin egen vei, noe som er en policybeslutning noen må eie. I en konfigurasjon som blokkerer uten VPN, kan en unntatt app rett og slett miste tilkoblingen, så test den kombinasjonen før du lover at den virker.

Etter enhver endring, gjenta tidstesten fra trinn en, bekreft at appen virker og bekreft at alle andre apper fortsatt bruker tunnelen. Gjenopprett deretter den forrige konfigurasjonen og sjekk om feilen kommer tilbake, fordi en rettelse du ikke kan reprodusere er et sammentreff du vil møte igjen.