VPN sa host o kliyente sa loob ng Genymotion: magpasya kung sino ang may-ari ng tunnel

Ang isang desktop VPN ay nakakaapekto sa Genymotion sa dalawang lugar, at ang pag-aayos ng isa ay walang pinapatunayan tungkol sa isa pa. Ang una ay ang koneksyon na ginagamit ng desktop app upang kontrolin ang virtual device; ang pangalawa ay ang landas ng virtual Android app patungo sa isang pribadong serbisyo. Magpasya kung alin sa dalawa ang talagang binabago mo bago mo hawakan ang adapter, pagkatapos ay itala ang bersyon ng Genymotion Desktop, ang operating system ng host at ang hypervisor, dahil ang gabay na isinulat para sa isang VirtualBox host-only adapter ay hindi lumilipat sa isang QEMU device o sa isang session na naka-host sa cloud.

Dalawang landas sa isang makina

Ang control path ay tumatakbo mula sa Genymotion desktop application patungo sa virtual device, kadalasan sa isang host-only network. Ang app path ay tumatakbo mula sa loob ng Android palabas patungo sa kung ano man ang kausap ng app. Ang isang host VPN ay maaaring magdala ng pangalawa at sirain ang una, kaya naman ang isang browser na gumagana sa desktop ay napakaliit ng pinapatunayan. Ang isang tunnel ay maaaring maglingkod sa parehong landas o sa isa lamang, at ang kaayusang iyon ay isang desisyon, hindi isang aksidente.

Itala kung aling landas ang ginagamot mo. Karamihan sa mga nasayang na oras sa larangang ito ay nagmumula sa pagbabago ng DNS ng pribadong app gayong hindi kailanman nag-boot ang device, o sa pagluwag ng host VPN gayong mali lamang ang resolver ng app.

Panatilihing buhay ang control connection

Ang sariling Desktop support note ng Genymotion ay nagdodokumento ng isang kaso sa VirtualBox: kapag nakaupo na ang host VPN, hindi na nakikita ng Desktop ang virtual device, at ang eksepsiyon na mahalaga ay ang tunay na host-only adapter na nakalista sa network manager ng VirtualBox. Ilahad ang mga adapter na iyon sa halip na hulaan ang isang range:

VBoxManage list hostonlyifs

Ang default na range na nakalimbag sa dokumentasyon ay hindi dahilan para laktawan nang buo ang pribadong network sa bawat makina. Idagdag ang pinakamaliit na eksepsiyon na sumasaklaw sa adapter na ginagamit, at kunin ang pag-apruba ng VPN administrator, dahil ang isang managed client ay maaaring sadyang magharang sa lokal na network. Itala ang eksepsiyon kasama ang pangalan ng adapter at petsa ng pag-apruba. Makalipas ang kalahating taon, ang tala na iyon ang tanging bagay na nagpapaliwanag kung bakit may ganoong patakaran.

Sinasabi rin ng parehong tala na ang kombinasyon sa QEMU ay hindi pa nasubukan sa VPN. Ituring ito bilang limitasyon sa compatibility at hindi bilang pahiwatig na aayusin ito ng paglipat sa bridged network; binabago ng pagpapalit ng adapter ang anyo ng pagkabigo, ngunit hindi nito nilulutas ang hindi nasubukang kombinasyon.

Opsyon A: hayaang ang host ang magdala ng trapiko

Sa pagpipiliang ito, ang mga packet ng guest ay dapat makarating sa isang interface na parehong pinapayagan at ini-encrypt ng VPN. Tanong ito ng routing, hindi ng status light: ang mga packet ng guest ay dapat makarating sa interface na i-e-encrypt ng VPN, at ang mga sagot ay dapat makahanap ng daan pabalik.

Ang isang browser sa host ay nagpapatunay ng landas ng host at wala tungkol sa kung tinatanggap ang isang pinagmulan mula sa virtual device. Ang ilang VPN client ay iba ang pagtrato sa trapikong ipinasa o isinalin kaysa sa trapikong nalikha nang lokal, kaya subukan mula sa loob ng Android bago magpasyang gumagana ang tunnel. Hindi rin resolver ng host ang resolver ng Android. Kung nagre-resolve ang mga pangalan sa desktop ngunit nabibigo sa app, basahin ang configuration ng resolver ng guest bago hawakan ang profile ng VPN.

Opsyon B: magpatakbo ng sinusuportahang kliyente sa loob ng Android

Dito hinahawakan ng guest ang sarili nitong profile, kredensyal, ruta at patakaran sa resolver. Ang mga ordinaryong Android VPN interface ay hindi nangangailangan ng root access, kaya ang isang karaniwang kliyente ay naka-install at kumokonekta sa loob ng virtual device. Ang pag-apruba ang bahaging nilalaktawan ng mga tao. Dapat pahintulutan ng organisasyon ang kliyenteng iyon at ang environment ng virtual device na iyon, at ang isang malinis na import ay hindi nag-iisa na tumutugon sa mga pagsusuri ng device enrollment o posture. Magtanong bago ka bumuo ng workflow sa paligid nito.

Maaari ring magpatong ang dalawang pagpipilian: ang isang tunnel sa loob ng Android ay maaaring makarating sa server nito sa pamamagitan ng isang tunnel na tumatakbo na sa host. Ang ganoong kaayusan ay nangangailangan ng maabot na endpoint at pagpapasa na tunay mong pinahintulutan, hindi dalawang berdeng ilaw na nagkataong nakasindi nang sabay.

I-verify mula sa app at itala ang kaayusan

Gamitin ang parehong Android app sa bawat pagsubok at basahin ang iniuulat nito: kung tumutugon ang address, kung nagre-resolve ang pribadong pangalan, at kung ano ang ibinabalik ng app. Tatlong obserbasyon ang naghihiwalay ng pagkabigo sa routing mula sa pagkabigo ng resolver at mula sa pagtanggi ng patakaran.

Kapag hindi nag-boot ang device, o nawala ito ng Desktop, ituring itong sira sa control path at hindi sira sa DNS. Ang sintomas na iyon ay kabilang sa unang landas, at ang pag-aayos ay nasa host, hindi sa loob ng Android. Tapusin sa pagtatala ng apat na katotohanan: bersyon ng Genymotion Desktop, hypervisor, aling panig ang may-ari ng tunnel, at ang eksaktong host-only exception kung may idinagdag. Pumili ng dokumentadong kaayusan na sinusuportahan ng may-ari ng network, at huwag ituring na neutral na troubleshooting ang pagpatay sa isang enterprise VPN o ang pagpapahina sa posture checks kapag umaasa rito ang pribadong serbisyo.