VPN sull’host o client dentro Genymotion: decidete chi possiede il tunnel

Una VPN desktop influenza Genymotion in due punti, e correggerne uno non dimostra nulla sull’altro. Il primo è la connessione che l’app desktop usa per controllare il dispositivo virtuale; il secondo è il percorso dell’app Android virtuale verso un servizio privato. Decidete quale dei due state davvero cambiando prima di toccare un adattatore, poi annotate la versione di Genymotion Desktop, il sistema operativo host e l’hypervisor, perché indicazioni scritte per un adattatore host-only di VirtualBox non si trasferiscono a un dispositivo QEMU né a una sessione ospitata nel cloud.

Due percorsi su una sola macchina

Il percorso di controllo va dall’applicazione desktop Genymotion al dispositivo virtuale, spesso su una rete host-only. Il percorso dell’applicazione va dall’interno di Android verso qualunque cosa con cui l’app parla. Una VPN sull’host può portare il secondo e rompere il primo, ed è per questo che un browser che funziona sul desktop dimostra molto poco. Un solo tunnel può servire entrambi i percorsi o solo uno, e questa disposizione è una decisione, non un caso.

Annotate quale percorso state diagnosticando. La maggior parte delle ore perse in questo campo viene dal cambiare il DNS dell’app privata quando il dispositivo non si era mai avviato, o dall’allentare la VPN dell’host quando l’app aveva semplicemente il resolver sbagliato.

Mantenete vivo il collegamento di controllo

La nota di supporto di Genymotion Desktop documenta un caso VirtualBox: una volta attiva la VPN sull’host, Desktop non vede più il dispositivo virtuale, e l’eccezione che conta è il vero adattatore host-only elencato nel gestore di rete di VirtualBox. Elencate quegli adattatori invece di indovinare un intervallo:

VBoxManage list hostonlyifs

Un intervallo predefinito stampato nella documentazione non è una scusa per aggirare in blocco la rete privata su ogni macchina. Aggiungete l’eccezione più piccola che copre l’adattatore in uso e fatela approvare dall’amministratore della VPN, perché un client gestito può bloccare la rete locale di proposito. Annotate l’eccezione con il nome dell’adattatore e la data di approvazione. Sei mesi dopo quella nota è l’unica cosa che spiega perché la regola esiste.

La stessa nota dice che la combinazione con QEMU non è stata provata con una VPN. Trattatela come un limite di compatibilità e non come l’indizio che passare a una rete bridged la riparerà; cambiare adattatore cambia il guasto, ma non risolve la combinazione non provata.

Opzione A: lasciate che l’host porti il traffico

Con questa scelta i pacchetti dell’ospite devono arrivare a un’interfaccia che la VPN permette e cifra insieme. È una questione di routing, non di spia di stato: i pacchetti dell’ospite devono arrivare a un’interfaccia che la VPN cifrerà, e le risposte devono trovare la via del ritorno.

Un browser sull’host dimostra il percorso dell’host e nulla sull’accettazione di una sorgente da dispositivo virtuale. Alcuni client VPN trattano il traffico inoltrato o tradotto in modo diverso dal traffico generato localmente, quindi provate dall’interno di Android prima di concludere che il tunnel funziona. Anche il resolver di Android non è quello dell’host. Se i nomi si risolvono sul desktop e falliscono nell’app, leggete la configurazione del resolver dell’ospite prima di toccare il profilo VPN.

Opzione B: eseguite un client supportato dentro Android

Qui l’ospite tiene il proprio profilo, le credenziali, le rotte e la politica del resolver. Le normali API VPN di Android non richiedono accesso root, quindi un client standard si installa e si connette dentro il dispositivo virtuale. L’approvazione è la parte che le persone saltano. L’organizzazione deve consentire quel client e quell’ambiente di dispositivo virtuale, e un’importazione pulita non soddisfa da sola i controlli di registrazione del dispositivo né di postura. Chiedete prima di costruirci sopra un flusso di lavoro.

Le due scelte possono anche impilarsi: un tunnel dentro Android può raggiungere il suo server attraverso un tunnel già in esecuzione sull’host. Una tale disposizione richiede un endpoint raggiungibile e un inoltro che avete davvero consentito, non due luci verdi che per caso sono accese insieme.

Verificate dall’app e annotate la disposizione

Usate la stessa app Android per ogni prova e leggete che cosa riporta: se l’indirizzo risponde, se il nome privato si risolve e che cosa restituisce l’applicazione. Tre osservazioni separano un guasto di routing da un guasto del resolver e da un rifiuto di politica.

Quando il dispositivo non si avvia, o Desktop lo perde, trattatelo come un guasto del percorso di controllo e non come un guasto DNS. Quel sintomo appartiene al primo percorso, e la correzione è sull’host, non dentro Android. Chiudete annotando quattro fatti: versione di Genymotion Desktop, hypervisor, quale lato possiede il tunnel e l’esatta eccezione host-only se ne è stata aggiunta una. Scegliete una disposizione documentata che il proprietario della rete sostiene, e non trattate la disattivazione di una VPN aziendale o l’indebolimento dei controlli di postura come diagnosi neutrale quando il servizio privato vi si affida.