നിങ്ങളുടെ VPN DNS എൻക്രിപ്റ്റ് ചെയ്യുന്നുണ്ടോ, അതോ അടുത്ത ഹോപ്പ് മാത്രമോ?
VPN സെർവറിലെ എൻക്രിപ്റ്റ് ചെയ്ത DNS ക്ലയന്റ് വശത്തെ DoT-യിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു ഹോപ്പിനെ സംരക്ഷിക്കുന്നു. എന്തെങ്കിലും പ്രവർത്തനക്ഷമമാക്കുന്നതിന് മുമ്പ് ഓരോ ചോദ്യവും ആര് സ്വീകരിക്കുന്നുവെന്ന് കണ്ടെത്തുക.
VPN സെർവറിൽ എൻക്രിപ്റ്റ് ചെയ്ത DNS പ്രവർത്തനക്ഷമമാക്കുന്നതിനെ ഒരു ചോർച്ച അടയ്ക്കുന്നതായി പലപ്പോഴും വിശേഷിപ്പിക്കുന്നു, ആ വിശേഷണം ഏത് കണക്ഷൻ മാറിയെന്ന് മറച്ചുവയ്ക്കുന്നു. ക്ലയന്റിൽ നിന്ന് റിസോൾവറിലേക്കുള്ള ഹോപ്പും റിസോൾവറിൽ നിന്ന് മുകളിലേക്കുള്ള ഹോപ്പും വെവ്വേറെ ഉടമസ്ഥരുള്ള വെവ്വേറെ കണക്ഷനുകളാണ്. അവയിലൊന്ന് എൻക്രിപ്റ്റ് ചെയ്യുമ്പോഴും മറ്റൊന്ന് മുമ്പുണ്ടായിരുന്നതുപോലെ തന്നെ അവശേഷിക്കുന്നു.
ഒരു കോൺഫിഗറേഷൻ ഫയലിൽ തൊടുന്നതിന് മുമ്പ് ഓരോ ഘട്ടത്തിലും ചോദ്യം ആര് സ്വീകരിക്കുന്നുവെന്ന് എഴുതി വയ്ക്കുക.
രണ്ട് ക്രമീകരണങ്ങളും സെറ്റിംഗ്സ് പേജിൽ ഒരുപോലെ തോന്നുന്നു
ആദ്യ ക്രമീകരണത്തിൽ ഉപകരണം തന്നെ DNS over TLS പ്രവർത്തിപ്പിക്കുന്നു, തുരങ്കം ആ കണക്ഷനെ നിങ്ങൾ തിരഞ്ഞെടുത്ത റിസോൾവറിലേക്ക് കൊണ്ടുപോകുന്നു മാത്രം. TLS സെഷൻ റിസോൾവറിൽ അവസാനിക്കുന്നു, അതായത് റിസോൾവർ ചോദ്യം കാണുന്നു, VPN എക്സിറ്റ് വായിക്കാൻ കഴിയാത്ത എൻക്രിപ്റ്റ് ചെയ്ത ടെക്സ്റ്റ് കാണുന്നു. രണ്ടാം ക്രമീകരണത്തിൽ ഉപകരണം സാധാരണ DNS തുരങ്കത്തിലൂടെ VPN ഹോസ്റ്റിലെ ഫോർവേർഡറിലേക്ക് അയയ്ക്കുന്നു, ആ ഫോർവേർഡർ മുകളിലെ റിസോൾവറിലേക്ക് സ്വന്തം എൻക്രിപ്റ്റ് ചെയ്ത കണക്ഷൻ തുറക്കുന്നു. ഫീച്ചർ ലിസ്റ്റിൽ രണ്ടും "VPN-ഉം എൻക്രിപ്റ്റ് ചെയ്ത DNS-ഉം" എന്ന് തോന്നുന്നു, പക്ഷേ വായിക്കാവുന്ന ചോദ്യം അവ വ്യത്യസ്ത കെട്ടിടങ്ങളിൽ സൂക്ഷിക്കുന്നു.
വ്യത്യാസം തത്വശാസ്ത്രപരമല്ല, അളക്കാവുന്നതാണ്. ക്ലയന്റിലോ സെർവറിലോ TLS സെഷൻ തിരയുക, ഏത് ക്രമീകരണമാണ് യഥാർത്ഥത്തിൽ നിങ്ങൾക്കുള്ളതെന്ന് അറിയാം.
മാറ്റുന്നതിന് മുമ്പ് റിസോൾവർ ശൃംഖല ഭൂപടമാക്കുക
പാതയിലെ റിസോൾവറുകൾ എണ്ണി ഓരോന്നിന്റെയും പങ്ക് പേരിടുക. ഫോർവേർഡിംഗ് ഘടകം ഒരു അഭ്യർത്ഥന മറ്റൊരു റിസോൾവറിന് കൈമാറുന്നു, റിക്കഴ്സീവ് റിസോൾവർ ഉത്തരം കണ്ടെത്തുന്ന ജോലി ചെയ്യുന്നു, അതോറിറ്റേറ്റീവ് സെർവറുകളുമായി നേരിട്ട് സംസാരിച്ചേക്കാം. ഈ പങ്കുകൾ വെവ്വേറെ നിർവചിച്ചിരിക്കുന്നത് കൃത്യം ഈ കാരണത്താലാണ്, കൂടാതെ RFC 9076 റിസോൾവർ നിർവചനങ്ങൾ ഒരേയൊരു മുകളിലെ ലക്ഷ്യം മാത്രമേയുള്ളൂ എന്ന് കരുതുന്നതിന് മുമ്പ് വായിക്കാൻ അർഹിക്കുന്നു. സ്വന്തം റിക്കഴ്സീവ് റിസോൾവർ പ്രവർത്തിപ്പിക്കുന്ന ഹോസ്റ്റിന് എൻക്രിപ്റ്റ് ചെയ്യാൻ ഒരൊറ്റ "മുകളിലെ ലക്ഷ്യം" ഇല്ല, അത് മുഴുവൻ പദ്ധതിയെയും അസാധുവാക്കുന്നു.
പിന്നെ ക്ലയന്റ് ഏത് ഘടകം ഉപയോഗിക്കാൻ ക്രമീകരിച്ചിരിക്കുന്നുവെന്ന് ചോദിക്കുക. VPN പ്രൊഫൈൽ നൽകുന്ന DNS വിലാസം ചോദ്യങ്ങൾ എവിടേക്ക് പോകുന്നുവെന്ന് പറയുന്നു, ഏത് പ്രോസസ് ഉത്തരം നൽകുന്നുവെന്നല്ല.
പരാജയ സ്വഭാവവും ശ്രദ്ധിക്കുക. എൻക്രിപ്റ്റ് ചെയ്ത മുകളിലേക്കുള്ള ലക്ഷ്യം എത്താനാകാത്തതായാൽ, ഫോർവേർഡർ അടഞ്ഞ നിലയിൽ പരാജയപ്പെടുമോ, വ്യക്തമായ ടെക്സ്റ്റിലേക്ക് മടങ്ങുമോ, അതോ മറ്റൊരു റിസോൾവറിലേക്ക് മാറുമോ? ആ തീരുമാനം രേഖയിൽ ഉണ്ടായിരിക്കണം, കാരണം തുരങ്കം ഏറ്റവും ആരോഗ്യമില്ലാത്ത നിമിഷത്തിൽ അത് സ്വകാര്യതാ ഉറപ്പ് മാറ്റുന്നു.
ഏത് ഹോപ്പ് എൻക്രിപ്റ്റ് ചെയ്തിരിക്കുന്നുവെന്ന് പരിശോധിക്കുക
ക്ലയന്റിൽ നിന്ന് തുടങ്ങി അതിന് പോർട്ട് 853-ലേക്ക് TLS സെഷൻ ഉണ്ടോയെന്ന് സ്ഥിരീകരിക്കുക. പോർട്ട് 53 വഴി ശരിയായി പരിഹരിക്കുന്ന ചോദ്യം എൻക്രിപ്ഷനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.
resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A
പിന്നെ VPN ഹോസ്റ്റിലേക്ക് പോയി ഫോർവേർഡർ തുറന്ന പുറത്തേക്കുള്ള എൻക്രിപ്റ്റ് ചെയ്ത കണക്ഷൻ തിരയുക. സോക്കറ്റ് പട്ടിക മുകളിലെ TLS സെഷൻ ഉണ്ടോയെന്നും അത് ഏത് പ്രോസസ് കൈവശം വയ്ക്കുന്നുവെന്നും പറയുന്നു:
ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short
ക്ലയന്റ് TLS സെഷൻ കാണിക്കുകയും സെർവർ ഒന്നും കാണിക്കാതിരിക്കുകയും ചെയ്താൽ, നിങ്ങൾ ആദ്യ ക്രമീകരണത്തിലാണ്, സെർവറിന് IP പാളിയിൽ കൈമാറുന്ന ചോദ്യങ്ങൾ വായിക്കാൻ കഴിയില്ല. സെർവർ TLS സെഷൻ കാണിക്കുകയും ക്ലയന്റ് തുരങ്കത്തിനുള്ളിൽ സാധാരണ പോർട്ട് 53 ട്രാഫിക് കാണിക്കുകയും ചെയ്താൽ, നിങ്ങൾ രണ്ടാം ക്രമീകരണത്തിലാണ്: അടുത്ത ഹോപ്പ് സംരക്ഷിതമാണ്, ഫോർവേർഡർ ഇപ്പോഴും ഉപകരണം ചോദിക്കുന്ന ഓരോ പേരും വായിക്കുന്നു. ആ രണ്ടാമത്തെ ഫലം പരാജയമല്ല, പക്ഷേ അതിനെ അറ്റം മുതൽ അറ്റം വരെയുള്ള എൻക്രിപ്ഷൻ എന്ന് വിളിക്കുന്നത് തെറ്റാണ്.
ഉടമയും പരാജയ സ്വഭാവവും രേഖപ്പെടുത്തുക
എന്ത് വാഗ്ദാനം ചെയ്യാമെന്ന് ഉടമസ്ഥത തീരുമാനിക്കുന്നു. ഉപകരണ ഉടമ ക്ലയന്റ് വശത്തെ എൻക്രിപ്റ്റ് ചെയ്ത കണക്ഷൻ നിയന്ത്രിക്കുന്നു, VPN അഡ്മിനിസ്ട്രേറ്റർ തന്റെ ഫോർവേർഡർ സൃഷ്ടിക്കുന്ന അടുത്ത കണക്ഷൻ നിയന്ത്രിക്കുന്നു. രണ്ടും പ്രവർത്തിപ്പിക്കാത്തവർക്ക് പാത വിവരിക്കാൻ മാത്രമേ കഴിയൂ.
എന്തെങ്കിലും പ്രവർത്തനക്ഷമമാക്കുന്നതിന് മുമ്പ് ആന്തരിക നാമകരണം പരിശോധിക്കുക. സ്ഥാപനത്തിന്റെ പേരുകൾ പൊതു റിസോൾവറിലേക്ക് അയയ്ക്കുന്നത് തുല്യമായ രൂപകൽപ്പനയല്ല, നെറ്റ്വർക്കിനുള്ളിൽ മാത്രം നിലനിൽക്കുന്ന split-horizon മേഖല മുകളിലേക്ക് ഒട്ടും പരിഹരിക്കപ്പെടുകയില്ല. മാറ്റത്തിന് ശേഷം ഒരു ആന്തരികവും ഒരു പൊതു പേരും പരീക്ഷിച്ച് ഫലം കോൺഫിഗറേഷൻ മാറ്റത്തോടൊപ്പം സൂക്ഷിക്കുക. എൻക്രിപ്റ്റ് ചെയ്ത പാത ആന്തരിക ഹോസ്റ്റുകളുടെ പരിഹാരം തകർത്താൽ, പരിഹാരം വിശാലമായ തുരങ്കമല്ല, പരിധി നിശ്ചയിച്ച റിസോൾവർ നിയമമാണ്.
അവസാനമായി ഓരോ ഹോപ്പിനും ഒരു വാക്യം എഴുതുക: ചോദ്യം ഏത് ഘടകം സ്വീകരിച്ചു, ആ ഹോപ്പ് എൻക്രിപ്റ്റ് ചെയ്തിരുന്നോ, പേര് ആർക്ക് വായിക്കാം. VPN ഹോസ്റ്റിനെക്കുറിച്ചുള്ള വാക്യം ഇപ്പോഴും ചോദ്യങ്ങൾ വായിക്കാമെന്ന് പറയുന്നുവെങ്കിൽ, ഡോക്യുമെന്റേഷനും അത് പറയണം, കാരണം അല്ലെന്ന് അവകാശപ്പെടുന്ന ഡയഗ്രം കമാൻഡുകൾ ഒരിക്കലും പ്രവർത്തിപ്പിക്കാത്ത ഒരാൾ വിശ്വസിക്കും.