होस्ट VPN मा जोडिएपछि VirtualBox गेस्टको DNS बिग्रन्छ

VPN जोडिने क्षणमै Windows होस्टमा आन्तरिक अनुप्रयोग रिजोल्भ हुन्छ, तर VirtualBox NAT पछाडिको Ubuntu गेस्टले अझै भेट्टाउन सक्दैन। गेस्टको आफ्नै रिजोल्भर छ र NAT एडाप्टरले DNS लाई एकभन्दा बढी तरिकाले ह्यान्डल गर्न सक्छ। गेस्टको रिजोल्भरलाई सार्वजनिक सर्भरले बदल्दा सामान्य वेबसाइट चल्छन् र निजी नाम असफल हुन्छन्, जसले समस्या समाधान नगरी अन्यत्र सार्छ। चारै जाँच क्रममा गर्नु र नमिल्ने पहिलोमा रोक्नु।

तपाईं कुन एडाप्टर मोड डिबग गर्दै हुनुहुन्छ त्यो पुष्टि गर्नु

यो लेखले वर्णन गरेझैं साधारण NAT मोडको एडाप्टर मात्र व्यवहार गर्छ। ब्रिज एडाप्टर आफ्नै पहिचानसहित भौतिक सञ्जालमा बस्छ, NAT सञ्जाल आफ्नै DHCP र DNS सेटिङ भएको नामित भर्चुअल स्विच हो, र गेस्टभित्रको VPN क्लाइन्टले पूर्ण रूपमा दोस्रो रिजोल्भर थप्छ। पढ्न अगाडि बढ्नुअघि मोड पुष्टि गर्नु, किनकि यी प्रत्येक अवस्थामा मर्मत फरक हुन्छ।

एउटा VM ले फरक मोडमा दुई एडाप्टर बोक्न सक्छ, र प्रभावित एडाप्टर सधैं पहिलो हुँदैन।

होस्टले त्यो नाम नै रिजोल्भ गर्छ कि भनेर पनि पुष्टि गर्नु। टनेल उठाएर होस्टमा त्यही अनुप्रयोग खोल्नु, र गेस्टले प्रयोग गर्ने त्यही पूर्ण योग्य नाम प्रयोग गर्नु। होस्ट पनि असफल भए दोष गेस्टको होइन र कुनै भर्चुअल नेटवर्किङ परिवर्तनले त्यो सुधार्दैन।

गेस्टको रिजोल्भर हुँदै एउटा नाम पछ्याउनु

एउटा आन्तरिक नाम र एउटा सार्वजनिक नियन्त्रण नाम छान्नु, त्यसपछि दुवैलाई दुवै ठाउँमा परीक्षण गर्नु। निजी नाम रिजोल्भ नहुँदा सार्वजनिक नाम रिजोल्भ हुनुले त्रुटि सामान्य नाम रिजोल्भिङमा नभई निजी मार्गमा रहेको देखाउँछ। केवल निजी नाम परीक्षण गर्दा बिग्रिएको रिजोल्भर र बिग्रिएको मार्ग छुट्याउन सकिँदैन।

गेस्टभित्र रिजोल्भर वास्तवमा के प्रयोग गर्न कन्फिगर छ हेर्नु। systemd-resolved चलाउने Ubuntu गेस्टमा प्रत्येक लिंकको स्थितिले आएका सर्भर देखाउँछ, र resolv.conf फाइलमा स्टब ठेगाना मात्र हुन सक्छ, जो सही हो, शंकास्पद होइन। हातले सम्पादित फाइल वा छुट्टै इन्क्रिप्टेड-DNS क्लाइन्टले खोजी अन्यत्र पठाउन सक्छ। परिवर्तन गर्नुअघि भेटेको कुरा लेख्नु।

resolvectl status
resolvectl query app.internal.example

यहाँ रिजोल्भिङलाई पहुँचबाट अलग गर्नु। सेवा पहुँचबाहिर रहँदा आउने ठेगाना DNS होइन, राउटिङ वा नीतिको प्रश्न हो।

त्यो एडाप्टरमा होस्ट रिजोल्भर मोड प्रयास गर्नु

VirtualBox का NAT DNS विकल्पले फरक संयन्त्र वर्णन गर्छन्, र होस्टको आफ्नै रिजोल्भर टनेलसँगै बदलिँदा यो भिन्नता महत्त्वपूर्ण हुन्छ। DNS प्रोक्सीले गेस्टका अनुरोधलाई आफूलाई दिइएका सर्भरमा पठाउँछ। होस्ट रिजोल्भर मोडले अनुरोध रोकेर होस्टको DNS API बोलाउँछ, र VPN क्लाइन्टले पुनःकन्फिगर गरेको Windows रिजोल्भर पछ्याउने मोड यही हो।

गलत संयन्त्र सक्रिय गर्दा आदेश सफल हुन्छ तर व्यवहार बदलिँदैन, जो दिउँसो बर्बाद गर्ने भ्रमित तरिका हो।

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

VM का हालका सेटिङ लेख्नु, त्यसलाई बन्द गर्नु र पहिले पुष्टि गरेको एडाप्टर लक्षित गर्नु। विकल्पको अन्तिम अंक स्थिरांक होइन, एडाप्टर नम्बर हो, त्यसैले प्रभावित एडाप्टर दोस्रो भएको VM मा यो लागू गर्नु शान्त निष्क्रिय कार्य हो। गेस्ट सुरु गर्नु र यसले वास्तवमा पाएको रिजोल्भर कन्फिगरेसन जाँच्नु, किनकि गेस्टमा हातले गरेको सेटिङले NAT तहले दिने सबैलाई जित्छ। होस्ट रिजोल्भर मोडले होस्टको आफ्नै DNS मार्ग नै तपाईंले साझा गर्न चाहेको हो भन्ने पनि मान्छ भन्ने सम्झनु।

VPN पुनःजडानभरि तीही परीक्षण दोहोर्याउनु

गेस्टमा दुवै खोजी दोहोर्याउनु, त्यसपछि साँचो अनुप्रयोग खोलेर प्रमाणपत्र आफैं प्रमाणित गर्न दिनु। ठेगानामा मात्र आधारित परीक्षण नाम रिजोल्भिङ अलग गर्न उपयोगी छ र काम गर्ने TLS सत्रसँग बराबर होइन, त्यसैले ping मा रोक्नु हुँदैन। त्यसपछि स्वीकृत समयमा होस्ट टनेल विच्छेद र पुनः जोडेर अझै एकपटक दोहोर्याउनु। बुटपछिको पहिलो जडानमा मात्र टिक्ने व्यवहार रिपोर्ट गर्नुपर्ने जीवनचक्र समस्या हो, अर्को रिजोल्भरले पछ्याउने DNS रहस्य होइन।

सार्वजनिक रिजोल्भिङ चल्नुले निजी प्रश्नहरू तपाईंको नीतिले माग्ने मार्गमै रहे भन्ने प्रमाण दिँदैन।

होस्ट रिजोल्भर मोडले केही बदलेन भने, लेखिएको कन्फिगरेसन फर्काउनु र चार अवलोकन राख्नु: होस्टले के फर्कायो, गेस्टले के फर्कायो, एडाप्टर मोड र रिजोल्भरको स्थिति। पहुँचबाहिरको आन्तरिक सर्भर, हाइपरभाइजर ट्राफिक बाहिर राख्ने फिल्टर र गेस्टतर्फको ओभरराइड प्रत्येकलाई फरक सुधार चाहिन्छ। एडाप्टरलाई ब्रिजमा बदल्नुले सञ्जाल डिजाइन बदल्छ र त्यो DNS रिसेट होइन।