DNS റിസോൾവർ ലോഗുകളും VPN കണക്ഷൻ ലോഗുകളും: ഓരോന്നിലും എന്തുണ്ട്
റിസോൾവർ തന്നോട് ഉത്തരം പറയാൻ ആവശ്യപ്പെട്ട പേരുകൾ രേഖപ്പെടുത്തുന്നു; VPN സ്വന്തം നടപ്പാക്കലിൽ നിന്ന് ടണൽ സംഭവങ്ങൾ രേഖപ്പെടുത്തുന്നു. ഒരു സൂക്ഷിപ്പ് നയം മറ്റൊന്നിനെ ഉൾക്കൊള്ളുന്നില്ല.
DNS റിസോൾവർ ലോഗും VPN കണക്ഷൻ ലോഗും രണ്ടും നെറ്റ്‌വർക്ക് രേഖകളാണ്, രണ്ടും ഉപയോഗപ്രദമാണ്, പരസ്പരം പകരമാകില്ല. റിസോൾവർ തന്നോട് ഉത്തരം പറയാൻ ആവശ്യപ്പെട്ട പേരുകൾ സ്വീകരിക്കുന്നു. VPN എൻഡ്പോയിന്റ് ടണൽ കണക്ഷനുകൾ കൈകാര്യം ചെയ്യുന്നു, അതിന്റെ നടപ്പാക്കൽ അവയെക്കുറിച്ച് രേഖപ്പെടുത്താൻ തിരഞ്ഞെടുത്തതെല്ലാം രേഖപ്പെടുത്തുന്നു. അവ ഒരേ കെട്ടിടത്തിൽ ആകാം, ഒരേ ടീം പ്രവർത്തിപ്പിക്കാം, ഒരേ സ്വകാര്യതാ അറിയിപ്പിന്റെ പരിധിയിൽ വരാം, എന്നിട്ടും വ്യത്യസ്ത ഐഡന്റിഫയറുകളും വ്യത്യസ്ത സൂക്ഷിപ്പും ഉള്ള വ്യത്യസ്ത സംഭവങ്ങളെ അവ വിവരിക്കുന്നു. ഒന്നിനെ മറ്റൊന്നായി വായിക്കുന്നതാണ് അന്വേഷണങ്ങൾ വഴിതെറ്റുന്ന രീതി.
രണ്ട് ലോഗുകൾ, രണ്ട് സംഭവങ്ങൾ
റിസോൾവറിലെ ഒരു എൻട്രി നാമകരണത്തെക്കുറിച്ചുള്ള ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ഈ ക്ലയന്റ് ഈ സമയത്ത് ഈ പേര് ആവശ്യപ്പെട്ടു, ഉത്തരം ഇതായിരുന്നു. VPN-ലെ ഒരു എൻട്രി കണക്റ്റിവിറ്റിയെക്കുറിച്ചുള്ള ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ഈ പിയർ ഒരു ടണൽ സ്ഥാപിച്ചു അല്ലെങ്കിൽ നഷ്ടപ്പെടുത്തി, ഈ വിലാസം ലഭിച്ചു, പോകുന്നതിന് മുൻപ് ഏകദേശം ഇത്രയും ഡാറ്റ കൈമാറി. രണ്ടും HTTPS സെഷനുള്ളിൽ ഉപയോക്താവ് എന്ത് ചെയ്തു എന്നതിന്റെ രേഖയല്ല, ഒന്നും മറ്റൊന്നിന് പകരമാകുന്നുമില്ല.
ഈ വ്യത്യാസത്തിന് വാഗ്ദാനങ്ങൾക്ക് പ്രായോഗിക പ്രത്യാഘാതമുണ്ട്. VPN ദാതാവ് ടണൽ പ്രവർത്തനം രേഖപ്പെടുത്തുന്നില്ല എന്ന പ്രസ്താവന അത് നൽകുന്ന റിസോൾവറിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, റിസോൾവറിന്റെ സൂക്ഷിപ്പ് നയം ടണലിൽ ആര് ബന്ധിപ്പിച്ചു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഓരോ അവകാശവാദവും അതിന്റെ സ്വന്തം ഓപ്പറേറ്ററുടെയും സ്വന്തം സിസ്റ്റത്തിന്റെയും ആണ്.
ഏതെങ്കിലും ലോഗ് വായിക്കുന്നതിന് മുൻപ് ചോദ്യം പിന്തുടരുക
ചോദ്യം റിസോൾവറിലെത്തുന്നത് പാത അതിനോട് യഥാർത്ഥത്തിൽ ചോദിക്കുമ്പോൾ മാത്രമാണ്. ഒരു ആപ്ലിക്കേഷന് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ റിസോൾവർ ഉപയോഗിക്കാം, സ്വന്തം എൻക്രിപ്റ്റ് ചെയ്ത DNS ക്ലയന്റ് പ്രവർത്തിപ്പിക്കാം, അല്ലെങ്കിൽ കാഷ് ചെയ്ത ഉത്തരം വായിച്ച് ഒന്നും അയക്കാതിരിക്കാം. അതിനാൽ ഒന്നും കാണിക്കാത്ത റിസോൾവർ ലോഗ് ഒരു പേര് ഒരിക്കലും ഉപയോഗിച്ചില്ല എന്നതിന്റെ തെളിവല്ല; ഈ റിസോൾവറിനോട് ചോദിച്ചില്ല എന്നതിന്റെ തെളിവാണ്.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerഅവസാന കമാൻഡ് പ്രാദേശിക റിസോൾവറിന്റെ സ്വന്തം ജേണൽ വായിക്കുന്നു, അത് അപ്സ്ട്രീം സെർവറിന്റെ ലോഗിന് തുല്യമല്ല. നിങ്ങളുടെ ചോദ്യങ്ങൾ DNS over HTTPS വഴി ഒരു ദാതാവിലേക്ക് പോകുന്നുവെങ്കിൽ, പ്രാദേശിക സ്റ്റബ് ഒന്നും കാണിച്ചേക്കില്ല, ദാതാവിന് പൂർണ്ണ രേഖ ഉണ്ടാകും, ദാതാവ് വേറെ നയമുള്ള വേറെ ഓപ്പറേറ്ററാണ്.
ഓരോ രേഖയ്ക്കും എന്ത് കാണിക്കാം, എന്ത് കാണിക്കാനാവില്ല
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
അവയെ ബന്ധിപ്പിക്കുന്നതാണ് യഥാർത്ഥ ജോലി, ബന്ധിപ്പിക്കൽ എപ്പോഴും സാധ്യമല്ല. ക്ലയന്റ് വിലാസങ്ങൾ രേഖപ്പെടുത്തുന്ന റിസോൾവറിനെ അറിയപ്പെടുന്ന പൂളിൽ നിന്ന് വിലാസങ്ങൾ നൽകുന്ന VPN-മായി താരതമ്യം ചെയ്യാം, ആ താരതമ്യം ചോദിച്ച പേരും ടണലും തമ്മിൽ സാധ്യതയുള്ള ബന്ധം സൃഷ്ടിക്കുന്നു, അത് രണ്ട് രേഖകൾ തമ്മിലുള്ള ബന്ധമായി തുടരുന്നു, ഒരു വ്യക്തിയുടെ രേഖയല്ല.
എൻക്രിപ്റ്റ് ചെയ്ത DNS ഗതാഗതം മാറ്റുന്നു, എൻഡ്പോയിന്റിലെ ദൃശ്യതയല്ല. റിസോൾവർ താൻ ഉത്തരം നൽകുന്ന ചോദ്യം ഇപ്പോഴും സ്വീകരിക്കുന്നു, RFC 8484 വ്യക്തമാക്കുന്നതുപോലെ, ആ റിസോൾവറിലെ സൂക്ഷിപ്പ് പ്രോട്ടോക്കോളിന്റെ സ്വഭാവമല്ല, നയത്തിന്റെ തീരുമാനമാണ്.
വിഭജിത DNS-ഉം കാഷുകളും കഥ കുഴപ്പിക്കുന്നിടത്ത്
നിരവധി റിസോൾവറുകൾ സാധാരണമാണ്. വിഭജിത DNS രൂപകൽപ്പന ആന്തരിക പേരുകൾ ആന്തരിക സെർവറിലേക്കും ബാക്കിയെല്ലാം പൊതു സെർവറിലേക്കും അയക്കുന്നു, അതിനാൽ ഒരു അന്വേഷണം ഒരിക്കലും കൂട്ടിച്ചേർക്കാൻ ഉദ്ദേശിക്കാത്ത രണ്ട് ലോഗുകളും ഒരിക്കലും താരതമ്യം ചെയ്യാൻ ഉദ്ദേശിക്കാത്ത രണ്ട് സൂക്ഷിപ്പ് ക്രമീകരണങ്ങളും ഉൾപ്പെടുത്താം. രണ്ടിലും ചോദ്യങ്ങൾ കാണുന്നത് രൂപകൽപ്പന പ്രവർത്തിക്കുന്നു എന്നതിന്റെ തെളിവാണ്, ചോർച്ചയുടെ തെളിവല്ല.
കാഷുകൾ എതിർദിശയിൽ മുറിക്കുന്നു. ജനപ്രിയമായ ഒരു പേരിന് മണിക്കൂറുകളോളം കാഷിൽ നിന്ന് ഉത്തരം നൽകാം, അതിനാൽ റിസോൾവറിന്റെ രേഖ ആദ്യ ചോദ്യം കാണിച്ച് പിന്നെ ഒന്നും കാണിക്കുന്നില്ല, ഉപയോക്താവിന്റെ ആപ്ലിക്കേഷൻ അതേ പേര് സന്തോഷത്തോടെ പരിഹരിച്ചുകൊണ്ടിരിക്കും. ഒരു നിശ്ചിത സമയത്തിന് ശേഷം എൻട്രികൾ ഇല്ലാതിരിക്കുന്നത് ആ സമയത്തിന് ശേഷം ആരും പേര് ഉപയോഗിച്ചില്ല എന്നർത്ഥമാക്കുന്നില്ല.
പശ്ചാത്തല ട്രാഫിക്കാണ് മൂന്നാമത്തെ വൈകൃതം. ബൂട്ടിൽ ടെലിമെട്രി പേര് പരിഹരിക്കുന്ന ഫോൺ, തിരയൽ നിർദ്ദേശ ഡൊമെയ്ൻ പരിഹരിക്കുന്ന ബ്രൗസർ, മണിക്കൂറിൽ ഒരിക്കൽ ബന്ധപ്പെടുന്ന അപ്ഡേറ്റർ—എല്ലാം റിസോൾവർ ലോഗിൽ നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ പ്രധാനമായ പേരിനൊപ്പം പ്രത്യക്ഷപ്പെടുന്നു. ആ ലോഗിലെ അളവ് ശ്രദ്ധയല്ല, ചോദ്യങ്ങൾ എണ്ണുന്നത് സന്ദർശനങ്ങൾ എണ്ണുന്നതല്ല. റിസോൾവർ ലോഗ് ചോദ്യങ്ങളുടെ രേഖയാണ്, ചോദ്യങ്ങൾ സൃഷ്ടിക്കാൻ വിലകുറവാണ്.
സൂക്ഷിപ്പ് ചോദ്യങ്ങൾ വെവ്വേറെ ചോദിക്കുക
ഓരോ സിസ്റ്റത്തിനും മൂന്ന് ചോദ്യങ്ങൾ ചോദിക്കുക: ആര് ശേഖരിക്കുന്നു, എന്ത് ശേഖരിക്കുന്നു, ഒപ്പം എത്ര കാലം അത് സൂക്ഷിക്കുന്നു. തുടർന്ന് അത് ആർക്ക് വായിക്കാം, ഏത് പ്രക്രിയയിൽ എന്ന് ചോദിക്കുക. DNS over HTTPS-നെക്കുറിച്ചുള്ള RFC 8484 ചർച്ച, എൻക്രിപ്റ്റ് ചെയ്ത ഗതാഗതം എൻഡ്പോയിന്റ് നീക്കം ചെയ്യുന്നില്ല എന്നതിന്റെ നല്ല ഓർമ്മപ്പെടുത്തലാണ്, ഓപ്പറേറ്ററുടെ സ്വന്തം ഡോക്യുമെന്റേഷൻ മാത്രമാണ് ആ എൻഡ്പോയിന്റ് എന്ത് സൂക്ഷിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള വിശ്വസനീയമായ പ്രസ്താവന.
സ്വകാര്യതയെക്കുറിച്ച് “VPN”-നെ കുറിച്ച് ഒരു അവകാശവാദം ഉയരുമ്പോൾ, അത് സ്വീകരിക്കുന്നതിന് മുൻപ് ഘടകങ്ങളായി വിഭജിക്കുക: ടണൽ ഓപ്പറേറ്റർ, ടണൽ നൽകുന്ന റിസോൾവർ, ആ ചോദ്യങ്ങൾ എത്തുന്ന ഏതെങ്കിലും അപ്സ്ട്രീം റിസോൾവർ, ഉപകരണത്തിലെ ആപ്ലിക്കേഷനുകൾ. ഓരോന്നിനും സ്വന്തം ഉത്തരമുണ്ട്, ഒന്നിന് കൃത്യമായ അവകാശവാദം നാലും ഉൾക്കൊള്ളുന്നതായി പതിവായി ആവർത്തിക്കുന്നു.
പ്രശ്നപരിഹാരത്തിന് അതേ വിഭജനം ഉപയോഗിക്കുക. ഏത് ആപ്ലിക്കേഷൻ ചോദ്യം നടത്തി, ഏത് റിസോൾവർ ഉത്തരം നൽകി എന്ന് ചോദിക്കുക, തുടർന്ന് ആ സംഭവത്തിന്റെ യഥാർത്ഥ ഉടമയായ ലോഗ് നോക്കുക. മറ്റേ ലോഗിൽ നിന്ന് ഊഹിക്കുന്നത് ഒരു മിനിറ്റ് ലാഭിക്കും, ഒരു ഉച്ചയ്ക്ക് ശേഷം നഷ്ടപ്പെടുത്തും.