VPN വിച്ഛേദിച്ചതിന് ശേഷം resolv.conf എഡിറ്റ് ചെയ്യുന്നത് DNS നന്നാക്കുന്നില്ല

നിങ്ങൾ VPN വിച്ഛേദിക്കുന്നു, ping 1.1.1.1 ഇപ്പോഴും ഉത്തരം നൽകുന്നു, പേജ് ഒടുവിൽ കീഴടങ്ങുന്നതിന് മുൻപ് ഓരോ നാമ അന്വേഷണവും തൂങ്ങിക്കിടക്കുന്നു. പിന്നീട് cat /etc/resolv.conf ടണലിനുള്ളിൽ മാത്രം ഉണ്ടായിരുന്ന ഒരു നെയിംസർവർ കാണിക്കുന്നു, സാധാരണയായി ലിസ്റ്റിൽ ആദ്യത്തേത്. ആ വരി ഇല്ലാതാക്കുന്നത് ഏകദേശം പത്ത് മിനിറ്റ് നേരത്തേക്ക് ശരിയാക്കിയതായി തോന്നും, പിന്നീട് സസ്പെൻഡ്, Wi-Fi റോമിംഗ് അല്ലെങ്കിൽ റീസ്റ്റാർട്ട് അത് തിരികെ കൊണ്ടുവരുന്നു. നിങ്ങൾ എഡിറ്റ് ചെയ്ത ഫയൽ ക്രമീകരണമല്ല; അത് മറ്റൊരു ഘടകത്തിന്റെ ഉടമസ്ഥതയിലുള്ള ലിങ്ക് നിലയുടെ ചിത്രീകരണമാണ്.

ഒരു പഴയ എൻട്രി ഓരോ ലുക്കപ്പിനും സെക്കൻഡുകൾ ചെലവാക്കുന്നത് എന്തുകൊണ്ട്

glibc റിസോൾവർ നെയിംസർവർ ലിസ്റ്റ് ക്രമത്തിൽ സഞ്ചരിച്ച് അടുത്തത് പരീക്ഷിക്കുന്നതിന് മുൻപ് ടൈംഔട്ട് തീരുന്നത് കാത്തിരിക്കുന്നു, ഒപ്പം resolv.conf(5) ആ ലിസ്റ്റ് മൂന്ന് എൻട്രികളായി പരിമിതപ്പെടുത്തുന്നു. ടണൽ പോയതിന് ശേഷം 10.8.0.1 പോലുള്ള ടണൽ-വശ റിസോൾവർ ലിസ്റ്റിന്റെ മുകളിൽ വെക്കുക, അപ്പോൾ ഉത്തരം നൽകുന്ന സർവറിലേക്ക് വീഴുന്നതിന് മുൻപ് ഓരോ ലുക്കപ്പും ടൈംഔട്ട് നൽകുന്നു. ലക്ഷണം DNS പിശകിനെക്കാൾ മൃതമായ കണക്ഷൻ പോലെ തോന്നുന്നതിന്റെ കാരണം ഇതാണ്: ബ്രൗസറുകൾ തടയുന്നു, സമയം തീരുന്നു, ചിലപ്പോൾ പിന്നീട് പഴയതാകുന്ന കാഷ് ചെയ്ത വിലാസം നൽകുന്നു.

«ഇന്റർനെറ്റ് കേടായി» എന്ന പരാതി എത്തുന്നതിന്റെ കാരണവും ഇത് വിശദീകരിക്കുന്നു. IP വിലാസത്തിലേക്കുള്ള ping ലിങ്ക് കുഴപ്പമില്ലെന്ന് തെളിയിക്കുന്നു, അത് തകരാറിനെ ആപ്പിന്റേതായി തോന്നിപ്പിക്കുന്നു. റിസോൾവർ ലിസ്റ്റാണ് ആദ്യം വായിക്കേണ്ടതും അവസാനം എഡിറ്റ് ചെയ്യേണ്ടതും.

മിത്ത്: resolv.conf ഒരു ക്രമീകരണ ഫയലാണ്

മാറ്റുന്നതിന് മുൻപ് ആ പാത യഥാർത്ഥത്തിൽ എന്താണെന്ന് ചോദിക്കുക:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

systemd-resolved ഹോസ്റ്റിൽ അത് 127.0.0.53 ലേക്ക് ചൂണ്ടുന്ന സ്റ്റബ് ഫയലിലേക്കുള്ള സിംബോളിക് ലിങ്കാണ്, യഥാർത്ഥ സർവറുകൾ resolvectl പ്രിന്റ് ചെയ്യുന്ന ലിങ്ക്-തോറുമുള്ള നിലയിൽ കഴിയുന്നു. NetworkManager ഹോസ്റ്റിൽ അത് NetworkManager സജീവ കണക്ഷനിൽ നിന്ന് എഴുതുന്ന ഫയലാകാം. ചില വെണ്ടർ ക്ലയന്റുകളിൽ അത് കണക്ട് ചെയ്യുമ്പോൾ സ്ഥലത്തുതന്നെ മാറ്റിയെഴുതുന്ന, ഭാഗ്യമില്ലെങ്കിൽ വിച്ഛേദിക്കുമ്പോൾ ഒരിക്കലും പുനഃസ്ഥാപിക്കാത്ത സാധാരണ ഫയലാണ്. ഇവ മൂന്ന് വ്യത്യസ്ത ഉടമകളാണ്, ആദ്യത്തെ രണ്ടെണ്ണം കൈകൊണ്ട് എഡിറ്റ് ചെയ്യുന്നത് ഒന്നും ചെയ്യുന്നില്ല അല്ലെങ്കിൽ അടുത്ത നെറ്റ്വർക്ക് സംഭവം വരെ നിലനിൽക്കുന്നു.

resolvectl status സത്യം പറയുന്ന കാഴ്ചയാണ്: ലിങ്ക്-തോറുമുള്ള DNS സർവറുകൾ, റൂട്ടിംഗ് ഡൊമെയ്നുകൾ, ടണൽ ലിങ്ക് ഇനിയും ഉണ്ടോ എന്നതും. resolvectl query example.com കൂടുതൽ മുന്നോട്ട് പോയി ഏത് ഇന്റർഫേസ് ഉത്തരം നൽകി എന്ന് കാണിക്കുന്നു. ഫയൽ തൊടുന്നതിന് മുൻപ് രണ്ടും ഉപയോഗിക്കുക, സ്വന്തം സുരക്ഷിത DNS ഉള്ള ബ്രൗസർ ഇതെല്ലാം അവഗണിക്കുന്നു എന്ന് ഓർക്കുക.

എന്തെങ്കിലും എഡിറ്റ് ചെയ്യുന്നതിന് മുൻപ് ഉടമയെ കണ്ടെത്തുക

സാധാരണയായി മൂന്ന് ഘടകങ്ങൾ ഒരേ ക്രമീകരണത്തിനായി മത്സരിക്കുന്നു: systemd-resolved, NetworkManager, VPN ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്തത്. ആദ്യം ജീവിച്ചിരിക്കുന്നതിനെ തിരിച്ചറിയുക:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

resolved സജീവവും സിംബോളിക് ലിങ്ക് അതിന്റെ സ്റ്റബ്ബിലേക്ക് ചൂണ്ടുന്നതുമാണെങ്കിൽ, ആഗോള ഫയൽ സൃഷ്ടിച്ച ഔട്ട്പുട്ടാണ്, നിങ്ങളുടെ എഡിറ്റ് ദൃശ്യപരം മാത്രം. NetworkManager കണക്ഷന്റെ ഉടമയാണെങ്കിൽ, സർവറുകൾ കണക്ഷൻ പ്രൊഫൈലിന്റേതാണ്, അതിനാൽ പരിഹാരം ഫയൽ എഡിറ്റല്ല, nmcli പ്രോപ്പർട്ടി മാറ്റമാണ്. വെണ്ടർ ഡീമൺ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, അടുത്ത കണക്ഷനെ അതിജീവിക്കുന്നത് അതിന്റെ സ്വന്തം പുനഃസ്ഥാപന പാത മാത്രമാണ്.

ക്ലയന്റ് അവശേഷിപ്പിച്ച ലിങ്ക് നില വൃത്തിയാക്കുക

കൊല്ലപ്പെട്ട ക്ലയന്റിന് അതിന്റെ ക്ലീനപ്പ് ഹൂക്ക് പ്രവർത്തിപ്പിക്കാനാവില്ല. SIGKILL ഒട്ടും പിടിക്കാനാവില്ല, SIGINT, SIGTERM എന്നിവ പിടിക്കാം, അതിനാൽ നിർബന്ധിത കൊലയ്ക്ക് ശേഷം «വെറുതെ നിന്നുപോയ» ടണൽ ഇന്റർഫേസ് രജിസ്ട്രേഷനും റിസോൾവർ എൻട്രിയും സ്ഥലത്തുതന്നെ വിടുന്നു. കൃത്യമായ PID കണ്ടെത്തി സിഗ്നൽ അതിന് മാത്രം അയക്കുക:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

പൂർണ്ണ പൊരുത്ത ലിസ്റ്റ് വായിക്കുന്നതിന് മുൻപ് pkill -f vpn അല്ലെങ്കിൽ killall vpn ലേക്ക് കൈ നീട്ടരുത്. -f മുഴുവൻ കമാൻഡ് ലൈനുമായി പൊരുത്തപ്പെടുന്നു, അതിനാൽ റാപ്പർ സ്ക്രിപ്റ്റ്, എഡിറ്റർ സെഷൻ അല്ലെങ്കിൽ പാതയിൽ ആ സ്ട്രിംഗ് ഉള്ള അസംബന്ധ പ്രോസസ് പോലും അത് അവസാനിപ്പിക്കാം. ജോലിയുടെ നടുവിൽ തെറ്റായ പ്രോസസ് അവസാനിപ്പിക്കുന്നതാണ് റിസോൾവർ പ്രശ്നം നഷ്ടപ്പെട്ട ഫയലാകുന്ന വഴി.

resolvectl revert ആ ലിങ്കിന്റെ റൺടൈം DNS കോൺഫിഗറേഷൻ പുനഃസജ്ജമാക്കുന്നു, ഇത് റിസോൾവർ റീസ്റ്റാർട്ട് ചെയ്യുന്നതിനേക്കാൾ ഇടുങ്ങിയതും ആഗോള ഫയൽ എഡിറ്റ് ചെയ്യുന്നതിനേക്കാൾ വളരെ ഇടുങ്ങിയതുമാണ്. ടണൽ ലിങ്ക് പൂർണ്ണമായി പോയെങ്കിൽ, systemctl restart NetworkManager കണക്ഷൻ നില പുനർനിർമ്മിക്കുന്നു, സ്രോതസ്സ് ത്രെഡുകൾ വീണ്ടും വീണ്ടും മടങ്ങുന്നത് ഈ ഘട്ടത്തിലേക്കാണ്. Restart=always ഉള്ള സർവീസ് മാനേജറെ സൂക്ഷിക്കുക, അത് കൊല്ലപ്പെട്ട ക്ലയന്റിനെയും അതിന്റെ DNS ക്രമീകരണങ്ങളെയും നേരിട്ട് തിരികെ വെക്കാം.

മറ്റൊരു ദിശ: തള്ളിയെത്തിയെങ്കിലും എത്താത്ത DNS

പഴയ എൻട്രിയുടെ കണ്ണാടി പ്രതിബിംബം ഉപയോഗയോഗ്യമായ റിസോൾവർ ഇല്ലാത്ത ടണലാണ്. പ്രൊഫൈലിലെ DNS ഓപ്ഷൻ ഒരു അഭ്യർത്ഥനയാണ്; കണക്ഷൻ കൈകാര്യം ചെയ്യുന്ന ഘടകം അത് റിസോൾവറിന് കൈമാറണം. സർവർ ലഭിച്ചു എന്ന് ലോഗ് കാണിച്ചാലും ടണൽ ലിങ്ക് DNS ക്രമീകരണങ്ങൾ ഒന്നും വഹിക്കുന്നില്ലെങ്കിൽ, ഇല്ലാത്തത് സംയോജനമാണ്, സർവറല്ല.

കൈമാറ്റം കൈകൊണ്ട് ചെയ്ത് പരീക്ഷിക്കുക, ഇത് «സർവർ തെറ്റാണ്», «ആരും പ്രയോഗിച്ചില്ല» എന്നിവ വേർതിരിക്കുന്നു:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

എല്ലാം പിടിക്കുന്ന റൂട്ടിംഗ് ഡൊമെയ്ൻ ഓരോ നാമവും ആ ലിങ്കിലേക്ക് അയക്കുന്നു, ഇതാണ് പൂർണ്ണ ടണൽ ക്ലയന്റ് ആഗ്രഹിക്കുന്നതും വിഭജിത DNS ഉപയോഗിക്കരുതാത്തതും. ഈ ക്രമീകരണങ്ങൾ അടുത്ത കണക്ഷനിൽ അപ്രത്യക്ഷമാകുന്നു. NetworkManager-ൽ അവ സ്ഥിരമാക്കാൻ യാന്ത്രിക DNS പ്രവർത്തനരഹിതമാക്കി, കണക്ഷനിൽ സർവർ സജ്ജീകരിച്ച് ഡൊമെയ്ൻ ചേർക്കുക:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

ആന്തരിക നാമങ്ങൾക്ക് മാത്രം ഉത്തരം നൽകേണ്ട കമ്പനി ടണലിന്, ആ സോണുകൾ എല്ലാം പിടിക്കുന്നതിന് പകരം ആരംഭത്തിൽ ടിൽഡയോടെ ലിസ്റ്റ് ചെയ്യുക, പൊതു നാമങ്ങൾ പ്രാദേശിക റിസോൾവർ ഉപയോഗിച്ചുകൊണ്ടിരിക്കാൻ.

അടുത്ത തടസ്സമാകുന്ന പരിഹാരങ്ങൾ

കണക്ട് ചെയ്യുന്നതിന് മുൻപ് resolv.conf പകർത്തി പിന്നീട് പുനഃസ്ഥാപിക്കുന്നത് runbook-ൽ സാധുവായ ഒരു വരിയാണ്, അത് നന്നാക്കലല്ല, പരിഹാരമാണ്. ക്രാഷോ നിർബന്ധിത റീബൂട്ടോ പുനഃസ്ഥാപനം ഒഴിവാക്കുന്നതിനാൽ അത് പ്രധാനമാകുന്ന സമയത്തുതന്നെ പരാജയപ്പെടുന്നു. അടുത്ത ആൾ അതിൽ കെട്ടിപ്പടുക്കാതിരിക്കാൻ അത് പരിഹാരമായി എഴുതിവെക്കുക.

systemd-resolved പ്രവർത്തനരഹിതമാക്കി പൊതു സർവറുകൾ ഹാർഡ്കോഡ് ചെയ്യുന്നത് മറ്റൊരു ജനപ്രിയ നീക്കമാണ്. ഇത് കണക്ട്, വിച്ഛേദം എന്നിവ പ്രവചനീയമാക്കുകയും മറ്റെല്ലാ നെറ്റ്വർക്കുകൾക്കും ലിങ്ക്-തോറുമുള്ള DNS നീക്കം ചെയ്യുകയും ചെയ്യുന്നു, അത് ആന്തരിക നാമങ്ങളുടെ വിഭജിത DNS തകർക്കുകയും അന്വേഷണങ്ങൾ അകത്ത് നിർത്താൻ ഉദ്ദേശിച്ച ടണലിന്റെ ലക്ഷ്യം അസാധുവാക്കുകയും ചെയ്യുന്നു. resolvconf ഇൻസ്റ്റാൾ ചെയ്ത് പൊതു സർവറുകൾ പിൻ ചെയ്യുന്നത് ഒരു അധിക പാളിയോടെ അതേ ചെലവാണ്. ഏതിനെയും രോഗനിർണ്ണയമായി കാണുക: അത് ബ്രൗസിംഗ് തിരികെ കൊണ്ടുവന്നാൽ, പൊതു സർവറുകൾ ശരിയാണെന്നല്ല, റിസോൾവർ സംയോജനമാണ് കുറ്റക്കാരനെന്ന് നിങ്ങൾ മനസ്സിലാക്കി.

നിലനിൽക്കുന്ന പരിഹാരം ഓരോ പാളിക്കും ഒരു ഉടമയാണ്: ടണൽ ലിങ്കിന്റെ DNS ഏത് ഘടകത്തിന്റേതാണ്, ആഗോള സ്ഥിരസ്ഥിതി ഏതിന്റേതാണ് എന്ന് തീരുമാനിച്ച് അത് എഴുതിവെച്ച് ബാക്കിയുള്ളവയെ പാതയിൽ നിന്ന് നീക്കുക. പിന്നീട് വിച്ഛേദത്തിന് ശേഷം VPN മാത്രം പരിഹരിക്കുന്ന ഒരു നാമം ഉപയോഗിച്ച് പരിശോധിക്കുക. സ്വകാര്യ നാമം ഇപ്പോഴും ഉത്തരം നൽകുന്നുവെങ്കിൽ രജിസ്ട്രേഷൻ നീക്കിയിട്ടില്ല; ഒന്നും പരിഹരിക്കുന്നില്ലെങ്കിൽ ഫയൽ ഇനിയില്ലാത്ത ഒരു സർവറിലേക്ക് ചൂണ്ടുന്നു. രണ്ടും ബ്രൗസർ തുറക്കുന്നതിന് മുൻപ് resolvectl-ൽ കാണാം.