VPN på værten eller en klient inde i Genymotion: afgør, hvem der ejer tunnelen

En desktop-VPN påvirker Genymotion to steder, og at rette det ene beviser intet om det andet. Det første er den forbindelse, desktop-appen bruger til at styre den virtuelle enhed; det andet er den virtuelle Android-apps vej til en privat tjeneste. Afgør, hvilken af dem du faktisk ændrer, før du rører en adapter, og notér derefter Genymotion Desktop-versionen, værtens styresystem og hypervisoren, fordi vejledning skrevet til en VirtualBox host-only-adapter ikke overføres til en QEMU-enhed eller til en session hostet i skyen.

To veje på én maskine

Kontrolvejen løber fra Genymotion-desktopapplikationen til den virtuelle enhed, ofte over et host-only-netværk. Appvejen løber inde fra Android ud til det, appen taler med. En vært-VPN kan bære den anden og bryde den første, og derfor betyder en fungerende browser på skrivebordet meget lidt. Én tunnel kan betjene begge veje eller kun én af dem, og det arrangement er en beslutning, ikke et tilfælde.

Skriv ned, hvilken vej du fejlfinder. De fleste spildte timer på dette område kommer fra at ændre den private apps DNS, når enheden aldrig startede, eller fra at lempe vært-VPN’en, når appen blot havde den forkerte resolver.

Hold kontrolforbindelsen i live

Genymotions egen Desktop-supportnote dokumenterer et VirtualBox-tilfælde: når en vært-VPN er oppe, kan Desktop ikke længere se den virtuelle enhed, og den undtagelse, der betyder noget, er den rigtige host-only-adapter, der er opført i VirtualBox’ netværksadministrator. List de adaptere i stedet for at gætte et område:

VBoxManage list hostonlyifs

Et standardområde trykt i dokumentationen er ingen undskyldning for en generel omgåelse af det private netværk på hver maskine. Tilføj den mindste undtagelse, der dækker den adapter, der bruges, og få VPN-administratoren til at godkende den, fordi en administreret klient kan blokere det lokale netværk med vilje. Skriv undtagelsen ned med adapternavn og godkendelsesdato. Seks måneder senere er den note det eneste, der forklarer, hvorfor reglen findes.

Den samme note siger, at QEMU-kombinationen ikke er testet med VPN. Behandl det som en kompatibilitetsbegrænsning snarere end et vink om, at skift til bridged-netværk vil reparere det; at skifte adapter ændrer fejlen, det løser ikke den utestede kombination.

Mulighed A: lad værten bære trafikken

Med dette valg skal gæstens pakker nå en grænseflade, som VPN’en både tillader og krypterer. Det er et routing-spørgsmål, ikke et statuslys-spørgsmål: gæstens pakker skal nå en grænseflade, som VPN’en vil kryptere, og svarene skal finde vej tilbage.

En browser på værten beviser værtens vej og intet om, hvorvidt en kilde fra en virtuel enhed accepteres. Nogle VPN-klienter behandler videresendt eller oversat trafik anderledes end lokalt genereret trafik, så test inde fra Android, før du konkluderer, at tunnelen virker. Androids resolver er heller ikke værtens resolver. Hvis navne opløses på skrivebordet og fejler i appen, så læs gæstens resolver-konfiguration, før du rører VPN-profilen.

Mulighed B: kør en understøttet klient inde i Android

Her har gæsten sin egen profil, sine egne legitimationsoplysninger, ruter og resolverpolitik. De almindelige Android VPN-API’er kræver ingen root-adgang, så en standardklient installeres og forbindes inde i den virtuelle enhed. Godkendelse er den del, folk springer over. Organisationen skal tillade den klient og det virtuelle enhedsmiljø, og en ren import opfylder ikke i sig selv enhedsregistrering eller posture-kontroller. Spørg, før du bygger en arbejdsgang omkring det.

De to valg kan også stable: en tunnel inde i Android kan nå sin server gennem en tunnel, der allerede kører på værten. Det arrangement kræver et tilgængeligt endepunkt og videresendelse, som du faktisk har tilladt, ikke to grønne lys, der tilfældigvis er tændt samtidig.

Verificér fra appen, og skriv arrangementet ned

Brug den samme Android-app til hver test, og læs, hvad den rapporterer: om adressen svarer, om det private navn opløses, og hvad applikationen returnerer. Tre observationer adskiller en routingfejl fra en resolverfejl fra en politikafvisning.

Når enheden ikke starter, eller Desktop mister den, så behandl det som en fejl i kontrolvejen snarere end en DNS-fejl. Det symptom hører til den første vej, og rettelsen er på værten, ikke inde i Android. Afslut med at notere fire fakta: Genymotion Desktop-version, hypervisor, hvilken side der ejer tunnelen, og den præcise host-only-undtagelse, hvis en blev tilføjet. Vælg et dokumenteret arrangement, som netværksejeren støtter, og behandl ikke deaktivering af en virksomheds-VPN eller svækkelse af posture-kontroller som neutral fejlfinding, når den private tjeneste afhænger af dem.