VPN en el host o cliente dentro de Genymotion: decida quién posee el túnel

Una VPN de escritorio afecta a Genymotion en dos lugares, y arreglar uno no demuestra nada sobre el otro. El primero es la conexión que usa la aplicación de escritorio para controlar el dispositivo virtual; el segundo es la ruta de la aplicación Android virtual hacia un servicio privado. Decida cuál de los dos está cambiando realmente antes de tocar un adaptador y, después, anote la versión de Genymotion Desktop, el sistema operativo anfitrión y el hipervisor, porque las indicaciones escritas para un adaptador host-only de VirtualBox no se trasladan a un dispositivo QEMU ni a una sesión alojada en la nube.

Dos rutas en una misma máquina

La ruta de control va de la aplicación de escritorio de Genymotion al dispositivo virtual, a menudo por una red host-only. La ruta de la aplicación va desde dentro de Android hacia lo que sea con lo que habla la aplicación. Una VPN en el host puede llevar la segunda y romper la primera, y por eso un navegador que funciona en el escritorio dice muy poco. Un túnel puede servir ambas rutas o solo una, y esa disposición es una decisión, no un accidente.

Anote qué ruta está diagnosticando. La mayor parte de las horas perdidas en este terreno viene de cambiar el DNS de la aplicación privada cuando el dispositivo nunca se inició, o de relajar la VPN del host cuando la aplicación simplemente tenía el resolutor equivocado.

Mantenga viva la conexión de control

La propia nota de soporte de Genymotion Desktop documenta un caso de VirtualBox: una vez que la VPN del host está activa, Desktop ya no ve el dispositivo virtual, y la excepción que importa es el adaptador host-only real listado en el administrador de red de VirtualBox. Enumere esos adaptadores en lugar de adivinar un rango:

VBoxManage list hostonlyifs

Un rango predeterminado impreso en la documentación no es excusa para una exención total de la red privada en cada máquina. Añada la excepción más pequeña que cubra el adaptador en uso y haga que el administrador de la VPN la apruebe, porque un cliente gestionado puede bloquear la red local a propósito. Anote la excepción con el nombre del adaptador y la fecha de aprobación. Seis meses después, esa nota es lo único que explica por qué existe la regla.

La misma nota dice que la combinación con QEMU no se ha probado con VPN. Trátelo como una limitación de compatibilidad y no como una pista de que pasar a red bridged lo arreglará; cambiar el adaptador cambia el fallo, pero no resuelve la combinación no probada.

Opción A: deje que el host lleve el tráfico

Con esta elección, los paquetes del invitado deben llegar a una interfaz que la VPN permita y cifre a la vez. Es una cuestión de enrutamiento, no de luz de estado: los paquetes del invitado deben llegar a una interfaz que la VPN cifrará, y las respuestas deben encontrar el camino de vuelta.

Un navegador en el host demuestra la ruta del host y nada sobre si se acepta un origen de dispositivo virtual. Algunos clientes VPN tratan el tráfico reenviado o traducido de forma distinta al tráfico generado localmente, así que pruebe desde dentro de Android antes de concluir que el túnel funciona. El resolutor de Android tampoco es el del host. Si los nombres se resuelven en el escritorio y fallan en la aplicación, lea la configuración del resolutor del invitado antes de tocar el perfil de la VPN.

Opción B: ejecute un cliente compatible dentro de Android

Aquí el invitado tiene su propio perfil, credenciales, rutas y política de resolutor. Las API VPN normales de Android no necesitan acceso root, así que un cliente estándar se instala y se conecta dentro del dispositivo virtual. La aprobación es la parte que la gente se salta. La organización debe permitir ese cliente y ese entorno de dispositivo virtual, y una importación limpia no cumple por sí sola las comprobaciones de registro del dispositivo ni de postura. Pregunte antes de construir un flujo de trabajo alrededor de esto.

Las dos opciones también pueden apilarse: un túnel dentro de Android puede llegar a su servidor a través de un túnel que ya se ejecuta en el host. Esa disposición necesita un extremo alcanzable y un reenvío que usted haya permitido de verdad, no dos luces verdes que casualmente están encendidas a la vez.

Verifique desde la aplicación y anote la disposición

Use la misma aplicación Android en cada prueba y lea lo que informa: si la dirección responde, si el nombre privado se resuelve y qué devuelve la aplicación. Tres observaciones separan un fallo de enrutamiento de un fallo de resolutor y de un rechazo por política.

Cuando el dispositivo no arranca, o Desktop lo pierde, trátelo como un fallo de la ruta de control y no como un fallo de DNS. Ese síntoma pertenece a la primera ruta, y el arreglo está en el host, no dentro de Android. Termine anotando cuatro hechos: versión de Genymotion Desktop, hipervisor, qué lado posee el túnel y la excepción host-only exacta si se añadió alguna. Elija una disposición documentada que el propietario de la red respalde, y no trate desactivar una VPN corporativa o debilitar las comprobaciones de postura como un diagnóstico neutro cuando el servicio privado depende de ellas.