Una app d’Android es nega a funcionar amb VPN: quina capa decideix

Quan una app d’Android deixa de funcionar en el moment que puja el túnel, poden ser-ne responsables tres coses diferents i totes produeixen fallades d’aspecte semblant. L’app pot llegir l’estat de xarxa del propi telèfon i negar-s’hi localment. El servidor pot classificar l’adreça des de la qual arribeu i rebutjar-la. O bé el rebuig pot no tenir res a veure amb la VPN. L’ordre de sota recull proves abans de canviar res, perquè canviar la sortida és el pas més car i el que menys probablement ajuda si la comprovació és local.

Pas 1: esbrinar quan es nega l’app

El moment és el primer element que discrimina. Buideu el buffer del registre, reproduïu la fallada i mireu què va fer l’app abans de queixar-se:

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

Si l’app es nega abans que es provi cap petició de sortida, esteu davant d’una decisió local. Si es connecta, envia alguna cosa i després mostra un error, el rebuig ha vingut de l’altra banda. Si falla igual amb el túnel apagat, la VPN no va ser mai la variable.

Tracteu aquest moment com una prova i no com una confirmació. Una app pot reproduir una resposta en memòria cau, i les peticions en segon pla poden haver tingut èxit o haver fallat abans que ho miréssiu. Anoteu les marques de temps de l’última petició correcta i de l’error, no només el moment en què va aparèixer el missatge.

Pas 2: llegir la visió que té el telèfon de la xarxa

Android exposa l’estat de la VPN com una capacitat de xarxa, així que una app no necessita cap llista de proveïdors comercials per adonar-se que hi ha un túnel actiu. Pregunta al servei de connectivitat quina és la xarxa actual, i la resposta inclou un bit de transport de VPN:

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

Aquesta comprovació és local i barata, i explica tota una classe d’informes del tipus «aquesta app no funciona amb VPN» sense cap classificació remota. El que l’app pot veure encara depèn del seu propi context de xarxa, així que no suposeu que tota app inspecciona tots els perfils del dispositiu.

Des d’una estació de treball podeu veure el mateix estat en un dispositiu de prova amb adb shell dumpsys connectivity i buscant l’entrada de xarxa VPN. Compareu una execució amb el túnel aixecat amb una altra amb el túnel baixat, i guardeu les dues sortides.

Pas 3: llegir què veu realment el servidor

L’altre observador és el servei. Veu l’adreça d’origen que arriba i pot actuar sobre l’adreça, la xarxa d’allotjament que hi ha al darrere, la regió, l’operador o senyals lligats al compte i al dispositiu. Cap d’aquests elements no és una identitat única, i l’adreçament compartit fa normals els bloqueigs col·laterals: una adreça restringida pot deixar fora usuaris sense relació que hi ha darrere de la mateixa traducció.

Obteniu l’adreça pel mateix camí que fa servir l’app, no des d’un navegador en un portàtil. Al telèfon, una petició senzilla a un servei d’eco d’adreça mostra què rep la banda remota, i comparar-ho amb una petició per la xarxa mòbil us diu si l’adreça ha canviat o no.

Si l’app funciona per la xarxa mòbil i falla pel túnel amb el mateix compte, el rebuig és a la banda remota o a la política pròpia de l’app. Si falla en els dos casos, la VPN no és el factor diferencial i hauríeu de deixar de provar punts finals.

Pas 4: encaixar les proves amb un dels tres veredictes

Tres combinacions cobreixen gairebé tots els informes. Un rebuig sense cap intent de sortida mentre hi ha un túnel actiu apunta a una comprovació local del transport. Una petició que surt i torna amb un error, un temps d’espera exhaurit en un amfitrió concret o un missatge de regió apunten a la banda remota. Una fallada que es repeteix per la xarxa mòbil sense túnel apunta al compte, a la versió de l’app o a la política del propi servei, i cap canvi de VPN la mourà.

Escriviu el veredicte juntament amb la prova que l’ha produït. El valor d’aquest pas és que atura el bucle en què algú canvia quatre vegades els nodes de sortida per arreglar una comprovació que s’executa al mateix telèfon.

També manté les afirmacions honestes. Allotjar-ho un mateix canvia el punt final i la seva sortida a internet; no fa que Android oblidi que hi ha una xarxa VPN activa ni garanteix que ho accepti un servei que classifica adreces. Un filtre local es pot activar en una xarxa VPN pròpia igual de fàcilment que en una de comercial.

Pas 5: seguir el camí suportat i verificar-lo

Comenceu per la política documentada del producte i pel seu responsable de suport. Envieu la versió del client, el missatge exacte i una finestra de fallada estreta; no envieu captures completes de trànsit ni credencials només per demostrar que existeix un error.

Si el servei permet l’accés directe i la política del dispositiu ho permet, l’exclusió per app és el mecanisme suportat, i treu deliberadament aquesta app del túnel en lloc d’amagar el túnel. Llavors el trànsit de l’app surt pel seu propi camí, que és una decisió de política que algú ha d’assumir. En una configuració que bloqueja sense VPN, una app exclosa pot simplement perdre la connectivitat, així que proveu aquesta combinació abans de prometre que funciona.

Després de qualsevol canvi, repetiu la prova de temps del primer pas, confirmeu que l’app funciona i confirmeu que tota la resta d’apps encara fa servir el túnel. Després restaureu la configuració anterior i comproveu si torna la fallada, perquè un arranjament que no podeu reproduir és una coincidència que tornareu a trobar.