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 ഐക്കൺ രണ്ടും തെളിയിക്കുന്നില്ല.

അനുബന്ധ ലേഖനങ്ങൾ