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'पहिला आदेश पर्यावरण संपवतो, दुसरा वितरण आता कोणता रिझोल्व्हर वापरते हे दाखवतो, आणि शेवटचे दोन प्रत्येक बाजूला तोच प्रश्न विचारतात. सेटिंगची स्थिती नाही, उत्तरांची तुलना करा. दोन्ही फाइल्स बरोबर असतानाही स्वच्छ पुनःसुरुवातीनंतर अयशस्वी होणारी क्वेरी कॉर्पोरेट रिझोल्व्हर धोरणाकडे निर्देश करते, आणि त्या संभाषणाचा मालक वेगळा आहे.