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 നോക്കുന്നത് നിർത്തി ആ പ്രിഫിക്സിനുള്ള കാണാത്ത റൂട്ട് തിരയുക. അടുത്ത പുനഃബന്ധനം വരെ എല്ലാം പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, റൺടൈം അവസ്ഥയെ ആശ്രയിക്കുന്ന ഒരു അറ്റകുറ്റപ്പണി നിങ്ങൾ കണ്ടെത്തി, അത് സ്വയമേവ വീണ്ടും പ്രയോഗിക്കണം അല്ലെങ്കിൽ മുകളിലുള്ള രണ്ട് മെക്കാനിസങ്ങളിൽ ഒന്ന് ഉപയോഗിച്ച് മാറ്റണം.