VPN എന്റെ DNS മാറ്റിയോ? മുമ്പും ശേഷവും താരതമ്യം ചെയ്യുക
ഒരു പ്രൊഫൈലിന് നിങ്ങളുടെ ക്വറികൾ ബോധപൂർവം നീക്കാൻ കഴിയും. VPN കണക്ട് ചെയ്യുന്നതിന് മുമ്പും ശേഷവും റിസോൾവർ നയവും യഥാർത്ഥ ഉത്തരവും താരതമ്യം ചെയ്യുക, ഒരു വേരിയബിൾ സ്ഥിരമായി നിർത്തി.
നിങ്ങൾ ടണൽ ബന്ധിപ്പിക്കുന്നു, ഒരു സ്വകാര്യ ഡാഷ്ബോർഡ് തുറക്കുന്നു, പേര് നിങ്ങൾ ഒരിക്കലും കണ്ടിട്ടില്ലാത്ത ഒരു വിലാസത്തിലേക്ക് പരിഹരിക്കുന്നു. അല്ലെങ്കിൽ വിപരീതം സംഭവിക്കുന്നു: ബ്രൗസർ പ്രവർത്തിച്ചുകൊണ്ടിരിക്കുമ്പോൾ കമാൻഡ്-ലൈൻ ടൂൾ പെട്ടെന്ന് ഒന്നും പരിഹരിക്കുന്നില്ല. രണ്ട് ഫലങ്ങളും ഒരേ മാറ്റത്തിൽ നിന്നാണ് വരുന്നത്, ആളുകൾ ഇത് സാധാരണയായി VPN "സ്വന്തം DNS ഉപയോഗിക്കുന്നു" എന്ന ഒരു വാക്യം കൊണ്ട് വിശദീകരിക്കുന്നു, ഇത് ഡീബഗ് ചെയ്യാനോ സ്ഥിരീകരിക്കാനോ മത്രമുള്ള കൃത്യതയല്ല. ആ വാക്യത്തിൽ രണ്ട് ചോദ്യങ്ങൾ ഒളിഞ്ഞിരിക്കുന്നു: ഈ പ്രൊഫൈൽ ഏത് ക്വറികൾ ഏറ്റെടുക്കണം, നിങ്ങളുടെ യന്ത്രം അവ യഥാർത്ഥത്തിൽ തനിക്ക് നൽകിയ റിസോൾവറിലേക്ക് അയച്ചോ? അവയെ വേർതിരിച്ച് നിർത്തുന്നതാണ് മുഴുവൻ രീതി, കാരണം അവ കലർത്തുന്ന പരിശോധന രണ്ട് ദിശകളിലും ആത്മവിശ്വാസമുള്ള തെറ്റായ ഉത്തരം നൽകുന്നു.
ഒരു പ്രൊഫൈൽ എന്തിന് റിസോൾവർ നൽകുന്നു
ടണലിനുള്ളിൽ, വിദൂര അറ്റത്തിന് പിന്നിലുള്ള പേരുകൾ സാധാരണയായി ആ നെറ്റ്‌വർക്കിൽ മാത്രം നിലനിൽക്കുന്ന വിലാസങ്ങളിലേക്ക് പരിഹരിക്കുന്നു. corp.internal പോലുള്ള സ്വകാര്യ സോണിന് പൊതു പ്രതിനിധാനമില്ല, അതിനാൽ അതിന് ഉത്തരം നൽകുന്ന റിസോൾവർ ടണലിനുള്ളിൽ നിന്ന് എത്താവുന്നതായിരിക്കണം. അതേ സംവിധാനം രണ്ടാമത്തെ ലക്ഷ്യത്തിനും ഉപകരിക്കുന്നു: ക്വറികൾ അല്ലെങ്കിൽ നിങ്ങളുടെ ISP വഴി പുറത്തുപോകുമായിരുന്നു എങ്കിൽ, വിദൂര വശത്തെ റിസോൾവർ ക്വറിയെ എൻക്രിപ്റ്റ് ചെയ്ത പാതയ്ക്കുള്ളിൽ നിർത്തുന്നു. അതുകൊണ്ടാണ് DNS സെർവർ വിലാസം കണക്ഷന്റെ നയത്തിന്റെ ഭാഗമായി വരുന്നത്, യന്ത്രത്തിനായി ഒരിക്കൽ തിരഞ്ഞെടുത്ത ആഗോള ക്രമീകരണമായി അല്ല.
വിലാസം മാത്രം ഒന്നും തീരുമാനിക്കുന്നില്ല. റിസോൾവറിന് എത്താൻ ഒരു പാത ഉണ്ടെങ്കിൽ മാത്രമേ ഉത്തരം നൽകാൻ കഴിയൂ, ഏറ്റവും സാധാരണമായ തകരാർ ടണൽ ഉയർന്നിരിക്കുമ്പോൾ മാത്രം എത്താവുന്ന റിസോൾവറാണ്. ടണൽ വീണ് നയം നിലനിൽക്കുമ്പോൾ ക്വറികൾ പാതയില്ലാത്ത വിലാസത്തിലേക്ക് പോകുന്നു, ലക്ഷണം വ്യക്തമായ പിശകല്ല, സമയപരിധി കഴിയലാണ്. അടുത്ത പരിശോധനാ ഫലം വായിക്കുമ്പോൾ ഈ വ്യത്യാസം പ്രധാനമാണ്, കാരണം സമയപരിധി ആളുകളെ ഒരിക്കലും ബന്ധപ്പെട്ടിട്ടില്ലാത്ത ട്രാൻസ്പോർട്ട് ക്രമീകരണങ്ങളിലേക്ക് അയയ്ക്കുന്നു.
ഉത്തരങ്ങൾ താരതമ്യം ചെയ്യുന്നതിന് മുമ്പ് രണ്ട് രൂപകൽപ്പനകൾ താരതമ്യം ചെയ്യുക
പൂർണ്ണ ടണലും വിഭജിത DNS-ഉം വിപരീത പ്രതീക്ഷകൾ സൃഷ്ടിക്കുന്നു, രണ്ടും തകരാറല്ല. പൂർണ്ണ ടണലിൽ ഓരോ ക്വറിയും ദാതാവിലേക്കോ കോർപ്പറേറ്റ് റിസോൾവറിലേക്കോ നീങ്ങാം, അതിനാൽ ബന്ധിപ്പിച്ചതിന് ശേഷം പൊതു പേരുകൾ വ്യത്യസ്തമായി ഉത്തരം നൽകുന്നത് പ്രതീക്ഷിതമാണ്. വിഭജിത DNS-ൽ പട്ടികയിലുള്ള ഡൊമെയ്നുകൾ മാത്രം സ്വകാര്യ റിസോൾവറിലേക്ക് പോകുന്നു, ബാക്കിയെല്ലാം പ്രാദേശികമായി തുടരുന്നു; Windows-ൽ ഡൊമെയ്ൻ പട്ടിക Name Resolution Policy Table-ൽ, macOS-ൽ DNS ക്രമീകരണങ്ങളുടെ പൊരുത്തപ്പെടുന്ന ഡൊമെയ്നുകളിൽ, systemd-resolved ഹോസ്റ്റിൽ ഓരോ ലിങ്കിന്റെയും റൂട്ടിംഗ് ഡൊമെയ്നുകളിൽ ആണ്.
ആണ് ആദ്യം ചെയ്യേണ്ട താരതമ്യം, കാരണം എന്തിനെ തകരാറായി കണക്കാക്കണം എന്നത് അതാണ് തീരുമാനിക്കുന്നത്. വിഭജിത DNS-ൽ, പുതിയ റിസോൾവറിൽ നിന്ന് ഉത്തരം നൽകുന്ന പൊതു പേരാണ് അന്വേഷിക്കാൻ യോഗ്യമായത്, ശരിയായി ഉത്തരം നൽകുന്ന ആന്തരിക പേരാണ് സിസ്റ്റം തന്റെ ജോലി ചെയ്യുന്നത്. പൂർണ്ണ ടണലിൽ, ഇപ്പോഴും നിങ്ങളുടെ ISP റിസോൾവറിൽ നിന്ന് ഉത്തരം നൽകുന്ന പൊതു പേരാണ് അസാധാരണത. Microsoft-ന്റെ VPN നാമ പരിഹാരത്തെക്കുറിച്ചുള്ള ഡോക്യുമെന്റേഷൻ ഈ നിയമങ്ങളുടെ Windows ക്രമം വിവരിക്കുന്നു, പൊരുത്തപ്പെടുന്ന നയ എൻട്രി അഡാപ്റ്ററിന്റെ സ്വന്തം സെർവറുകൾക്ക് മുമ്പ് എങ്ങനെ പരിഗണിക്കുന്നു എന്നതും ഉൾപ്പെടെ.
മറക്കാൻ എളുപ്പമുള്ള മൂന്നാമത്തെ റിസോൾവറും മുറിയിലുണ്ട്. ബ്രൗസറിന്റെ സുരക്ഷിത DNS സ്വയം പേരുകൾ പരിഹരിക്കുന്നു, ടണൽ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം നയം മാറ്റിയതിന് ശേഷവും ഉത്തരം നൽകുന്നത് തുടരാം, അതിനാൽ ലോഡ് ചെയ്യുന്ന പേജ് ബ്രൗസർ റിസോൾവർ പ്രവർത്തിച്ചു എന്ന് തെളിയിക്കുന്നു, പ്രൊഫൈൽ പ്രയോഗിച്ചു എന്നല്ല. ബ്രൗസർ കാണിക്കുന്നത് മാത്രം താരതമ്യം ചെയ്താൽ, പകുതി സമയവും തെറ്റായ പാളിയാണ് നിങ്ങൾ പരിശോധിക്കുന്നത്.
ഒരു വേരിയബിൾ മാത്രം ഉപയോഗിച്ച് അടിസ്ഥാനരേഖ രേഖപ്പെടുത്തുക
ടണൽ മാറ്റുക. അതേ ഘട്ടത്തിൽ പേരോ ഉപകരണമോ തിരയൽ പ്രത്യയമോ കൂടി മാറ്റരുത്. ക്വറി ചെയ്യാൻ അനുവാദമുള്ള ഒരു പേര് തിരഞ്ഞെടുക്കുക, ഏത് ആപ്ലിക്കേഷൻ ഉപയോഗിച്ചു എന്ന് കുറിക്കുക, തിരികെ വന്ന വിലാസമോ കൃത്യമായ പിശകോ എഴുതുക. Windows-ൽ Get-DnsClientServerAddress -AddressFamily IPv4 ഓരോ അഡാപ്റ്ററിന്റെയും സെർവറുകൾ അച്ചടിക്കുന്നു, Get-DnsClientNrptPolicy നയ എൻട്രികൾ അച്ചടിക്കുന്നു; systemd-resolved ഉള്ള Linux-ൽ resolvectl status ഓരോ ലിങ്കിന്റെയും DNS സെർവറുകളും റൂട്ടിംഗ് ഡൊമെയ്നുകളും കാണിക്കുന്നു; macOS-ൽ scutil --dns സിസ്റ്റം യഥാർത്ഥത്തിൽ പിന്തുടരുന്ന റിസോൾവർ ക്രമം അച്ചടിക്കുന്നു.
തുടർന്ന് ക്ലയന്റിന്റെ സാധാരണ നിയന്ത്രണങ്ങളിലൂടെ ബന്ധിപ്പിച്ച് അതേ കമാൻഡുകൾ കൃത്യമായി ആവർത്തിക്കുക. ആദ്യ ഔട്ട്പുട്ട് ഓർമ്മിക്കുന്നതിന് പകരം സൂക്ഷിക്കുക, കാരണം താരതമ്യമാണ് മുഴുവൻ കാര്യം, കാഷ് ശൂന്യമാക്കിയതിന് ശേഷം എടുക്കുന്ന രണ്ടാം വായന ഇതിനകം മറ്റൊരു അളവാണ്. അടിസ്ഥാനരേഖ ബ്രൗസർ മുന്നിൽ നിർത്തി എടുത്തതും ബന്ധിപ്പിച്ചതിന് ശേഷമുള്ള പ്രവർത്തനം ടെർമിനലിൽ നടക്കുന്നതുമാണെങ്കിൽ, നിങ്ങൾ രണ്ട് റിസോൾവറുകളെയാണ് താരതമ്യം ചെയ്യുന്നത്, ഒരു റിസോൾവറിന്റെ രണ്ട് അവസ്ഥകളെയല്ല.
വ്യക്തമായ ക്വറിയും ആപ്ലിക്കേഷൻ ലുക്കപ്പും വ്യത്യസ്ത പരിശോധനകളാണ്
ഒരു നിർദ്ദിഷ്ട സെർവറിനോട് nslookup name 10.20.0.1 അല്ലെങ്കിൽ dig @10.20.0.1 name ഉപയോഗിച്ച് ചോദിക്കുന്നത് ഒരു കാര്യം മാത്രം തെളിയിക്കുന്നു: നിങ്ങൾ പേരിട്ട സെർവറിലേക്ക് എത്താൻ കഴിയുമ്പോൾ അത് ഉത്തരം നൽകുന്നു. ഇത് തിരഞ്ഞെടുപ്പ് യുക്തിയെ പൂർണ്ണമായും ഒഴിവാക്കുന്നു, അതിനാൽ സിസ്റ്റം ഈ പേരിന് ആ സെർവർ തിരഞ്ഞെടുക്കുമായിരുന്നോ എന്ന് പറയാൻ കഴിയില്ല. നൽകപ്പെട്ട റിസോൾവർ എത്താവുന്നതാണോ എന്ന് പരിശോധിക്കാൻ ഇത് ഉപയോഗിക്കുക, നയം പരിശോധിക്കാൻ ഇത് ഉപയോഗിക്കരുത്.
പ്രാദേശിക റിസോൾവറിലൂടെയുള്ള ലുക്കപ്പ് തിരഞ്ഞെടുപ്പ് യഥാർത്ഥത്തിൽ പ്രയോഗിക്കുന്നു. resolvectl query name അതേ റൂട്ടിംഗ് ഡൊമെയ്ൻ നിയമങ്ങളിലൂടെ നടന്ന് ഏത് പ്രോട്ടോക്കോൾ ഉത്തരം നൽകി എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, Windows-ൽ Resolve-DnsName നയ പട്ടികയിലൂടെയും ക്ലയന്റ് കാഷിലൂടെയും കടക്കുന്നു, scutil --dns ലുക്കപ്പ് പിന്തുടരുന്ന ക്രമം കാണിക്കുന്നു. രണ്ട് തരവും പ്രവർത്തിപ്പിച്ച് അവ നിങ്ങളുടെ കുറിപ്പുകളിൽ വേറിട്ട നിരകളിൽ സൂക്ഷിക്കുക. വിജയകരമായ വ്യക്തമായ ക്വറിക്ക് അരികിൽ പരാജയപ്പെട്ട ആപ്ലിക്കേഷൻ ലുക്കപ്പ് ഉണ്ടെങ്കിൽ അത് റൂട്ടിംഗ് അല്ലെങ്കിൽ തിരഞ്ഞെടുപ്പ് പ്രശ്നമാണ്, പ്രവർത്തിക്കാൻ വിസമ്മതിക്കുന്ന റിസോൾവറല്ല.
കാഷ് നിങ്ങൾക്കും ഉത്തരത്തിനും ഇടയിൽ നിൽക്കുന്നു. ഓപ്പറേറ്റിംഗ് സിസ്റ്റം, പ്രാദേശിക സ്റ്റബ് റിസോൾവർ, ബ്രൗസർ, നെഗറ്റീവ് കാഷ് എന്നിവയെല്ലാം ഫലങ്ങൾ സൂക്ഷിക്കുന്നു, അതിനാൽ ഒരു പാക്കറ്റും യന്ത്രം വിടാതെ ലുക്കപ്പ് വിജയിക്കാം. എന്തെങ്കിലും ശൂന്യമാക്കുന്നതിന് മുമ്പ് ഫലം രേഖപ്പെടുത്തുക: ipconfig /flushdns, resolvectl flush-caches അല്ലെങ്കിൽ macOS-ൽ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. ഈ ഘട്ടത്തിൽ വിശാലമായ നെറ്റ്‌വർക്ക് റീസെറ്റ് ഒഴിവാക്കുക, കാരണം അത് നിങ്ങൾ ഇപ്പോഴും ശേഖരിക്കുന്ന തെളിവുകൾ നശിപ്പിക്കുന്നു.
ഈ വ്യത്യാസം എന്താണ് അർത്ഥമാക്കുന്നത്
നിങ്ങൾ രേഖപ്പെടുത്തിയ രണ്ട് വരികൾ താരതമ്യം ചെയ്ത്, ഒരു ക്രമീകരണത്തിൽ പോലും തൊടുന്നതിന് മുമ്പ് മാറ്റം വർഗ്ഗീകരിക്കുക.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
ഒരു വരി പ്രത്യേകം ഊന്നൽ അർഹിക്കുന്നു. പരിഹരിക്കുന്ന പേര് പ്രവർത്തിക്കുന്ന ഒരു സേവനമല്ല, DNS-ന്റെ വിജയം ഒരു വിലാസം കണ്ടെത്തി എന്ന് മാത്രം പറയുന്നു. ഫോർവേഡിംഗ്, ഫയർവാൾ നിയമങ്ങൾ, അല്ലെങ്കിൽ നിങ്ങളുടെ അക്കൗണ്ടിന് ഈ സേവനം ഉപയോഗിക്കാൻ അനുവാദമുണ്ടോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല, അതിനാൽ തകരാർ സ്വയം മാറിപ്പോയി എന്ന് അനുമാനിക്കുന്നതിന് പകരം യഥാർത്ഥ ആപ്ലിക്കേഷൻ പരിശോധിച്ച് അവസാനിപ്പിക്കുക.
അടിസ്ഥാനരേഖ പുനഃസ്ഥാപിച്ച് സ്ഥിരീകരിക്കുക
പ്രോസസ്സ് കൊല്ലുന്നതിന് പകരം ക്ലയന്റിന്റെ സ്വന്തം നിയന്ത്രണങ്ങളിലൂടെ വിച്ഛേദിച്ച്, അതേ മൂന്ന് കമാൻഡുകൾ വീണ്ടും വായിക്കുക. ഓരോ ലിങ്കിന്റെയും സെർവറുകൾ, നയ എൻട്രികൾ, നിങ്ങളുടെ പരീക്ഷണ നാമത്തിന്റെ ഉത്തരം എന്നിവ മുമ്പ് എഴുതിയ അടിസ്ഥാനരേഖയിലേക്ക് മടങ്ങണം. വൃത്തിയായി വിച്ഛേദിച്ചതിന് ശേഷം അവശേഷിക്കുന്ന നയ എൻട്രി രേഖപ്പെടുത്താൻ യോഗ്യമായ യഥാർത്ഥ വീഴ്ചയാണ്, ജനറേറ്റ് ചെയ്ത റിസോൾവർ ഫയൽ കൈകൊണ്ട് തിരുത്തുന്നത് മോശം ശീലമാകാനുള്ള കാരണവും അതുതന്നെ: ഫയൽ വീണ്ടും എഴുതപ്പെടുന്നു, തിരുത്ത് അപ്രത്യക്ഷമാകുന്നു, അല്ലെങ്കിൽ തിരുത്ത് അവശേഷിച്ച് ഇനി പാതയില്ലാത്ത റിസോൾവറിനെ പിൻ ചെയ്യുന്നു.
ഈ പട്ടിക ഒരിക്കൽ, ക്രമത്തിൽ ചെയ്യുക. ഏതെങ്കിലും ഫലം വിലയിരുത്തുന്നതിന് മുമ്പ് പ്രൊഫൈൽ ഏത് രൂപകൽപ്പന നടപ്പാക്കുന്നു എന്ന് തീരുമാനിക്കുക. രണ്ട് റണ്ണുകളിലും പേര്, ഉപകരണം, പ്രത്യയം എന്നിവ സ്ഥിരമായി നിർത്തുക. വ്യക്തമായ ക്വറിയെ ആപ്ലിക്കേഷൻ ലുക്കപ്പിൽ നിന്ന് വേർതിരിക്കുക. ഉത്തരം മാത്രമല്ല, ഫലപ്രദമായ നയം വായിക്കുക. താരതമ്യം എഴുതിയതിന് ശേഷം കാഷുകൾ അവസാനം ശൂന്യമാക്കുക. യഥാർത്ഥ ആപ്ലിക്കേഷൻ ഉപയോഗിച്ച് സ്ഥിരീകരിക്കുക, തുടർന്ന് ഒരിക്കൽ റീബൂട്ട് ചെയ്ത് വിച്ഛേദിത അവസ്ഥ ഇപ്പോഴും വൃത്തിയാണോ എന്ന് ഉറപ്പാക്കുക.