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 చూడటం ఆపి ఆ ప్రిఫిక్స్ కోసం తప్పిపోయిన మార్గాన్ని వెతకండి. తదుపరి పునఃకనెక్షన్ వరకు అన్నీ పనిచేస్తే, మీరు రన్టైమ్ స్థితిపై ఆధారపడిన సరిచేయడాన్ని కనుగొన్నారు, అది స్వయంచాలకంగా మళ్లీ వర్తించాలి లేదా పైన ఉన్న రెండు మెకానిజమ్లలో ఒకదానితో భర్తీ చేయాలి.