dnsmasq-ൽ നിങ്ങളുടെ VPN ഡൊമെയിൻ സോൺ കൈമാറ്റമല്ല

ക്ലയന്റിന്റെ dnsmasq കോൺഫിഗറേഷനിൽ കോർപ്പറേറ്റ് സോൺ തിരയുന്നു, കണ്ടെത്തുന്നില്ല, VPN അതിന്റെ ഡൊമെയിൻ പുഷ് ചെയ്തില്ലെന്ന് തീരുമാനിക്കുന്നു. പുഷ് ചെയ്തത് റൂട്ടിംഗ് സൂചനയാണ്, സോണല്ല. ക്ലയന്റ് ഡൊമെയിനും അതിന് ഉത്തരം നൽകേണ്ട resolver-ഉം രേഖപ്പെടുത്തുന്നു, നിർവ്വഹിക്കുന്ന backend അതിനെ സോപാധിക ഫോർവേഡിംഗ് ആക്കിമാറ്റുന്നു. തെറ്റായ സ്ഥലത്ത് നോക്കുന്നത് ആത്മവിശ്വാസമുള്ളതും പൂർണ്ണമായും തെറ്റായതുമായ രോഗനിർണ്ണയം നൽകുന്നു.

ക്ലയന്റ് സ്വീകരിച്ചത് ഗേറ്റ്‌വേ നൽകിയതല്ല

ഗേറ്റ്‌വേ ഒരു resolver, ഒരു ഡൊമെയിൻ, ആ resolver-ൽ എത്താൻ ആവശ്യമായ റൂട്ട് എന്നിവ നൽകാം, ക്ലയന്റിന് മൂന്നും അല്ലെങ്കിൽ ഒന്നും സ്വീകരിക്കാം. ഇറക്കുമതി ചെയ്ത പ്രൊഫൈൽ, സഹായ സ്ക്രിപ്റ്റ് അല്ലെങ്കിൽ പുഷ് ചെയ്ത ഓപ്ഷനുകൾ അവഗണിക്കുന്ന നയം സ്വീകരിച്ച സെറ്റ് കാലിയായി വിടാം, അതേസമയം സർവർ ഭാഗം ശരിയായി തോന്നും. സർവറിന്റെ കോൺഫിഗറേഷനല്ല, ക്ലയന്റിന്റെ രേഖപ്പെടുത്തിയ അവസ്ഥയിൽ നിന്ന് തുടങ്ങുക, കാരണം resolver യഥാർത്ഥത്തിൽ ലഭിക്കുന്നത് ആ അവസ്ഥയാണ്. സ്വീകരിച്ച ഡൊമെയിൻ ഇല്ലെങ്കിൽ, അതിനപ്പുറം ഒന്നും പ്രധാനമല്ല. ഏതെങ്കിലും കാഷെ പരിശോധിക്കുന്നതിന് മുമ്പ് കണക്ഷന്റെ DNS ഗുണങ്ങൾ പരിശോധിക്കുക.

ആ വ്യത്യാസം ഒരിക്കലും വന്നിട്ടില്ലാത്ത ഡൊമെയിനിനെക്കുറിച്ചുള്ള മിക്ക റിപ്പോർട്ടുകളെയും വിശദീകരിക്കുന്നു. അത് നൽകി, പ്രയോഗിച്ചില്ല.

രണ്ട് തരത്തിലുള്ള ഡൊമെയിൻ എൻട്രികൾ

ഒരു കണക്ഷന് സാധാരണ തിരയൽ ഡൊമെയിനുകളും റൂട്ട്-മാത്രം ഡൊമെയിനുകളും വഹിക്കാം, രണ്ടാമത്തെ തരം ടിൽഡിൽ തുടങ്ങുന്നു. തിരയൽ ഡൊമെയിൻ അന്വേഷണങ്ങൾ റൂട്ട് ചെയ്യുന്നു, കൂടാതെ ചെറിയ പേരുകൾ വികസിക്കാൻ അനുവദിക്കുന്നു, ഇത് വർക്ക്സ്റ്റേഷനിൽ സൗകര്യപ്രദവും സർവറിൽ അത്ഭുതകരവുമാണ്. റൂട്ട്-മാത്രം ഡൊമെയിൻ ആ സഫിക്സിനുള്ള അന്വേഷണങ്ങൾ ചെറിയ പേരുകൾ എങ്ങനെ പരിഹരിക്കപ്പെടുന്നു എന്നത് മാറ്റാതെ നിർദ്ദിഷ്ട സർവറുകളിലേക്ക് പോകണമെന്ന് പറയുന്നു. ഒരേ ഡൊമെയിൻ രണ്ട് വിധത്തിൽ എഴുതുന്നത് അനാവശ്യമല്ല, കാരണം രണ്ട് എൻട്രികളും വ്യത്യസ്ത ജോലികൾ ചെയ്യുന്നു.

സ്വകാര്യ നെയിംസ്പേസിന് സാധാരണയായി റൂട്ട്-മാത്രം രൂപമാണ് വേണ്ടത്. അത് കോർപ്പറേറ്റ് സഫിക്സ് കോർപ്പറേറ്റ് resolver-ലേക്ക് നിലനിർത്തി ബാക്കിയെല്ലാം ഒറ്റയ്ക്ക് വിടുന്നു.

resolv.conf-ലെ localhost ഒരു ബഗ് അല്ല

പ്രാദേശിക കാഷിംഗ് resolver ഉപയോഗിക്കുമ്പോൾ, സിസ്റ്റം ഫയൽ loopback വിലാസത്തെ മാത്രം ചൂണ്ടിക്കാണിക്കുന്നു, മറ്റൊന്നും അല്ല. ആ എൻട്രി പ്രാദേശിക ശ്രോതാവിനെ തിരിച്ചറിയിക്കുന്നു, മാനേജർ അതിന് നൽകിയ അപ്സ്ട്രീം സർവറുകളെയല്ല. കോർപ്പറേറ്റ് വിലാസം ഫയലിൽ നിയമാനുസൃതമായി ഇല്ലാതിരിക്കും.

ആ എൻട്രി പൊതു resolver ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നത് ക്ലാസിക് തെറ്റായ പരിഹാരമാണ്. അത് പൊതു പേര് പരിഹരണം പുനഃസ്ഥാപിക്കുകയും അതേ എഡിറ്റിൽ സോപാധിക നയം ഉപേക്ഷിക്കുകയും ചെയ്യുന്നു.

backend-കൾ കൂട്ടിക്കുഴയ്ക്കരുത്

നിർവ്വഹിക്കുന്ന dnsmasq ഇൻസ്റ്റൻസും സിസ്റ്റം resolver-ഉം വ്യത്യസ്ത കോൺഫിഗറേഷനും വ്യത്യസ്ത അവസ്ഥാ കാഴ്ചകളുമുള്ള വ്യത്യസ്ത പ്രോഗ്രാമുകളാണ്. ഒന്നിനുള്ള അവസ്ഥാ കമാൻഡ് മറ്റൊന്നിനെക്കുറിച്ച് ഉപയോഗപ്രദമായി ഒന്നും പറയുന്നില്ല.

മാനേജർ ഏത് backend ഉപയോഗിക്കാൻ കോൺഫിഗർ ചെയ്തിരിക്കുന്നു എന്ന് നിർണ്ണയിച്ച്, ആ backend-ന്റെ ജനറേറ്റ് ചെയ്ത കോൺഫിഗറേഷൻ വായിക്കുക, യാദൃച്ഛികമായി നിലവിലുള്ള മുഴുവൻ വിതരണ-വ്യാപക ഫയലല്ല. മാനേജർ സ്വന്തം ഇൻസ്റ്റൻസ് കോൺഫിഗറേഷൻ എഴുതുന്നു, ആ ഇൻസ്റ്റൻസിനുള്ള ഇഷ്ടാനുസൃത ഓപ്ഷനുകൾ പിന്തുണയ്ക്കുന്നു, അതിനാൽ ബന്ധമില്ലാത്ത ആഗോള ഫയൽ എഡിറ്റ് ചെയ്യുന്നത് ഒന്നും മാറ്റുന്നില്ല, ഫലമില്ലാത്ത മാറ്റം പോലെ തോന്നും. പോർട്ട് 53-ൽ രണ്ടാമത്തെ ഡീമൺ ആരംഭിക്കുന്നത് ഉപയോഗശൂന്യതയേക്കാൾ മോശമാണ്, കാരണം ഇപ്പോൾ രണ്ട് പ്രോഗ്രാമുകൾ പോർട്ട് ആർക്കുള്ളതെന്ന കാര്യത്തിൽ യോജിക്കുന്നില്ല. ആദ്യം ഉടമയെ നിർണ്ണയിക്കുക, പിന്നീട് ആ ഉടമ വായിക്കുന്നിടത്ത് എഡിറ്റ് ചെയ്യുക.

നെയിംസ്പേസ് പരീക്ഷിക്കുക, ഉത്തരം മാത്രമല്ല

ആപ്ലിക്കേഷന്റെ സാധാരണ പാതയിലൂടെ ഒരു അനുവദനീയ സ്വകാര്യ നാമവും ഒരു പൊതു നിയന്ത്രണ നാമവും ചോദിക്കുക. കോർപ്പറേറ്റ് സർവറിനോടുള്ള നേരിട്ടുള്ള അന്വേഷണം റെക്കോർഡ് നിലവിലുണ്ടെന്ന് തെളിയിക്കുന്നു; ക്ലയന്റ് ആ സർവർ തിരഞ്ഞെടുത്തുവെന്ന് തെളിയിക്കുന്നില്ല. രണ്ടാമത്തെ അന്വേഷണമാണ് നയം പരീക്ഷിക്കുന്നത്.

തുടർന്ന് വീണ്ടും കണക്ട് ചെയ്തതിനും ഡിസ്കണക്ട് ചെയ്തതിനും ശേഷം ആവർത്തിക്കുക. അസോസിയേഷൻ കണക്ഷന്റെ ജീവിതചക്രം പിന്തുടരണം, സ്വകാര്യ നാമങ്ങൾ ടണൽ ഇല്ലാത്തപ്പോൾ പരിഹരിക്കുന്നത് നിർത്തണം, അതേ സഫിക്സിന് ഉത്തരം നൽകുന്ന പൊതു resolver-ലേക്ക് തിരികെ വീഴുന്നതിന് പകരം. അവ തിരികെ വീഴുന്നുവെങ്കിൽ, നിങ്ങൾ ഒരു ചോർച്ച കണ്ടെത്തി, അത് തകർന്ന ലുക്കപ്പിൽ നിന്ന് വ്യത്യസ്തമായ വൈകല്യമാണ്. ഏത് backend പ്രവർത്തിച്ചു, ഏത് ഡൊമെയിനുകൾ പ്രയോഗിച്ചു, ഓരോ അന്വേഷണവും എന്ത് തിരികെ നൽകി എന്ന് എഴുതുക.