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 पाहणे थांबवा आणि त्या प्रीफिक्ससाठी गहाळ मार्ग शोधा. पुढील पुन्हा कनेक्शनपर्यंत सर्व चालत असेल तर तुम्ही रनटाइम स्थितीवर अवलंबून असलेली दुरुस्ती शोधली आहे, आणि ती स्वयंचलितपणे पुन्हा लागू करावी लागेल किंवा वरील दोन यंत्रणांपैकी एकाने बदलावी लागेल.