VPN जुड़ने के बाद WSL2 ने DNS खो दिया? दो कारण

पते से ping डिस्ट्रिब्यूशन के भीतर काम करता है, पैकेज इंस्टॉल और git खींचना नहीं, और विफलता टनल ऊपर आने के ठीक बाद दिखी। केवल नाम हल होना बंद हुआ, जो DNS की ओर इशारा करता है, कनेक्टिविटी की ओर नहीं। पैकेज फिर से इंस्टॉल करना यहाँ सबसे लोकप्रिय गलत पहला कदम है। WSL2 के पास ठीक यही लक्षण पैदा करने के दो स्वतंत्र तरीके हैं, और दोनों को अलग मरम्मत चाहिए।

डिस्ट्रिब्यूशन अपना resolver क्यों रखता है

Windows का DNS क्लाइंट डिस्ट्रिब्यूशन के भीतर इस्तेमाल नहीं होता। WSL2 शुरू होते समय अपनी resolver फ़ाइल बनाता है, जो एक stub पते की ओर इशारा करती है जिसे Windows सहायक वर्चुअल मशीन के लिए वर्चुअल स्विच पर प्रकाशित करता है।

सामान्य नेटवर्क बदलावों में यह व्यवस्था स्थिर रहती है क्योंकि यह एक बार लिखी जाती है और दोबारा इस्तेमाल होती है। जब टनल क्लाइंट सहायक वर्चुअल मशीन के पहले से शुरू हो जाने के बाद होस्ट की एडाप्टर सूची फिर से लिखता है, तो यह व्यवस्था सही नहीं रहती।

डिस्ट्रिब्यूशन के भीतर कुछ भी इस बदलाव पर नज़र नहीं रखता, इसलिए फ़ाइल ऐसे पते की ओर इशारा करती रहती है जो शायद अब मार्ग पर न हो। अगली लुकअप तब प्रतीक्षा करती है, समय-सीमा खत्म होती है, या ऐसे सर्वर से उत्तर मिलता है जिसने आंतरिक ज़ोन के बारे में कभी नहीं सुना। भीतर से resolver केवल उत्तर देना बंद कर देता है, और सभी नाम एक साथ विफल होते हैं।

पहले दोनों पक्षों के प्रमाण जुटाएँ

कुछ भी बदलने से पहले दर्ज करें कि डिस्ट्रिब्यूशन क्या देखता है, फिर Windows क्या देखता है। दोनों दृश्य मिलकर ही विफलता के प्रकार अलग करते हैं।

डिस्ट्रिब्यूशन के भीतर, resolver फ़ाइल, रूटिंग तालिका और एक आंतरिक तथा एक सार्वजनिक लुकअप छापें:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Windows पर, प्रत्येक एडाप्टर के अनुसार DNS सर्वर और मीट्रिक के साथ IPv4 तालिका सूचीबद्ध करें। VPN क्लाइंट आमतौर पर WSL2 सबनेट के लिए एक रूट स्थापित करता है, और उसका मीट्रिक तय करता है कि वह ट्रैफ़िक टनल से बाहर जाए या स्थानीय रहे।

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

रूट मीट्रिक या पुरानी फ़ाइल

पहली विफलता पुरानी फ़ाइल है। resolver शुरुआत के समय की एडाप्टर स्थिति के लिए लिखा गया था, और टनल ने वह स्थिति बदल दी। उसका stub पता अब पहुँच से बाहर हो सकता है, या वह ऐसे सर्वर का नाम ले सकता है जो आंतरिक ज़ोन के बारे में कुछ नहीं जानता।

दूसरी रूटिंग की समस्या है। जब VPN WSL2 सबनेट को कवर करने वाला रूट जोड़ता है होस्ट लिंक रूट से कम मीट्रिक के साथ, तब सहायक वर्चुअल मशीन को संबोधित पैकेट टनल में प्रवेश करते हैं। फिर केवल DNS ही नहीं, हर WSL2 सेवा का समय खत्म होता है।

भेद करने वाली जाँच में एक पंक्ति लगती है। अगर सार्वजनिक resolver जैसा संख्यात्मक पता नाम विफल रहने पर भी ping का उत्तर देता है, तो मार्ग अक्षुण्ण है और समस्या DNS है। यही वह स्थिति है जिसमें resolver बदलना उचित है, और जिसमें नहीं है वह भी स्पष्ट हो जाती है। अगर संख्यात्मक जाँच भी विफल हो, तो सहायक वर्चुअल मशीन ने अपना मार्ग खो दिया है और कोई resolver फ़ाइल उसे ठीक नहीं करेगी।

रूटिंग के मामले में, टनल एडाप्टर पर स्वचालित मीट्रिक हटाएँ और उसे WSL2 लिंक रूट से ऊपर की संख्या दें:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

बंद करना मायने रखता है। मीट्रिक बदलना चल रही सहायक वर्चुअल मशीन को फिर से नहीं लिखता, इसलिए बदलाव दिखने से पहले डिस्ट्रिब्यूशन को फिर से बनाना पड़ेगा।

फ़ाइल जानबूझकर अपने हाथ में लें

अगर रूटिंग सही है और केवल आंतरिक नाम विफल हो रहे हैं, तो दोष resolver का है और आप जनरेटर रोक सकते हैं। यह रखरखाव लागत वाला जानबूझकर किया गया बदलाव है, लापरवाही से लगाने का कोई उपाय नहीं।

डिस्ट्रिब्यूशन के भीतर जनरेशन बंद करने वाले नेटवर्क खंड के साथ /etc/wsl.conf बनाएँ, फिर resolver फ़ाइल स्वयं लिखें, पहले कॉर्पोरेट सर्वर और फिर सार्वजनिक वैकल्पिक:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

क्रम मायने रखता है। सार्वजनिक resolver आंतरिक नाम का उत्तर नहीं दे सकता, और वैकल्पिक केवल इंटरनेट लुकअप के लिए है। फ़ाइल एक बार आपकी हो जाए, तो कोई उसे फिर से नहीं बनाता, इसलिए स्थानांतरित होने वाला कॉर्पोरेट resolver ऐसा व्यवधान बन जाता है जिसे आपको स्वयं ध्यान में लाना होगा।

पहले नाम जाँचें, फिर पैकेज

सिस्टम resolver से एक आंतरिक और एक सार्वजनिक नाम सत्यापित करें, फिर वह क्रिया दोहराएँ जो विफल हुई थी। पैकेज प्रबंधक कभी-कभी अपना resolver इस्तेमाल करते हैं, इसलिए काम करता getent टूटी इंस्टॉल के साथ भी मौजूद रह सकता है।

अगर आप फिर से लिखना स्वचालित करते हैं, तो उसे समान परिणाम देने वाला बनाएँ: टनल न हो तो खाली सर्वर सूची लिखने के बजाय पहले से मौजूद फ़ाइल रखें।

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

डिस्ट्रिब्यूशन के भीतर से काम करता आंतरिक लुकअप और काम करता सार्वजनिक लुकअप ही दर्ज करने योग्य परिणाम है। होस्ट पर हरा VPN चिह्न दोनों में से किसी को सिद्ध नहीं करता।