Android-appen vägrar köra över VPN: vilket lager avgör

När en Android-app slutar fungera i samma stund som tunneln kommer upp kan tre olika saker vara ansvariga, och de ger liknande fel. Appen kan läsa telefonens eget nätverkstillstånd och neka lokalt. Servern kan klassificera adressen du kommer från och avvisa den. Eller så kan nekandet inte ha något med VPN att göra. Ordningen nedan samlar bevis innan den ändrar något, eftersom att byta utgång är det dyraste steget och det som minst sannolikt hjälper om kontrollen är lokal.

Steg 1: ta reda på när appen nekar

Tidpunkten är den första urskiljaren. Töm loggbufferten, återskapa felet och titta på vad appen gjorde innan den klagade:

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

Om appen nekar innan något utgående anrop har försökts har du en lokal bedömning. Om den ansluter, skickar något och först därefter visar ett fel kom avvisandet från andra sidan. Om appen misslyckas likadant med tunneln avstängd var VPN aldrig variabeln.

Behandla den tidpunkten som bevis, inte som bevisning. En app kan spela upp ett cachelagrat svar, och bakgrundsanrop kan ha lyckats eller misslyckats innan du tittade. Notera tidsstämplarna för det senaste lyckade anropet och felet, inte bara ögonblicket då meddelandet dök upp.

Steg 2: läs telefonens egen bild av nätverket

Android exponerar VPN-tillståndet som en nätverksförmåga, så en app behöver ingen lista över kommersiella leverantörer för att märka att en tunnel är aktiv. Den frågar anslutningstjänsten vilket nätverk som är aktuellt, och svaret innehåller 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 är lokal och billig, och den förklarar en hel klass av rapporter av typen "den här appen fungerar inte över VPN" utan någon fjärrklassificering. Vad appen kan se beror fortfarande på dess egen nätverkskontext, så anta inte att varje app inspekterar varje profil på enheten.

Från en arbetsstation ser du samma tillstånd på en testenhet med adb shell dumpsys connectivity och genom att leta efter VPN-nätverksposten. Jämför en körning med tunneln uppe med en då den är nere och behåll båda utskrifterna.

Steg 3: läs vad servern faktiskt ser

Den andra observatören är tjänsten. Den ser källadressen som kommer in och kan agera på adressen, värdnätverket bakom den, regionen, operatören eller signaler knutna till kontot och enheten. Ingen av dem är en unik identitet, och delade adresser gör följdblockeringar normala: en begränsad adress kan slå ut orelaterade användare bakom samma översättning.

Hämta adressen via samma väg som appen använder, inte från en webbläsare på en laptop. På telefonen visar en enkel begäran till en adresseko-tjänst vad fjärrsidan tar emot, och en jämförelse med en begäran över mobilnätet säger om adressen ändrades alls.

Om appen fungerar över mobilnätet och misslyckas över tunneln med samma konto ligger avvisandet i fjärränden eller i appens egen policy. Om den misslyckas i båda fallen är VPN inte skillnaden och du bör sluta testa ändpunkter.

Steg 4: matcha bevisen mot en av tre slutsatser

Tre kombinationer täcker nästan varje rapport. Ett nekande utan utgående försök medan en tunnel är aktiv pekar på en lokal transportkontroll. En begäran som går ut och kommer tillbaka med ett fel, en tidsgräns på en viss värd eller ett regionmeddelande pekar på fjärrsidan. Ett fel som återkommer över mobilnätet utan tunnel pekar på kontot, appversionen eller tjänstens egen policy, och ingen VPN-ändring flyttar det.

Skriv ner slutsatsen tillsammans med bevisen som gav den. Värdet med steget är att det stoppar loopen där någon byter utgångsnoder fyra gånger för att laga en kontroll som körs i själva telefonen.

Det håller också påståendena ärliga. Egen drift ändrar ändpunkten och dess internetutgång; det får inte Android att glömma att ett VPN-nätverk är aktivt och garanterar inte att en tjänst som klassificerar adresser accepterar dig. Ett lokalt filter kan slå till på ett VPN-nätverk du äger lika lätt som på ett kommersiellt.

Steg 5: ta den stödda vägen och verifiera den

Börja med produktens dokumenterade policy och dess supportägare. Skicka klientversionen, det exakta meddelandet och ett snävt fönster för felet; skicka inte fullständiga trafikupptagningar eller autentiseringsuppgifter bara för att bevisa att ett fel finns.

Om tjänsten tillåter direkt åtkomst och enhetspolicyn tillåter det, är undantag för en enskild app den stödda mekanismen, och den tar medvetet bort appen från tunneln i stället för att dölja tunneln. Appens trafik går då sin egen väg, vilket är ett policybeslut som någon måste äga. I en konfiguration som blockerar utan VPN kan en undantagen app helt enkelt tappa anslutningen, så testa den kombinationen innan du lovar att den fungerar.

Efter varje ändring, upprepa tidstestet från steg ett, bekräfta att appen fungerar och bekräfta att alla andra appar fortfarande använder tunneln. Återställ sedan den tidigare konfigurationen och kontrollera att felet återkommer, eftersom en åtgärd du inte kan återskapa är en slump du kommer att möta igen.