/etc/resolv.conf നുവേണ്ടി മത്സരിക്കുന്ന രണ്ട് Linux സേവനങ്ങൾ നിർത്തുക

DNS വീണ്ടും വീണ്ടും പഴയ അവസ്ഥയിലേക്ക് മടങ്ങുന്നു, VPN വീണ്ടും കണക്റ്റ് ചെയ്യുന്നത് നിങ്ങളുടെ തിരുത്തൽ റദ്ദാക്കുന്നു, ഒടുവിൽ ടീമിലെ ആരോ ഫയൽ ലോക്ക് ചെയ്യാൻ നിർദ്ദേശിക്കുന്നു. ആ ക്രമം ഒരു ലക്ഷണമാണ്, പരിഹാരമല്ല: രണ്ട് ഘടകങ്ങളും /etc/resolv.conf തങ്ങളുടേതാണെന്ന് കരുതുന്നു, അവസാനം എഴുതുന്നവൻ വിജയിക്കുന്നു. ഫയൽ ലോക്ക് ചെയ്യുന്നത് ഉടമസ്ഥതാ സംഘർഷം പരിഹരിക്കുന്നില്ല, അത് മറയ്ക്കുക മാത്രം ചെയ്യുന്നു, അതേസമയം നിങ്ങൾ യഥാർത്ഥത്തിൽ ആഗ്രഹിച്ച ഘടകം തകർക്കുന്നു. താഴെയുള്ള നാല് പരിശോധനകൾ ക്രമത്തിൽ ചെയ്ത്, ഫയലിൽ അല്ല, അതിനെ ഉടമസ്ഥാനം ചെയ്യുന്ന തലത്തിൽ ക്രമീകരണം ശരിയാക്കുക.

പരിശോധന 1: ഇത് സിംബോളിക് ലിങ്കാണോ, എങ്ങോട്ട്

ഫയലിൽ നിന്ന് തന്നെ തുടങ്ങുക, കാരണം നിങ്ങൾ എഡിറ്റ് ചെയ്യുന്ന പാത ഫയൽ അല്ലായിരിക്കാം. റിസോൾവറിന്റെ റൺടൈം ഡയറക്ടറിയിലേക്കുള്ള സിംബോളിക് ലിങ്ക്, ക്ലയന്റ് സ്ക്രിപ്റ്റ് വീണ്ടും എഴുതുന്ന സാധാരണ ഫയലിൽ നിന്ന് തികച്ചും വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു:

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

systemd-resolved ന്റെ stub പാതയിലേക്കുള്ള ലിങ്ക് എന്നാൽ ഫയലിന്റെ ഉള്ളടക്കം സൃഷ്ടിക്കപ്പെടുന്നു, കൈകൊണ്ടുള്ള എഡിറ്റിംഗ് അടുത്ത സംഭവത്തിൽ മേലെഴുതപ്പെടും. nameserver വരികളുള്ള സാധാരണ ഫയൽ സാധാരണയായി കണക്റ്റ് ചെയ്യുമ്പോൾ പ്രവർത്തിക്കുന്ന ക്ലയന്റോ DHCP ഹുക്കോ ആണ് എഴുതുന്നത്. രണ്ടും സാധുവാണ്; പ്രധാനം, എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് നിങ്ങൾക്ക് ഏതാണെന്ന് അറിയുക എന്നതാണ്.

പരിശോധന 2: ഏത് ഡീമോൺ പ്രവർത്തിക്കുന്നു

എന്താണ് ഇൻസ്റ്റാൾ ചെയ്തിരിക്കുന്നത് എന്നല്ല, എന്താണ് യഥാർത്ഥത്തിൽ സജീവമെന്ന് കണ്ടെത്തുക. ആധുനിക ഡിസ്ട്രിബ്യൂഷനിൽ നിരവധി റിസോൾവറുകൾ ഉണ്ടാകാം, ലൂപ്പ്ബാക്ക് ഇന്റർഫേസിൽ പോർട്ട് 53 കൈവശം വയ്ക്കുന്നതാണ് ഉത്തരം നൽകുന്നത്:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

സ്റ്റാറ്റസ് ഔട്ട്പുട്ട് ഓരോ ലിങ്കിന്റെയും DNS സെർവറുകളും റൂട്ടിംഗ് ഡൊമെയ്നുകളും പേരിടുന്നു, അതാണ് split DNS-ന് നിങ്ങൾക്ക് വേണ്ട മാപ്പ്. ആന്തരിക നാമങ്ങൾ ആന്തരിക സെർവറിലേക്കും ബാക്കിയെല്ലാം പൊതു സെർവറിലേക്കും പോകണമെങ്കിൽ, ആ നയം ഓരോ ലിങ്കിന്റെയും ഡൊമെയ്നുകളിൽ ജീവിക്കുന്നു, അത് ഫയലിലെ സ്ഥിരമായ nameserver പട്ടികയിലേക്ക് പരത്തുന്നത് ആ വ്യത്യാസം നിശബ്ദമായി നഷ്ടപ്പെടുത്തുന്നു.

NetworkManager ന്റെ സ്വന്തം കോൺഫിഗറേഷൻ ഇവയിൽ ഏത് ബാക്കെൻഡ് ഉപയോഗിക്കണമെന്ന് തീരുമാനിക്കുന്നു. പ്രധാന കോൺഫിഗറേഷൻ ഫയലിലെ അതിന്റെ dns= ക്രമീകരണം അതിന്റെ ആന്തരിക റിസോൾവർ, dnsmasq, systemd-resolved, none എന്നിവയ്ക്കിടയിൽ തിരഞ്ഞെടുക്കുന്നു, ഡിസ്ട്രിബ്യൂഷൻ നിങ്ങൾക്കുവേണ്ടി തിരഞ്ഞെടുത്തിരിക്കാം. ഈ ഹോസ്റ്റിൽ “DNS ശരിയാക്കുക” എന്നതിന്റെ അർത്ഥം തീരുമാനിക്കുന്നതിന് മുൻപ് ആ ക്രമീകരണം വായിക്കുക.

പരിശോധന 3: VPN ക്ലയന്റിന് എന്ത് എഴുതാൻ അനുവാദമുണ്ട്

സംഘർഷം സാധാരണയായി ഇവിടെയാണ് ജീവിക്കുന്നത്. റിസോൾവർ ഫയൽ നേരിട്ട് വീണ്ടും എഴുതുന്ന VPN ക്ലയന്റ് അത് പരിപാലിക്കുന്ന ഏതൊരു സേവനവുമായും പോരാടും, തോൽക്കുന്നത് ആദ്യം പ്രവർത്തിക്കുന്നതാണ്. പുതിയ OpenVPN റിലീസുകൾ ഫയൽ വീണ്ടും എഴുതുന്നതിന് പകരം DNS ക്രമീകരണങ്ങൾ systemd-resolved-ന് നൽകാം, അതാണ് നിങ്ങൾ ആഗ്രഹിക്കുന്ന സഹകരണ സ്വഭാവം; പഴയ സ്ക്രിപ്റ്റുകളും കൈകൊണ്ട് എഴുതിയ ഹുക്കുകളും പലപ്പോഴും പഴയ സഹായിയെ വിളിക്കുകയോ ഫയൽ മേലെഴുതുകയോ ചെയ്യുന്നു.

WireGuard ന്റെ അവസ്ഥ രൂപത്തിൽ സമാനമാണ്: ഇന്റർഫേസ് കോൺഫിഗറേഷൻ തന്നെ DNS കൈകാര്യം ചെയ്യുന്നില്ല, ചുറ്റുമുള്ള ഉപകരണങ്ങൾ റിസോൾവർ സഹായി അല്ലെങ്കിൽ resolved ഇന്റഗ്രേഷൻ വഴി ചെയ്യുന്നു. അത്തരം രണ്ട് സഹായികൾ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെങ്കിൽ, രണ്ടും കണക്റ്റ് ചെയ്യുമ്പോൾ തങ്ങളുടെ ലോകവീക്ഷണം അടിച്ചേൽപ്പിക്കാൻ ശ്രമിക്കും.

ഊഹിക്കുന്നതിന് പകരം ക്ലയന്റിന്റെ up, down ഹുക്കുകൾ വായിക്കുക. /etc/openvpn/up.sh അല്ലെങ്കിൽ തത്തുല്യമായ ഡയറക്ടറിയിലെ കുറച്ച് shell വരികൾ, അല്ലാത്തപക്ഷം ക്രമരഹിതമായി തോന്നുന്ന സ്വഭാവം വിശദീകരിക്കുന്നു, ക്ലയന്റിനെ മത്സരിക്കുന്നതിന് പകരം സഹകരിപ്പിക്കാൻ കഴിയുന്ന സ്ഥലവും അതുതന്നെ.

പരിശോധന 4: ഉടമയുടെ അടുത്ത് ശരിയാക്കുക, ഫയലിൽ അല്ല

ഉടമ ആരെന്ന് അറിഞ്ഞാൽ, ആ ഉടമ പിന്തുണയ്ക്കുന്ന ഇന്റർഫേസിലൂടെ DNS കോൺഫിഗർ ചെയ്യുക. systemd-resolved-ന് ഇത് സ്ഥിര ഫയലിന് പകരം ഓരോ ലിങ്കിന്റെയും ക്രമീകരണങ്ങളും റൂട്ടിംഗ് ഡൊമെയ്നുകളും അർത്ഥമാക്കുന്നു; NetworkManager-ന് കണക്ഷൻ പ്രൊഫൈലിന്റെ DNS ക്രമീകരണങ്ങളും തിരഞ്ഞെടുത്ത ബാക്കെൻഡും; resolvconf ഇന്റഗ്രേഷൻ ഉപയോഗിക്കുന്ന ഡിസ്ട്രിബ്യൂഷന് ആ സഹായിയിലൂടെ എഴുതുന്നതും.

ഫയൽ മാറ്റമില്ലാത്തതാക്കരുത്. മാറ്റമില്ലായ്മ അട്ട്രിബ്യൂട്ട് സാധുവായ DHCP പുതുക്കലുകളും VPN അപ്ഡേറ്റുകളും നിങ്ങൾ പോരാടിയവയോടൊപ്പം നിർത്തുന്നു, അടുത്ത പാക്കേജ് അപ്ഗ്രേഡോ വീണ്ടും കണക്റ്റ് ചെയ്യലോ കോൺഫിഗറേഷനിൽ നിന്ന് ആർക്കും വിശദീകരിക്കാനാകാത്ത പരാജയം ഉണ്ടാക്കുന്ന അവസ്ഥയിൽ സിസ്റ്റം വിടുന്നു. അത് ഉടമസ്ഥതാ സംഘർഷം മറയ്ക്കുന്നു, അതാണ് നിങ്ങൾ പരിഹരിക്കാൻ ശ്രമിച്ചിരുന്ന കാര്യം.

രണ്ട് ഘടകങ്ങൾ യഥാർത്ഥത്തിൽ ഒരുമിച്ച് നിലനിൽക്കേണ്ടിടത്ത് അവയ്ക്ക് വ്യത്യസ്ത ജോലികൾ നൽകുക. നെറ്റ്വർക്ക് മാനേജർക്ക് ഇന്റർഫേസ് തലത്തിലെ കോൺഫിഗറേഷൻ ഉടമസ്ഥാനം ചെയ്യാൻ അനുവദിക്കുക, VPN ക്ലയന്റിന് അതേ ഇന്റഗ്രേഷനിലൂടെ ഓരോ ലിങ്കിന്റെയും DNS-ഉം ഡൊമെയ്നുകളും സംഭാവന ചെയ്യാൻ അനുവദിക്കുക, ഫയൽ നേരിട്ട് എഴുതുന്ന മൂന്നാമത്തെ സ്ക്രിപ്റ്റ് നീക്കം ചെയ്യുക. systemd-resolved ന്റെ ഡോക്യുമെന്റേഷൻ അത് പിന്തുണയ്ക്കുന്ന മോഡുകളും ഓരോന്നും /etc/resolv.conf ൽ എന്ത് കാണിക്കുന്നുവെന്നും വിശദീകരിക്കുന്നു. നിങ്ങൾ സൂക്ഷിക്കേണ്ട നയത്തിന്റെ അളവിന് യോജിക്കുന്ന മോഡ് തിരഞ്ഞെടുക്കുക. split DNS പ്രധാനമാണെങ്കിൽ, ഓരോ ലിങ്കിന്റെയും ഡൊമെയ്നുകളുള്ള stub ക്രമീകരണം അത് സംരക്ഷിക്കുന്നു, upstream സെർവറുകൾ ഫയലിലേക്ക് പകർത്തുന്ന മോഡ് അത് നിശബ്ദമായി പരത്തിക്കളയുന്നു.

വീണ്ടും കണക്റ്റ് ചെയ്തതിന് ശേഷം പരിശോധിക്കുക, എഡിറ്റിംഗിന് ശേഷമല്ല

നിങ്ങളുടെ മാറ്റത്തിന് ശേഷം ഉടനെ ശരിയായി തോന്നുന്ന ഫയൽ ഒന്നും തെളിയിക്കുന്നില്ല, കാരണം അടുത്ത സംഭവം ഇതുവരെ സംഭവിച്ചിട്ടില്ല. മുൻപ് അത് തകർത്തിരുന്ന ക്രമം പ്രവർത്തിപ്പിക്കുക: ടണൽ താഴ്ത്തി വീണ്ടും ഉയർത്തുക, DHCP ലീസ് പുതുക്കുക അല്ലെങ്കിൽ ഇന്റർഫേസ് മാറ്റുക, എന്നിട്ട് അതേ മൂല്യങ്ങൾ വീണ്ടും വായിക്കുക.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

പിന്നീട് പ്രധാനമായ വ്യത്യാസം സ്ഥിരീകരിക്കുക: ആന്തരിക നാമം ആന്തരിക സെർവർ വഴി പരിഹരിക്കപ്പെടുന്നു, പൊതു നാമം ഇപ്പോഴും പ്രവർത്തിക്കുന്നു. എല്ലാം ആന്തരിക സെർവറിലേക്ക് അയക്കുന്ന കോൺഫിഗറേഷൻ, ആരെങ്കിലും ടണൽ വഴി ഇന്റർനെറ്റിൽ എത്താൻ ശ്രമിക്കുന്നതുവരെ നന്നായി തോന്നും, എല്ലാം പൊതു സെർവറിലേക്ക് അയക്കുന്ന കോൺഫിഗറേഷൻ ആന്തരിക നാമങ്ങൾ ചോർത്തുന്നു.

വിന്യാസ കുറിപ്പുകളിൽ ഉടമ, ബാക്കെൻഡ്, സിംബോളിക് ലിങ്ക് മോഡ് എന്നിവ രേഖപ്പെടുത്തുക. ആ ഒരു ഖണ്ഡിക ഭാവിയിലെ പാക്കേജ് അപ്ഗ്രേഡിനെ ഒരു സംഭവത്തിൽ നിന്ന് അവലോകന ഇനമാക്കി മാറ്റുന്നു, അടുത്ത ആൾ chattr കമാൻഡ് ഉപയോഗിച്ച് അതേ സംഘർഷം വീണ്ടും കണ്ടെത്തുന്നതിൽ നിന്ന് തടയുന്നു.