VPN na hostiteli, nebo klient uvnitř Genymotion: rozhodněte, kdo vlastní tunel

Desktop VPN ovlivňuje Genymotion na dvou místech a oprava jednoho nic nedokazuje o druhém. První je spojení, které desktopová aplikace používá k ovládání virtuálního zařízení; druhé je cesta virtuální aplikace pro Android k soukromé službě. Rozhodněte, které z nich skutečně měníte, než se dotknete adaptéru, potom si zapište verzi Genymotion Desktop, hostitelský operační systém a hypervizor, protože pokyny napsané pro host-only adaptér VirtualBoxu se nepřenášejí na zařízení QEMU ani na relaci hostovanou v cloudu.

Dvě cesty na jednom stroji

Řídicí cesta vede z desktopové aplikace Genymotion k virtuálnímu zařízení, často přes host-only síť. Cesta aplikace vede zevnitř Androidu k čemukoli, s čím aplikace mluví. Hostitelská VPN může nést druhou a zlomit první, a proto funkční prohlížeč na ploše znamená velmi málo. Jeden tunel může obsloužit obě cesty nebo jen jednu a takové uspořádání je rozhodnutí, nikoli náhoda.

Zapište si, kterou cestu diagnostikujete. Většina ztracených hodin v této oblasti pochází ze změny DNS soukromé aplikace, když se zařízení vůbec nespustilo, nebo z uvolnění hostitelské VPN, když měla aplikace prostě špatný resolver.

Udržte řídicí spojení živé

Vlastní poznámka podpory Genymotion Desktop dokumentuje případ s VirtualBoxem: jakmile je hostitelská VPN nahoru, Desktop už virtuální zařízení nevidí, a výjimka, na které záleží, je skutečný host-only adaptér uvedený ve správci sítě VirtualBoxu. Vyjmenujte tyto adaptéry, místo abyste hádali rozsah:

VBoxManage list hostonlyifs

Výchozí rozsah vytištěný v dokumentaci není omluvou pro plošné obcházení soukromé sítě na každém stroji. Přidejte nejmenší výjimku, která pokrývá používaný adaptér, a nechte ji schválit správcem VPN, protože spravovaný klient může místní síť blokovat záměrně. Zapište výjimku s názvem adaptéru a datem schválení. O šest měsíců později je ta poznámka jediné, co vysvětluje, proč pravidlo existuje.

Stejná poznámka říká, že kombinace s QEMU není s VPN vyzkoušená. Berte to jako omezení kompatibility, ne jako náznak, že přechod na bridged síť to spraví; změna adaptéru mění selhání, ale nevyzkoušenou kombinaci neřeší.

Možnost A: nechte provoz nést hostitele

Při této volbě musí pakety hosta dorazit na rozhraní, které VPN jak povoluje, tak šifruje. To je otázka směrování, ne kontrolky stavu: pakety hosta musí dorazit na rozhraní, které VPN bude šifrovat, a odpovědi musí najít cestu zpět.

Prohlížeč na hostiteli dokazuje cestu hostitele a nic o tom, zda je zdroj z virtuálního zařízení přijímán. Někteří klienti VPN zacházejí s předávaným nebo překládaným provozem jinak než s provozem vytvořeným lokálně, proto testujte zevnitř Androidu, než usoudíte, že tunel funguje. Ani resolver Androidu není resolver hostitele. Pokud se jména na ploše přeloží a v aplikaci ne, přečtěte si konfiguraci resolveru hosta, než se dotknete profilu VPN.

Možnost B: spusťte podporovaného klienta uvnitř Androidu

Tady má host vlastní profil, přihlašovací údaje, trasy a pravidla resolveru. Běžná rozhraní VPN v Androidu nevyžadují přístup root, takže standardní klient se uvnitř virtuálního zařízení nainstaluje a připojí. Schválení je ta část, kterou lidé přeskakují. Organizace musí toho klienta a to prostředí virtuálního zařízení povolit a čistý import sám o sobě nesplňuje kontroly registrace zařízení ani stavu. Zeptejte se, než kolem toho postavíte pracovní postup.

Obě volby se také mohou vrstvit: tunel uvnitř Androidu může ke svému serveru dojít tunelem, který už běží na hostiteli. Takové uspořádání potřebuje dosažitelný koncový bod a předávání, které jste skutečně povolili, ne dvě zelená světla, která náhodou svítí zároveň.

Ověřte to z aplikace a zapište uspořádání

Použijte stejnou aplikaci pro Android při každém testu a čtěte, co hlásí: zda adresa odpovídá, zda se soukromé jméno přeloží a co aplikace vrací. Tři pozorování oddělí selhání směrování od selhání resolveru a od odmítnutí podle pravidel.

Když se zařízení nespustí nebo ho Desktop ztratí, berte to jako závadu řídicí cesty, ne jako závadu DNS. Ten příznak patří první cestě a oprava je na hostiteli, ne uvnitř Androidu. Na závěr zapište čtyři fakta: verze Genymotion Desktop, hypervizor, která strana vlastní tunel a přesnou výjimku host-only, pokud byla přidána. Vyberte zdokumentované uspořádání, které vlastník sítě podporuje, a nevypínání podnikové VPN ani oslabení kontrol stavu nepovažujte za neutrální diagnostiku, když na nich soukromá služba stojí.