ADB i l’emulador d’Android fallen darrere d’una VPN: tres camins
El descobriment d’ADB, la targeta de xarxa virtual de l’emulador i el resolutor de l’amfitrió fallen per separat darrere d’una VPN. Proveu cada camí per ordre abans de culpar el túnel.
Connecteu la VPN de l’oficina i Android Studio perd l’emulador en marxa, adb start-server s’encalla i un telèfon físic per Wi-Fi desapareix de la llista de dispositius. Sembla que un sol túnel bloqueja un sol producte. A la pràctica fallen tres camins diferents de tres maneres: el descobriment de dispositius d’ADB, la xarxa virtual de l’emulador i el resolutor de l’amfitrió. El túnel normalment només posseeix l’últim, i sovint només una part.
Tres sòcols, tres propietaris
El servidor adb escolta al port 5037 de l’amfitrió i parla amb els dispositius per USB o per TCP, amb mDNS per al descobriment de xarxa. L’emulador funciona darrere del seu propi encaminador virtual: el convidat és 10.0.2.15, la passarel·la és 10.0.2.2 i el servidor DNS és 10.0.2.3, i el procés de l’emulador ho tradueix tot a sòcols de l’amfitrió. El resolutor de l’amfitrió és on el client VPN instal·la el DNS i els dominis de cerca.
Aquesta separació explica per què una correcció sembla funcionar per a una eina i no per a una altra. Un client que canvia el resolutor de l’amfitrió deixa el procés de l’emulador amb l’estat del resolutor que va llegir en arrencar. Un client que filtra multicast trenca el descobriment sense tocar el DNS. Un client que filtra adaptadors virtuals denega l’emulador mentre el navegador de l’amfitrió continua funcionant. Cada símptoma té una causa diferent, així que identifiqueu el camí que falla abans de canviar cap paràmetre.
Comenceu pel que adb pot veure
Executeu adb devices abans de tocar la VPN. Una llista buida és un problema de transport, no d’encaminament, i cap paràmetre del túnel arreglarà un dispositiu que el servidor no ha enumerat mai. Reinicieu el servidor net: primer adb kill-server i després adb start-server, i llegiu la sortida per saber quin port ha ocupat. Si l’arrencada mateixa s’encalla, el descobriment mDNS és el sospitós habitual en una xarxa que filtra multicast; la solució documentada és arrencar el servidor amb el descobriment desactivat:
ADB_MDNS_OPENSCREEN=0 adb start-server
adb devicesPer a un dispositiu físic, l’USB és el camí més curt. Si necessiteu TCP, poseu el dispositiu en mode d’escolta amb adb tcpip 5555 i connecteu-vos a l’adreça i al port del dispositiu, adb connect 192.0.2.10:5555. El port 5037 és el port del servidor de l’amfitrió, no el port on escolta un dispositiu.
Proveu l’emulador des de dins
L’emulador respon al DNS des de 10.0.2.3, i aquest resolutor s’alimenta del procés de l’amfitrió. Quan el client VPN canvia el resolutor de l’amfitrió, l’emulador el pot heretar; quan el client filtra el procés de l’emulador o la llista d’adaptadors de l’amfitrió canvia després d’arrencar, no pot. Separeu-ho amb un objectiu numèric i un nom des del mateix shell. adb shell ping -c 2 10.0.2.2 demostra que la xarxa virtual pot arribar al costat de l’amfitrió. Una consulta de nom després us diu si la resolució ha creuat la frontera.
Després executeu la mateixa consulta de nom a l’amfitrió. Que l’amfitrió resolgui i l’emulador no vol dir que el trencament és entre el resolutor de l’amfitrió i la xarxa virtual de l’emulador, no al túnel. Que tots dos fallin vol dir que cal mirar el resolutor de l’amfitrió. Reiniciar l’emulador després de connectar la VPN val un intent, perquè alguns clients instal·len un estat de resolutor que un procés d’emulador en marxa no recull.
Reviseu el resolutor de l’amfitrió i els filtres del client
Un client de túnel complet substitueix el resolutor de l’amfitrió pel seu, i un client split-DNS afegeix dominis de cerca i reenviadors condicionals. Els noms interns sovint depenen d’aquesta configuració split-DNS, així que mireu què fa servir l’amfitrió mentre esteu connectat: l’adreça del resolutor, el domini de cerca i si la zona interna s’encamina al DNS corporatiu. Un resolutor que respon noms públics però no interns és una qüestió de política, no un túnel trencat.
Alguns clients corporatius també bloquegen el trànsit d’adaptadors virtuals. Per a un controlador de filtre, l’emulador sembla un adaptador virtual, així que l’amfitrió pot funcionar perfectament mentre la política denega l’emulador. Aquesta política no és visible des de l’estació de treball, i endevinar paràmetres de proxy no la revelarà. Si l’amfitrió resol i l’emulador queda bloquejat independentment dels paràmetres del resolutor, l’escalada correcta és a l’equip que posseeix la política del client.
Ordre de comprovacions i què significa cada resultat
Treballeu de dalt a baix i atureu-vos a la primera fila que falli. Cada resultat apunta a un propietari diferent, i cap no es resol reinstal·lant Android Studio.
| Result | Likely owner | Next check |
|---|---|---|
| adb devices is empty with USB attached | USB, driver or adb server | cable, authorization prompt, adb kill-server |
| adb start-server hangs | mDNS discovery | ADB_MDNS_OPENSCREEN=0 |
| Emulator reaches 10.0.2.2, names fail | Host resolver to emulator boundary | host lookup of the same name |
| Host resolves, emulator still fails | Emulator process or client filter | restart emulator, ask IT about virtual adapters |
| Both fail for internal names only | Split DNS or search domain | resolver and zone configuration |
Només les dues últimes files són preguntes de VPN en el sentit habitual, i només l’última tracta del contingut del DNS. La documentació d’adb cobreix el port del servidor i les variables d’entorn esmentades aquí, prou per mantenir honest el costat del transport mentre proveu la resta.