WSL2 कॉर्पोरेट VPN का वारिस नहीं होता, और बग यही है
WSL2 अपने अलग वर्चुअल नेटवर्क में चलता है और होस्ट के VPN स्टैक का कभी वारिस नहीं होता। resolv.conf में बदलाव करने से पहले नाम की विफलताओं को पाथ की विफलताओं से अलग करें।
आंतरिक विकी Edge में लोड होती है, जबकि डिस्ट्रिब्यूशन के अंदर git clone टाइम आउट हो जाता है। यह अकेला अवलोकन आम तौर पर «VPN WSL2 को ब्लॉक कर रहा है» के रूप में पढ़ा जाता है, और अगला घंटा /etc/resolv.conf संपादित करने में जाता है। अधिक उपयोगी पाठ यह है कि WSL2 के पास होस्ट का नेटवर्क पाथ कभी था ही नहीं: यह अपने अडैप्टर, अपने रूट और Windows द्वारा इसके लिए बनाई गई resolver फ़ाइल वाले यूटिलिटी VM में चलता है। आगे सब कुछ इस पर निर्भर है कि उन तीन में से वास्तव में कौन सी चीज़ आपके पास नहीं है।
VM का अपना स्टैक, मेट्रिक और resolver है
डिफ़ॉल्ट NAT मोड में, डिस्ट्रिब्यूशन एक वर्चुअल स्विच के पीछे बैठता है और होस्ट के ज़रिए इंटरनेट तक पहुँचता है, लेकिन होस्ट के अडैप्टर नहीं देखता। ip addr निजी पते वाला एक इंटरफ़ेस दिखाता है, ip route उस स्विच के ज़रिए डिफ़ॉल्ट रूट दिखाता है, और /etc/resolv.conf एक जनरेट की गई फ़ाइल है जो Windows द्वारा चुने गए stub resolver की ओर इशारा करती है। Windows की ओर VPN क्लाइंट शुरू होने से इनमें से कुछ भी नहीं बदलता।
इसीलिए «ब्राउज़र काम करता है» इतना कम साबित करता है। ब्राउज़र होस्ट का स्टैक, टनल और होस्ट की resolver नीति इस्तेमाल करता है। आपका शेल एक अलग स्टैक इस्तेमाल करता है जो संयोग से एक फ़िज़िकल नेटवर्क कार्ड साझा करता है। वे सुखद स्थिति में सहमत होते हैं और ठीक तब अलग होते हैं जब VPN फ़िल्टर लगाता है, DNS सूची फिर से लिखता है या वर्चुअल स्विच के सबनेट के लिए रूट जोड़ता है।
दो परीक्षण तय करते हैं कि आप किस दुनिया में हैं, और उन्हें डिस्ट्रिब्यूशन के अंदर चलना चाहिए:
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confशाब्दिक पता जवाब देते समय नाम विफल होना resolver समस्या है। नाम और पते साथ में विफल होना पाथ की समस्या है, और resolver संपादन उसे छुएगा भी नहीं। इसके बाद Windows की ओर से सबूत आते हैं: Get-NetAdapter | Get-DnsClientServerAddress और route print -4 दिखाते हैं कि टनल ने वह सबनेट ले लिया है या नहीं जिसमें आपका VM रहता है।
पहला मिथक: कॉर्पोरेट DNS सर्वर इसे ठीक कर देते हैं
resolver फ़ाइल संपादित करना पुरानी सलाह है, और यह लगभग आधे समय सही होती है। जब सही होती है, तो किसी ख़ास कारण से सही होती है: जनरेट की गई फ़ाइल ऐसे resolver की ओर इशारा करती है जो केवल सार्वजनिक नाम जानता है, इसलिए intranet.example.internal के लिए क्वेरी पाथ ठीक होने पर भी अनुपस्थित के रूप में लौटती है।
VPN के सर्वर पिन करने का मतलब है Windows को फ़ाइल फिर से बनाने से रोकना, क्योंकि हाथ से लिखी कोई भी फ़ाइल अगली शुरुआत में बदल दी जाती है:
[network]
generateResolvConf = falseइसे /etc/wsl.conf के रूप में सहेजें, Windows से wsl --shutdown चलाएँ, फिर डिस्ट्रिब्यूशन शुरू करें और /etc/resolv.conf लिखें जिसमें टनल के सर्वर पहले और सार्वजनिक resolver केवल बैकअप के रूप में हों। यह रखरखाव लागत वाला टिकाऊ बदलाव है: फ़ाइल अब होस्ट का पीछा नहीं करती, इसलिए जब कॉर्पोरेट DNS पते बदलते हैं तो डिस्ट्रिब्यूशन पुराने ही पूछता रहता है। किसी को उस फ़ाइल का मालिक होना चाहिए।
जब विफलता व्यापक हो तो यह कुछ नहीं करता। अगर curl से 1.1.1.1 टाइम आउट हो जाता है, तो टनल क्लाइंट वर्चुअल स्विच को फ़िल्टर कर रहा है या VM के सबनेट को टनल में भेज रहा है, और सही resolver आपको केवल ऐसे नाम देता है जहाँ अभी पहुँचा नहीं जा सकता।
दूसरा मिथक: मेट्रिक बदलाव टिकता है
जब नाम हल हो जाते हैं लेकिन ट्रैफ़िक फ़िज़िकल अडैप्टर से निकलता है, तो इंटरफ़ेस मेट्रिक्स लीवर हैं। VPN अडैप्टर को ऊँची लागत और WSL स्विच को कम लागत दें:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1फिर याद रखें कि कई क्लाइंट बिल्ड में टनल अडैप्टर हर कनेक्शन पर फिर से बनाया जाता है और मेट्रिक अपने डिफ़ॉल्ट पर लौट आती है। एक बार का कमांड ऐसा सुधार है जो चुपचाप समाप्त हो जाता है, आम तौर पर सप्ताहांत में, और टिकट «पिछले हफ़्ते काम कर रहा था» के साथ लौटता है। VPN इवेंट से शुरू होने वाला निर्धारित कार्य, या उपयोगकर्ता द्वारा कनेक्ट होने के बाद चलाई जाने वाली स्क्रिप्ट, इस सुधार का ईमानदार संस्करण है।
वही समाप्ति उन होस्ट रूट पर लागू होती है जो एक ज़िद्दी प्रीफ़िक्स के लिए जोड़े गए थे। निदान के रूप में वे मूल्यवान हैं, क्योंकि वे बताते हैं कि समस्या एक गंतव्य है या पूरा पाथ, लेकिन वे आर्किटेक्चर नहीं हैं।
तीसरा मिथक: एक सुधार हर Windows बिल्ड को कवर करता है
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit sidecar पैटर्न है: एक छोटा डिस्ट्रिब्यूशन होस्ट की ओर का पाथ रखता है और वर्चुअल सॉकेट के ज़रिए दूसरे डिस्ट्रिब्यूशन के लिए फ़ॉरवर्ड करता है, इसलिए एप्लिकेशन ट्रैफ़िक फ़िल्टर किए गए स्विच पर निर्भर रहना छोड़ देता है। इसे स्टॉक पाथ के काम करने की ज़रूरत है, यानी networkingMode और dnsTunneling ओवरराइड %UserProfile%\.wslconfig से हटाना, हर काम करने वाले डिस्ट्रिब्यूशन में generateResolvConf = true बहाल करना और लॉगिन पर सेवा शुरू करना।
मिरर्ड मोड Windows 11 22H2 और उसके बाद में बिल्ट-इन विकल्प है, और यह एक सेटिंग प्लस एक शटडाउन है:
[wsl2]
networkingMode=mirroredडिस्ट्रिब्यूशन के अंदर ip addr फिर होस्ट के अडैप्टर सूचीबद्ध करता है, टनल उनके बीच दिख सकता है, और DNS टनलिंग Windows resolver के ज़रिए लुकअप फ़ॉरवर्ड करती है तब भी जब क्लाइंट DNS सूची फिर से लिखता है। यह सार्वभौमिक नहीं है: कुछ फ़िल्टर ड्राइवर अब भी मिरर्ड पाथ छोड़ देते हैं, और Hyper-V फ़ायरवॉल नियमों को स्पष्ट अनुमति चाहिए हो सकती है। Microsoft की WSL नेटवर्किंग गाइड वह पृष्ठ है जिसे नए के लिए लिखी गई विधि लागू करने से पहले अपने बिल्ड से मिलाना चाहिए।
हर बदलाव के बाद तीन चीज़ें जाँचें
हर मशीन के लिए एक तंत्र चुनें और लिख लें, क्योंकि दोनों बुरी तरह मिलते हैं। मिरर्ड मोड के ऊपर sidecar फ़ॉरवर्डिंग दोगुनी कर देता है, और .wslconfig में पुरानी sidecar प्रविष्टि वाला मिरर्ड होस्ट अपग्रेड के बाद विफल होता है, पहले नहीं।
आपने जो भी चुना हो, स्वीकृति परीक्षण डिस्ट्रिब्यूशन के अंदर वही तीन अनुरोध हैं: एक आंतरिक नाम, एक सार्वजनिक नाम और एक कच्चा पता। फिर टनल को डिस्कनेक्ट और फिर से कनेक्ट करने के बाद, और wsl --shutdown के बाद उन्हें दोहराएँ। केवल आंतरिक नाम विफल होना resolver नीति है; आंतरिक और सार्वजनिक नाम साथ में विफल होना जब पता काम करता है तो भी resolver नीति है; सब कुछ विफल होना पाथ है।
अगर एक आंतरिक होस्ट विफल हो जाता है जबकि बाकी काम करते हैं, तो resolver देखना बंद करें और उस प्रीफ़िक्स के लिए गुम रूट खोजें। अगर सब कुछ अगले पुनःकनेक्शन तक काम करता है, तो आपने रनटाइम स्थिति पर निर्भर सुधार पाया है, और उसे स्वचालित रूप से फिर से लागू करना होगा या ऊपर के दो तंत्रों में से एक से बदलना होगा।