ADB e o emulador de Android fallan detrás dunha VPN: tres rutas

Conecta a VPN da oficina e Android Studio perde o emulador en marcha, adb start-server colga e un teléfono físico por Wi-Fi desaparece da lista de dispositivos. Parece que un túnel bloquea un produto. Na práctica fallan tres rutas distintas de tres maneiras: o descubrimento de dispositivos de adb, a rede virtual do emulador e o resolvedor do host. O túnel adoita posuír só a última, e a miúdo só unha parte.

Tres sockets, tres donos

O servidor adb escoita no porto 5037 do host e fala cos dispositivos por USB ou TCP, con mDNS para o descubrimento de rede. O emulador execútase detrás do seu propio encamiñador virtual: o convidado é 10.0.2.15, a súa pasarela é 10.0.2.2 e o seu servidor DNS é 10.0.2.3, e o proceso do emulador tradúceo todo a sockets do host. O resolvedor do host é onde o cliente VPN instala o DNS e os dominios de busca.

Esa separación explica por que unha corrección parece funcionar para unha ferramenta e non para outra. Un cliente que cambia o resolvedor do host deixa o proceso do emulador co estado de resolvedor que leu ao arrincar. Un cliente que filtra multicast rompe o descubrimento sen tocar o DNS. Un cliente que filtra adaptadores virtuais denega o emulador mentres o navegador do host segue funcionando. Cada síntoma ten unha causa distinta, así que identifique a ruta que falla antes de cambiar calquera axuste.

Empece polo que adb pode ver

Execute adb devices antes de tocar a VPN. Unha lista baleira é un problema de transporte, non de encamiñamento, e ningún axuste do túnel arranxará un dispositivo que o servidor nunca enumerou. Reinicie o servidor limpo: primeiro adb kill-server e logo adb start-server, e lea a saída para ver que porto ocupou. Se o propio arrinque se colga, o descubrimento mDNS é o sospeitoso habitual nunha rede que filtra multicast; a solución documentada é arrincar o servidor co descubrimento desactivado:

ADB_MDNS_OPENSCREEN=0 adb start-server
adb devices

Para un dispositivo físico, USB é a ruta máis curta. Se precisa TCP, poña o dispositivo en modo de escoita con adb tcpip 5555 e concéctese ao enderezo e ao porto do dispositivo, adb connect 192.0.2.10:5555. O porto 5037 é o porto do servidor do host, non o porto no que escoita un dispositivo.

Probe o emulador desde dentro

O emulador responde ao DNS desde 10.0.2.3, e ese resolvedor aliméntase do proceso do host. Cando o cliente VPN cambia o resolvedor do host, o emulador pode herdalo; cando o cliente filtra o proceso do emulador ou a lista de adaptadores do host cambia despois de arrincar, non pode. Separe ambos cun obxectivo numérico e un nome desde a mesma shell. adb shell ping -c 2 10.0.2.2 demostra que a rede virtual acada o lado do host. Unha consulta de nome despois indica se a resolución cruzou a fronteira.

Logo execute a mesma consulta no host. Que o host resolva e o emulador non significa que a rotura está entre o resolvedor do host e a rede virtual do emulador, non no túnel. Que ambos fallen significa que hai que mirar o resolvedor do host. Reiniciar o emulador tras conectar a VPN merece un intento, porque algúns clientes instalan un estado de resolvedor que un proceso de emulador en marcha non recolle.

Revise o resolvedor do host e os filtros do cliente

Un cliente de túnel completo substitúe o resolvedor do host polo seu, e un cliente split-DNS engade dominios de busca e reenviadores condicionais. Os nomes internos adoitan depender desa configuración split-DNS, así que mire que usa o host mentres está conectado: o enderezo do resolvedor, o dominio de busca e se a zona interna se encamiña ao DNS corporativo. Un resolvedor que responde a nomes públicos pero non a internos é unha cuestión de política, non un túnel roto.

Algúns clientes corporativos tamén bloquean o tráfico de adaptadores virtuais. Para un controlador de filtro, o emulador parece un adaptador virtual, así que o host pode funcionar perfectamente mentres a política denega o emulador. Esa política non é visible desde a estación de traballo, e adiviñar axustes de proxy non a revelará. Se o host resolve e o emulador queda bloqueado independentemente do resolvedor, a escalada correcta é ao equipo que posúe a política do cliente.

Orde das comprobacións e que significa cada resultado

Traballa de arriba abaixo e detense na primeira fila que falle. Cada resultado apunta a un dono distinto, e ningún se arranxa reinstalando Android Studio.

Só as dúas últimas filas son preguntas de VPN no sentido habitual, e só a última trata do contido do DNS. A documentación de adb cobre o porto do servidor e as variables de contorno citadas aquí, suficiente para manter honesto o lado do transporte mentres proba o resto.