VPN जोडिएपछि WSL2 ले DNS गुमायो? दुई कारण

पुरानो resolver फाइल र प्रतिस्पर्धी रुट मेट्रिकले WSL2 भित्र एउटै लक्षण उत्पन्न गर्छन्। दुवै पक्ष रेकर्ड गर्नुहोस्, त्यसपछि साँच्चै बिग्रेको पक्ष मात्र ठीक गर्नुहोस्।

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

किन डिस्ट्रिब्युसनले आफ्नै resolver राख्छ

Windows को DNS क्लाइन्ट डिस्ट्रिब्युसन भित्र प्रयोग हुँदैन। WSL2 सुरु हुँदा आफ्नै resolver फाइल बनाउँछ, जुन Windows ले सहायक भर्चुअल मेसिनका लागि भर्चुअल स्विचमा प्रकाशित गर्ने stub ठेगानातिर देखाउँछ।

यो व्यवस्था सामान्य नेटवर्क परिवर्तनमा स्थिर हुन्छ किनभने यो एक पटक लेखिन्छ र पुनः प्रयोग हुन्छ। सहायक भर्चुअल मेसिन पहिले नै सुरु भइसकेपछि टनेल क्लाइन्टले होस्टको एडाप्टर सूची फेरि लेख्दा यो व्यवस्था सही रहँदैन।

डिस्ट्रिब्युसन भित्र केहीले पनि यो परिवर्तन हेर्दैन, त्यसैले फाइल अब बाटोमा नहुन सक्ने ठेगानातिर देखाउँदै रहन्छ। अर्को लुकअप त्यसपछि पर्खन्छ, समय सकिन्छ, वा आन्तरिक जोनका बारेमा कहिल्यै नसुनेको सर्भरबाट उत्तर आउँछ। भित्रबाट 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 चिन्हले दुवैमध्ये एउटै पनि प्रमाणित गर्दैन।

सम्बन्धित लेखहरू