ADB et l’émulateur Android échouent derrière un VPN : trois chemins

Vous connectez le VPN du bureau et Android Studio perd l’émulateur en cours, adb start-server se bloque et un téléphone physique en Wi-Fi disparaît de la liste des appareils. On croirait un produit bloqué par un tunnel. En pratique trois chemins distincts échouent de trois façons : la découverte d’appareils par adb, le réseau virtuel de l’émulateur et le résolveur de l’hôte. Le tunnel ne possède souvent que le dernier, et parfois seulement une partie.

Trois sockets, trois propriétaires

Le serveur adb écoute sur le port 5037 de l’hôte et parle aux appareils en USB ou TCP, avec mDNS pour la découverte réseau. L’émulateur tourne derrière son propre routeur virtuel : l’invité est 10.0.2.15, sa passerelle 10.0.2.2 et son serveur DNS 10.0.2.3, et le processus de l’émulateur traduit tout en sockets de l’hôte. Le résolveur de l’hôte est l’endroit où le client VPN installe le DNS et les domaines de recherche.

Cette séparation explique pourquoi un correctif semble marcher pour un outil et pas pour un autre. Un client qui change le résolveur de l’hôte laisse le processus d’émulateur avec l’état de résolveur lu au démarrage. Un client qui filtre le multicast casse la découverte sans toucher au DNS. Un client qui filtre les adaptateurs virtuels refuse l’émulateur alors que le navigateur de l’hôte continue de fonctionner. Chaque symptôme a sa cause, identifiez donc le chemin défaillant avant de changer un réglage.

Commencez par ce qu’adb voit

Exécutez adb devices avant de toucher au VPN. Une liste vide est un problème de transport, pas de routage, et aucun réglage de tunnel ne réparera un appareil que le serveur n’a jamais énuméré. Redémarrez le serveur proprement : d’abord adb kill-server puis adb start-server, et lisez la sortie pour voir quel port il a pris. Si le démarrage lui-même se bloque, la découverte mDNS est le suspect habituel sur un réseau qui filtre le multicast ; la solution documentée est de démarrer le serveur avec la découverte désactivée :

ADB_MDNS_OPENSCREEN=0 adb start-server
adb devices

Pour un appareil physique, l’USB est le chemin le plus court. Si vous avez besoin de TCP, passez l’appareil en mode écoute avec adb tcpip 5555 et connectez-vous à l’adresse et au port de l’appareil, adb connect 192.0.2.10:5555. Le port 5037 est celui du serveur de l’hôte, pas celui sur lequel un appareil écoute.

Testez l’émulateur de l’intérieur

L’émulateur répond au DNS depuis 10.0.2.3, et ce résolveur est alimenté par le processus de l’hôte. Quand le client VPN change le résolveur, l’émulateur peut l’hériter ; quand le client filtre le processus d’émulateur ou que la liste d’adaptateurs change après le démarrage, il ne peut pas. Séparez les deux avec une cible numérique et un nom depuis le même shell. adb shell ping -c 2 10.0.2.2 prouve que le réseau virtuel atteint le côté hôte. Une résolution de nom ensuite indique si la résolution a franchi la frontière.

Exécutez ensuite la même résolution sur l’hôte. L’hôte résout et l’émulateur non signifie que la rupture se situe entre le résolveur de l’hôte et le réseau virtuel de l’émulateur, pas dans le tunnel. Les deux échouent signifie qu’il faut regarder le résolveur de l’hôte. Redémarrer l’émulateur après la connexion VPN vaut un essai, car certains clients installent un état de résolveur qu’un processus d’émulateur en cours ne reprend pas.

Vérifiez le résolveur de l’hôte et les filtres du client

Un client de tunnel complet remplace le résolveur de l’hôte par le sien, et un client split-DNS ajoute des domaines de recherche et des redirecteurs conditionnels. Les noms internes dépendent souvent de cette configuration split-DNS, regardez donc ce que l’hôte utilise pendant la connexion : l’adresse du résolveur, le domaine de recherche et si la zone interne est routée vers le DNS d’entreprise. Un résolveur qui répond aux noms publics mais pas aux internes est une question de politique, pas un tunnel cassé.

Certains clients d’entreprise bloquent aussi le trafic des adaptateurs virtuels. Pour un pilote de filtre, l’émulateur ressemble à un adaptateur virtuel, si bien que l’hôte peut fonctionner parfaitement tandis que l’émulateur est refusé par la politique. Cette politique n’est pas visible depuis le poste de travail, et deviner des réglages de proxy ne la révélera pas. Si l’hôte résout et que l’émulateur reste bloqué quels que soient les réglages, l’escalade correcte va à l’équipe qui possède la politique du client.

Ordre des vérifications et ce que signifie chaque résultat

Travaillez de haut en bas et arrêtez-vous à la première ligne en échec. Chaque résultat désigne un propriétaire différent, et aucun ne se règle en réinstallant Android Studio.

Seules les deux dernières lignes sont des questions de VPN au sens habituel, et seule la dernière concerne le contenu DNS. La documentation adb couvre le port du serveur et les variables d’environnement citées ici, de quoi garder le côté transport honnête pendant que vous testez le reste.