ADB y el emulador de Android fallan detrás de una VPN: tres rutas

Conecta la VPN de la oficina y Android Studio pierde el emulador en marcha, adb start-server se cuelga y un teléfono físico por Wi-Fi desaparece de la lista de dispositivos. Parece que un túnel bloquea un producto. En realidad fallan tres rutas distintas de tres maneras: el descubrimiento de dispositivos de adb, la red virtual del emulador y el resolutor del host. El túnel suele poseer solo la última, y a menudo solo una parte.

Tres sockets, tres dueños

El servidor adb escucha en el puerto 5037 del host y habla con los dispositivos por USB o TCP, con mDNS para el descubrimiento en red. El emulador se ejecuta detrás de su propio enrutador virtual: el invitado es 10.0.2.15, su puerta de enlace es 10.0.2.2 y su servidor DNS es 10.0.2.3, y el proceso del emulador lo traduce todo a sockets del host. El resolutor del host es donde el cliente VPN instala el DNS y los dominios de búsqueda.

Esa separación explica por qué una corrección parece funcionar para una herramienta y no para otra. Un cliente que cambia el resolutor del host deja el proceso del emulador con el estado de resolutor que leyó al arrancar. Un cliente que filtra multicast rompe el descubrimiento sin tocar el DNS. Un cliente que filtra adaptadores virtuales deniega el emulador mientras el navegador del host sigue funcionando. Cada síntoma tiene una causa distinta, así que identifique la ruta que falla antes de cambiar cualquier ajuste.

Empiece por lo que adb puede ver

Ejecute adb devices antes de tocar la VPN. Una lista vacía es un problema de transporte, no de enrutamiento, y ningún ajuste del túnel arreglará un dispositivo que el servidor nunca enumeró. Reinicie el servidor limpio: primero adb kill-server y luego adb start-server, y lea la salida para ver qué puerto ocupó. Si el propio arranque se cuelga, el descubrimiento mDNS es el sospechoso habitual en una red que filtra multicast; la solución documentada es arrancar el servidor con el descubrimiento desactivado:

ADB_MDNS_OPENSCREEN=0 adb start-server
adb devices

Para un dispositivo físico, USB es la ruta más corta. Si necesita TCP, ponga el dispositivo en modo de escucha con adb tcpip 5555 y conéctese a la dirección y al puerto del dispositivo, adb connect 192.0.2.10:5555. El puerto 5037 es el puerto del servidor del host, no el puerto en el que escucha un dispositivo.

Pruebe el emulador desde dentro

El emulador responde al DNS desde 10.0.2.3, y ese resolutor se alimenta del proceso del host. Cuando el cliente VPN cambia el resolutor del host, el emulador puede heredarlo; cuando el cliente filtra el proceso del emulador o la lista de adaptadores del host cambia después de arrancar, no puede. Separe ambos con un objetivo numérico y un nombre desde el mismo shell. adb shell ping -c 2 10.0.2.2 demuestra que la red virtual alcanza el lado del host. Una consulta de nombre después indica si la resolución cruzó la frontera.

Luego ejecute la misma consulta en el host. Que el host resuelva y el emulador no significa que la rotura está entre el resolutor del host y la red virtual del emulador, no en el túnel. Que ambos fallen significa que hay que mirar el resolutor del host. Reiniciar el emulador tras conectar la VPN merece un intento, porque algunos clientes instalan un estado de resolutor que un proceso de emulador en marcha no recoge.

Revise el resolutor del host y los filtros del cliente

Un cliente de túnel completo sustituye el resolutor del host por el suyo, y un cliente split-DNS añade dominios de búsqueda y reenviadores condicionales. Los nombres internos suelen depender de esa configuración split-DNS, así que mire qué usa el host mientras está conectado: la dirección del resolutor, el dominio de búsqueda y si la zona interna se enruta al DNS corporativo. Un resolutor que responde a nombres públicos pero no a internos es una cuestión de política, no un túnel roto.

Algunos clientes corporativos también bloquean el tráfico de adaptadores virtuales. Para un controlador de filtro, el emulador parece un adaptador virtual, así que el host puede funcionar perfectamente mientras la política deniega el emulador. Esa política no es visible desde la estación de trabajo, y adivinar ajustes de proxy no la revelará. Si el host resuelve y el emulador queda bloqueado independientemente del resolutor, la escalada correcta es al equipo que posee la política del cliente.

Orden de las comprobaciones y qué significa cada resultado

Trabaje de arriba abajo y deténgase en la primera fila que falle. Cada resultado apunta a un dueño distinto, y ninguno se arregla reinstalando Android Studio.

Solo las dos últimas filas son preguntas de VPN en el sentido habitual, y solo la última trata del contenido del DNS. La documentación de adb cubre el puerto del servidor y las variables de entorno citadas aquí, suficiente para mantener honesto el lado del transporte mientras prueba el resto.