Android-app weigert te werken via VPN: welke laag beslist

Wanneer een Android-app stopt met werken op het moment dat de tunnel omhoog komt, kunnen drie verschillende dingen verantwoordelijk zijn, en ze veroorzaken vergelijkbare storingen. De app kan de eigen netwerkstatus van de telefoon uitlezen en lokaal weigeren. De server kan het adres waar je vandaan komt classificeren en dat weigeren. Of de weigering kan niets met de VPN te maken hebben. De volgorde hieronder verzamelt bewijs voordat er iets verandert, omdat de uitgang wijzigen de duurste stap is en degene die het minst waarschijnlijk helpt als de controle lokaal is.

Stap 1: uitzoeken wanneer de app weigert

Timing is de eerste onderscheider. Maak de logbuffer leeg, reproduceer de storing en kijk wat de app deed voordat hij klaagde:

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

Als de app weigert voordat er ook maar een uitgaand verzoek is geprobeerd, kijk je naar een lokale beslissing. Als hij verbindt, iets verstuurt en daarna een fout toont, kwam de weigering van de andere kant. Als de app op dezelfde manier faalt met de tunnel uit, was de VPN nooit de variabele.

Behandel dat moment als bewijs en niet als bevestiging. Een app kan een gecacht antwoord opnieuw afspelen, en achtergrondverzoeken kunnen zijn geslaagd of mislukt voordat je keek. Noteer de tijdstempels van het laatste geslaagde verzoek en van de fout, niet alleen het moment waarop het bericht verscheen.

Stap 2: de eigen kijk van de telefoon op het netwerk lezen

Android stelt de VPN-status beschikbaar als netwerkmogelijkheid, dus een app heeft geen lijst met commerciële providers nodig om te merken dat een tunnel actief is. Hij vraagt de connectiviteitsservice wat het huidige netwerk is, en het antwoord bevat een VPN-transportbit:

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

Die controle is lokaal en goedkoop, en verklaart een hele klasse meldingen van het type ‘deze app werkt niet via VPN’ zonder enige classificatie op afstand. Wat de app kan zien hangt nog steeds af van zijn eigen netwerkcontext, dus ga er niet van uit dat elke app elk profiel op het toestel inspecteert.

Vanaf een werkstation zie je dezelfde status op een testtoestel met adb shell dumpsys connectivity en door te zoeken naar de VPN-netwerkvermelding. Vergelijk een run met de tunnel omhoog met een run met de tunnel omlaag, en bewaar beide uitvoer.

Stap 3: lezen wat de server werkelijk ziet

De andere waarnemer is de dienst. Hij ziet het bronadres dat binnenkomt, en kan handelen op het adres, het hostingnetwerk erachter, de regio, de provider of signalen die aan het account en toestel zijn gekoppeld. Niets daarvan is een unieke identiteit, en gedeelde adressering maakt nevenschade normaal: één beperkt adres kan ongerelateerde gebruikers achter dezelfde vertaling uitschakelen.

Haal het adres via dezelfde weg die de app gebruikt, niet uit een browser op een laptop. Op de telefoon laat een eenvoudig verzoek aan een adres-echodienst zien wat de andere kant ontvangt, en door dat te vergelijken met een verzoek via het mobiele netwerk weet je of het adres überhaupt veranderde.

Als de app via het mobiele netwerk werkt en via de tunnel faalt met hetzelfde account, ligt de weigering aan de andere kant of in het eigen beleid van de app. Als hij op beide faalt, is de VPN niet de onderscheider en kun je beter stoppen met eindpunten testen.

Stap 4: het bewijs aan een van drie uitspraken koppelen

Drie combinaties dekken bijna elk rapport. Een weigering zonder enige uitgaande poging terwijl een tunnel actief is wijst op een lokale transportcontrole. Een verzoek dat naar buiten gaat en terugkomt met een fout, een time-out op een specifieke host of een regiomelding wijst op de andere kant. Een storing die zich via het mobiele netwerk zonder tunnel herhaalt wijst op het account, de appversie of het eigen beleid van de dienst, en geen VPN-wijziging zal die verplaatsen.

Schrijf de uitspraak op samen met het bewijs dat hem opleverde. De waarde van deze stap is dat hij de lus stopt waarin iemand vier keer uitgangsknooppunten wisselt om een controle te repareren die op het toestel zelf loopt.

Het houdt ook de beweringen eerlijk. Zelf hosten verandert het eindpunt en de internetuitgang ervan; het zorgt er niet voor dat Android vergeet dat een VPN-netwerk actief is, en het garandeert geen acceptatie door een dienst die adressen classificeert. Een lokaal filter kan op je eigen VPN-netwerk net zo makkelijk afgaan als op een commercieel netwerk.

Stap 5: de ondersteunde weg nemen en verifiëren

Begin met het gedocumenteerde beleid van het product en de eigenaar van de ondersteuning. Stuur de clientversie, de exacte melding en een smal storingsvenster; stuur geen volledige verkeersopnamen of inloggegevens alleen om te bewijzen dat er een fout bestaat.

Als de dienst directe toegang toestaat en het toestelbeleid dat toestaat, dan is uitsluiting per app het ondersteunde mechanisme, en dat haalt die app bewust uit de tunnel in plaats van de tunnel te verbergen. Het verkeer van de app gaat dan zijn eigen weg, wat een beleidsbeslissing is die iemand moet dragen. In een configuratie die zonder VPN blokkeert, kan een uitgesloten app simpelweg de verbinding verliezen, dus test die combinatie voordat je belooft dat het werkt.

Herhaal na elke wijziging de timingtest van stap één, bevestig dat de app werkt en bevestig dat elke andere app nog steeds de tunnel gebruikt. Zet daarna de vorige configuratie terug en controleer of de storing terugkomt, want een oplossing die je niet kunt reproduceren is een toeval die je opnieuw zult tegenkomen.