वर्चुअल मशीन में VPN के ज़रिए निजी सेवा तक कैसे पहुँचें

मेज़मान और Mac को एक पतले दरवाज़े से जुड़े दो अलग नेटवर्क मानें। वर्चुअल मशीन अपना VPN क्लाइंट और अपना इंटरनेट रास्ता रखती है; Mac सिर्फ़-होस्ट एडाप्टर और एक ही फ़ॉरवर्ड किए पोर्ट से ठीक एक सेवा तक पहुँचता है। और कुछ भी पार नहीं होना चाहिए। चरणों को क्रम से पूरा करें और जब कोई असफल हो तो रुक जाएँ, क्योंकि हर अगला चरण मानता है कि पिछले चरण टिके रहे।

कुछ भी बदलने से पहले दोनों रास्ते दर्ज करें

मेज़मान पर, ipconfig /all वह एडाप्टर दिखाता है जो VPN परिवहन ढोता है और वह पता जो उसे वर्चुअल नेटवर्क के DHCP से मिला था। Mac पर, वह वर्चुअल इंटरफ़ेस दर्ज करें जो हाइपरवाइज़र ने उस सेगमेंट के लिए बनाया; VMware Fusion में सिर्फ़-होस्ट डिवाइस आम तौर पर vmnet1 होता है, और Parallels अपना नाम देता है। ध्यान दें कि वहाँ पते कौन बाँटता है, फिर सब कुछ लिख लें, क्योंकि वर्चुअल नेटवर्क दोबारा बनने पर सिर्फ़-होस्ट सबनेट अकसर फिर से आवंटित होता है। वर्चुअल मशीन का नेटवर्क मोड हाइपरवाइज़र में जाँचें, अपनी याद में नहीं। इंटरनेट की ओर वाले एडाप्टर के लिए साझा या NAT मोड और Mac की ओर वाले एडाप्टर के लिए सिर्फ़-होस्ट मोड ही वह व्यवस्था है जो ये चरण मानते हैं।

दो एडाप्टर, दो मक़सद। उन्हें ऐसे मिलाना कि एक ही एडाप्टर Mac और इंटरनेट दोनों को सेवा दे, वही पतले दरवाज़े को राउट होते रास्ते में बदल देता है।

पहले मेज़मान का अपना VPN पक्का करें

Windows के अंदर क्लाइंट शुरू करें और पक्का करें कि वह समाप्त होता है, विक्रेता जो भी परीक्षण दर्ज करता हो उससे। तब तक आगे न बढ़ें जब तक मेज़मान अकेले निजी सेवा तक न पहुँचे, क्योंकि टूटी टनल पर चढ़ी फ़ॉरवर्डिंग समस्या के दो कारण होते हैं और कोई काम का त्रुटि संदेश नहीं मिलता। मेज़मान के भीतर से सेवा जिस निजी पते पर हल होती है उसे दर्ज करें। फ़ॉरवर्डिंग नियम को सिर्फ़ वही पता नाम देना चाहिए।

अगर क्लाइंट पूरी टनल धकेलता है, तो सिर्फ़-होस्ट एडाप्टर फिर भी स्थानीय ट्रैफ़िक ढोता है, लेकिन जाँचें कि निजी गंतव्य टनल ऐसे न पकड़े जिससे उसका पता बदल जाए। स्प्लिट टनल प्रोफ़ाइल इसे आसान बनाता है और VPN के मालिक से यह माँगना बनता है।

सिर्फ़-होस्ट टाँग जोड़ें और उसे अकेले जाँचें

मेज़मान से सिर्फ़-होस्ट एडाप्टर जोड़ें, उसे ऐसे सबनेट पर स्थिर पता दें जिसे और कोई नहीं इस्तेमाल करता, और पक्का करें कि Mac उसे ping कर सकता है। VPN जुड़ा हो और अलग हो दोनों हालत में जाँचें, क्योंकि पते को दोनों झेलने हैं। ऐसा मेज़मान जो सिर्फ़ तब जवाब देता है जब उसकी टनल चालू हो उसमें राउटिंग की समस्या है जिसे आपने अभी तक नहीं खोजा।

Windows नए एडाप्टर को सार्वजनिक नेटवर्क के रूप में वर्गीकृत कर सकता है, जो डिफ़ॉल्ट रूप से आने वाले ट्रैफ़िक को रोकता है। कुछ और डिबग करने से पहले प्रोफ़ाइल सेट करें।

सिर्फ़ एक पोर्ट फ़ॉरवर्ड करें, सबनेट नहीं

सामान्य IP फ़ॉरवर्डिंग के बजाय एक फ़ॉरवर्ड किया पोर्ट चुनें। Windows netsh interface portproxy देता है, जो सुनते हुए पोर्ट को गंतव्य होस्ट और पोर्ट पर फ़ॉरवर्ड करता है, और उसके लिए IP Helper सेवा चालू होनी चाहिए।

listenaddress हमेशा सिर्फ़-होस्ट पते पर सेट करें। उसे छोड़ देने से सारे इंटरफ़ेस बँध जाते हैं, जो सेवा को उस हर नेटवर्क के सामने खोल देता है जिस पर वर्चुअल मशीन हो। सिर्फ़-होस्ट इंटरफ़ेस और उस एक पोर्ट तक सीमित फ़ायरवॉल नियम जोड़ें, ताकि श्रोता और अनुमति मेल खाएँ। प्रॉक्सी समझने वाला ऐप्लिकेशन शायद इसके बजाय मेज़मान के भीतर छोटा प्रॉक्सी चाहे, जो कनेक्शन समाप्त करता है और Mac तक लौटने के रास्ते की ज़रूरत नहीं रखता। प्रोटोकॉल इजाज़त दे तो प्रॉक्सी चुनें, क्योंकि वह अपनी रचना से बंद होकर असफल होता है।

जाँचें, फिर रोलबैक लिखें

Mac से निजी नाम हल करें, तय काम चलाएँ, फिर मेज़मान का VPN बंद करें और पक्का करें कि काम चुपचाप पीछे लौटने के बजाय असफल होता है। वही आख़िरी जाँच साबित करती है कि रास्ता वही है जो आपने बनाया। दर्ज करें कि गेटवे कौन-सी पहचान देखता है और किसे फ़ॉरवर्ड इस्तेमाल करने की इजाज़त है।

रोलबैक तीन चरणों में लिखें: portproxy प्रविष्टि हटाएँ, फ़ायरवॉल नियम हटाएँ, सिर्फ़-होस्ट एडाप्टर अलग करें। फिर ज़रूरत पड़ने से पहले उसे एक बार चलाएँ और पक्का करें कि मेज़मान का अपना VPN उसके बाद भी काम करता है। अगर आपकी संस्था हर Mac के अलग पंजीकरण की माँग करती है, तो यहीं रुकें और इसके बजाय वही मॉडल अपनाएँ, क्योंकि साझा फ़ॉरवर्डिंग बिंदु पहुँच को एक मेज़मान पर केंद्रित करता है। किसी भी हालत में पते और पोर्ट बदलाव रिकॉर्ड में डालें; अगला व्यक्ति उन्हें दोबारा खोजना नहीं चाहेगा।