VPN no host ou cliente dentro de Genymotion: decida quen posúe o túnel

Unha VPN de escritorio afecta Genymotion en dous lugares, e arranxar un non demostra nada sobre o outro. O primeiro é a conexión que usa a aplicación de escritorio para controlar o dispositivo virtual; o segundo é o camiño da aplicación Android virtual cara a un servizo privado. Decida cal dos dous está a cambiar realmente antes de tocar un adaptador e, despois, anote a versión de Genymotion Desktop, o sistema operativo anfitrión e o hipervisor, porque as indicacións escritas para un adaptador host-only de VirtualBox non se trasladan a un dispositivo QEMU nin a unha sesión aloxada na nube.

Dous camiños nunha mesma máquina

O camiño de control vai da aplicación de escritorio de Genymotion ao dispositivo virtual, a miúdo por unha rede host-only. O camiño da aplicación vai desde dentro de Android cara ao que sexa co que fala a aplicación. Unha VPN no host pode levar a segunda e romper a primeira, e por iso un navegador que funciona no escritorio di moi pouco. Un túnel pode servir ambos os camiños ou só un, e esa disposición é unha decisión, non un accidente.

Anote que camiño está a diagnosticar. A maior parte das horas perdidas neste terreo vén de cambiar o DNS da aplicación privada cando o dispositivo nunca se iniciou, ou de relaxar a VPN do host cando a aplicación simplemente tiña o resolutor equivocado.

Manteña viva a conexión de control

A propia nota de soporte de Genymotion Desktop documenta un caso de VirtualBox: unha vez que a VPN do host está activa, Desktop xa non ve o dispositivo virtual, e a excepción que importa é o adaptador host-only real listado no xestor de rede de VirtualBox. Enumere eses adaptadores en lugar de adiviñar un rango:

VBoxManage list hostonlyifs

Un rango predeterminado impreso na documentación non é escusa para unha exención total da rede privada en cada máquina. Engada a excepción máis pequena que cubra o adaptador en uso e faga que o administrador da VPN a aprobe, porque un cliente xestionado pode bloquear a rede local a propósito. Anote a excepción co nome do adaptador e a data de aprobación. Seis meses despois, esa nota é o único que explica por que existe a regra.

A mesma nota di que a combinación con QEMU non se probou con VPN. Tráteo como unha limitación de compatibilidade e non como unha pista de que pasar a rede bridged o arranxará; cambiar o adaptador cambia o fallo, pero non resolve a combinación non probada.

Opción A: deixe que o host leve o tráfico

Con esta elección, os paquetes do convidado deben chegar a unha interface que a VPN permita e cifre á vez. É unha cuestión de encamiñamento, non de luz de estado: os paquetes do convidado deben chegar a unha interface que a VPN cifrará, e as respostas deben atopar o camiño de volta.

Un navegador no host demostra o camiño do host e nada sobre se se acepta unha orixe de dispositivo virtual. Algúns clientes VPN tratan o tráfico reenviado ou traducido de forma distinta ao tráfico xerado localmente, así que probe desde dentro de Android antes de concluír que o túnel funciona. O resolutor de Android tampouco é o do host. Se os nomes se resolven no escritorio e fallan na aplicación, lea a configuración do resolutor do convidado antes de tocar o perfil da VPN.

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

Aquí o convidado ten o seu propio perfil, credenciais, rutas e política de resolutor. As API VPN normais de Android non necesitan acceso root, así que un cliente estándar instálase e conéctase dentro do dispositivo virtual. A aprobación é a parte que a xente salta. A organización debe permitir ese cliente e ese contorno de dispositivo virtual, e unha importación limpa non cumpre por si soa as comprobacións de rexistro do dispositivo nin de postura. Pregunte antes de construír un fluxo de traballo arredor disto.

As dúas opcións tamén se poden apilar: un túnel dentro de Android pode chegar ao seu servidor a través dun túnel que xa se executa no host. Esa disposición necesita un extremo alcanzable e un reenvío que vostede permitise de verdade, non dúas luces verdes que casualmente están acendidas á vez.

Verifique desde a aplicación e anote a disposición

Use a mesma aplicación Android en cada proba e lea o que informa: se o enderezo responde, se o nome privado se resolve e que devolve a aplicación. Tres observacións separan un fallo de encamiñamento dun fallo de resolutor e dun rexeitamento por política.

Cando o dispositivo non arrinca, ou Desktop o perde, tráteo como un fallo do camiño de control e non como un fallo de DNS. Ese síntoma pertence ao primeiro camiño, e o arranxo está no host, non dentro de Android. Remate anotando catro feitos: versión de Genymotion Desktop, hipervisor, que lado posúe o túnel e a excepción host-only exacta se se engadiu algunha. Escolla unha disposición documentada que o propietario da rede admita, e non trate desactivar unha VPN corporativa ou debilitar as comprobacións de postura como un diagnóstico neutro cando o servizo privado depende delas.