Android-app nægter at køre over VPN: hvilket lag afgør det

Når en Android-app holder op med at virke i det øjeblik, tunnelen kommer op, kan tre forskellige ting være ansvarlige, og de giver lignende fejl. Appen kan læse telefonens egen netværkstilstand og afvise lokalt. Serveren kan klassificere den adresse, du kommer fra, og afvise den. Eller afvisningen kan slet ikke have noget med VPN at gøre. Rækkefølgen nedenfor samler beviser, før den ændrer noget, fordi det er det dyreste skridt at skifte udgang, og det mindst sandsynlige at hjælpe, hvis tjekket er lokalt.

Trin 1: find ud af, hvornår appen afviser

Tidspunktet er den første skelnen. Ryd logbufferen, genskab fejlen, og se på, hvad appen gjorde, før den klagede:

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

Hvis appen afviser, før der overhovedet er forsøgt en udgående anmodning, ser du en lokal beslutning. Hvis den forbinder, sender noget og derefter viser en fejl, kom afvisningen fra den anden side. Hvis appen fejler ens med tunnelen nede, var VPN aldrig variablen.

Behandl det tidspunkt som bevis, ikke som bekræftelse. En app kan afspille et cachelagret svar, og baggrundsanmodninger kan være lykkedes eller fejlet, før du kiggede. Noter tidsstemplerne for den sidste vellykkede anmodning og for fejlen, ikke bare det øjeblik, meddelelsen dukkede op.

Trin 2: læs telefonens eget syn på netværket

Android eksponerer VPN-tilstanden som en netværksevne, så en app behøver ikke en liste over kommercielle udbydere for at bemærke, at en tunnel er aktiv. Den spørger forbindelsestjenesten, hvad det aktuelle netværk er, og svaret indeholder en VPN-transportbit:

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

Det tjek er lokalt og billigt, og det forklarer en hel klasse af rapporter om, at »denne app virker ikke over VPN«, uden nogen fjernklassificering. Hvad appen kan se, afhænger stadig af dens egen netværkskontekst, så antag ikke, at enhver app undersøger enhver profil på enheden.

Fra en arbejdsstation kan du se samme tilstand på en testenhed med adb shell dumpsys connectivity og ved at lede efter VPN-netværksposten. Sammenlign en kørsel med tunnelen oppe med en kørsel med den nede, og gem begge uddata.

Trin 3: læs, hvad serveren faktisk ser

Den anden observatør er tjenesten. Den ser kildeadressen, der ankommer, og den kan handle på adressen, hostingnetværket bag den, regionen, operatøren eller signaler knyttet til kontoen og enheden. Intet af dette er en unik identitet, og delt adressering gør sideblokeringer normale: én begrænset adresse kan tage uskyldige brugere bag den samme oversættelse med ned.

Hent adressen ad samme vej, som appen bruger, ikke fra en browser på en laptop. På telefonen viser en almindelig anmodning til en adresse-ekko-tjeneste, hvad den fjerne side modtager, og ved at sammenligne det med en anmodning over mobildata får du at vide, om adressen overhovedet ændrede sig.

Hvis appen virker over mobildata og fejler over tunnelen med samme konto, ligger afvisningen i den fjerne ende eller i appens egen politik. Hvis den fejler begge steder, er VPN ikke det afgørende, og du bør stoppe med at teste endepunkter.

Trin 4: knyt beviserne til en af tre domme

Tre kombinationer dækker næsten enhver rapport. En afvisning uden forsøg på udgående trafik, mens en tunnel er aktiv, peger på et lokalt transporttjek. En anmodning, der går ud og kommer tilbage med en fejl, en timeout på en bestemt vært eller en regionsmeddelelse, peger på den fjerne side. En fejl, der gentages over mobildata uden tunnel, peger på kontoen, appversionen eller tjenestens egen politik, og ingen VPN-ændring flytter den.

Skriv dommen ned sammen med det bevis, der frembragte den. Værdien af dette trin er, at det stopper den løkke, hvor nogen skifter udgangsnoder fire gange for at rette et tjek, der kører på selve telefonen.

Det holder også påstandene ærlige. Selvhosting ændrer endepunktet og dets internetudgang; det får ikke Android til at glemme, at et VPN-netværk er aktivt, og det garanterer ikke accept hos en tjeneste, der klassificerer adresser. Et lokalt filter kan udløses på dit eget VPN-netværk lige så let som på et kommercielt.

Trin 5: tag den understøttede vej og verificer den

Start med produktets dokumenterede politik og dets supportejer. Send klientversionen, den præcise meddelelse og et snævert fejlvindue; send ikke fulde trafikoptagelser eller legitimationsoplysninger blot for at bevise, at en fejl findes.

Hvis tjenesten tillader direkte adgang, og enhedspolitikken tillader det, er undtagelse pr. app den understøttede mekanisme, og den fjerner bevidst den app fra tunnelen i stedet for at skjule tunnelen. Appens trafik forlader derefter sin egen vej, hvilket er en politisk beslutning, som nogen skal eje. I en konfiguration, der blokerer uden VPN, kan en undtaget app simpelthen miste forbindelsen, så test den kombination, før du lover, at den virker.

Efter enhver ændring gentages trin et-tidstesten, bekræft at appen virker, og bekræft at alle andre apps stadig bruger tunnelen. Gendan derefter den tidligere konfiguration, og kontroller, om fejlen vender tilbage, fordi en rettelse, du ikke kan genskabe, er et tilfælde, du møder igen.