होस्ट VPN या Genymotion के भीतर क्लाइंट: तय करें कि टनल किसका है

एक डेस्कटॉप 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 बंद करना या पोस्चर जाँच कमज़ोर करना तटस्थ समस्या-निवारण न मानें।