VPN på verten eller en klient inne i Genymotion: avgjør hvem som eier tunnelen

En desktop-VPN påvirker Genymotion på to steder, og å rette det ene beviser ingenting om det andre. Det første er forbindelsen desktop-appen bruker til å styre den virtuelle enheten; det andre er den virtuelle Android-appens vei til en privat tjeneste. Avgjør hvilken av dem du faktisk endrer før du rører en adapter, og noter deretter Genymotion Desktop-versjonen, vertens operativsystem og hypervisoren, fordi veiledning skrevet for en VirtualBox host-only-adapter ikke overføres til en QEMU-enhet eller til en økt som kjøres i skyen.

To veier på én maskin

Kontrollveien går fra Genymotion-desktopapplikasjonen til den virtuelle enheten, ofte over et host-only-nettverk. Appveien går fra inne i Android og ut til det appen snakker med. En vert-VPN kan bære den andre og bryte den første, og derfor betyr en nettleser som virker på skrivebordet svært lite. Én tunnel kan betjene begge veiene eller bare én av dem, og den ordningen er en beslutning, ikke et uhell.

Skriv ned hvilken vei du feilsøker. De fleste tapte timene på dette området kommer fra å endre DNS-en til den private appen når enheten aldri startet, eller fra å lempe på vert-VPN-en når appen bare hadde feil resolver.

Hold kontrollkoblingen i live

Genymotions egen Desktop-støttenotat dokumenterer et VirtualBox-tilfelle: når en vert-VPN er oppe, ser ikke Desktop den virtuelle enheten lenger, og unntaket som betyr noe, er den ekte host-only-adapteren som står i VirtualBox’ nettverksbehandler. List opp de adapterne i stedet for å gjette et område:

VBoxManage list hostonlyifs

Et standardområde trykt i dokumentasjonen er ingen unnskyldning for å omgå det private nettverket på hver maskin. Legg til det minste unntaket som dekker adapteren som brukes, og få VPN-administratoren til å godkjenne det, fordi en administrert klient kan blokkere det lokale nettverket med vilje. Skriv ned unntaket med adapternavn og godkjenningsdato. Et halvt år senere er den noten det eneste som forklarer hvorfor regelen finnes.

Den samme noten sier at QEMU-kombinasjonen ikke er testet med VPN. Behandle det som en kompatibilitetsbegrensning og ikke som et hint om at bytte til bridged-nettverk vil reparere det; å bytte adapter endrer feilen, men løser ikke den utestede kombinasjonen.

Alternativ A: la verten bære trafikken

Med dette valget må gjestens pakker nå et grensesnitt som VPN-en både tillater og krypterer. Det er et rutingspørsmål, ikke et statuslysspørsmål: gjestens pakker må nå et grensesnitt som VPN-en vil kryptere, og svarene må finne veien tilbake.

En nettleser på verten beviser vertens vei og ingenting om hvorvidt en kilde fra en virtuell enhet godtas. Noen VPN-klienter behandler videresendt eller oversatt trafikk annerledes enn lokalt generert trafikk, så test inne fra Android før du konkluderer med at tunnelen virker. Android sin resolver er heller ikke vertens resolver. Hvis navn løses på skrivebordet og feiler i appen, les gjestens resolverkonfigurasjon før du rører VPN-profilen.

Alternativ B: kjør en støttet klient inne i Android

Her har gjesten sin egen profil, sine egne påloggingsdata, ruter og resolverpolicy. De vanlige Android VPN-grensesnittene krever ingen root-tilgang, så en standardklient installeres og kobles til inne i den virtuelle enheten. Godkjenning er den delen folk hopper over. Organisasjonen må tillate den klienten og det virtuelle enhetsmiljøet, og en ren import oppfyller ikke i seg selv enhetsregistrering eller tilstandskontroller. Spør før du bygger en arbeidsflyt rundt det.

De to valgene kan også stables: en tunnel inne i Android kan nå serveren sin gjennom en tunnel som allerede kjører på verten. En slik ordning trenger et nåbart endepunkt og videresending du faktisk tillot, ikke to grønne lys som tilfeldigvis er på samtidig.

Verifiser fra appen og skriv ned ordningen

Bruk den samme Android-appen for hver test og les hva den rapporterer: om adressen svarer, om det private navnet løses og hva applikasjonen returnerer. Tre observasjoner skiller en rutingfeil fra en resolverfeil og fra en policyavvisning.

Når enheten ikke starter, eller Desktop mister den, behandle det som en feil i kontrollveien og ikke som en DNS-feil. Det symptomet hører til den første veien, og rettelsen er på verten, ikke inne i Android. Avslutt med å notere fire fakta: Genymotion Desktop-versjon, hypervisor, hvilken side som eier tunnelen og det nøyaktige host-only-unntaket hvis ett ble lagt til. Velg en dokumentert ordning som netteieren støtter, og ikke behandle deaktivering av en bedrifts-VPN eller svekkelse av tilstandskontroller som nøytral feilsøking når den private tjenesten er avhengig av dem.