VMware का ब्रिज वाला गेस्ट OpenVPN के बाद अपना नेटवर्क खो बैठा

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

गेस्ट नहीं बदला, ब्रिज बदला

Windows पर OpenVPN क्लाइंट स्थापित करने से एक वर्चुअल नेटवर्क अडैप्टर जुड़ता है, जिससे सेवा तब बँधती है जब टनल ऊपर आता है। ऑपरेटिंग सिस्टम के लिए यह लिंक स्थिति वाला एक साधारण इंटरफ़ेस और अक्सर अपने ही पतों वाला दिखता है। यही VMware के लिए इसे ब्रिज उम्मीदवार मानने को काफ़ी है।

VMnet0 डिफ़ॉल्ट रूप से स्वचालित पर सेट है, यानी हाइपरवाइज़र हर बार ब्रिज बनाते समय एक होस्ट अडैप्टर चुनता है। नया स्थापित वर्चुअल अडैप्टर उस पूल में शामिल हो जाता है, और अगर उसे चुना जाए, तो गेस्ट का भेजा हर फ़्रेम भौतिक स्विच पोर्ट के बजाय टनल डिवाइस पर जाता है।

ब्रिज पिन करें या गेस्ट को रूट करें

पहली शाखा तब सही है जब गेस्ट को भौतिक LAN पर बराबर का सदस्य होना है: ब्रिज को चुनने देना बंद करें, और अडैप्टर का नाम स्पष्ट रूप से लें। दूसरी शाखा तब लागू होती है जब गेस्ट को कॉर्पोरेट टनल इस्तेमाल करना है, और उस स्थिति में ब्रिज कभी सही डिज़ाइन नहीं था, क्योंकि ब्रिज वाला गेस्ट होस्ट का VPN रूट विरासत में नहीं पाता।

यह पहले तय करें, क्योंकि दोनों जवाब अलग काम की ओर ले जाते हैं। क्रम उलटने से सही ढंग से पिन किया ब्रिज बनता है, पर वह ऐसे गेस्ट से जुड़ा होता है जिसे कभी ब्रिज नहीं करना चाहिए था।

पहली शाखा के लिए होस्ट पर वर्चुअल नेटवर्क एडिटर खोलें, VMnet0 चुनें और स्वचालित को भौतिक अडैप्टर से बदलें। अगर कई अडैप्टर हैं, तो स्वचालित सेटिंग्स की सूची इस्तेमाल करें और हर उस चीज़ का निशान हटाएँ जिसे कभी गेस्ट ट्रैफ़िक नहीं ढोना चाहिए: OpenVPN TAP या Wintun डिवाइस, साथ ही Hyper-V, WSL, Docker और loopback अडैप्टर। लैपटॉप पर वायर्ड और वायरलेस दोनों भौतिक अडैप्टर चिह्नित रखें, वरना अगली बार जब उपयोगकर्ता इसे डॉक में लगाएगा तो गेस्ट अपना ब्रिज खो देगा।

तीन शर्तें जो चुनाव तय करती हैं

ब्रिज उपयुक्त है या नहीं यह इस पर निर्भर है कि गेस्ट किस लिए है। अगर गेस्ट को LAN पर अपने अलग होस्ट के रूप में दिखना है, अपने पते और अपनी इनबाउंड पहुँच के साथ, तो ब्रिज सही मॉडल है और पिन करना पूरा सुधार है। अगर गेस्ट को केवल आउटबाउंड पहुँच चाहिए, तो होस्ट-ओनली या NAT नेटवर्क आसान है और अडैप्टर बदलने से अप्रभावित रहता है।

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

VMware Player के इंटरफ़ेस में नेटवर्क एडिटर नहीं है, इसलिए जो होस्ट केवल Player चलाता है उसे इन सेटिंग्स तक पहुँचने के लिए अलग एडिटर या Workstation इंस्टॉल चाहिए। यह बाधा कभी-कभी दृष्टिकोण अकेले ही तय कर देती है।

परिणाम गेस्ट के अंदर से पढ़ें

वर्चुअल NIC को फिर से चालू करें, या गेस्ट को फिर से चालू करें, ताकि वह दोबारा लीज़ माँगे। फिर पढ़ें कि उसे वास्तव में क्या मिला, न कि वह क्या जो होस्ट सोचता है कि उसने कॉन्फ़िगर किया है।

ipconfig /all
ip addr
ip route

उस आउटपुट में दो फ़ील्ड पढ़ें और बाकी को अभी अनदेखा करें। गेटवे LAN राउटर होना चाहिए, और अडैप्टर का विवरण टनल के बजाय VMware Ethernet डिवाइस बताना चाहिए। 169.254.0.0/16 में स्वयं आवंटित पता इसका मतलब है कि कोई DHCP सर्वर जवाब नहीं दे पाया, और गेस्ट की ओर से टनल अडैप्टर पर ब्रिज ठीक ऐसा दिखता है।

कुछ और बदलने से पहले एक और अंतर करना उचित है। जो गेस्ट राउटर तक पहुँचता है पर इंटरनेट तक नहीं, उसका ब्रिज काम कर रहा है और समस्या ऊपर की ओर है। जो गेस्ट टनल की श्रेणी में पता पाता है वह अब भी गलत डिवाइस से जुड़ा है। TAP अडैप्टर बंद करना दोनों में से किसी भी स्थिति का हल नहीं है, क्योंकि OpenVPN सेवा को उसकी ज़रूरत है।