OpenVPN DNS അയയ്ക്കുന്നു, പക്ഷേ നിങ്ങളുടെ റിസോൾവർ അത് ഒരിക്കലും കാണണമെന്നില്ല

ക്ലയന്റ് ലോഗ് അയച്ച DNS സെർവർ കാണിക്കുന്നു, ടണൽ ബന്ധിപ്പിച്ചിരിക്കുന്നു, എന്നിട്ടും ആന്തരിക നാമം ഒന്നിലേക്കും പരിഹരിക്കുന്നില്ല. അയയ്ക്കുന്നതിൽ തന്നെ ഒന്നും തകർന്നിട്ടില്ല. ഓപ്ഷൻ എത്തി, എന്നാൽ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ റിസോൾവർ അത് ഒരിക്കലും ഉപയോഗിച്ചില്ല, കാരണം മിക്ക Unix ക്ലയന്റുകളിലും OpenVPN മൂല്യം കൈമാറി ആപ്ലിക്കേഷനെ പ്ലാറ്റ്ഫോമിന് വിടുന്നു.

ലക്ഷണം: ലോഗ് DNS കാണിക്കുന്നു, പേരുകൾ ഇപ്പോഴും പരാജയപ്പെടുന്നു

OpenVPN dhcp-option DNS, ഡൊമെയ്ൻ വിവരങ്ങൾ വഹിക്കുന്നു, ലഭിച്ചത് ക്ലയന്റ് രേഖപ്പെടുത്തുന്നു. ചില നടപ്പാക്കലുകളിൽ ക്ലയന്റ് ആ ക്രമീകരണങ്ങൾ അകത്ത് പ്രയോഗിക്കുന്നു; മറ്റുള്ളവയിൽ ഇന്റഗ്രേഷൻ സ്ക്രിപ്റ്റിനോ നെറ്റ്വർക്ക് സേവനത്തിനോ അവ കയറ്റുമതി ചെയ്യുന്നു. ലോഗ് വരി കഥയുടെ ആദ്യ പകുതി മാത്രം വിവരിക്കുന്നു. രണ്ടാം പകുതി ക്ലയന്റ് നിയന്ത്രിക്കാത്ത ഇടത്ത് സംഭവിക്കുന്നു. പരാജയം സാധാരണയായി അവിടെയാണ്.

അതുകൊണ്ടാണ് ബന്ധിപ്പിച്ച ടണലും പരാജയപ്പെടുന്ന ആന്തരിക നാമവും ഇത്രയധികം ഒരുമിച്ച് നിൽക്കുന്നത്. മൂല്യം ഉണ്ട്, ഉപയോക്താവ് ഇല്ല അല്ലെങ്കിൽ തെറ്റായി ക്രമീകരിച്ചിരിക്കുന്നു, റിസോൾവർ നിശബ്ദമായി കണക്ഷന് മുമ്പ് ഉപയോഗിച്ച പൊതു സെർവർ തുടർന്നും ഉപയോഗിക്കുന്നു.

ലഭിക്കുന്നത് പ്രയോഗിക്കുന്നതല്ല

സിസ്റ്റം റിസോൾവർ ഇപ്പോഴും മറ്റൊരു സേവനത്തിന്റെ ഉടമസ്ഥതയിലായിരിക്കുമ്പോൾ ക്ലയന്റ് അയച്ച DNS മൂല്യം രേഖപ്പെടുത്താം. ബ്രൗസറിന് സിസ്റ്റം റിസോൾവറിനെ പൂർണ്ണമായി ഒഴിവാക്കുന്ന സ്വന്തം എൻക്രിപ്റ്റഡ് DNS നയവുമാകാം, ഇത് ഒരു ആപ്ലിക്കേഷൻ ആന്തരിക നാമങ്ങൾ പരിഹരിക്കുകയും മറ്റൊന്ന് പരിഹരിക്കാതിരിക്കുകയും ചെയ്യുന്ന ഓർമ്മയിൽ നിൽക്കുന്ന സാഹചര്യം സൃഷ്ടിക്കുന്നു.

ഓരോ Unix ക്ലയന്റും ഒരേ ഫയൽ വീണ്ടും എഴുതുമെന്ന് അനുമാനിക്കുന്നതിന് പകരം നടപ്പാക്കലിന്റെ പിന്തുണയുള്ള സംയോജനം പരിശോധിക്കുക. ആ അനുമാനമാണ് ഒന്നും വായിക്കാത്ത റിസോൾവർ കോൺഫിഗറേഷൻ തിരുത്താൻ ആളുകളെ പ്രേരിപ്പിക്കുന്നത്.

ഓരോ പ്ലാറ്റ്ഫോമിലും റിസോൾവറിന്റെ ഉടമയെ കണ്ടെത്തുക

Windows-ൽ പേര് പരിഹരണ നയ പട്ടിക ചില പ്രത്യയങ്ങളെ ചില സെർവറുകളിലേക്ക് അയയ്ക്കാം, VPN ക്ലയന്റ് അവിടെ നിയമങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യാം. അഡാപ്റ്ററിന്റെ DNS പട്ടിക മാത്രമല്ല, നയം പരിശോധിക്കുക. Linux-ൽ NetworkManager അല്ലെങ്കിൽ systemd-resolved കോൺഫിഗറേഷന്റെ ഉടമയാകാം, ആരാണ് ഉടമ എന്നത് വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ എന്ത് നിലനിർത്തുമെന്ന് നിർണ്ണയിക്കുന്നു.

യഥാർത്ഥത്തിൽ അന്വേഷണങ്ങൾക്ക് ഉത്തരം നൽകുന്ന ഉപകരണം കൊണ്ട് ഫലപ്രദമായ അവസ്ഥ വായിക്കുക: systemd-resolved ഹോസ്റ്റിൽ resolvectl query internal.example.net, അല്ലെങ്കിൽ പ്ലാറ്റ്ഫോമിന്റെ തത്തുല്യം. പിന്നീട് ആ ഉത്തരം ക്ലയന്റ് ലോഗ് അയച്ചതായി അവകാശപ്പെടുന്ന DNS സെർവറുമായി താരതമ്യം ചെയ്യുക.

ഏകോപനമില്ലാതെ റിസോൾവർ ക്രമീകരണങ്ങൾ മേലെഴുതുന്ന നിരവധി സേവനങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നത് ഒഴിവാക്കുക. രണ്ട് ഉടമകൾ ഇടവിട്ട് കാണുന്ന ഫലം നൽകുന്നു, ഓരോ വീണ്ടും ബന്ധിപ്പിക്കലും അത് യദൃച്ഛയാ ശരിയാക്കുകയോ തകർക്കുകയോ ചെയ്യുന്നതായി തോന്നുന്നു.

സ്ക്രിപ്റ്റുകളും foreign_option-ഉം

OpenVPN അയച്ച ഓപ്ഷനുകൾ foreign_option_N എന്ന വേരിയബിളുകളിലൂടെ സ്ക്രിപ്റ്റുകളിലേക്ക് കയറ്റുമതി ചെയ്യുന്നു, സ്ക്രിപ്റ്റിന് അവയെ റിസോൾവർ കമാൻഡുകളാക്കി മാറ്റാം. ഈ ക്രമീകരണം പിന്തുണയുള്ള സംയോജനമാണ്, സ്വയമേവയുള്ള പെരുമാറ്റമല്ല, അത് ക്ലയന്റിൽ ഇൻസ്റ്റാൾ ചെയ്ത് വിളിക്കണം.

സ്ക്രിപ്റ്റിനെ ആശ്രയിക്കുന്നെങ്കിൽ അതിന്റെ പ്രവർത്തനവും എക്സിറ്റ് നിലയും രേഖപ്പെടുത്തുക. പ്രവർത്തിക്കുന്നുവെങ്കിലും നിശബ്ദമായി പരാജയപ്പെടുന്ന സ്ക്രിപ്റ്റ് സ്ക്രിപ്റ്റ് ഇല്ലാത്തതിന് സമാനമായ ലക്ഷണം വിടുന്നു, കോൺഫിഗറേഷൻ പൂർണ്ണമായി കാണുന്നതിനാൽ അത് ശ്രദ്ധിക്കാൻ ബുദ്ധിമുട്ടാണ്. സ്ക്രിപ്റ്റ് ഫയലല്ല, സ്ക്രിപ്റ്റിന്റെ ഔട്ട്പുട്ട് പരിശോധിക്കുക. ഫയൽ ഉണ്ടെന്നത് സ്ക്രിപ്റ്റ് പ്രവർത്തിച്ചു എന്നല്ല.

ലോഗല്ല, പേര് പരീക്ഷിക്കുക

ബന്ധിപ്പിച്ച ശേഷം ക്ലയന്റിൽ നിന്ന് ആന്തരികം മാത്രമുള്ള ഹോസ്റ്റ്നെയിം അന്വേഷിക്കുക, പിന്നീട് പൊതു നാമം അന്വേഷിക്കുക, പിന്നീട് ഏത് സെർവർ ഉത്തരം നൽകി എന്ന് പരിശോധിക്കുക. പ്രവർത്തിക്കുന്ന സജ്ജീകരണത്തിൽ രണ്ട് ഉത്തരങ്ങളും വ്യത്യസ്ത ഇടങ്ങളിൽ നിന്ന് വരുന്നു, രണ്ടും രൂപകൽപ്പനയുമായി ഒത്തുപോകണം.

പേര് പരിഹരിക്കുന്നുവെങ്കിലും സേവനം പരാജയപ്പെടുന്നെങ്കിൽ, വീണ്ടും DNS മാറ്റുന്നതിന് പകരം റൂട്ടിംഗും ആപ്ലിക്കേഷൻ പ്രവേശനവും ലേക്ക് പോകുക. OpenVPN കൈപ്പുസ്തകം dhcp-option-ഉം സ്ക്രിപ്റ്റ് പരിസ്ഥിതിയും രേഖപ്പെടുത്തുന്നു; അടുത്ത റിസോൾവർ ഫയൽ തിരുത്തുന്നതിന് മുമ്പ് നിങ്ങളുടെ ക്ലയന്റ് എന്ത് പ്രയോഗിക്കണമെന്ന് സ്ഥിരീകരിക്കാൻ അത് ഉപയോഗിക്കുക.