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 साठवलेल्या किंवा शब्दशः पत्त्यावर यशस्वी होऊ शकते। मग जोडणी तोडून पुन्हा जोडल्यावर पुन्हा करा, कारण एकदा चालणारी आणि पुन्हा सुरू होताना पुन्हा तयार होणारी सेटिंग कधीच दुरुस्त झाली नाही। आधीचा मजकूर जतन करा आणि त्या मशीनवर मार्ग कोणत्या घटकाच्या मालकीचा आहे ते नोंदवा, जेणेकरून पुढील बदल पुराव्याने सुरू होईल।