VPN sur l’hôte ou client dans Genymotion : décidez qui possède le tunnel

Un VPN de bureau affecte Genymotion à deux endroits, et corriger l’un ne prouve rien sur l’autre. Le premier est la connexion que l’application de bureau utilise pour contrôler l’appareil virtuel ; le second est le chemin de l’application Android virtuelle vers un service privé. Décidez lequel des deux vous modifiez réellement avant de toucher un adaptateur, puis notez la version de Genymotion Desktop, le système d’exploitation hôte et l’hyperviseur, car des consignes écrites pour un adaptateur host-only de VirtualBox ne se transposent ni à un appareil QEMU ni à une session hébergée dans le cloud.

Deux chemins sur une même machine

Le chemin de contrôle va de l’application de bureau Genymotion à l’appareil virtuel, souvent par un réseau host-only. Le chemin de l’application va de l’intérieur d’Android vers ce avec quoi l’application parle. Un VPN sur l’hôte peut porter le second et casser le premier, et c’est pourquoi un navigateur qui fonctionne sur le bureau ne prouve presque rien. Un seul tunnel peut servir les deux chemins ou un seul, et cette disposition est une décision, pas un accident.

Notez quel chemin vous diagnostiquez. La plupart des heures perdues dans ce domaine viennent du changement du DNS de l’application privée alors que l’appareil ne s’est jamais lancé, ou du relâchement du VPN de l’hôte alors que l’application avait simplement le mauvais résolveur.

Gardez la connexion de contrôle en vie

La note d’assistance de Genymotion Desktop documente un cas VirtualBox : une fois le VPN de l’hôte actif, Desktop ne voit plus l’appareil virtuel, et l’exception qui compte est le véritable adaptateur host-only répertorié dans le gestionnaire de réseau de VirtualBox. Énumérez ces adaptateurs au lieu de deviner une plage :

VBoxManage list hostonlyifs

Une plage par défaut imprimée dans la documentation n’excuse pas un contournement global du réseau privé sur chaque machine. Ajoutez la plus petite exception qui couvre l’adaptateur utilisé, et faites-la approuver par l’administrateur du VPN, car un client géré peut bloquer le réseau local à dessein. Notez l’exception avec le nom de l’adaptateur et la date d’approbation. Six mois plus tard, cette note est la seule chose qui explique pourquoi la règle existe.

La même note indique que la combinaison avec QEMU n’est pas testée avec un VPN. Traitez cela comme une limite de compatibilité et non comme l’indice que passer à un réseau bridged la réparera ; changer d’adaptateur change la panne, mais ne résout pas la combinaison non testée.

Option A : laissez l’hôte porter le trafic

Avec ce choix, les paquets de l’invité doivent arriver sur une interface que le VPN autorise et chiffre à la fois. C’est une question de routage, pas de voyant d’état : les paquets de l’invité doivent arriver sur une interface que le VPN chiffrera, et les réponses doivent retrouver le chemin du retour.

Un navigateur sur l’hôte prouve le chemin de l’hôte et rien sur l’acceptation d’une source d’appareil virtuel. Certains clients VPN traitent le trafic transféré ou traduit différemment du trafic généré localement, alors testez depuis l’intérieur d’Android avant de conclure que le tunnel fonctionne. Le résolveur d’Android n’est pas non plus celui de l’hôte. Si les noms se résolvent sur le bureau et échouent dans l’application, lisez la configuration du résolveur de l’invité avant de toucher au profil VPN.

Option B : exécutez un client pris en charge dans Android

Ici, l’invité détient son propre profil, ses identifiants, ses routes et sa politique de résolveur. Les API VPN ordinaires d’Android n’exigent aucun accès root, donc un client standard s’installe et se connecte dans l’appareil virtuel. L’approbation est la partie que les gens sautent. L’organisation doit autoriser ce client et cet environnement d’appareil virtuel, et une importation propre ne satisfait pas à elle seule les contrôles d’enregistrement de l’appareil ni de posture. Demandez avant de bâtir un flux de travail autour de cela.

Les deux choix peuvent aussi se superposer : un tunnel dans Android peut atteindre son serveur par un tunnel déjà actif sur l’hôte. Cette disposition exige un point de terminaison joignable et un transfert que vous avez réellement autorisé, pas deux voyants verts qui se trouvent allumés ensemble.

Vérifiez depuis l’application et notez la disposition

Utilisez la même application Android pour chaque test et lisez ce qu’elle rapporte : si l’adresse répond, si le nom privé se résout et ce que l’application renvoie. Trois observations séparent une panne de routage d’une panne de résolveur et d’un rejet de politique.

Quand l’appareil ne démarre pas, ou que Desktop le perd, traitez cela comme une panne du chemin de contrôle et non comme une panne DNS. Ce symptôme appartient au premier chemin, et le correctif se fait sur l’hôte, pas dans Android. Terminez en notant quatre faits : version de Genymotion Desktop, hyperviseur, quel côté possède le tunnel et l’exception host-only exacte si une a été ajoutée. Choisissez une disposition documentée que le propriétaire du réseau prend en charge, et ne traitez pas la désactivation d’un VPN d’entreprise ou l’affaiblissement des contrôles de posture comme un diagnostic neutre quand le service privé en dépend.