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 चिन्ह दोन्हींपैकी एकही सिद्ध करत नाही।

संबंधित लेख