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

ആദ്യ മിത്ത്: ബാഡ്ജ് നിങ്ങളുടെ റിസോൾവറിനെ പേരിടുന്നു

ലീക്ക് ടെസ്റ്റ് ഒരു പ്രോബ് നാമം പരിഹരിച്ച് ഉത്തരം നൽകിയ വിലാസം റിപ്പോർട്ട് ചെയ്യുന്നു. ആ റിസോൾവറിനെ തിരഞ്ഞെടുത്ത നയം അത് റിപ്പോർട്ട് ചെയ്യുന്നില്ല, അന്വേഷണം DNS over HTTPS-ൽ പൊതിഞ്ഞിരിക്കുമ്പോൾ പാതയിലെ ഇടനില പെട്ടിക്ക് നാമം കാണാനേ കഴിയില്ല. രണ്ട് വ്യത്യസ്ത യന്ത്രങ്ങൾ ഒരേ ആശ്വാസകരമായ ബാഡ്ജ് നൽകുന്നു: ഒന്നിൽ VPN 10.8.0.1 അയച്ചു, ബ്രൗസർ അത് ഉപയോഗിക്കുന്നു; മറ്റൊന്നിൽ ബ്രൗസർ സിസ്റ്റം പട്ടിക അവഗണിച്ച് നാമം ടണലിലൂടെ സ്വന്തം എൻക്രിപ്റ്റ് ദാതാവിന് അയച്ചു.

സ്വകാര്യ നാമം പരാജയപ്പെടുന്ന നിമിഷത്തിൽ ഈ വ്യത്യാസം പ്രധാനമാണ്. ആദ്യ ക്രമീകരണത്തിൽ VPN റിസോൾവർ കോർപ്പറേറ്റ് സോണിന് ഉത്തരം നൽകുന്നു; രണ്ടാമത്തേതിൽ ബ്രൗസർ അതിനോട് ഒരിക്കലും ചോദിച്ചിട്ടില്ല, അതിനാൽ ചെറിയ ഹോസ്റ്റ്നാമം പരിഹരിക്കപ്പെടുന്നില്ല, പരാജയം കേടായ VPN പോലെ തോന്നുന്നു. ഈ പരിശോധന മറ്റൊരു ലീക്ക് ടെസ്റ്റല്ല, ഒരു റിസോൾവറിന് മാത്രം അറിയാവുന്ന ഒരു നാമത്തിനായുള്ള തിരയലാണ്.

രണ്ടാം മിത്ത്: ബ്രൗസർ ടണൽ വിടുന്നു

DNS ഒരു വിലാസം തിരഞ്ഞെടുക്കുന്നു, റൂട്ടിംഗ് കണക്ഷൻ വഹിക്കുന്നു, ഇവ രണ്ട് വേർതിരിച്ച പാളികളാണ്. പൊതു DoH ദാതാവിന് അയക്കുന്ന അന്വേഷണം ഇപ്പോഴും റൂട്ട് ചെയ്യാവുന്ന വിലാസത്തിലേക്കുള്ള TCP പോർട്ട് 443 ആണ്. നിങ്ങളുടെ റൂട്ട് ടേബിൾ ഡിഫോൾട്ട് റൂട്ട് ടണലിലേക്ക് അയച്ചാൽ, ആ അന്വേഷണവും ടണലിലൂടെ പോകുന്നു. റിസോൾവറിന്റെ ബ്രാൻഡ് പാത തീരുമാനിക്കുന്നില്ല.

ബ്രൗസർ DoH മാറ്റുന്നത് നാമങ്ങളുടെ സ്വീകർത്താവിനെയാണ്. അത് യഥാർത്ഥ സ്വകാര്യതാ തീരുമാനവും യഥാർത്ഥ നയ തീരുമാനവുമാണ്, പക്ഷേ റൂട്ടിംഗ് ഒഴിവാക്കലല്ല. നാമങ്ങൾ VPN ഓപ്പറേറ്ററുടെ പക്കൽ തന്നെ നിൽക്കണം എന്നതാണ് നിങ്ങളുടെ വ്യവസ്ഥയെങ്കിൽ, മറ്റൊരാൾക്ക് അയക്കുന്ന എൻക്രിപ്റ്റ് അന്വേഷണം ആ വ്യവസ്ഥ പാലിക്കുന്നില്ല, എന്നിട്ടും യഥാർത്ഥ കണക്ഷന് ടണൽ ഉപയോഗിക്കുന്നു.

മൂന്നാം മിത്ത്: ഓരോ VPN ഓരോ ബ്രൗസറിനെയും മറികടക്കുന്നു

ബ്രൗസറിലെ സുരക്ഷിത DNS-ന് മോഡുകളുണ്ട്, സ്വിച്ചല്ല: ഓഫ്, ഫാൾബാക്കുള്ള ഡിഫോൾട്ട് ദാതാവ്, ഇഷ്ടാനുസൃത ടെംപ്ലേറ്റ്, അല്ലെങ്കിൽ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം അല്ലെങ്കിൽ സംഘടന അടിച്ചേൽപ്പിക്കുന്ന നയം. ഫാൾബാക്ക് കേസാണ് ഇടവിട്ടുള്ള റിപ്പോർട്ടുകൾ സൃഷ്ടിക്കുന്നത്. എൻക്രിപ്റ്റ് എൻഡ്പോയിന്റ് എത്താനാകാത്തപ്പോൾ ബ്രൗസർ സിസ്റ്റം റിസോൾവറിലേക്ക് മടങ്ങാം, അതിനാൽ അതേ ലാപ്ടോപ്പ് തിങ്കളാഴ്ച സ്വകാര്യ നാമം ശരിയായി പരിഹരിക്കുന്നു, ചൊവ്വാഴ്ച പരിഹരിക്കുന്നില്ല.

അതേ സമയം, മിക്ക VPN ക്ലയന്റുകളും കണക്ഷൻ ഉയരുമ്പോൾ സിസ്റ്റം റിസോൾവർ സജ്ജീകരിക്കുകയും അത് വീഴുമ്പോൾ മുൻപത്തേത് പുനഃസ്ഥാപിക്കുകയും ചെയ്യുന്നു. ഇഷ്ടാനുസൃത എൻക്രിപ്റ്റ് റിസോൾവർ കൈവശം വയ്ക്കുന്ന ബ്രൗസർ ആ പുനഃസ്ഥാപനം ഒട്ടും ശ്രദ്ധിക്കുന്നില്ല. അതുകൊണ്ടാണ് അതേ പ്രൊഫൈൽ രണ്ട് ലാപ്ടോപ്പുകളിൽ വ്യത്യസ്തമായി പെരുമാറുന്നത്, അതുകൊണ്ടാണ് ബ്രൗസർ ഇപ്പോഴും മറ്റൊരാളോട് ചോദിക്കുമ്പോൾ resolv.conf ശരിയായി തോന്നുന്നത്.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

കണക്ട് ചെയ്തിരിക്കുമ്പോൾ അവ പ്രവർത്തിപ്പിക്കുക, ഓരോ റിസോൾവറും ഏത് ഡൊമെയ്നുകൾ അവകാശപ്പെടുന്നു എന്ന് ശ്രദ്ധിക്കുക, ബ്രൗസർ സ്വന്തം മോഡിനെക്കുറിച്ച് റിപ്പോർട്ട് ചെയ്യുന്നതുമായി താരതമ്യം ചെയ്യുക. Mozilla-യുടെ DoH ഡോക്യുമെന്റേഷൻ ബ്രൗസറിന്റെ ഡിഫോൾട്ട്, ഫാൾബാക്ക് പെരുമാറ്റങ്ങൾ എങ്ങനെ പ്രവർത്തിക്കണം എന്നതിന്റെ ന്യായമായ വിവരണമാണ്.

തീരുമാനത്തിന് മൂന്ന് ഇൻപുട്ടുകളുണ്ട്, ഒന്നല്ല

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

ConditionWhat it forces
Internal names must resolveSplit DNS: private suffixes to the VPN resolver, the rest to your chosen default
Queries must stay with one operatorPin both the system resolver and the browser mode, and disable fallback
Resolver only reachable through the tunnelKeep the pushed resolver; do not point DoH at an endpoint your routes exclude

ഈ വരികളിൽ ഒന്നും സാർവത്രിക ശുപാർശയല്ല. VPN പ്രവർത്തിപ്പിക്കുന്ന റിസോൾവർ നിരീക്ഷണങ്ങൾ ആ ഓപ്പറേറ്ററുടെ പക്കൽ കേന്ദ്രീകരിക്കുന്നു; പ്രത്യേക സേവനം ചോദിക്കപ്പെട്ട നാമങ്ങളുടെ മറ്റൊരു സ്വീകർത്താവിനെ കൂട്ടിച്ചേർക്കുന്നു. രണ്ട് ക്രമീകരണങ്ങളും സൂക്ഷിക്കുന്നതിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, നിങ്ങൾ നയം വായിക്കുന്നില്ലെങ്കിൽ.

ഓരോ പ്രൊഫൈലിനും തീരുമാനം എഴുതിവയ്ക്കുക, കാരണം ഈ ക്രമീകരണങ്ങൾ നീങ്ങുന്നു. കഴിഞ്ഞ മാസം ഒരു റിസോൾവർ അയച്ച പ്രൊഫൈൽ ഇന്ന് ഒന്നും അയക്കണമെന്നില്ല, ഇപ്പോഴും ഉത്തരം നൽകുന്ന പഴയ ഇഷ്ടാനുസൃത എൻഡ്പോയിന്റ് ബ്രൗസർ സന്തോഷത്തോടെ നിലനിർത്തും. കുറിപ്പിൽ റിസോൾവറിന്റെ വിലാസം, അതിന്റെ ഉടമസ്ഥതയിലുള്ള സഫിക്സുകൾ, ബ്രൗസർ മോഡ് എന്നിവ വേണം, സേവനത്തിന്റെ ബ്രാൻഡല്ല.

നിങ്ങൾ കോൺഫിഗർ ചെയ്തുവെന്ന് കരുതുന്ന നയം പരിശോധിക്കുക

ബാഡ്ജ് കൊണ്ടല്ല, നാമം കൊണ്ട് പരിശോധിക്കുക. സിസ്റ്റം റിസോൾവർ വഴി ഒരു പൊതു നാമവും ഒരു സ്വകാര്യ നാമവും പരിഹരിക്കുക, തുടർന്ന് നിങ്ങൾ ഉപയോഗിക്കാൻ ഉദ്ദേശിക്കുന്ന മോഡിൽ ബ്രൗസറിന്റെ സ്വന്തം സുരക്ഷിത DNS ക്രമീകരണത്തോടെ അത് ആവർത്തിക്കുക. സ്വകാര്യ നാമം ബ്രൗസറിൽ മാത്രം പരാജയപ്പെട്ടാൽ, ഒരു VPN ക്രമീകരണവും തൊടാതെ സ്വീകർത്താവിന്റെ പൊരുത്തക്കേട് നിങ്ങൾ കണ്ടെത്തി.

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

നാമസ്പേസ് ചോദ്യത്തിൽ തുടങ്ങിയാൽ ഇതിൽ ഭൂരിഭാഗവും ഒഴിവാക്കാം. യന്ത്രത്തിന് ആന്തരിക നാമങ്ങളിൽ എത്തണമെങ്കിൽ, ബ്രൗസറിന്റെ എൻക്രിപ്റ്റ് റിസോൾവർ പൊതു പകുതിയെക്കുറിച്ചുള്ള തീരുമാനം മാത്രമാണ്, സ്വകാര്യ പകുതി VPN അയച്ചതിനൊപ്പം തുടരുന്നു.

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