resolvectl ഔട്ട്പുട്ടിൽ നിന്ന് ഓരോ ലിങ്കിനും VPN DNS റൗട്ടിംഗ് എങ്ങനെ വായിക്കാം
resolvectl status ഓരോ ലിങ്കിനും സർവറുകൾ, ഡൊമെയ്നുകൾ, ഡിഫോൾട്ട് റൂട്ട് എന്നിവ കാണിക്കുന്നു। അവ ഒരുമിച്ച് വായിക്കുക, പിന്നെ പേര് ചോദിച്ച് ഏത് ലിങ്ക് ഉത്തരം നൽകി എന്ന് ശ്രദ്ധിക്കുക।
resolvectl status പ്രവർത്തിപ്പിക്കുമ്പോൾ ഓരോ ലിങ്കിനും ബ്ലോക്കുകളുടെ ഒരു മതിൽ ലഭിക്കും, ഓരോന്നിനും സ്വന്തം സർവറുകളും സ്വന്തം ഡൊമെയ്ൻ വരിയും ഉണ്ട്। റൗട്ടിംഗ് നിർണ്ണയിക്കുന്ന വരി ഡൊമെയ്ൻ പട്ടികയാണ്, നെയിംസർവർ വിലാസമല്ല, കാരണം പ്രാദേശിക സ്റ്റബ് ഓരോ ചോദ്യവും പേര് ക്ലെയിം ചെയ്യുന്ന ലിങ്കിലേക്ക് അയയ്ക്കുന്നു। ഉത്തരം വായിക്കുന്നതിന് മുമ്പ് ആ ക്ലെയിമുകൾ വായിക്കുക, പിന്നെ പേര് ചോദിച്ച് ഏത് ലിങ്ക് അത് സൃഷ്ടിച്ചു എന്ന് പരിശോധിക്കുക। ശരിയായ ലിങ്കിൽ നിന്നുള്ള തെറ്റായ ഉത്തരം തെറ്റായ ലിങ്കിൽ നിന്നുള്ള ശരിയായ ഉത്തരത്തിൽ നിന്ന് വ്യത്യസ്തമായ പ്രശ്നമാണ്।
ഓരോ ലിങ്ക് ബ്ലോക്കും നിങ്ങളോട് എന്ത് പറയുന്നു
ഓരോ ബ്ലോക്കും റിസോൾവർ ആ ഇന്റർഫേസിനായി ഉപയോഗിക്കുന്ന സർവറുകൾ, ഡൊമെയ്ൻ പട്ടിക, ലിങ്ക് ഡിഫോൾട്ട് റൂട്ട് ആണോ എന്നിവ പട്ടികപ്പെടുത്തുന്നു। ഡൊമെയ്ൻ പട്ടിക ക്ലെയിമുകളുടെ ഒരു കൂട്ടമാണ്, റിസോൾവർ ഏറ്റവും നീളമുള്ള പ്രത്യയത്തിന്റെ പൊരുത്തം പ്രയോഗിക്കുന്നു: host.corp.example നുള്ള ചോദ്യം corp.example ഉള്ള ലിങ്ക്, ഡിഫോൾട്ട് റൂട്ട് മാത്രമുള്ള ലിങ്കിന് മുമ്പ് ക്ലെയിം ചെയ്യുന്നു। ഒരേ പ്രത്യയം ക്ലെയിം ചെയ്യുന്ന രണ്ട് ലിങ്കുകൾ ഫലം മുൻഗണനയ്ക്കും ക്രമത്തിനും വിടുന്നു, അതിനാൽ പകർപ്പുകൾ ആദ്യം ശ്രദ്ധ അർഹിക്കുന്നു। നിലവിലെ സർവർ വരി പട്ടികയിലുള്ള ഏത് സർവർ ആ നിമിഷം ഉപയോഗത്തിലുണ്ടെന്ന് കാണിക്കുന്നു।
/etc/resolv.conf ലെ 127.0.0.53 പോലുള്ള സ്റ്റബ് വിലാസം സ്റ്റബ് മുന്നിലുണ്ടെന്ന് മാത്രം പറയുന്നു। അത് ഉത്തരം നൽകിയ മുകളിലെ ഉറവിടത്തെ പേരിടുന്നില്ല, അതിനാൽ resolv.conf മാത്രം അടിസ്ഥാനമാക്കിയുള്ള രോഗനിർണ്ണയം കുടുങ്ങുന്നു।
മൂന്ന് തരം ഡൊമെയ്ൻ എൻട്രികൾ ശരിയായി വായിക്കുക
| എൻട്രി | എന്ത് ക്ലെയിം ചെയ്യുന്നു | സാധാരണ തെറ്റ് |
|---|---|---|
| corp.example | റൗട്ടിംഗ് ഡൊമെയ്നും തിരയൽ പ്രത്യയവും: അതിന് താഴെയുള്ള പേരുകൾ ഈ ലിങ്കിലേക്ക് പോകുന്നു, സ്ട്രിംഗ് നഗ്നനാമങ്ങളിൽ ചേർക്കുന്നു | റൗട്ടിംഗ് എങ്ങനെയും പ്രവർത്തിക്കുന്നതായി തോന്നുന്നതിനാൽ നീക്കം ചെയ്തു |
| ~corp.example | റൂട്ട് മാത്രം: അതിന് താഴെയുള്ള പേരുകൾ ഈ ലിങ്കിലേക്ക് പോകുന്നു, പക്ഷേ പ്രത്യയം ചേർക്കുന്നില്ല | റൗട്ടിംഗിന് ആവശ്യമാണെന്ന് അനുമാനിച്ചു |
| ~. | ഡിഫോൾട്ട് റൂട്ട്: മറ്റൊരു ലിങ്കും പൊരുത്തപ്പെടാത്ത ചോദ്യങ്ങൾ ക്ലെയിം ചെയ്യുന്നു | വിഭജിത പ്രൊഫൈലിൽ സജീവമായി വിട്ടു, അതിനാൽ പൊതു പേരുകൾ ടണൽ പിന്തുടരുന്നു |
ടിൽഡ തിരയലിന്റെ സ്വഭാവം മാറ്റുന്നു, റൗട്ടിംഗ് അല്ല। ടിൽഡ ഇല്ലാത്ത എൻട്രി റൗട്ടിംഗ് ഡൊമെയ്നും തിരയൽ ഡൊമെയ്നുമാണ്, അതിനാൽ അതിന് താഴെയുള്ള പേരുകൾ ആ ലിങ്കിലേക്ക് അയയ്ക്കുന്നു, ഒറ്റ ലേബൽ പേരുകളിൽ പ്രത്യയം ചേർക്കുന്നു। ടിൽഡ എൻട്രി അതേ പ്രത്യയം റൗട്ട് ചെയ്യുന്നു, പക്ഷേ അതിനെ തിരയൽ പട്ടികയ്ക്ക് പുറത്ത് നിർത്തുന്നു। അതിനാൽ ടിൽഡ നീക്കം ചെയ്യുന്നത് ഏത് നഗ്നനാമങ്ങൾ പരിഹരിക്കപ്പെടുന്നു എന്നത് മാറ്റുന്നു, അതിനാൽ ടിൽഡ ഇല്ലാതിരിക്കുന്നത് തിരയൽ പ്രശ്നമാണ്, വിഭജിത DNS പരാജയമല്ല।
ഡിഫോൾട്ട് റൂട്ട് എൻട്രി മറ്റൊരു ലിങ്കും പൊരുത്തപ്പെടാത്ത എല്ലാം ക്ലെയിം ചെയ്യുന്നു। പൂർണ്ണ ടണൽ പ്രൊഫൈൽ സാധാരണയായി അത് ആഗ്രഹിക്കുന്നു, വിഭജിത പ്രൊഫൈൽ സാധാരണയായി ആഗ്രഹിക്കുന്നില്ല, കാരണം പൊതു പേരുകൾ അപ്പോൾ സ്വകാര്യ റിസോൾവറിലേക്ക് പോകുന്നു, അവിടെ പരാജയപ്പെടാം। പ്രൊഫൈലുകൾക്കിടയിൽ ഫ്ലാഗുകൾ പകർത്തുന്നതിന് പകരം പ്രൊഫൈലിന്റെ ഉദ്ദേശ്യത്തിനെതിരെ പട്ടിക വായിക്കുക। രണ്ട് ലിങ്കുകൾ ഒരേ പ്രത്യയം ക്ലെയിം ചെയ്യുമ്പോൾ, മറ്റെന്തെങ്കിലും എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് മുൻഗണനയുടെ ചോദ്യം തീർക്കുക।
ഒരു പേര് ചോദിച്ച് ഏത് ലിങ്ക് ഉത്തരം നൽകി എന്ന് കാണുക
query ഉപകമാന്റ് വിലാസവും പ്രോട്ടോക്കോളും ഉത്തരം സൃഷ്ടിച്ച ലിങ്ക് അല്ലെങ്കിൽ വ്യാപ്തിയും പ്രിന്റ് ചെയ്യുന്നു। സ്വകാര്യ പ്രത്യയം ക്ലെയിം ചെയ്യേണ്ട ഒരു പേരും ഒരു സാധാരണ പൊതു പേരും പരീക്ഷിച്ച്, റിപ്പോർട്ട് ചെയ്ത ഉറവിടങ്ങൾ താരതമ്യം ചെയ്യുക। സ്വകാര്യ പേര് വയർലെസ് ലിങ്കിൽ നിന്ന് ഉത്തരം നൽകിയാൽ, ക്ലെയിം ഇല്ല അല്ലെങ്കിൽ ടണൽ താഴെയാണ്; വിഭജിത പ്രൊഫൈലിൽ പൊതു പേര് ടണലിൽ നിന്ന് ഉത്തരം നൽകിയാൽ, ഡിഫോൾട്ട് റൂട്ട് വളരെ വീതമാണ്। ആ രണ്ട് പരാജയങ്ങളും ബ്രൗസറിൽ ഒരുപോലെയും ഈ ഔട്ട്പുട്ടിൽ വിപരീതമായും കാണുന്നു।
resolvectl status
resolvectl query host.corp.exampleറിപ്പോർട്ട് ചെയ്ത പ്രോട്ടോക്കോളും ശ്രദ്ധിക്കുക, കാരണം കാഷിൽ നിന്നോ hosts ഫയലിൽ നിന്നോ ഉള്ള ഉത്തരം ഒരു മുകളിലെ ഉറവിടത്തോടും ചോദിക്കാതെ വരാം। കാഷിൽ നിന്നുള്ള ഉത്തരം പേര് എപ്പോഴോ പരിഹരിക്കപ്പെട്ടു എന്ന് തെളിയിക്കുന്നു, നിലവിലെ നയം അതിനെ ശരിയായി റൗട്ട് ചെയ്യുന്നു എന്നല്ല।
പേരുകളുടെ റൗട്ടിംഗ് പാക്കറ്റ് റൗട്ടിംഗിൽ നിന്ന് വേർതിരിക്കുക
റിസോൾവറിന്റെ തീരുമാനം ഒരു പാത സൃഷ്ടിക്കുന്നില്ല। തിരഞ്ഞെടുത്ത സർവറിന് ഇപ്പോഴും സ്വന്തം വിലാസത്തിലേക്ക് റൂട്ട് വേണം, തിരികെ ലഭിച്ച വിലാസത്തിന് ഇപ്പോഴും സ്വകാര്യ നെറ്റ്വർക്കിലേക്ക് റൂട്ട് വേണം, അതിനാൽ ശരിയായ DNS നയം ഒരിക്കലും തുറക്കാത്ത ഒരു കണക്ഷനോടൊപ്പം നിലനിൽക്കാം। പേര് പരിഹരിക്കപ്പെടുകയും ആപ്ലിക്കേഷൻ പരാജയപ്പെടുകയും ചെയ്താൽ, വീണ്ടും DNS മാറ്റുന്നതിന് പകരം വിലാസവും റൂട്ടും പരിശോധിക്കുക। പേര് പരിഹരിക്കലും എത്തിച്ചേരലും രണ്ട് വ്യത്യസ്ത ഉടമകളുള്ള രണ്ട് ചോദ്യങ്ങളാണ്।
ആപ്ലിക്കേഷനുകൾക്ക് സ്വന്തം സുരക്ഷിത DNS ക്രമീകരണമോ ഉൾപ്പെടുത്തിയ റിസോൾവറോ വഴി സിസ്റ്റം റിസോൾവറിനെ പൂർണ്ണമായി ഒഴിവാക്കാം। resolvectl ഫലം സിസ്റ്റം പാത വിവരിക്കുന്നു, അത് അവഗണിക്കുന്ന ബ്രൗസർ നിങ്ങൾ നടത്തുന്ന ഓരോ പരീക്ഷണവുമായും യോജിക്കില്ല। നയം തകർന്നു എന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് ആ ക്രമീകരണം പരിശോധിക്കുക।
പേര് പരിഹരിക്കപ്പെട്ട വിലാസം ലിങ്കിനൊപ്പം രേഖപ്പെടുത്തുക। തെറ്റായ വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന ശരിയായ പേര് റൗട്ടിംഗല്ല, റെക്കോർഡിന്റെ പ്രശ്നമാണ്।
ലിങ്ക് മാറിയതിന് ശേഷം വീണ്ടും പരിശോധിക്കുക
വീണ്ടും കണക്ട് ചെയ്യലോ വയർലെസ് മാറ്റമോ ലിങ്കിന്റെ അവസ്ഥ വീണ്ടും നിർമ്മിക്കുന്നു, നെറ്റ്വർക്ക് മാനേജർ കൈകൊണ്ട് ക്രമീകരിച്ച എല്ലാത്തിനും മുകളിൽ തന്റെ ഡൊമെയ്നുകളും സർവറുകളും വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്തേക്കാം। പിന്നീട് അതേ രണ്ട് പേരുകൾ ചോദിച്ച് രേഖപ്പെടുത്തിയ അടിസ്ഥാനരേഖയുമായി താരതമ്യം ചെയ്യുക। കൈകൊണ്ടുള്ള തിരുത്ത് അപ്രത്യക്ഷമായെങ്കിൽ, തിരുത്തൽ കണക്ഷൻ പ്രൊഫൈലിലാണ് ഷെൽ കമാന്റിലല്ല। മുമ്പും ശേഷവും രേഖപ്പെടുത്തുന്നതാണ് അതിനെ ദൃശ്യമാക്കുന്നത്।
റിപ്പോർട്ടിന് ആവശ്യമായ പേരുകളും സർവർ സന്ദർഭവും മാത്രം പങ്കിടുക, കാരണം ആന്തരിക പ്രത്യയങ്ങൾ ടോപ്പോളജി വെളിപ്പെടുത്തുന്നു। systemd-resolved ന്റെ ഡൊമെയ്ൻ റൗട്ടിംഗ് ഡോക്യുമെന്റേഷൻ ഏറ്റവും നീളമുള്ള പൊരുത്തത്തിന്റെ നിയമവും ടിൽഡയുടെ സ്വഭാവവും ഉൾക്കൊള്ളുന്നു, ഒരിക്കൽ വായിച്ചാൽ മുകളിലെ പട്ടികയിലെ മിക്ക തെറ്റുകളും ഒഴിവാക്കാം: systemd-resolved ലെ ചോദ്യ റൗട്ടിംഗ്।