Az asztali VPN két helyen hat a Genymotionre, és az egyik javítása semmit sem bizonyít a másikról. Az első az a kapcsolat, amelyet az asztali alkalmazás a virtuális eszköz vezérlésére használ; a második a virtuális Android-alkalmazás útvonala egy privát szolgáltatás felé. Döntse el, melyiket módosítja valójában, mielőtt adapterhez nyúlna, majd jegyezze fel a Genymotion Desktop verzióját, a gazdagép operációs rendszerét és a hipervizort, mert a VirtualBox host-only adapterhez írt útmutatás nem vihető át QEMU-eszközre vagy felhőben üzemeltetett munkamenetre.

Két útvonal egy gépen

A vezérlőútvonal a Genymotion asztali alkalmazásától a virtuális eszközig fut, gyakran host-only hálózaton át. Az alkalmazás útvonala az Androidon belülről kifelé fut ahhoz, amivel az alkalmazás beszél. A gazdagép VPN-je elviheti a másodikat és eltörheti az elsőt, ezért egy működő böngésző az asztalon nagyon keveset bizonyít. Egy alagút kiszolgálhatja mindkét útvonalat vagy csak az egyiket, és ez az elrendezés döntés, nem véletlen.

Írja le, melyik útvonalat vizsgálja. Az ezen a területen elvesztegetett órák többsége abból származik, hogy a privát alkalmazás DNS-ét változtatják, amikor az eszköz soha nem indult el, vagy hogy lazítják a gazdagép VPN-jét, amikor az alkalmazásnak egyszerűen rossz feloldója volt.

Tartsa életben a vezérlőkapcsolatot

A Genymotion saját Desktop-támogatási jegyzete egy VirtualBox-esetet dokumentál: amint a gazdagép VPN-je feláll, a Desktop már nem látja a virtuális eszközt, és az a kivétel számít, amely a VirtualBox hálózatkezelőjében felsorolt valódi host-only adapter. Sorolja fel ezeket az adaptereket ahelyett, hogy tartományt tippelne:

VBoxManage list hostonlyifs

A dokumentációban kinyomtatott alapértelmezett tartomány nem mentség arra, hogy minden gépen általánosan megkerüljék a privát hálózatot. Adja hozzá a legkisebb kivételt, amely lefedi a használt adaptert, és szerezze be a VPN-adminisztrátor jóváhagyását, mert egy felügyelt kliens szándékosan blokkolhatja a helyi hálózatot. Jegyezze fel a kivételt az adapter nevével és a jóváhagyás dátumával. Fél év múlva ez a jegyzet az egyetlen, ami megmagyarázza, miért létezik a szabály.

Ugyanez a jegyzet azt mondja, hogy a QEMU-kombinációt nem tesztelték VPN-nel. Kezelje ezt kompatibilitási korlátként, és ne utalásként arra, hogy a bridged hálózatra váltás megjavítja; az adapter cseréje megváltoztatja a hibát, de nem oldja meg a teszteltelen kombinációt.

A lehetőség: hagyja, hogy a gazdagép vigye a forgalmat

Ennél a választásnál a vendég csomagjainak olyan interfészre kell érkezniük, amelyet a VPN egyszerre engedélyez és titkosít. Ez útválasztási kérdés, nem állapotlámpa kérdése: a vendég csomagjainak arra az interfészre kell érkezniük, amelyet a VPN titkosítani fog, és a válaszoknak meg kell találniuk a visszautat.

A gazdagépen futó böngésző a gazdagép útvonalát bizonyítja, és semmit arról, hogy elfogadnak-e virtuális eszközről származó forrást. Egyes VPN-kliensek a továbbított vagy lefordított forgalmat másképp kezelik, mint a helyben keletkezett forgalmat, ezért az Androidon belülről teszteljen, mielőtt arra jutna, hogy az alagút működik. Az Android feloldója sem a gazdagép feloldója. Ha a nevek az asztalon feloldódnak és az alkalmazásban meghiúsulnak, olvassa el a vendég feloldó-konfigurációját, mielőtt a VPN-profilhoz nyúlna.

B lehetőség: futtasson támogatott klienst az Androidon belül

Itt a vendég a saját profilját, hitelesítő adatait, útvonalait és feloldó-szabályzatát tartja. A szokásos Android VPN API-k nem igényelnek root hozzáférést, ezért egy szabványos kliens települ és csatlakozik a virtuális eszközön belül. A jóváhagyás az a rész, amelyet az emberek kihagynak. A szervezetnek engedélyeznie kell azt a klienst és azt a virtuális eszközkörnyezetet, és egy tiszta import önmagában nem teljesíti az eszközregisztrációs vagy állapotellenőrzéseket. Kérdezzen, mielőtt munkafolyamatot építene rá.

A két választás egymásra is rakható: az Androidon belüli alagút elérheti a kiszolgálóját egy már a gazdagépen futó alagúton keresztül. Az ilyen elrendezéshez elérhető végpont és ténylegesen engedélyezett továbbítás kell, nem két zöld lámpa, amelyek véletlenül egyszerre világítanak.

Ellenőrizze az alkalmazásból, és írja le az elrendezést

Minden teszthez ugyanazt az Android-alkalmazást használja, és olvassa el, mit jelent: válaszol-e a cím, feloldódik-e a privát név, és mit ad vissza az alkalmazás. Három megfigyelés választja el az útválasztási hibát a feloldóhibától és a szabályzat általi elutasítástól.

Amikor az eszköz nem indul el, vagy a Desktop elveszíti, kezelje ezt vezérlőútvonal-hibaként, nem DNS-hibaként. Ez a tünet az első útvonalhoz tartozik, és a javítás a gazdagépen van, nem az Androidon belül. Fejezze be négy tény rögzítésével: Genymotion Desktop verziója, hipervizor, melyik fél birtokolja az alagutat, és a pontos host-only kivétel, ha hozzáadtak egyet. Olyan dokumentált elrendezést válasszon, amelyet a hálózat tulajdonosa támogat, és ne tekintse a vállalati VPN kikapcsolását vagy az állapotellenőrzések gyengítését semleges hibakeresésnek, amikor a privát szolgáltatás ezekre támaszkodik.

Kapcsolódó cikkek