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-ஐப் பார்ப்பதை நிறுத்தி அந்த முன்னொட்டுக்கான காணாமல் போன வழியைத் தேடுங்கள். அடுத்த மறுஇணைப்பு வரை எல்லாம் வேலை செய்தால், இயக்க நேர நிலையைச் சார்ந்த ஒரு பழுதைக் கண்டீர்கள், அது தானாக மீண்டும் பயன்படுத்தப்பட வேண்டும் அல்லது மேலே உள்ள இரண்டு பொறிமுறைகளில் ஒன்றால் மாற்றப்பட வேண்டும்.