ADB e l’emulatore Android falliscono dietro una VPN: tre percorsi

Collegate la VPN dell’ufficio e Android Studio perde l’emulatore in esecuzione, adb start-server si blocca e un telefono fisico in Wi-Fi sparisce dall’elenco dei dispositivi. Sembra che un tunnel blocchi un prodotto. In pratica falliscono tre percorsi distinti in tre modi: il rilevamento dei dispositivi di adb, la rete virtuale dell’emulatore e il resolver dell’host. Il tunnel di solito possiede solo l’ultimo, e spesso solo una parte.

Tre socket, tre proprietari

Il server adb ascolta sulla porta 5037 dell’host e parla con i dispositivi via USB o TCP, con mDNS per il rilevamento in rete. L’emulatore gira dietro il proprio router virtuale: il guest è 10.0.2.15, il gateway 10.0.2.2 e il server DNS 10.0.2.3, e il processo dell’emulatore traduce tutto in socket dell’host. Il resolver dell’host è dove il client VPN installa DNS e domini di ricerca.

Questa separazione spiega perché una correzione sembra funzionare per uno strumento e non per un altro. Un client che cambia il resolver dell’host lascia il processo dell’emulatore con lo stato del resolver letto all’avvio. Un client che filtra il multicast rompe il rilevamento senza toccare il DNS. Un client che filtra gli adattatori virtuali nega l’emulatore mentre il browser dell’host continua a funzionare. Ogni sintomo ha una causa diversa, quindi individuate il percorso che fallisce prima di cambiare qualsiasi impostazione.

Partite da ciò che adb vede

Eseguite adb devices prima di toccare la VPN. Un elenco vuoto è un problema di trasporto, non di routing, e nessuna impostazione del tunnel riparerà un dispositivo che il server non ha mai elencato. Riavviate il server in modo pulito: prima adb kill-server poi adb start-server, e leggete l’output per vedere quale porta ha occupato. Se l’avvio stesso si blocca, il rilevamento mDNS è il sospetto abituale su una rete che filtra il multicast; la soluzione documentata è avviare il server con il rilevamento disattivato:

ADB_MDNS_OPENSCREEN=0 adb start-server
adb devices

Per un dispositivo fisico l’USB è il percorso più breve. Se serve TCP, mettete il dispositivo in modalità ascolto con adb tcpip 5555 e collegatevi all’indirizzo e alla porta del dispositivo, adb connect 192.0.2.10:5555. La porta 5037 è la porta del server dell’host, non la porta su cui ascolta un dispositivo.

Provate l’emulatore dall’interno

L’emulatore risponde al DNS da 10.0.2.3, e quel resolver è alimentato dal processo dell’host. Quando il client VPN cambia il resolver dell’host, l’emulatore può ereditarlo; quando il client filtra il processo dell’emulatore o l’elenco degli adattatori cambia dopo l’avvio, non può. Separate i due con un obiettivo numerico e un nome dalla stessa shell. adb shell ping -c 2 10.0.2.2 dimostra che la rete virtuale raggiunge il lato host. Una risoluzione di nome dopo indica se la risoluzione ha superato il confine.

Poi eseguite la stessa risoluzione sull’host. L’host risolve e l’emulatore no significa che la rottura è tra il resolver dell’host e la rete virtuale dell’emulatore, non nel tunnel. Entrambi falliscono significa che il posto da guardare è il resolver dell’host. Riavviare l’emulatore dopo la connessione VPN vale un tentativo, perché alcuni client installano uno stato del resolver che un processo dell’emulatore in esecuzione non riprende.

Controllate il resolver dell’host e i filtri del client

Un client a tunnel completo sostituisce il resolver dell’host con il proprio, e un client split-DNS aggiunge domini di ricerca e forwarder condizionali. I nomi interni spesso dipendono da quella configurazione split-DNS, quindi guardate cosa usa l’host mentre è connesso: l’indirizzo del resolver, il dominio di ricerca e se la zona interna è instradata al DNS aziendale. Un resolver che risponde ai nomi pubblici ma non a quelli interni è una questione di policy, non un tunnel rotto.

Alcuni client aziendali bloccano anche il traffico dagli adattatori virtuali. Per un driver di filtro l’emulatore sembra un adattatore virtuale, quindi l’host può funzionare perfettamente mentre la policy nega l’emulatore. Quella policy non è visibile dalla workstation, e indovinare le impostazioni del proxy non la rivelerà. Se l’host risolve e l’emulatore resta bloccato a prescindere dalle impostazioni, l’escalation corretta è al team che possiede la policy del client.

Ordine dei controlli e cosa significa ogni risultato

Lavorate dall’alto verso il basso e fermatevi alla prima riga che fallisce. Ogni risultato indica un proprietario diverso, e nessuno si risolve reinstallando Android Studio.

Solo le ultime due righe sono domande VPN nel senso comune, e solo l’ultima riguarda il contenuto DNS. La documentazione di adb copre la porta del server e le variabili d’ambiente citate qui, abbastanza per tenere onesto il lato trasporto mentre provate il resto.