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 सेवेला त्याची गरज आहे।