VPN जोडिँदा WSL कार्य होस्टनाम किन गुमाउँछ?
उही नाम Windows मा काम गर्छ र सुरुङ उठ्ने बित्तिकै WSL भित्र असफल हुन्छ। रिजोल्भर थप्नु अघि प्लेटफर्मको DNS मोड र पुराना ओभरराइडहरू जाँच्नुहोस्।
Windows आन्तरिक होस्टलाई कुनै गुनासो बिना रिजोल्भ गर्छ, र उही नाम सुरुङ उठ्ने क्षणमै WSL भित्र असफल हुन्छ। सामान्य समाधान भनेको वितरणभित्र सार्वजनिक रिजोल्भर लेख्नु हो, जसले सामान्य ब्राउजिङ फर्काउँछ र कार्य होस्टनामलाई रिजोल्भ गर्न नसकिने बनाउँछ। यसले एउटा असफलतालाई अर्कोसँग साट्छ र वास्तवमा भाँचिएको तह लुकाउँछ। कुनै पनि रिजोल्भर लाइन थप्नु वा हटाउनु अघि तीनमध्ये कुन तह असफल भइरहेको छ निर्धारण गर्नुहोस्।
पहिले राउटिङ असफलता बाहिर राख्नुहोस्
दुवै तर्फ उही पूर्ण योग्य नाम सोध्नुहोस्, उस्तै देखिने दुई नाम होइन। एउटै स्ट्रिङका लागि Windows मा सफलता र WSL मा असफलता दुई फरक रिजोल्युसन मार्गको हस्ताक्षर हो, र यो ढाँचा यति सफा रूपमा अरू थोरैले मात्र बनाउँछ। यदि WSL ले सेवाको ज्ञात सङ्ख्यात्मक ठेगानामा पनि पुग्न सक्दैन भने राउटिङ वा फिल्टरिङ समस्या पनि छ। त्यस्तो अवस्थामा DNS को कामले त्यो खुलासा गर्दैन, र दिउँसो गलत तहमा जान्छ।
तीन लक्षणहरूले यी अधिकांश अवस्था समेट्छन्, र प्रत्येकले फरक ठाउँतिर सङ्केत गर्छ। कन्फिगरेसन फाइल खोल्नु अघि मिल्ने पङ्क्ति पढ्नुहोस्:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
बीचको पङ्क्ति मानिसहरूले गलत पढ्ने पङ्क्ति हो, किनकि त्यसलाई भाँच्ने परिवर्तन हप्तौं अघि गरिएको थियो र त्यतिबेला सफल देखिन्थ्यो। तेस्रो पङ्क्ति मानिसहरूले गलत निदान गर्ने पङ्क्ति हो, किनकि रिजोल्भ हुने नाम नेटवर्क स्वस्थ भएको प्रमाणजस्तो लाग्छ। दुवै पङ्क्तिले तपाईंलाई तलको फरक खण्डमा पठाउँछन्।
DNS सुरुङमा न्यूनतम संस्करण सीमा छ
Microsoft ले भर्चुअलाइजेसन च्यानलमार्फत DNS अनुरोधहरू Windows रिजोल्भरमा सुरुङ गर्ने WSL नेटवर्किङ मोडको दस्तावेजीकरण गर्छ। समर्थित Windows 11 बिल्डहरूमा यो पूर्वनिर्धारित रूपमा सक्रिय हुन्छ, त्यसैले एउटै कर्पोरेट नेटवर्कका दुई मेसिन फरक व्यवहार गर्छन्। परिवर्तनशील कुरा बिल्ड नम्बर हो, कर्पोरेट नीति होइन।
WSL नेटवर्किङ गाइड ले त्यो मोड र यसलाई समर्थन गर्ने संस्करणहरू वर्णन गर्छ। यो सुविधा महत्त्वपूर्ण छ किनकि कर्पोरेट DNS नीति सामान्यतया Windows रिजोल्भरमा बस्छ, र Windows को मार्ग पाइने वितरणले नीति पनि सँगै पाउँछ। सार्वजनिक रिजोल्भरलाई सोध्ने वितरणसँग निजी नामसम्म कुनै मार्ग हुँदैन, यसको आफ्नै कन्फिगरेसन जतिसुकै सफा देखिए पनि। त्यही कार्यविधिले सम्पूर्ण लक्षण व्याख्या गर्छ, र सार्वजनिक-रिजोल्भर उपाय किन असफल हुन्छ भन्ने पनि व्याख्या गर्छ।
केही सम्पादन गर्नु अघि बिल्ड पढ्नुहोस्। नयाँ इन्स्टलेसनबाट प्रतिलिपि गरिएको सेटिङ पुरानोले त्यो लागू गर्छ भन्ने प्रमाण होइन। परिवर्तनको छेउमा बिल्ड नम्बर लेख्नुहोस्, किनकि दुई मेसिनबीचको फरक लगभग सधैं नीति होइन, संस्करण हो।
पुराना ओभरराइडहरूले आफूले समाधान गरेको समस्याभन्दा लामो बाँच्छन्
पुराना विधिहरू उत्पन्न हुने रिजोल्भर फाइलहरू असक्षम पार्थे, नेमसर्भर हार्डकोड गर्थे वा फाइललाई अपरिवर्तनीय विशेषताले लक गर्थे। ती परिवर्तनहरू तिनीहरूलाई निम्त्याउने कनेक्टिभिटी समस्या हराएको लामो समयपछि पनि आफ्नै ठाउँमा रहन्छन्, र नयाँ सेटिङले केही नगरेजस्तो देखिनुको कारण सामान्यतया तिनीहरू नै हुन्। तिनीहरू वितरणको पुनःस्थापनापछि पनि shell प्रोफाइलको रूपमा टिक्छन्, जसले हरेक लगइनमा फाइल पुनः लेख्छ। अन्तिमलाई भेट्टाउन सबैभन्दा कठिन छ, किनकि सबैले जाँच्ने फाइलबाट त्यो अदृश्य हुन्छ।
हातले लेखिएको रिजोल्भर फाइल, त्यसमाथि अपरिवर्तनीय विशेषता, र त्यसलाई पुनः लेख्ने स्टार्टअप स्क्रिप्ट खोज्नुहोस्। सम्पादन गर्नु अघि अपरिवर्तनीय झन्डा जाँच्नुहोस्, किनकि लक गरिएको फाइलमा लेख्ने काम अनुमति समस्याजस्तो पढिने तरिकाले असफल हुन्छ। त्यसपछि shell प्रोफाइल जाँच्नुहोस्, किनकि त्यहाँको स्क्रिप्टले तपाईंको सुधारपछि केही सेकेन्डभित्र पुरानो सामग्री फर्काउँछ।
ओभरराइड हटाउनुका परिणाम हुन्छन्, त्यसैले के हटाउनुभयो र किन लेख्नुहोस्। अर्को उद्देश्यका लागि साँच्चै स्थिर रिजोल्भर चाहिने वितरण उत्पन्न फाइल फर्केपछि भाँचिन्छ।
दुई फाइल, दुई फरक भूमिका
दुवै कन्फिगरेसन फाइलहरू फरक ठाउँमा बस्छन् र फरक कुरा नियन्त्रण गर्छन्, र तिनीहरूलाई गलत मिसाउँदा गलत तहमा लागू हुने सम्पादन बन्छ। Windows तर्फको फाइलले भर्चुअल मेसिनका गुण सेट गर्छ, जबकि वितरण तर्फको फाइलले त्यो वितरणले आफ्नै रिजोल्भर कन्फिगरेसन कसरी बनाउँछ भन्ने सेट गर्छ। कुनैले अर्कोलाई ओभरराइड गर्दैन, त्यसैले दुवै मिल्नुपर्छ।
यो सुविधा समर्थन गर्ने इन्स्टलेसनका लागि Windows तर्फको टुक्रा छोटो छ। त्यो तर्फको सम्पूर्ण परिवर्तन यही हो:
[wsl2]
dnsTunneling=trueत्यो टुक्रा Windows प्रयोगकर्ता प्रोफाइलमा जान्छ र एउटा वितरणमा होइन, भर्चुअल मेसिनमा लागू हुन्छ। सुरुङका लागि वितरणले रिजोल्भर उत्पादन असक्षम नगरेको पनि आवश्यक छ, त्यसैले वितरण तर्फको फाइलले त्यो व्यवहार शान्त छोड्नुपर्छ। एउटा अर्को बिना बदल्नुहोस् र मोड चुपचाप केही गर्दैन, र यो सुधार भाँचिएको भनी रिपोर्ट गर्ने सबैभन्दा सामान्य तरिका यही हो। दुवै फाइल एउटै सत्रमा जाँच्नुहोस्, किनकि हप्तौंको अन्तरमा गरिएका दुई सम्पादन यस्ता दुई सम्पादन हुन् जसलाई कसैले जिम्मा लगाउन सक्दैन।
पुनः सुरु गर्नुहोस्, त्यसपछि दुवै तर्फबाट सोध्नुहोस्
यी सेटिङहरू वातावरण सुरु हुँदा पढिन्छन्, त्यसैले चलिरहेको वितरणभित्रको नयाँ shell ले तिनीहरू पुनः लोड गर्दैन। shell पुनः सुरु गर्नुको सट्टा वातावरण बन्द गर्नुहोस्, र पहिले चलिरहेको काम सुरक्षित गर्नुहोस् किनकि हरेक वितरण त्यससँगै रोकिन्छ। यही एउटा छुटले परिवर्तनको कुनै प्रभाव नभएको अधिकांश रिपोर्ट व्याख्या गर्छ।
त्यसपछि दुवै तर्फ उही प्रश्न सोध्नुहोस्। आउटपुटले वितरण अन्ततः कुन रिजोल्भरसँग रह्यो पनि देखाउँछ:
wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'पहिलो आदेशले वातावरण अन्त्य गर्छ, दोस्रोले वितरणले अहिले कुन रिजोल्भर प्रयोग गर्छ देखाउँछ, र अन्तिम दुईले हरेक तर्फ उही प्रश्न राख्छन्। सेटिङको स्थिति होइन, उत्तरहरू तुलना गर्नुहोस्। दुवै फाइल ठीक हुँदा पनि सफा पुनःसुरुवातपछि असफल हुने क्वेरीले कर्पोरेट रिजोल्भर नीतितिर सङ्केत गर्छ, र त्यो कुराकानीको मालिक अर्कै छ।