WSL 2 में resolv.conf: VPN जुड़ते ही DNS काम करना बंद कर देता है

डिस्ट्रिब्यूशन के अंदर ब्राउज़िंग काम करती है, और सुरंग ऊपर आते ही पहला आंतरिक होस्टनाम विफल हो जाता है। स्वाभाविक प्रतिक्रिया है सार्वजनिक रिज़ॉल्वर जोड़ना, जो इंटरनेट लौटा देता है और कॉर्पोरेट नाम को बाकी दिन के लिए अगम्य बना देता है। WSL 2 में, /etc/resolv.conf कॉन्फ़िगरेशन नहीं बल्कि जनरेट किया गया आउटपुट है, और समझने योग्य तंत्र यही है। समाधान बेहतर रिज़ॉल्वर नहीं, फ़ाइल पर स्वामित्व है।

फ़ाइल जनरेट होती है, कॉन्फ़िगर नहीं

WSL 2 स्टार्टअप पर उस समय दिखने वाले Windows एडाप्टरों से फ़ाइल लिखता है और ऊपर एक टिप्पणी छापता है जो यही कहती है। बाद में जब कोई VPN क्लाइंट एडाप्टर जोड़ता या फिर से लिखता है, तो डिस्ट्रिब्यूशन ज़रूरी नहीं कि कुछ फिर बनाए, और फ़ाइल ऐसे नेटवर्क का वर्णन करती रहती है जो अब नहीं है।

विफलता का दूसरा तरीका अधिक शांत है: WSL केवल कुछ एडाप्टरों से सर्वर कॉपी कर सकता है। अगर भौतिक एडाप्टर में पहले से IPv6 रिज़ॉल्वर है, तो VPN एडाप्टर जो IPv4 सर्वर देता है वे जोड़े जाने के बजाय छोड़ दिए जा सकते हैं, और फ़ाइल पूरी दिखती है जबकि वह ठीक उसी सर्वर को छोड़ देती है जो आंतरिक नामों का जवाब देता है।

Windows के दृश्य की तुलना Linux के दृश्य से करें

संपादन से पहले दोनों पक्ष पढ़ें। डिस्ट्रिब्यूशन के अंदर देखें कि फ़ाइल में क्या है और वह सामान्य फ़ाइल है या लिंक। Windows पर हर एडाप्टर का रिज़ॉल्वर सूचीबद्ध करें, उस एडाप्टर सहित जो VPN ने बनाया:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

जब VPN एडाप्टर कॉर्पोरेट सर्वर दिखाता है और Linux कुछ और, तो अंतर पहुँच में नहीं, जनरेशन में है। एडाप्टर सूची के साथ पते भी तुलना करें, क्योंकि गायब एडाप्टर गायब सर्वर की व्याख्या करता है। यही भेद तय करता है कि आप WSL ठीक कर रहे हैं या फ़ायरवॉल, और दोनों में कुछ भी साझा नहीं है।

जनरेशन बंद करें और अपनी फ़ाइल लिखें

एक प्रलेखित सेटिंग WSL को फ़ाइल फिर से लिखने से रोकती है, और वह /etc/wsl.conf में है। उस फ़ाइल में नेटवर्क अनुभाग जोड़ें:

[network]
generateResolvConf = false

फिर Windows से wsl --shutdown के साथ डिस्ट्रिब्यूशन समाप्त करें और उसे फिर शुरू करें। अगर पथ सामान्य फ़ाइल नहीं बल्कि सिम्बॉलिक लिंक है, तो अपनी सामग्री लिखने से पहले लिंक हटाएँ, क्योंकि लिंक से लिखने पर अगली शुरुआत में जनरेट किया गया लक्ष्य फिर बन सकता है। उस क्षण से फ़ाइल आपकी है और कोई उसे फिर से नहीं लिखता।

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

खोज डोमेन के बिना, अपूर्ण होस्टनाम सार्वजनिक मूल के साथ पूरा होता है और ‘ऐसा कोई डोमेन नहीं’ के रूप में लौटता है। timeout मृत पहले सर्वर को हर लुकअप अटकाने से रोकता है, attempts सीमित करता है कि एक लुकअप कितने प्रयास खर्च करे, और rotate पुनः प्रयासों को हमेशा ऊपर से शुरू करने के बजाय फैलाता है। सौदा यह है कि फ़ाइल अब ऐसे VPN का पीछा नहीं करती जिसका रिज़ॉल्वर पता सत्रों के बीच बदलता है।

खिसकने वाले रिज़ॉल्वर को संभालें, फिर सत्यापित करें

कुछ क्लाइंट सत्र-विशिष्ट रिज़ॉल्वर देते हैं, इसलिए स्थिर फ़ाइल अगले कनेक्शन पर टूट जाती है। दो दृष्टिकोण उचित हैं। पता बदलने पर छोटी स्क्रिप्ट से फ़ाइल लिखें, या जनरेशन चालू रखें और सुनिश्चित करें कि WSL जिस एडाप्टर से कॉपी करता है वह कॉर्पोरेट सर्वर रखता है। दूसरे को कोई हुक नहीं चाहिए और जब जनरेशन VPN एडाप्टर छोड़ दे तब विफल होता है; दोनों को अभी भी पहले IPv6 टकराव सुलझाना ज़रूरी है।

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

पैकेट से नहीं, नाम से परीक्षण करें: getent hosts sensor-access0.corp.example रिज़ॉल्वर स्टैक से गुज़रता है, जबकि ping कैश किए गए या शाब्दिक पते के विरुद्ध सफल हो सकता है। फिर डिस्कनेक्ट और पुनः कनेक्ट के बाद दोहराएँ, क्योंकि जो सेटिंग एक बार काम करके फिर शुरू होने पर फिर से जनरेट होती है वह कभी ठीक नहीं हुई थी। पिछली सामग्री सहेजें और लिखें कि उस मशीन पर पथ किस घटक का है, ताकि अगला बदलाव प्रमाण के साथ शुरू हो।