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 చిహ్నం రెండింటిలో ఏదీ నిరూపించదు.

సంబంధిత వ్యాసాలు