ബ്രൗസർ ടണലിൽ നിന്ന് ഒഴിവാക്കിയിരിക്കുന്നു, പൊതു IP പേജ് അതിന്റെ ട്രാഫിക് വീട്ടിലെ കണക്ഷനിലൂടെ പുറത്തുപോകുന്നുവെന്ന് സ്ഥിരീകരിക്കുന്നു, എന്നിട്ടും ആന്തരിക വിക്കി തുറക്കുന്നില്ല. പേര് നിർണ്ണയം മറ്റൊരിടത്തേക്ക് പോയി, ആ മറ്റൊരിടം സാധാരണയായി VPN ക്രമീകരിച്ച റിസോൾവർ ആണ്. ഡാറ്റ പാതയും റിസോൾവർ പാതയും മിക്ക സ്പ്ലിറ്റ്-ടണൽ രൂപകൽപ്പനകളിലും വെവ്വേറെ തീരുമാനങ്ങളാണ്. ഒഴിവാക്കൽ തകർന്നതാണെന്ന് പറയുന്നതിന് മുമ്പ് ബ്രൗസർ യഥാർത്ഥത്തിൽ ഏതാണ് ഉപയോഗിച്ചതെന്ന് പരിശോധിക്കുക.

ഡാറ്റ പാതയും റിസോൾവർ പാതയും വേർപെടുന്നു

ഒഴിവാക്കൽ ഒരു അപ്ലിക്കേഷന്റെ പാക്കറ്റുകൾ ടണലിൽ നിന്ന് നീക്കം ചെയ്യുന്നു, അത് ഡാറ്റ പാതയിലെ റൂട്ടിംഗ്, ഫയർവാൾ തീരുമാനമാണ്. പേര് നിർണ്ണയം മറ്റൊരു അന്വേഷണമാണ്: ഒരു പ്രോസസ്സ് സിസ്റ്റത്തിന്റെ റിസോൾവറിനോട് ചോദിക്കുന്നു, ആ റിസോൾവർ ഏത് സെർവർ ചോദ്യം സ്വീകരിക്കണമെന്ന് തീരുമാനിക്കുന്നു.

രണ്ടും ബോധപൂർവവും വ്യത്യസ്തവുമാകാം. ഒരു ജോലി വിന്യാസം ആന്തരിക നാമസ്ഥലങ്ങൾ കോർപ്പറേറ്റ് റിസോൾവറിൽ നിലനിർത്തി തിരഞ്ഞെടുത്ത പൊതു ബ്രൗസിംഗ് ടണലിന് പുറത്തേക്ക് അയയ്ക്കാം, ആന്തരിക നാമങ്ങൾ മറ്റെവിടെയും നിർണ്ണയിക്കാത്തതിനാൽ തന്നെ. ആശയക്കുഴപ്പമുള്ള സന്ദർഭം വിപരീതമാണ്: ഒരു പൊതു സൈറ്റ് പരാജയപ്പെടുന്നു, കാരണം ബ്രൗസർ വിന്യാസം പ്രതീക്ഷിച്ച റിസോൾവറിനോട് ഒരിക്കലും ചോദിച്ചില്ല. പാതയും റിസോൾവറും വെവ്വേറെ രേഖപ്പെടുത്തുക, പകുതി തർക്കങ്ങൾ അപ്രത്യക്ഷമാകും.

ഏത് പ്രോസസ്സ് ചോദ്യം ചോദിക്കുന്നുവെന്ന് കണ്ടെത്തുക

ബ്രൗസറിന് സിസ്റ്റത്തിന്റെ റിസോൾവർ, സ്വന്തം എൻക്രിപ്റ്റ് ചെയ്ത DNS സേവനം, അല്ലെങ്കിൽ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ഓരോ നെറ്റ്വർക്കിനും നൽകുന്ന റിസോൾവർ ഉപയോഗിക്കാം. ആദ്യത്തേത് പ്ലാറ്റ്ഫോം നയം പിന്തുടരുന്നു, രണ്ടാമത്തേത് ആ നയം പൂർണ്ണമായി ഒഴിവാക്കുന്നു, മൂന്നാമത്തേത് ചോദ്യം ഏത് ലിങ്കിലേക്ക് റൂട്ട് ചെയ്യുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

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

ഏത് റിസോൾവർ ഏത് പേര് കാണണമെന്ന് തീരുമാനിക്കുക

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഉദ്ദേശിച്ച മാപ്പിംഗ് എഴുതുക: ആന്തരിക നാമങ്ങൾ കോർപ്പറേറ്റ് റിസോൾവറിലേക്ക്, പൊതു നാമങ്ങൾ നയം അനുവദിക്കുന്ന സേവനത്തിലേക്ക്, ഒഴിവുകൾ ഉടമയോടൊപ്പം. ആ പട്ടികയില്ലാതെ, ലീക്ക് പരിശോധനയുടെ ഓരോ ലേബലും ആർക്കും തീർപ്പാക്കാനാകാത്ത നയ തർക്കമായി മാറുന്നു.

പിന്നീട് ബ്രൗസറിന്റെ സ്വന്തം ക്രമീകരണം പരിശോധിക്കുക, കാരണം ബ്രൗസറിലെ എൻക്രിപ്റ്റ് ചെയ്ത DNS ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ചോദ്യം സ്വീകരിക്കുന്നതിന് മുമ്പ് പ്രയോഗിക്കുന്നു. ക്യാപ്റ്റീവ് പോർട്ടൽ ഒഴിവാക്കാൻ അത് ഓണാക്കിയ ഉപയോക്താവ് വിന്യാസം തിരഞ്ഞെടുത്ത റിസോൾവറിനെ നിശ്ശബ്ദമായി മറികടന്നു. അത് ലീക്കല്ല, കോൺഫിഗറേഷൻ തീരുമാനമാണ്, ബ്ലോക്ക്ലിസ്റ്റിനേക്കാൾ തീരുമാനത്തിന് അർഹമാണ്.

ഒരു പരിശോധന ലേബൽ പച്ചയാക്കാൻ ഓരോ DNS ഫീൽഡും വീണ്ടും എഴുതരുത്. ലേബൽ ഒരു നിമിഷത്തിൽ ഒരു പ്രോസസ്സിന്റെ ഒരു ചോദ്യം വിവരിക്കുന്നു.

ചോദ്യവും കണക്ഷനും വെവ്വേറെ പരിശോധിക്കുക

രണ്ട് പാതകളും സ്വതന്ത്രമായി പരിശോധിക്കുക. കണക്ഷൻ പരിശോധന ഡാറ്റ പാത കാണിക്കുന്നു, റിസോൾവർ പരിശോധന പേര് ആർ സ്വീകരിച്ചുവെന്ന് കാണിക്കുന്നു.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

റിസോൾവറിനോട് വ്യക്തമായും ചോദിക്കുക, പരാജയം പാതയ്ക്കല്ല സെർവറിന് ആരോപിക്കാൻ. പിന്നീട് ബ്രൗസർ പുനരാരംഭിച്ച് ആവർത്തിക്കുക, കാരണം അപ്ലിക്കേഷനുകൾ നെഗറ്റീവ് ഉത്തരങ്ങൾ കാഷ് ചെയ്യുന്നു, പഴയ പരാജയം നിത്യമായി തോന്നുന്നു.

അംഗീകരിച്ച മാറ്റത്തിന് ശേഷം ഡാറ്റ പാതയും റിസോൾവറിന്റെ സ്വീകർത്താവിനെ രണ്ട് വെവ്വേറെ വരികളായി തീയതിയോടൊപ്പം രേഖപ്പെടുത്തുക. അടുത്ത പുനർബന്ധനത്തിൽ പെരുമാറ്റം മടങ്ങിയാൽ, അത് നൽകുന്ന പ്രൊഫൈൽ ആണ് ശരിയാക്കേണ്ടത്, ബ്രൗസർ അല്ല.

അനുബന്ധ ലേഖനങ്ങൾ