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 टनेलिङले क्लाइन्टले DNS सूची पुनःलेख्दा पनि Windows resolver मार्फत खोज फर्वार्ड गर्छ। यो सार्वभौमिक होइन: केही फिल्टर ड्राइभरहरूले अझै मिरर बाटो छोड्छन्, र Hyper-V फायरवाल नियमहरूलाई स्पष्ट अनुमति चाहिन सक्छ। Microsoft को WSL नेटवर्किङ गाइड नयाँका लागि लेखिएको विधि लागू गर्नुअघि तपाईंको बिल्डसँग मिलाएर हेर्नुपर्ने पृष्ठ हो।
हरेक परिवर्तनपछि तीन कुरा परीक्षण गर्नुहोस्
प्रत्येक मेसिनका लागि एउटा संयन्त्र छान्नुहोस् र लेख्नुहोस्, किनकि दुवै नराम्ररी मिल्छन्। मिरर मोडमाथि sidecar ले फर्वार्डिङ दोब्बर बनाउँछ, र .wslconfig मा पुरानो sidecar प्रविष्टि भएको मिरर होस्ट अपग्रेडपछि असफल हुन्छ, अघि होइन।
तपाईंले जे छाने पनि, स्वीकृति परीक्षण डिस्ट्रिब्युसनभित्रका तीही तीन अनुरोध हुन्: आन्तरिक नाम, सार्वजनिक नाम र कच्चा ठेगाना। त्यसपछि टनेल विच्छेद र पुनःजडान गरेपछि, र wsl --shutdown पछि तिनीहरूलाई दोहोर्याउनुहोस्। केवल आन्तरिक नाम असफल हुनु resolver नीति हो; आन्तरिक र सार्वजनिक नाम सँगै असफल हुँदा ठेगाना चलिरहेको भए पनि resolver नीति हो; सबै असफल हुनु बाटो हो।
एउटा आन्तरिक होस्ट असफल भयो तर बाँकी चल्छन् भने resolver हेर्न छोड्नुहोस् र त्यो प्रिफिक्सका लागि हराएको रुट खोज्नुहोस्। अर्को पुनःजडानसम्म सबै चल्छ भने तपाईंले रनटाइम अवस्थामा निर्भर सुधार भेट्नुभयो, र त्यो स्वचालित रूपमा पुनः लागू गर्नुपर्छ वा माथिका दुई संयन्त्रमध्ये एउटाले बदल्नुपर्छ।