Emulador de Android e VPN do host: instantánea de DNS e explicación de NAT

Cando o emulador non chega a un servidor de compilación que o navegador do host abre sen problema, a pregunta útil non é se o VPN funciona. É cal dos dous mecanismos lle falta ao convidado. O dispositivo virtual executa a súa propia pila de rede detrás do NAT do emulador, e a súa lista de resolutores é unha copia tomada ao arrincar, así que un túnel que subiu despois cambia a ruta do host sen cambiar o que pregunta o convidado. Entender esas dúas capas explica case todas as variantes deste problema.

O convidado é unha pila aparte detrás dun NAT fixo

A rede QEMU en modo usuario sitúa o convidado en 10.0.2.15, a pasarela en 10.0.2.2 e o servizo DNS en 10.0.2.3 ata 10.0.2.6. O kernel do host non reenvía o tráfico saínte do convidado; tradúceo en sockets do lado do host, un por conexión do convidado, e eses sockets saen do espazo de enderezos do host. Por iso unha conexión do convidado herda a decisión de encamiñamento do host no momento de crearse, e por iso o convidado non ten ningunha entrada na táboa de rutas que nomee o seu túnel.

O mesmo mecanismo dálle ao convidado unha saída útil. 10.0.2.2 é un alias da interface de bucle local do host, así que un servizo que escoita en 127.0.0.1 no portátil é alcanzable desde o convidado nese enderezo. Todo o que o cliente expón só no bucle local pódese alcanzar así, e esa é a base da montaxe de proxy descrita máis abaixo.

O que o convidado non pode facer é observar a rede do host coma se fose un espazo de nomes sobre ela. Non hai ponte, nin táboa de rutas compartida, nin resolutor herdado; só o servizo NAT que acepta os seus paquetes e a instantánea que tomou o lanzador ao iniciar o dispositivo virtual.

O DNS é unha instantánea, non unha vista en vivo

Ao arrincar, o emulador le a lista de resolutores do host e entrega ao convidado ata catro servidores, expostos nos enderezos 10.0.2.3 a 10.0.2.6. Se o túnel estaba caído nese momento, a instantánea contén calquera resolutor público que usase o portátil, e o convidado segue preguntándolle toda a vida. Os nomes públicos resólvense, os internos fallan, e cada síntoma apunta ao VPN cando o valor obsoleto real é unha lista de resolutores capturada minutos antes de que subise o túnel.

Así que a corrección por orde non é folclore. Conecte primeiro o túnel, reinicie despois o emulador e prefira un arrinque en frío a restaurar unha instantánea, porque unha imaxe de arrinque rápido pode volver co estado de resolutor e rutas que gardou antes. Se precisa ver que usa o convidado agora, pregunte ao dispositivo e non ao host:

adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.example

O emulador tamén acepta un resolutor explícito ao arrincar, o que é útil cando sabe exactamente que servidor debe usar o convidado e perigoso cando ese servidor é público:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Un resolutor público non ten copia dunha zona interna, así que fixar un converte un problema de orde nun fallo permanente. Se o perfil empuxa DNS privado, deixe que o túnel o proporcione e arrinque o convidado en frío en lugar de codificar un enderezo.

O encamiñamento segue o host no momento da conexión

Como as conexións do convidado se converten en sockets do host, a decisión de encamiñamento tómase ao crear o socket. Un túnel levantado antes da petición significa que a petición sae polo túnel segundo as rutas do perfil. Un perfil de túnel dividido que só leva prefixos seleccionados deixará a súa subrede privada fóra, así que a alcanzabilidade do host é unha hipótese sobre o convidado, non un resultado. As conexións existentes do convidado conservan a ruta coa que se crearon, e por iso un cliente que se reconecta non sempre arranxa unha descarga atascada dentro do emulador.

A verificación vai na interface do host, non nas estatísticas do convidado:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Se a petición do convidado aparece na interface do túnel, o encamiñamento funciona e o problema está por riba. Se aparece na interface física, o perfil non cobre ese prefixo, e ningunha reconfiguración no lado do convidado o cambiará.

Cando o cliente só ofrece un proxy de bucle local

Algúns clientes comerciais non crean ningún túnel de sistema. Expón un escoitador HTTP ou SOCKS en 127.0.0.1 e esperan que as aplicacións o usen. O convidado non ve ese socket directamente, pero pódese dicir ao emulador que o use, xa sexa polos controis estendidos (Axustes, logo Proxy, modo manual, host 127.0.0.1 e o porto que imprime o cliente) ou ao arrincar:

emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080

Copie o porto da ventá do cliente; un porto adiviñado falla en silencio e parece un túnel roto. Teña en conta que cobre isto: a configuración de proxy HTTP respéctana as aplicacións conscientes do proxy, e os sockets crus ignórana por completo. Se a carga é un binario nativo que abre as súas propias conexións, a ruta por proxy non equivale a un túnel e a comparación debe facerse de forma explícita.

Demostre o resultado desde dentro do convidado

Separe resolución de encamiñamento con dúas probas na mesma sesión. Un nome que falla mentres o enderezo numérico responde é un problema de instantánea de DNS, e a solución é a orde ou un resolutor explícito. Se fallan ambos, apunta a encamiñamento ou política, e a seguinte comprobación é se a aplicación corre nun perfil de traballo coas súas propias restricións de rede.

Por último, saiba en que convidado proba. Imaxes moi antigas do emulador distribuíronse sen o soporte tun que necesita un cliente VPN do lado do convidado, así que ningún perfil podía funcionar alí; as imaxes actuais inclúeno. Un cliente que falla nunha imaxe actual é un problema de cliente ou de perfil, e reconstruír o túnel do host non cambiará o resultado.