OpenVPN ഒരു DNS സർവർ അയച്ചു, പക്ഷേ Linux അത് അവഗണിക്കുന്നു

അയച്ച DNS സർവർ ലോഗിൽ ഉണ്ട്, ടണൽ പ്രവർത്തിക്കുന്നു, ആന്തരിക നാമങ്ങൾ ഇപ്പോഴും പരാജയപ്പെടുന്നു. അയയ്ക്കുന്നതിൽ തന്നെ ഒന്നും കേടായിട്ടില്ല; ക്രമീകരണം എത്തി അവിടെ നിന്നു. അയച്ച DNS ഓപ്ഷൻ ക്ലയന്റിനുള്ള ഒരു സന്ദേശമാണ്, ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ റിസോൾവറിനുള്ള നിർദ്ദേശമല്ല, ഇവ രണ്ടിനും ഇടയിലുള്ള കൈമാറ്റമാണ് ഇത്തരം കേസുകളിൽ മിക്കതും അവസാനിക്കുന്ന സ്ഥലം. അഞ്ച് പരിശോധനകൾ, ക്രമത്തിൽ, നടക്കാത്ത കൈമാറ്റം കണ്ടെത്തുന്നു.

പരിശോധന ഒന്ന്: കണക്ഷൻ എങ്ങനെ തുടങ്ങുന്നു

കണക്ഷന്റെ ഉടമ റിസോൾവർ ക്രമീകരണങ്ങൾ ആർക്ക് പ്രയോഗിക്കാമെന്ന് തീരുമാനിക്കുന്നു. ഷെല്ലിൽ നിന്നുള്ള നേരിട്ടുള്ള openvpn കമാൻഡിന് സ്വന്തം പ്രോസസ്സല്ലാതെ ഒന്നുമില്ല, അതേസമയം systemd യൂണിറ്റ്, NetworkManager അല്ലെങ്കിൽ വെണ്ടർ ക്ലയന്റ് ഓരോന്നിനും DNS പ്രസിദ്ധീകരിക്കാനുള്ള സ്വന്തം വഴിയുണ്ട്. ഇവയിലേതെങ്കിലും അനുമാനിക്കുന്നതിന് മുമ്പ് പ്രോസസ്സ് പട്ടികയും യൂണിറ്റിന്റെ പേരും വായിക്കുക.

കമാൻഡ് ലൈൻ പ്രോസസ്സ് സ്വയമേവ NetworkManager കണക്ഷനല്ല, NetworkManager കണക്ഷൻ സ്വയമേവ resolv.conf എഴുതിയതുമല്ല. ഈ രണ്ട് അനുമാനങ്ങളാണ് ഈ അന്വേഷണത്തിൽ പാഴായ ഭൂരിഭാഗം മണിക്കൂറുകളും വിശദീകരിക്കുന്നത്. നിങ്ങൾ യഥാർത്ഥത്തിൽ കാണുന്ന ഇന്റർഫേസിന് ഏത് ഘടകം DNS പ്രസിദ്ധീകരിക്കുമെന്ന് ചോദിക്കുക.

തുടരുന്നതിന് മുമ്പ് ഉടമയെ എഴുതി വയ്ക്കുക. തുടർന്നുള്ള ഓരോ പരിശോധനയും അതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

പരിശോധന രണ്ട്: റിസോൾവർ ലിങ്ക് യഥാർത്ഥത്തിൽ എന്താണ് പിടിച്ചിരിക്കുന്നത്

systemd-resolved ഹോസ്റ്റിൽ, resolvectl status ഓരോ ലിങ്കും അതിന്റെ DNS സർവറുകളും ഡൊമെയ്നുകളും സഹിതം പട്ടികപ്പെടുത്തുന്നു. ടണൽ ലിങ്ക് കണ്ടെത്തി അതിന്റെ എൻട്രികൾ വായിക്കുക, ഇന്റർഫേസിന്റെ പേര് tun0 എന്ന് അനുമാനിക്കരുത്, കാരണം അക്കമിടൽ സൃഷ്ടിയുടെ ക്രമം പിന്തുടരുന്നു. അയച്ച വിലാസം ലിങ്കിൽ ഇല്ലെങ്കിൽ, പരാജയപ്പെട്ടത് ക്വറിയല്ല, കൈമാറ്റമാണ്.

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

ഏതെങ്കിലും നിഗമനത്തിലെത്തുന്നതിന് മുമ്പ് റിസോൾവർ ഔട്ട്പുട്ടിലെ ലിങ്ക് നാമം VPN ലോഗിലെ ഇന്റർഫേസ് നാമവുമായി താരതമ്യം ചെയ്യുക. അവിടെയുള്ള പൊരുത്തക്കേട് സാധാരണയായി ലോഗ് ലൈൻ മറ്റൊരു പ്രോസസ്സിൽ നിന്ന് വന്നു എന്നാണ് അർത്ഥമാക്കുന്നത്.

പരിശോധന മൂന്ന്: നാമസ്ഥലം ആ ലിങ്ക് തിരഞ്ഞെടുക്കുന്നുണ്ടോ

റിസോൾവറിന് ശരിയായ സർവർ ഉണ്ടായിരിക്കാം, എന്നിട്ടും അതിനോട് ആലോചിക്കപ്പെടണമെന്നില്ല. ഓരോ ലിങ്കിനുമുള്ള ഡൊമെയ്ൻ ഏത് ക്വറി എവിടേക്ക് പോകണമെന്ന് തീരുമാനിക്കുന്നു, റൂട്ടിംഗ് ഡൊമെയ്ൻ ഇല്ലെങ്കിൽ സ്വകാര്യ നാമസ്ഥലം സ്ഥിരസ്ഥിതി ലിങ്ക് പറയുന്നതിലേക്ക് മടങ്ങുന്നു. അതിനാലാണ് ആന്തരിക നാമത്തിന് resolvectl query വിജയിക്കുന്നത്, അതേസമയം ആപ്ലിക്കേഷൻ ഇപ്പോഴും പരാജയപ്പെടുന്നു. ആപ്ലിക്കേഷൻ തികച്ചും വ്യത്യസ്തമായ റിസോൾവർ പാത ഉപയോഗിക്കുന്നുണ്ടാകാം.

ഡൊമെയ്ൻ അനുവദനം പരിശോധിക്കുക, സർവർ വിലാസം മാത്രമല്ല. ~corp.example എന്ന് എഴുതിയ ഡൊമെയ്ൻ ഒരു റൂട്ടിംഗ് ഡൊമെയ്നാണ്, ടിൽഡെ ചിഹ്നം നാമം എങ്ങനെ ഒത്തുനോക്കുന്നു എന്നത് മാറ്റുന്നു.

ആപ്ലിക്കേഷന് സ്വന്തം റിസോൾവർ ഉണ്ടെങ്കിൽ, സിസ്റ്റം ടൂളുമായല്ല, അത് ഉപയോഗിക്കുന്ന അതേ സംവിധാനത്തോടെ പരിശോധിക്കുക. സിസ്റ്റം റിസോൾവറിനെ ഒഴിവാക്കുന്ന ക്വറി ടൂൾ ലിങ്കിന്റെ അവസ്ഥ എന്തായാലും വിജയിക്കും.

പരിശോധന നാല്: ഒരു ഉടമ, രണ്ടല്ല

NetworkManager ഇതിനകം VPN-ഉം റിസോൾവറിന്റെ അവസ്ഥയും കൈകാര്യം ചെയ്യുന്നുണ്ടെങ്കിൽ, ബന്ധമില്ലാത്ത ഹൂക്ക് സ്ക്രിപ്റ്റ് ചേർക്കുന്നത് മത്സരിക്കുന്ന എഴുത്തുകാരെ സൃഷ്ടിക്കുന്നു. systemd-resolved-നായി പാക്കേജ് നൽകുന്ന ഹൂക്ക് പിന്തുണയ്ക്കുന്ന ഒരു സംയോജനമാണ്, അത് ഒരു നിർദ്ദിഷ്ട ജീവിതചക്രം പ്രതീക്ഷിക്കുന്നു: script-security 2, ഒരു up പാത, up-restart, ഒരു down പാത, down-pre. ആ ഓപ്ഷനുകൾ രജിസ്ട്രേഷനും നീക്കലും ആദ്യ കണക്ഷനിൽ മാത്രമല്ല, ശരിയായ നിമിഷങ്ങളിൽ നടക്കാൻ ഇടയാക്കുന്നു.

ഗൈഡിൽ നിന്ന് പകർത്തിയ ഉദാഹരണമല്ല, പാക്കേജിൽ നിന്ന് ഇൻസ്റ്റാൾ ചെയ്ത പാത ഉപയോഗിക്കുക. അനുമതികളും പ്രധാനമാണ്, കാരണം ഹൂക്ക് പ്രത്യേകാവകാശങ്ങൾ കുറഞ്ഞതിന് ശേഷമാണ് പ്രവർത്തിക്കുന്നത്.

ഒരു വിതരണത്തിന്റെ റിസോൾവർ സ്ക്രിപ്റ്റ് അതിന്റെ ഔട്ട്പുട്ട് ലക്ഷ്യം മാറ്റാൻ എഡിറ്റ് ചെയ്യുന്നത് ഒരു ഹോസ്റ്റിന്റെ പരിഹാരം രേഖപ്പെടുത്തുന്നു. അത് പൊതുവായ അറ്റകുറ്റപ്പണിയല്ല.

പരിശോധന അഞ്ച്: വീണ്ടും കണക്ട് ചെയ്ത ശേഷം അതേ ഫലം

വീണ്ടും കണക്ട് ചെയ്ത് ലിങ്ക് വീണ്ടും വായിക്കുക. ഒരിക്കൽ പ്രത്യക്ഷപ്പെട്ട് അടുത്ത മാറ്റത്തിൽ അപ്രത്യക്ഷമാകുന്ന രജിസ്ട്രേഷനാണ് ഈ മുഴുവൻ ചെക്ക്ലിസ്റ്റും ഉണ്ടാകാനുള്ള കാരണമായ തകരാർ. സസ്പെൻഡിന് ശേഷം, നിർബന്ധിത വീണ്ടും കണക്ഷന് ശേഷം, റിസോൾവർ സേവനം പുനരാരംഭിച്ച ശേഷം പരിശോധിക്കുക. ഓരോ മാറ്റവും വ്യത്യസ്തമായ ക്രമ അനുമാനം പരീക്ഷിക്കുന്നു.

വീണ്ടും കണക്ഷനിൽ അഞ്ച് പരിശോധനകളും കടന്നാൽ മാത്രമേ അയച്ച ക്രമീകരണങ്ങൾ ഉപയോഗത്തിലുണ്ടെന്ന് പറയാൻ കഴിയൂ. അതിന് മുമ്പുള്ളതെല്ലാം ഒരു ഭാഗ്യകരമായ നിമിഷത്തിന്റെ സ്നാപ്പ്ഷോട്ടാണ്.