VPN på verten eller ein klient inne i Genymotion: avgjer kven som eig tunnelen

Ein desktop-VPN påverkar Genymotion på to stader, og å rette det eine beviser ingenting om det andre. Det første er sambandet desktop-appen brukar til å styre den virtuelle eininga; det andre er vegen til den virtuelle Android-appen til ei privat teneste. Avgjer kva av dei du faktisk endrar før du rører ein adapter, og noter deretter Genymotion Desktop-versjonen, operativsystemet til verten og hypervisoren, fordi rettleiing skriven for ein VirtualBox host-only-adapter ikkje flyttar over til ei QEMU-eining eller til ei økt som køyrer i skya.

To vegar på éin maskin

Kontrollvegen går frå Genymotion-skrivebordsapplikasjonen til den virtuelle eininga, ofte over eit host-only-nettverk. Appvegen går frå inne i Android og ut til det appen snakkar med. Ein vert-VPN kan bera den andre og bryte den første, og difor betyr ein nettlesar som verkar på skrivebordet svært lite. Éin tunnel kan tene begge vegane eller berre éin av dei, og den ordninga er eit vedtak, ikkje eit uhell.

Skriv ned kva veg du feilsøkjer. Dei fleste tapte timane på dette området kjem frå å endre DNS-en til den private appen når eininga aldri starta, eller frå å lempe på vert-VPN-en når appen berre hadde feil resolver.

Hald kontrollkoblinga i live

Genymotion sin eigen Desktop-støttenotat dokumenterer eit VirtualBox-tilfelle: når ein vert-VPN er oppe, ser ikkje Desktop den virtuelle eininga lenger, og unntaket som betyr noko, er den ekte host-only-adapteren som står i nettverkshandsamaren til VirtualBox. List opp dei adapterane i staden for å gjette eit område:

VBoxManage list hostonlyifs

Eit standardområde trykt i dokumentasjonen er inga unnskyldning for å omgå det private nettverket på kvar maskin. Legg til det minste unntaket som dekkjer adapteren som blir brukt, og få VPN-administratoren til å godkjenne det, fordi ein styrt klient kan blokkere det lokale nettverket med vilje. Skriv ned unntaket med adapternamn og godkjenningsdato. Eit halvt år seinare er den notata det einaste som forklarer kvifor regelen finst.

Den same notata seier at QEMU-kombinasjonen ikkje er testa med VPN. Handsame det som ei kompatibilitetsgrense og ikkje som eit hint om at byte til bridged-nettverk vil reparere det; å byte adapter endrar feilen, men løyser ikkje den utesta kombinasjonen.

Alternativ A: lat verten bera trafikken

Med dette valet må pakkane til gjesten nå eit grensesnitt som VPN-en både tillèt og krypterer. Det er eit rutingsspørsmål, ikkje eit statuslampespørsmål: pakkane til gjesten må nå eit grensesnitt som VPN-en vil kryptere, og svara må finne vegen tilbake.

Ein nettlesar på verten beviser vegen til verten og ingenting om ein godtek ei kjelde frå ei virtuell eining. Nokre VPN-klientar handsamar vidaresend eller omsett trafikk annleis enn lokalt generert trafikk, så test inne frå Android før du konkluderer med at tunnelen verkar. Resolveren til Android er heller ikkje resolveren til verten. Viss namn blir løyste på skrivebordet og feilar i appen, les resolverkonfigurasjonen til gjesten før du rører VPN-profilen.

Alternativ B: køyr ein støtta klient inne i Android

Her har gjesten sin eigen profil, sine eigne påloggingsdata, ruter og resolverpolitikk. Dei vanlege Android VPN-grensesnitta krev ingen root-tilgang, så ein standardklient blir installert og kopla til inne i den virtuelle eininga. Godkjenning er den delen folk hoppar over. Organisasjonen må tillate den klienten og det virtuelle einingsmiljøet, og ein rein import oppfyller ikkje i seg sjølv einingregistrering eller tilstandskontrollar. Spør før du byggjer ein arbeidsflyt rundt det.

Dei to vala kan også stable seg: ein tunnel inne i Android kan nå tenaren sin gjennom ein tunnel som allereie køyrer på verten. Ei slik ordning treng eit nåbart endepunkt og vidaresending du faktisk tillét, ikkje to grøne lys som tilfeldigvis er på samtidig.

Verifiser frå appen og skriv ned ordninga

Bruk den same Android-appen for kvar test og les kva han rapporterer: om adressa svarar, om det private namnet blir løyst og kva applikasjonen returnerer. Tre observasjonar skil ein rutingsfeil frå ein resolverfeil og frå ei policyavvising.

Når eininga ikkje startar, eller Desktop mistar henne, handsame det som ein feil i kontrollvegen og ikkje som ein DNS-feil. Det symptomet høyrer til den første vegen, og rettinga er på verten, ikkje inne i Android. Avslutt med å notere fire fakta: Genymotion Desktop-versjon, hypervisor, kva side som eig tunnelen og det nøyaktige host-only-unntaket viss eitt vart lagt til. Vel ei dokumentert ordning som netteigaren støttar, og ikkje handsame deaktivering av ein verksemds-VPN eller svekking av tilstandskontrollar som nøytral feilsøking når den private tenesta er avhengig av dei.