VPN a l’amfitrió o un client dins de Genymotion: decidiu qui posseeix el túnel

Una VPN d’escriptori afecta Genymotion en dos llocs, i arreglar-ne un no demostra res sobre l’altre. El primer és la connexió que l’aplicació d’escriptori fa servir per controlar el dispositiu virtual; el segon és el camí de l’aplicació Android virtual cap a un servei privat. Decidiu quin dels dos canvieu realment abans de tocar cap adaptador, i després anoteu la versió de Genymotion Desktop, el sistema operatiu amfitrió i l’hipervisor, perquè les indicacions escrites per a un adaptador host-only de VirtualBox no es traslladen a un dispositiu QEMU ni a una sessió allotjada al núvol.

Dos camins en una sola màquina

El camí de control va de l’aplicació d’escriptori Genymotion al dispositiu virtual, sovint per una xarxa host-only. El camí de l’aplicació va des de dins d’Android cap al que sigui amb què parla l’aplicació. Una VPN a l’amfitrió pot portar el segon i trencar el primer, i per això un navegador que funciona a l’escriptori diu molt poc. Un túnel pot servir tots dos camins o només un, i aquesta disposició és una decisió, no un accident.

Anoteu quin camí esteu diagnosticant. La major part de les hores perdudes en aquest àmbit ve de canviar el DNS de l’aplicació privada quan el dispositiu no s’havia iniciat mai, o d’afluixar la VPN de l’amfitrió quan l’aplicació simplement tenia el resolutor equivocat.

Manteniu viva la connexió de control

La nota de suport del mateix Genymotion Desktop documenta un cas de VirtualBox: un cop la VPN de l’amfitrió és activa, Desktop ja no veu el dispositiu virtual, i l’excepció que importa és l’adaptador host-only real llistat al gestor de xarxa de VirtualBox. Enumereu aquests adaptadors en lloc d’endevinar un rang:

VBoxManage list hostonlyifs

Un rang per defecte imprès a la documentació no és excusa per a una exempció total de la xarxa privada a cada màquina. Afegiu l’excepció més petita que cobreixi l’adaptador en ús i feu que l’administrador de la VPN l’aprovi, perquè un client gestionat pot bloquejar la xarxa local a propòsit. Anoteu l’excepció amb el nom de l’adaptador i la data d’aprovació. Sis mesos després, aquesta nota és l’única cosa que explica per què existeix la regla.

La mateixa nota diu que la combinació amb QEMU no s’ha provat amb VPN. Tracteu-ho com una limitació de compatibilitat i no com un indici que passar a xarxa bridged ho arreglarà; canviar l’adaptador canvia la fallada, però no resol la combinació no provada.

Opció A: deixeu que l’amfitrió porti el trànsit

Amb aquesta tria, els paquets del convidat han d’arribar a una interfície que la VPN permeti i xifri alhora. És una qüestió d’encaminament, no de llum d’estat: els paquets del convidat han d’arribar a una interfície que la VPN xifrarà, i les respostes han de trobar el camí de tornada.

Un navegador a l’amfitrió demostra el camí de l’amfitrió i res sobre si s’accepta una font de dispositiu virtual. Alguns clients VPN tracten el trànsit reenviat o traduït de manera diferent del trànsit generat localment, així que proveu des de dins d’Android abans de concloure que el túnel funciona. El resolutor d’Android tampoc no és el de l’amfitrió. Si els noms es resolen a l’escriptori i fallen a l’aplicació, llegiu la configuració del resolutor del convidat abans de tocar el perfil de la VPN.

Opció B: executeu un client compatible dins d’Android

Aquí el convidat té el seu propi perfil, credencials, rutes i política de resolutor. Les API VPN normals d’Android no necessiten accés root, així que un client estàndard s’instal·la i es connecta dins del dispositiu virtual. L’aprovació és la part que la gent s’estalvia. L’organització ha de permetre aquell client i aquell entorn de dispositiu virtual, i una importació neta no compleix per si sola les comprovacions d’enregistrament del dispositiu ni de postura. Pregunteu-ho abans de construir-hi un flux de treball.

Les dues tries també es poden apilar: un túnel dins d’Android pot arribar al seu servidor a través d’un túnel que ja corre a l’amfitrió. Aquesta disposició necessita un extrem abastable i un reenviament que hàgiu permès de veritat, no dos llums verds que casualment estan encesos alhora.

Verifiqueu-ho des de l’aplicació i anoteu la disposició

Feu servir la mateixa aplicació Android a cada prova i llegiu què informa: si l’adreça respon, si el nom privat es resol i què retorna l’aplicació. Tres observacions separen una fallada d’encaminament d’una fallada de resolutor i d’un rebuig per política.

Quan el dispositiu no s’inicia, o Desktop el perd, tracteu-ho com una fallada del camí de control i no com una fallada de DNS. Aquest símptoma pertany al primer camí, i l’arranjament és a l’amfitrió, no dins d’Android. Acabeu anotant quatre fets: versió de Genymotion Desktop, hipervisor, quin costat posseeix el túnel i l’excepció host-only exacta si se n’ha afegit una. Trieu una disposició documentada que el propietari de la xarxa doni suport, i no tracteu desactivar una VPN corporativa o afeblir les comprovacions de postura com un diagnòstic neutral quan el servei privat hi depèn.