હોસ્ટ VPN કે Genymotion ની અંદર ક્લાયન્ટ: ટનલ કોની છે તે નક્કી કરો
ડેસ્કટોપ VPN Genymotion ને બે જગ્યાએ સ્પર્શે છે: કંટ્રોલ લિંક અને એપનો પોતાનો માર્ગ. ટનલ કઈ બાજુની છે તે પસંદ કરો, પછી Android ની અંદર ચકાસો.
એક ડેસ્કટોપ VPN Genymotion ને બે જગ્યાએ અસર કરે છે, અને એકને ઠીક કરવાથી બીજા વિશે કંઈ સાબિત થતું નથી. પ્રથમ એ કનેક્શન છે જે ડેસ્કટોપ એપ વર્ચ્યુઅલ ઉપકરણને નિયંત્રિત કરવા વાપરે છે; બીજું એ વર્ચ્યુઅલ Android એપનો ખાનગી સેવા તરફનો માર્ગ છે. એડેપ્ટરને અડકતા પહેલાં નક્કી કરો કે તમે ખરેખર તેમાંથી કયું બદલી રહ્યા છો, પછી Genymotion Desktop નું સંસ્કરણ, હોસ્ટ ઓપરેટિંગ સિસ્ટમ અને હાઇપરવાઇઝર નોંધો, કારણ કે VirtualBox ફક્ત-હોસ્ટ એડેપ્ટર માટે લખાયેલી સૂચનાઓ QEMU ઉપકરણ કે ક્લાઉડમાં હોસ્ટ કરેલા સત્ર પર લાગુ પડતી નથી.
એક મશીન પર બે માર્ગ
કંટ્રોલ માર્ગ Genymotion ડેસ્કટોપ એપ્લિકેશનથી વર્ચ્યુઅલ ઉપકરણ સુધી જાય છે, ઘણી વાર ફક્ત-હોસ્ટ નેટવર્ક પરથી. એપનો માર્ગ Android ની અંદરથી બહાર એ જગ્યાએ જાય છે જ્યાં એપ વાત કરે છે. હોસ્ટ VPN બીજાને વહન કરી શકે છે અને પ્રથમને તોડી શકે છે, અને તેથી જ ડેસ્કટોપ પર ચાલતું બ્રાઉઝર ઘણું ઓછું સાબિત કરે છે. એક ટનલ બંને માર્ગો સેવ કરી શકે છે અથવા ફક્ત એક, અને આ ગોઠવણી અકસ્માત નહીં પણ નિર્ણય છે.
તમે કયા માર્ગનું નિદાન કરી રહ્યા છો તે લખો. આ ક્ષેત્રમાં વેડફાતા મોટા ભાગના કલાકો ખાનગી એપના DNS બદલવાથી આવે છે જ્યારે ઉપકરણ ક્યારેય શરૂ થયું જ નહોતું, અથવા હોસ્ટ VPN ઢીલું કરવાથી જ્યારે એપ પાસે ફક્ત ખોટું રિઝોલ્વર હતું.
કંટ્રોલ કનેક્શન જીવંત રાખો
Genymotion ની પોતાની Desktop સપોર્ટ નોંધ VirtualBox નો એક કિસ્સો દસ્તાવેજ કરે છે: હોસ્ટ VPN ચાલુ થયા પછી Desktop વર્ચ્યુઅલ ઉપકરણ જોઈ શકતું નથી, અને જે અપવાદ મહત્વનો છે તે VirtualBox ના નેટવર્ક મેનેજરમાં સૂચિબદ્ધ વાસ્તવિક ફક્ત-હોસ્ટ એડેપ્ટર છે. રેન્જ અનુમાન કરવાને બદલે તે એડેપ્ટરોની સૂચિ બનાવો:
VBoxManage list hostonlyifs
દસ્તાવેજીકરણમાં છપાયેલી ડિફોલ્ટ રેન્જ દરેક મશીન પર ખાનગી નેટવર્કને સંપૂર્ણ બાયપાસ કરવાનું બહાનું નથી. વપરાતા એડેપ્ટરને આવરી લેતો સૌથી નાનો અપવાદ ઉમેરો, અને VPN એડમિનિસ્ટ્રેટર પાસેથી મંજૂરી મેળવો, કારણ કે મેનેજ કરેલ ક્લાયન્ટ સ્થાનિક નેટવર્કને જાણી જોઈને બ્લોક કરી શકે છે. એડેપ્ટરનું નામ અને મંજૂરીની તારીખ સાથે અપવાદ લખો. છ મહિના પછી એ નોંધ એ જ એક વસ્તુ હશે જે સમજાવે છે કે નિયમ કેમ અસ્તિત્વમાં છે.
એ જ નોંધ કહે છે કે QEMU સંયોજન VPN સાથે પરીક્ષણ કરેલું નથી. તેને સુસંગતતાની મર્યાદા તરીકે લો, એ સંકેત તરીકે નહીં કે બ્રિજ્ડ નેટવર્કિંગ પર જવાથી તે ઠીક થશે; એડેપ્ટર બદલવાથી નિષ્ફળતા બદલાય છે, પરંતુ ન પરીક્ષણ કરેલું સંયોજન હલ થતું નથી.
વિકલ્પ પ્રથમ: હોસ્ટને ટ્રાફિક વહન કરવા દો
આ પસંદગી સાથે ગેસ્ટના પેકેટોએ એવા ઇન્ટરફેસ પર પહોંચવું પડે છે જેને VPN તેમ મંજૂર કરે છે તેમ એન્ક્રિપ્ટ પણ કરે છે. આ રૂટિંગનો પ્રશ્ન છે, સ્ટેટસ-લાઇટનો પ્રશ્ન નથી: ગેસ્ટના પેકેટોએ VPN એન્ક્રિપ્ટ કરશે તે ઇન્ટરફેસ પર પહોંચવું પડે છે, અને જવાબોએ પાછા ફરવાનો રસ્તો શોધવો પડે છે.
હોસ્ટ પરનું બ્રાઉઝર હોસ્ટનો માર્ગ સાબિત કરે છે અને વર્ચ્યુઅલ ઉપકરણનો સ્રોત સ્વીકારાય છે કે નહીં તે વિશે કંઈ નહીં. કેટલાક VPN ક્લાયન્ટ ફોરવર્ડ કરેલા કે અનુવાદિત ટ્રાફિકને સ્થાનિક રીતે ઉત્પન્ન થયેલા ટ્રાફિક કરતાં અલગ રીતે લે છે, તેથી ટનલ કામ કરે છે તેવા નિષ્કર્ષ પર આવતાં પહેલાં Android ની અંદરથી પરીક્ષણ કરો. Android નું રિઝોલ્વર પણ હોસ્ટનું રિઝોલ્વર નથી. જો નામ ડેસ્કટોપ પર ઉકેલાય અને એપમાં નિષ્ફળ જાય, તો VPN પ્રોફાઇલને અડકતા પહેલાં ગેસ્ટના રિઝોલ્વર રૂપરેખાંકન વાંચો.
વિકલ્પ બીજો: Android ની અંદર સમર્થિત ક્લાયન્ટ ચલાવો
અહીં ગેસ્ટ પોતાની પ્રોફાઇલ, ઓળખપત્રો, રૂટ અને રિઝોલ્વર નીતિ રાખે છે. સામાન્ય Android VPN ઇંટરફેસ ને રૂટ ઍક્સેસની જરૂર નથી, તેથી પ્રમાણભૂત ક્લાયન્ટ વર્ચ્યુઅલ ઉપકરણની અંદર સ્થાપિત થાય છે અને જોડાય છે. મંજૂરી એ ભાગ છે જે લોકો છોડી દે છે. સંસ્થાએ તે ક્લાયન્ટ અને તે વર્ચ્યુઅલ-ઉપકરણ વાતાવરણને મંજૂર કરવું પડે છે, અને સ્વચ્છ આયાત પોતાની રીતે ઉપકરણ-નોંધણી કે પોસ્ચર તપાસ પૂરી કરતી નથી. તેની આસપાસ વર્કફ્લો બનાવતા પહેલાં પૂછો.
બંને પસંદગીઓ એકબીજા પર થર પણ બની શકે: Android ની અંદરની ટનલ હોસ્ટ પર પહેલેથી ચાલતી ટનલ દ્વારા તેના સર્વર સુધી પહોંચી શકે છે. આવી ગોઠવણીને પહોંચી શકાય તેવા અંતિમ બિંદુ અને તમે ખરેખર મંજૂર કરેલા ફોરવર્ડિંગની જરૂર છે, એકસાથે ચાલુ થઈ ગયેલા બે લીલા દીવા નહીં.
એપમાંથી ચકાસો અને ગોઠવણી લખો
દરેક પરીક્ષણ માટે એ જ Android એપ વાપરો અને તે શું જણાવે છે તે વાંચો: સરનામું જવાબ આપે છે કે નહીં, ખાનગી નામ ઉકેલાય છે કે નહીં અને એપ શું પરત કરે છે. ત્રણ અવલોકનો રૂટિંગ નિષ્ફળતાને રિઝોલ્વર નિષ્ફળતાથી અને નીતિ-અસ્વીકારથી અલગ પાડે છે.
જ્યારે ઉપકરણ શરૂ ન થાય, અથવા Desktop તેને ગુમાવે, ત્યારે તેને DNS ખામી નહીં પણ કંટ્રોલ-માર્ગની ખામી તરીકે લો. તે લક્ષણ પ્રથમ માર્ગનું છે, અને સુધારો હોસ્ટ પર છે, Android ની અંદર નહીં. ચાર હકીકતો લખીને પૂર્ણ કરો: Genymotion Desktop નું સંસ્કરણ, હાઇપરવાઇઝર, ટનલ કઈ બાજુની છે અને જો ઉમેરાયું હોય તો ચોક્કસ ફક્ત-હોસ્ટ અપવાદ. નેટવર્ક માલિક જે દસ્તાવેજીકૃત ગોઠવણીને સમર્થન આપે છે તે પસંદ કરો, અને જ્યારે ખાનગી સેવા તેમના પર આધાર રાખે છે ત્યારે એન્ટરપ્રાઇઝ VPN બંધ કરવા કે પોસ્ચર તપાસ નબળી કરવાને તટસ્થ સમસ્યા-શોધ ગણશો નહીં.