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 एक WSL नेटवर्किंग मोड का दस्तावेज़ीकरण करता है जो DNS अनुरोधों को वर्चुअलाइज़ेशन चैनल के ज़रिए Windows रिज़ॉल्वर तक सुरंगता है। समर्थित 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'पहला कमांड पर्यावरण समाप्त करता है, दूसरा दिखाता है कि डिस्ट्रिब्यूशन अब कौन-सा रिज़ॉल्वर इस्तेमाल करता है, और अंतिम दो हर तरफ़ को वही सवाल पूछते हैं। सेटिंग की स्थिति नहीं, जवाबों की तुलना करें। दोनों फ़ाइलें सही होने पर भी साफ़ पुनःआरंभ के बाद विफल रहने वाली क्वेरी कॉर्पोरेट रिज़ॉल्वर नीति की ओर इशारा करती है, और उस बातचीत का मालिक कोई और है।