Une appli Android refuse de fonctionner sous VPN : quelle couche décide

Quand une appli Android cesse de fonctionner à l’instant où le tunnel monte, trois choses différentes peuvent être responsables, et elles produisent des pannes d’apparence similaire. L’appli peut lire l’état réseau du téléphone et refuser localement. Le serveur peut classer l’adresse d’où vous arrivez et la rejeter. Ou le refus peut n’avoir aucun rapport avec le VPN. L’ordre ci-dessous rassemble des preuves avant de changer quoi que ce soit, car changer la sortie est l’étape la plus coûteuse et celle qui a le moins de chances d’aider si le contrôle est local.

Étape 1 : savoir quand l’appli refuse

Le moment est le premier discriminant. Videz le tampon de journal, reproduisez la panne et regardez ce que l’appli a fait avant de se plaindre :

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

Si l’appli refuse avant qu’une seule requête sortante ait été tentée, vous êtes devant une décision locale. Si elle se connecte, envoie quelque chose puis affiche une erreur, le rejet vient de l’autre côté. Si elle échoue de la même manière avec le tunnel coupé, le VPN n’a jamais été la variable.

Traitez ce moment comme une preuve et non comme une confirmation. Une appli peut rejouer une réponse en cache, et des requêtes d’arrière-plan ont pu réussir ou échouer avant que vous ne regardiez. Notez les horodatages de la dernière requête réussie et de l’erreur, pas seulement l’instant où le message est apparu.

Étape 2 : lire la vision du téléphone sur le réseau

Android expose l’état du VPN comme une capacité réseau, donc une appli n’a pas besoin d’une liste de fournisseurs commerciaux pour remarquer qu’un tunnel est actif. Elle demande au service de connectivité quel est le réseau courant, et la réponse contient un bit de transport VPN :

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

Ce contrôle est local et bon marché, et il explique toute une catégorie de rapports du type « cette appli ne marche pas en VPN » sans aucune classification distante. Ce que l’appli peut voir dépend encore de son propre contexte réseau, alors ne supposez pas que chaque appli inspecte chaque profil de l’appareil.

Depuis un poste de travail, vous pouvez voir le même état sur un appareil de test avec adb shell dumpsys connectivity et en cherchant l’entrée de réseau VPN. Comparez une exécution tunnel levé avec une exécution tunnel baissé, et conservez les deux sorties.

Étape 3 : lire ce que le serveur voit réellement

L’autre observateur est le service. Il voit l’adresse source qui arrive et peut agir sur l’adresse, le réseau d’hébergement derrière elle, la région, l’opérateur ou des signaux liés au compte et à l’appareil. Rien de tout cela n’est une identité unique, et l’adressage partagé rend les blocages collatéraux normaux : une adresse restreinte peut mettre hors jeu des utilisateurs sans rapport derrière la même traduction.

Obtenez l’adresse par le même chemin que l’appli, pas depuis un navigateur sur un ordinateur portable. Sur le téléphone, une simple requête vers un service d’écho d’adresse montre ce que reçoit le côté distant, et la comparer à une requête en réseau mobile vous dit si l’adresse a changé du tout.

Si l’appli fonctionne en réseau mobile et échoue par le tunnel avec le même compte, le refus est à l’extrémité distante ou dans la politique propre de l’appli. Si elle échoue dans les deux cas, le VPN n’est pas le facteur discriminant et vous devriez cesser de tester des points de sortie.

Étape 4 : rattacher les preuves à l’un des trois verdicts

Trois combinaisons couvrent presque tous les rapports. Un refus sans aucune tentative sortante alors qu’un tunnel est actif pointe vers un contrôle local du transport. Une requête qui sort et revient avec une erreur, un dépassement de délai sur un hôte précis ou un message de région pointe vers le côté distant. Une panne qui se reproduit en réseau mobile sans tunnel pointe vers le compte, la version de l’appli ou la politique du service, et aucun changement de VPN ne la déplacera.

Écrivez le verdict avec la preuve qui l’a produit. L’intérêt de cette étape est qu’elle arrête la boucle où quelqu’un change quatre fois de nœud de sortie pour corriger un contrôle qui s’exécute sur le téléphone lui-même.

Elle garde aussi les affirmations honnêtes. Héberger soi-même change le point de sortie et sa sortie internet ; cela ne fait pas oublier à Android qu’un réseau VPN est actif, et cela ne garantit pas l’acceptation par un service qui classe les adresses. Un filtre local peut se déclencher sur votre propre réseau VPN aussi facilement que sur un réseau commercial.

Étape 5 : suivre la voie prise en charge et la vérifier

Commencez par la politique documentée du produit et par son responsable du support. Envoyez la version du client, le message exact et une fenêtre de panne étroite ; n’expédiez pas des captures de trafic complètes ni des identifiants juste pour prouver qu’une erreur existe.

Si le service autorise l’accès direct et que la politique de l’appareil le permet, l’exclusion par application est le mécanisme pris en charge, et elle retire délibérément cette appli du tunnel au lieu de cacher le tunnel. Le trafic de l’appli sort alors par son propre chemin, ce qui est une décision de politique que quelqu’un doit assumer. Dans une configuration qui bloque sans VPN, une appli exclue peut simplement perdre la connectivité, alors testez cette combinaison avant de promettre qu’elle fonctionne.

Après chaque changement, refaites le test de moment de l’étape un, confirmez que l’appli fonctionne et confirmez que toutes les autres applis utilisent encore le tunnel. Puis rétablissez la configuration précédente et vérifiez que la panne revient, car un correctif que vous ne pouvez pas reproduire est une coïncidence que vous retrouverez.