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 सेवालाई त्यसको आवश्यकता छ।