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

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

Trinn 1: finne ut når appen avslår

Tidspunktet er den første skilleren. Tøm loggbufferen, reproduser feilen og se 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 avslår 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 avslaget 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 legger VPN-tilstanden fram 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 nettverket er nå, 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, henger fortsatt sammen med dens egen nettverkskontekst, så ikke anta at hver app gransker 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 utskriftene.

Trinn 3: les hva tjeneren faktisk ser

Den andre observatøren er tjenesten. Den ser kildeadressen som kommer inn, 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 gjennom 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 avslaget i den fjerne enden eller i appens egen policy. Hvis den feiler på begge, er ikke VPN skilleren, og du bør slutte å teste endepunkter.

Trinn 4: knytte bevisene til en av tre dommer

Tre kombinasjoner dekker nesten hver rapport. Et avslag 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, tidsavbrudd på en bestemt vert eller en regionsmelding peker på den fjerne siden. En feil som gjentar seg 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 utgangsknuter fire ganger for å rette en kontroll som kjører på selve telefonen.

Det holder også påstandene ærlige. Egen drifting endrer endepunktet og internettutgangen; det får ikke Android til å glemme at et VPN-nettverk er aktivt, og det garanterer ikke at en tjeneste som klassifiserer adresser godtar det. Et lokalt filter kan slå til på ditt eget VPN-nettverk like lett som på et kommersielt.

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

Begynn med produktets dokumenterte policy og støtteansvarlige. Send klientversjonen, den nøyaktige meldingen og et smalt feilvindu; ikke send fullstendige trafikkfangster eller påloggingsdetaljer 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 med vilje 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 hver endring, gjenta tidstesten fra trinn en, bekreft at appen virker og bekreft at alle andre apper fortsatt bruker tunnelen. Sett deretter den forrige konfigurasjonen tilbake og sjekk om feilen kommer tilbake, fordi en rettelse du ikke kan reprodusere er et sammentreff du vil møte igjen.