VPN op de host of een client binnen Genymotion: bepaal wie de tunnel bezit

Een desktop-VPN beïnvloedt Genymotion op twee plekken, en het ene repareren bewijst niets over het andere. Het eerste is de verbinding die de desktop-app gebruikt om het virtuele apparaat te besturen; het tweede is het pad van de virtuele Android-app naar een particuliere dienst. Bepaal welke van die twee u werkelijk wijzigt voordat u een adapter aanraakt, en noteer daarna de Genymotion Desktop-versie, het hostbesturingssysteem en de hypervisor, want richtlijnen die voor een VirtualBox host-only-adapter zijn geschreven, gaan niet over naar een QEMU-apparaat of naar een in de cloud gehoste sessie.

Twee paden op één machine

Het besturingspad loopt van de Genymotion-desktopapplicatie naar het virtuele apparaat, vaak via een host-only-netwerk. Het app-pad loopt van binnen Android naar alles waarmee de app praat. Een host-VPN kan het tweede dragen en het eerste breken, en daarom zegt een werkende browser op de desktop heel weinig. Eén tunnel kan beide paden dienen of slechts één, en die ordening is een beslissing, geen toeval.

Schrijf op welk pad u onderzoekt. De meeste verloren uren in dit gebied komen van het wijzigen van de DNS van de particuliere app terwijl het apparaat nooit is gestart, of van het versoepelen van de host-VPN terwijl de app gewoon de verkeerde resolver had.

Houd de besturingsverbinding in leven

Genymotions eigen Desktop-supportnotitie documenteert een VirtualBox-geval: zodra een host-VPN actief is, ziet Desktop het virtuele apparaat niet meer, en de uitzondering die ertoe doet is de echte host-only-adapter die in het netwerkbeheer van VirtualBox staat. Noem die adapters op in plaats van een bereik te raden:

VBoxManage list hostonlyifs

Een standaardbereik dat in documentatie is gedrukt, is geen excuus voor een algehele omzeiling van het particuliere netwerk op elke machine. Voeg de kleinste uitzondering toe die de gebruikte adapter dekt, en laat de VPN-beheerder die goedkeuren, want een beheerde client kan het lokale netwerk met opzet blokkeren. Schrijf de uitzondering op met de adaptornaam en de goedkeuringsdatum. Een half jaar later is die notitie het enige dat verklaart waarom de regel bestaat.

Dezelfde notitie zegt dat de QEMU-combinatie niet met een VPN is getest. Behandel dat als een compatibiliteitsbeperking en niet als een hint dat overstappen op bridged-netwerk het repareert; de adapter wijzigen verandert de fout, maar lost de ongeteste combinatie niet op.

Optie A: laat de host het verkeer dragen

Bij deze keuze moeten de pakketten van de gast aankomen op een interface die de VPN zowel toestaat als versleutelt. Dat is een routeringsvraag, geen statuslampvraag: de pakketten van de gast moeten aankomen op een interface die de VPN zal versleutelen, en de antwoorden moeten de weg terug vinden.

Een browser op de host bewijst het pad van de host en niets over de vraag of een bron van een virtueel apparaat wordt geaccepteerd. Sommige VPN-clients behandelen doorgestuurd of vertaald verkeer anders dan lokaal gegenereerd verkeer, dus test van binnen Android voordat u concludeert dat de tunnel werkt. Ook de resolver van Android is niet de resolver van de host. Als namen op de desktop worden opgelost en in de app mislukken, lees dan de resolverconfiguratie van de gast voordat u het VPN-profiel aanraakt.

Optie B: voer een ondersteunde client uit binnen Android

Hier heeft de gast zijn eigen profiel, inloggegevens, routes en resolverbeleid. De gewone Android-VPN-interfaces hebben geen root-toegang nodig, dus een standaardclient installeert en verbindt binnen het virtuele apparaat. Goedkeuring is het deel dat mensen overslaan. De organisatie moet die client en die virtuele-apparaatomgeving toestaan, en een schone import voldoet op zichzelf niet aan apparaatregistratie of posture-controles. Vraag het voordat u er een werkstroom omheen bouwt.

De twee keuzes kunnen ook stapelen: een tunnel binnen Android kan zijn server bereiken via een tunnel die al op de host draait. Zo'n ordening vraagt een bereikbaar eindpunt en doorsturing die u werkelijk hebt toegestaan, niet twee groene lampen die toevallig samen aan staan.

Verifieer vanuit de app en schrijf de ordening op

Gebruik dezelfde Android-app voor elke test en lees wat die rapporteert: of het adres antwoordt, of de particuliere naam wordt opgelost en wat de applicatie teruggeeft. Drie waarnemingen scheiden een routeringsfout van een resolverfout en van een beleidsafwijzing.

Wanneer het apparaat niet start, of Desktop het verliest, behandel dat als een fout in het besturingspad en niet als een DNS-fout. Dat symptoom hoort bij het eerste pad, en de oplossing zit op de host, niet in Android. Sluit af met vier feiten: Genymotion Desktop-versie, hypervisor, welke kant de tunnel bezit en de exacte host-only-uitzondering als er een is toegevoegd. Kies een gedocumenteerde ordening die de netwerkeigenaar ondersteunt, en behandel het uitschakelen van een bedrijfs-VPN of het verzwakken van posture-controles niet als neutraal foutonderzoek wanneer de particuliere dienst daarop leunt.