VPN no host ou cliente dentro do Genymotion: decida quem possui o túnel

Uma VPN de desktop afeta o Genymotion em dois pontos, e corrigir um não prova nada sobre o outro. O primeiro é a ligação que a aplicação de desktop usa para controlar o dispositivo virtual; o segundo é o caminho da aplicação Android virtual até um serviço privado. Decida qual dos dois está realmente a mudar antes de tocar num adaptador e, depois, registe a versão do Genymotion Desktop, o sistema operativo anfitrião e o hipervisor, porque as indicações escritas para um adaptador host-only do VirtualBox não se transferem para um dispositivo QEMU nem para uma sessão alojada na nuvem.

Dois caminhos numa só máquina

O caminho de controle vai da aplicação de desktop do Genymotion ao dispositivo virtual, muitas vezes através de uma rede host-only. O caminho da aplicação vai de dentro do Android para aquilo com que a aplicação fala. Uma VPN no host pode levar o segundo e quebrar o primeiro, e é por isso que um navegador que funciona no desktop prova muito pouco. Um único túnel pode servir os dois caminhos ou apenas um, e essa disposição é uma decisão, não um acidente.

Registe qual caminho está a diagnosticar. A maior parte das horas perdidas nesta área vem de alterar o DNS da aplicação privada quando o dispositivo nunca arrancou, ou de afrouxar a VPN do host quando a aplicação tinha simplesmente o resolvedor errado.

Mantenha a ligação de controlo viva

A própria nota de suporte do Genymotion Desktop documenta um caso de VirtualBox: assim que uma VPN no host está ativa, o Desktop deixa de ver o dispositivo virtual, e a exceção que importa é o adaptador host-only real listado no gestor de rede do VirtualBox. Enumere esses adaptadores em vez de adivinhar um intervalo:

VBoxManage list hostonlyifs

Um intervalo predefinido impresso na documentação não é desculpa para uma isenção total da rede privada em cada máquina. Acrescente a exceção mais pequena que cubra o adaptador em uso e faça com que o administrador da VPN a aprove, porque um cliente gerido pode bloquear a rede local de propósito. Registe a exceção com o nome do adaptador e a data de aprovação. Seis meses depois, essa nota é a única coisa que explica por que a regra existe.

A mesma nota diz que a combinação com QEMU não foi testada com VPN. Trate isso como uma limitação de compatibilidade e não como a pista de que passar para rede bridged a vai reparar; mudar o adaptador muda a falha, mas não resolve a combinação não testada.

Opção A: deixe o host levar o tráfego

Com esta escolha, os pacotes do convidado têm de chegar a uma interface que a VPN permita e cifre ao mesmo tempo. É uma questão de encaminhamento, não de luz de estado: os pacotes do convidado têm de chegar a uma interface que a VPN vai cifrar, e as respostas têm de encontrar o caminho de volta.

Um navegador no host prova o caminho do host e nada sobre se uma origem de dispositivo virtual é aceite. Alguns clientes VPN tratam o tráfego reencaminhado ou traduzido de forma diferente do tráfego gerado localmente, por isso teste de dentro do Android antes de concluir que o túnel funciona. O resolvedor do Android também não é o do host. Se os nomes se resolvem no desktop e falham na aplicação, leia a configuração do resolvedor do convidado antes de tocar no perfil da VPN.

Opção B: execute um cliente suportado dentro do Android

Aqui o convidado tem o seu próprio perfil, credenciais, rotas e política de resolvedor. As interfaces VPN normais do Android não exigem acesso root, por isso um cliente padrão instala-se e liga-se dentro do dispositivo virtual. A aprovação é a parte que as pessoas saltam. A organização tem de permitir esse cliente e esse ambiente de dispositivo virtual, e uma importação limpa não cumpre por si só as verificações de registo do dispositivo nem de postura. Pergunte antes de construir um fluxo de trabalho à volta disto.

As duas escolhas também podem empilhar-se: um túnel dentro do Android pode chegar ao seu servidor através de um túnel que já corre no host. Essa disposição precisa de um extremo alcançável e de um reencaminhamento que tenha realmente permitido, não de duas luzes verdes que por acaso estão acesas ao mesmo tempo.

Verifique a partir da aplicação e registe a disposição

Use a mesma aplicação Android em cada teste e leia o que ela relata: se o endereço responde, se o nome privado se resolve e o que a aplicação devolve. Três observações separam uma falha de encaminhamento de uma falha de resolvedor e de uma rejeição por política.

Quando o dispositivo não arranca, ou o Desktop o perde, trate isso como uma falha do caminho de controlo e não como uma falha de DNS. Esse sintoma pertence ao primeiro caminho, e a correção está no host, não dentro do Android. Termine registando quatro factos: versão do Genymotion Desktop, hipervisor, que lado possui o túnel e a exceção host-only exata se alguma foi adicionada. Escolha uma disposição documentada que o proprietário da rede apoie, e não trate desativar uma VPN empresarial ou enfraquecer as verificações de postura como um diagnóstico neutro quando o serviço privado depende delas.