VPN på värden eller en klient inuti Genymotion: avgör vem som äger tunneln

En desktop-VPN påverkar Genymotion på två ställen, och att laga det ena bevisar ingenting om det andra. Det första är den anslutning som desktopappen använder för att styra den virtuella enheten; det andra är den virtuella Android-appens väg till en privat tjänst. Avgör vilken av dem du faktiskt ändrar innan du rör en adapter, och notera sedan Genymotion Desktop-versionen, värdens operativsystem och hypervisorn, eftersom vägledning skriven för en VirtualBox host-only-adapter inte överförs till en QEMU-enhet eller till en session som körs i molnet.

Två vägar på en maskin

Kontrollvägen går från Genymotions desktopapplikation till den virtuella enheten, ofta över ett host-only-nätverk. Appvägen går från insidan av Android ut till det appen talar med. En värd-VPN kan bära den andra och bryta den första, och därför betyder en webbläsare som fungerar på skrivbordet mycket lite. En tunnel kan betjäna båda vägarna eller bara en av dem, och den ordningen är ett beslut, inte en olycka.

Skriv ned vilken väg du felsöker. De flesta förlorade timmarna inom detta område kommer från att ändra DNS för den privata appen när enheten aldrig startade, eller från att lätta på värd-VPN:n när appen bara hade fel resolver.

Håll kontrollänken vid liv

Genymotions egen Desktop-supportanteckning dokumenterar ett VirtualBox-fall: när en värd-VPN är uppe ser Desktop inte längre den virtuella enheten, och det undantag som betyder något är den riktiga host-only-adaptern som listas i VirtualBox nätverkshanterare. Lista de adaptrarna i stället för att gissa ett intervall:

VBoxManage list hostonlyifs

Ett standardintervall som tryckts i dokumentationen är ingen ursäkt för att kringgå det privata nätverket på varje maskin. Lägg till det minsta undantaget som täcker adaptern som används, och få VPN-administratören att godkänna det, eftersom en hanterad klient kan blockera det lokala nätverket med avsikt. Skriv ned undantaget med adapterns namn och godkännandedatum. Ett halvår senare är den anteckningen det enda som förklarar varför regeln finns.

Samma anteckning säger att QEMU-kombinationen inte är testad med VPN. Behandla det som en kompatibilitetsbegränsning och inte som en antydan om att byte till bryggat nätverk kommer att reparera det; att byta adapter ändrar felet men löser inte den otestade kombinationen.

Alternativ A: låt värden bära trafiken

Med detta val måste gästens paket nå ett gränssnitt som VPN:n både tillåter och krypterar. Det är en routingfråga, inte en statuslampa: gästens paket måste nå ett gränssnitt som VPN:n kommer att kryptera, och svaren måste hitta vägen tillbaka.

En webbläsare på värden bevisar värdens väg och ingenting om huruvida en källa från en virtuell enhet accepteras. Vissa VPN-klienter behandlar vidarebefordrad eller översatt trafik annorlunda än lokalt genererad trafik, så testa inifrån Android innan du drar slutsatsen att tunneln fungerar. Inte heller Androids resolver är värdens resolver. Om namn löses på skrivbordet och misslyckas i appen, läs gästens resolverkonfiguration innan du rör VPN-profilen.

Alternativ B: kör en klient som stöds inuti Android

Här har gästen sin egen profil, sina egna inloggningsuppgifter, rutter och resolverpolicy. De vanliga Android VPN-gränssnitten kräver ingen root-åtkomst, så en standardklient installeras och ansluter inuti den virtuella enheten. Godkännandet är den del folk hoppar över. Organisationen måste tillåta den klienten och den virtuella enhetsmiljön, och en ren import uppfyller inte i sig enhetsregistrering eller tillståndskontroller. Fråga innan du bygger ett arbetsflöde kring det.

De två valen kan också staplas: en tunnel inuti Android kan nå sin server genom en tunnel som redan körs på värden. En sådan ordning kräver en nåbar slutpunkt och vidarebefordran som du faktiskt tillät, inte två gröna ljus som råkar vara på samtidigt.

Verifiera från appen och skriv ned ordningen

Använd samma Android-app för varje test och läs vad den rapporterar: om adressen svarar, om det privata namnet löses och vad applikationen returnerar. Tre observationer skiljer ett routingfel från ett resolverfel och från ett policyavslag.

När enheten inte startar, eller Desktop tappar den, behandla det som ett fel i kontrollvägen och inte som ett DNS-fel. Det symptomet hör till den första vägen, och rättelsen är på värden, inte inuti Android. Avsluta med att anteckna fyra fakta: Genymotion Desktop-version, hypervisor, vilken sida som äger tunneln och det exakta host-only-undantaget om ett lades till. Välj en dokumenterad ordning som nätägaren stöder, och behandla inte avstängning av ett företags-VPN eller försvagning av tillståndskontroller som neutral felsökning när den privata tjänsten är beroende av dem.