Një VPN desktop ndikon në Genymotion në dy vende, dhe rregullimi i njërit nuk provon asgjë për tjetrin. I pari është lidhja që aplikacioni desktop përdor për të kontrolluar pajisjen virtuale; i dyti është rruga e aplikacionit virtual Android drejt një shërbimi privat. Vendosni se cilën prej tyre po ndryshoni në të vërtetë përpara se të prekni një përshtatës, pastaj shënoni versionin e Genymotion Desktop, sistemin operativ të hostit dhe hipervizorin, sepse udhëzimet e shkruara për një përshtatës host-only të VirtualBox nuk transferohen në një pajisje QEMU apo në një sesion të strehuar në re.

Dy rrugë në një makinë

Rruga e kontrollit shkon nga aplikacioni desktop i Genymotion te pajisja virtuale, shpesh përmes një rrjeti host-only. Rruga e aplikacionit shkon nga brenda Android jashtë, drejt asaj me të cilën flet aplikacioni. Një VPN në host mund të mbajë të dytën dhe të thyejë të parën, dhe për këtë arsye një shfletues që punon në desktop provon shumë pak. Një tunel i vetëm mund t'u shërbejë të dy rrugëve ose vetëm njërës, dhe kjo rregullim është vendim, jo aksident.

Shënoni cilën rrugë po diagnostikoni. Shumica e orëve të humbura në këtë fushë vijnë nga ndryshimi i DNS-së së aplikacionit privat kur pajisja nuk u nis kurrë, ose nga lehtësimi i VPN-së së hostit kur aplikacioni thjesht kishte zgjidhësin e gabuar.

Mbajeni gjallë lidhjen e kontrollit

Shënimi i vetë mbështetjes së Genymotion Desktop dokumenton një rast VirtualBox: sapo VPN-ja e hostit është lart, Desktop nuk e sheh më pajisjen virtuale, dhe përjashtimi që ka rëndësi është përshtatësi i vërtetë host-only i listuar në menaxherin e rrjetit të VirtualBox. Listoni ata përshtatës në vend që të hamendësoni një interval:

VBoxManage list hostonlyifs

Një interval i parazgjedhur i shtypur në dokumentacion nuk është justifikim për një anashkalim të plotë të rrjetit privat në çdo makinë. Shtoni përjashtimin më të vogël që mbulon përshtatësin në përdorim dhe merrni miratimin e administratorit të VPN-së, sepse një klient i menaxhuar mund ta bllokojë qëllimisht rrjetin lokal. Shënoni përjashtimin me emrin e përshtatësit dhe datën e miratimit. Gjashtë muaj më vonë ai shënim është e vetmja gjë që shpjegon pse ekziston rregulli.

I njëjti shënim thotë se kombinimi me QEMU nuk është testuar me VPN. Trajtojeni si kufizim përputhshmërie dhe jo si një aluzion se kalimi në rrjet bridged do ta rregullojë; ndryshimi i përshtatësit ndryshon dështimin, por nuk e zgjidh kombinimin e patestuar.

Opsioni A: lëreni hostin të mbajë trafikun

Me këtë zgjedhje, paketat e mysafirit duhet të arrijnë në një ndërfaqe që VPN-ja e lejon dhe e kripton njëkohësisht. Është çështje rrugëtimi, jo drita statusi: paketat e mysafirit duhet të arrijnë në ndërfaqen që VPN-ja do të kriptojë, dhe përgjigjet duhet të gjejnë rrugën e kthimit.

Një shfletues në host provon rrugën e hostit dhe asgjë për faktin nëse pranohet një burim nga pajisje virtuale. Disa klientë VPN e trajtojnë trafikun e përçuar ose të përkthyer ndryshe nga trafiku i krijuar lokalisht, prandaj testoni nga brenda Android përpara se të përfundoni që tuneli punon. Edhe zgjidhësi i Android nuk është zgjidhësi i hostit. Nëse emrat zgjidhen në desktop dhe dështojnë në aplikacion, lexoni konfigurimin e zgjidhësit të mysafirit përpara se të prekni profilin e VPN-së.

Opsioni B: ekzekutoni një klient të mbështetur brenda Android

Këtu mysafiri mban profilin, kredencialet, rrugët dhe politikën e zgjidhësit të vet. Ndërfaqet e zakonshme VPN të Android nuk kërkojnë akses root, prandaj një klient standard instalohet dhe lidhet brenda pajisjes virtuale. Miratimi është pjesa që njerëzit e anashkalojnë. Organizata duhet ta lejojë atë klient dhe atë mjedis të pajisjes virtuale, dhe një import i pastër nuk i plotëson vetë kontrollet e regjistrimit të pajisjes apo të qëndrimit. Pyetni përpara se të ndërtoni një rrjedhë pune rreth tij.

Të dyja zgjedhjet mund të mbivendosen: një tunel brenda Android mund ta arrijë serverin e vet përmes një tuneli që tashmë punon në host. Një rregullim i tillë kërkon një pikë fundore të arritshme dhe përcjellje që ju e keni lejuar vërtet, jo dy drita jeshile që ndodh të jenë ndezur bashkë.

Verifikoni nga aplikacioni dhe shënoni rregullimin

Përdorni të njëjtin aplikacion Android për çdo test dhe lexoni çfarë raporton: nëse adresa përgjigjet, nëse emri privat zgjidhet dhe çfarë kthen aplikacioni. Tre vëzhgime ndajnë një dështim rrugëtimi nga një dështim zgjidhësi dhe nga një refuzim politikë.

Kur pajisja nuk niset, ose Desktop e humb atë, trajtojeni si defekt i rrugës së kontrollit dhe jo si defekt DNS. Ai simptom i përket rrugës së parë, dhe rregullimi është në host, jo brenda Android. Përfundoni duke shënuar katër fakte: versioni i Genymotion Desktop, hipervizori, cila anë e zotëron tunelin dhe përjashtimi i saktë host-only nëse u shtua ndonjë. Zgjidhni një rregullim të dokumentuar që pronari i rrjetit e mbështet, dhe mos e trajtoni çaktivizimin e një VPN ndërmarrjeje ose dobësimin e kontrolleve të qëndrimit si diagnostikim neutral kur shërbimi privat mbështetet në to.

Artikuj të ngjashëm