നിങ്ങളുടെ Mac VPN-ൽ ഉപയോഗിക്കുന്ന DNS റിസോൾവറുകൾ എങ്ങനെ പരിശോധിക്കാം

scutil --dns macOS യഥാർത്ഥത്തിൽ സമീപിക്കുന്ന റിസോൾവർ കോൺഫിഗറേഷൻ പ്രിന്റ് ചെയ്യുന്നു, നിങ്ങൾ സെറ്റിംഗ്സ് പാനലിൽ ടൈപ്പ് ചെയ്ത ഏക DNS സെർവർ അല്ല. ഔട്ട്പുട്ട് മിക്ക ആളുകളും പ്രതീക്ഷിക്കുന്നതിനേക്കാൾ നീളമുള്ളതാണ്, കാരണം സിസ്റ്റം ഡിഫോൾട്ട് പാത, സ്കോപ്പ് ചെയ്ത ഇന്റർഫേസുകൾ, ഡൊമെയിൻ-നിർദ്ദിഷ്ട ഫോർവേഡിംഗ് എന്നിവയ്ക്കായി വെവ്വേറെ റിസോൾവർ ബ്ലോക്കുകൾ സൂക്ഷിക്കുന്നു. ഔട്ട്പുട്ടിന്റെ മുകളിലെ ബ്ലോക്ക് ക്വറിക്ക് ഉത്തരം നൽകുന്ന ബ്ലോക്ക് ആയിരിക്കണമെന്നില്ല. ഒരു സ്വകാര്യ നാമം ഓഫീസിൽ റിസോൾവ് ചെയ്ത് VPN ഉയരുന്ന നിമിഷത്തിൽ പരാജയപ്പെട്ടാൽ, പൊരുത്തക്കേട് പൊരുത്തപ്പെടുത്തൽ നിയമങ്ങളിലും റൂട്ടുകളിലും ആണ്, സെർവർ വിലാസത്തിലല്ല. ആദ്യം ക്രമം വായിക്കുക, പിന്നീട് യഥാർത്ഥ ലുക്കപ്പ് ഉപയോഗിച്ച് ഉത്തരം തെളിയിക്കുക.

വിലാസങ്ങൾക്ക് മുമ്പ് ബ്ലോക്ക് ക്രമം വായിക്കുക

ഓരോ എൻട്രിയും resolver #N ൽ തുടങ്ങി nameserver[0], ചിലപ്പോൾ if_index, flags വരി, reach എന്നിവ ലിസ്റ്റ് ചെയ്യുന്നു, ബ്ലോക്ക് സാധാരണ ഡിഫോൾട്ട് അല്ലെങ്കിൽ domain ഉം search domain പട്ടികയും കാണിക്കുന്നു. ഡൊമെയിൻ ഇല്ലാത്ത 1-ാം റിസോൾവർ പൊതു നാമങ്ങൾ കൈകാര്യം ചെയ്യുന്ന ഡിഫോൾട്ട് ആണ്. അതിന്റെ ഫ്ലാഗുകളിൽ Scoped വഹിക്കുന്ന ഏതും if_index പേരിടുന്ന ഇന്റർഫേസുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു, Supplemental എന്ന് അടയാളപ്പെടുത്തിയതെല്ലാം അതിനടിയിൽ ലിസ്റ്റ് ചെയ്ത ഡൊമെയിനുകൾക്ക് മാത്രം ബാധകമാണ്.

തിരഞ്ഞെടുപ്പ് പ്രത്യയ പൊരുത്തമാണ്. intranet.corp.example പോലുള്ള ഒരു നാമത്തിന്, domain എൻട്രി ഏറ്റവും നീളമുള്ള പൊരുത്തപ്പെടുന്ന പ്രത്യയമായ റിസോൾവറിനെ macOS മുൻഗണന നൽകുന്നു, അതിനാൽ domain : corp.example ഉള്ള ബ്ലോക്ക് ഔട്ട്പുട്ടിൽ വളരെ താഴെയാണെങ്കിലും ഡിഫോൾട്ടിനെ തോൽപ്പിക്കുന്നു. ഒരേ നീളമുള്ള ഡൊമെയിനുകൾ തമ്മിലുള്ള സമനില order പരിഹരിക്കുന്നു. ആദ്യ നോട്ടത്തിന് ഇതിലധികം അപൂർവ്വമായി വേണ്ടിവരും: ഒരു ബ്ലോക്ക് തുടക്കം മുതൽ അവസാനം വരെ വായിക്കാൻ താൽപ്പര്യമുള്ളപ്പോൾ മുഴുവൻ ഔട്ട്പുട്ട്, ബ്ലോക്ക് ക്രമം അറിയാൻ ആദ്യ വരികൾ, ഫീൽഡ് വരികൾക്കൊപ്പം ബ്ലോക്ക് തലക്കെട്ടുകൾ പ്രിന്റ് ചെയ്യുന്ന ഫിൽട്ടർ ചെയ്ത ഒരു പാസ്. സ്കോപ്പ് ചെയ്ത ബ്ലോക്കുകൾ സ്വന്തം തലക്കെട്ടിന് കീഴിൽ പ്രത്യക്ഷപ്പെടുകയും മുകളിലെ പട്ടികയുടെ തുടർച്ചയായി വായിക്കപ്പെടുകയും ചെയ്യുന്നു, അതിനാൽ ഔട്ട്പുട്ട് ഉദ്ധരിക്കുമ്പോൾ തലക്കെട്ട് കണ്ണിൽ തന്നെ സൂക്ഷിക്കുക.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

if_index ടണൽ ഇന്റർഫേസുമായി ചേർക്കുക

ഒരു ഇൻഡക്സ് അതിന് പിന്നിലെ ഇന്റർഫേസ് പേരിടാൻ കഴിഞ്ഞാൽ മാത്രം ഉപയോഗപ്രദമാണ്. scutil --nwi സിസ്റ്റം സൂക്ഷിക്കുന്ന നെറ്റ്വർക്ക് വിവരങ്ങൾ ലിസ്റ്റ് ചെയ്യുന്നു, പ്രാഥമിക ഇന്റർഫേസും എത്തിച്ചേരാനുള്ള കഴിവും ഉൾപ്പെടെ, അതേസമയം ifconfig -l നിങ്ങൾക്ക് പേരുകൾ നൽകുന്നു, അവിടെ utun0 മുതൽ utun9 വരെ ഒരു ക്ലയന്റ് സാധാരണയായി സൃഷ്ടിക്കുന്ന ടണൽ സ്ഥാനാർത്ഥികളാണ്. Apple തന്റെ സ്വന്തം പരിശോധനാ ഉദാഹരണമായി scutil --dns ഉപയോഗിക്കുന്നു വിന്യാസ ഗൈഡിൽ, Network Extension എങ്ങനെ തിരഞ്ഞെടുത്ത ഡൊമെയിനുകൾ തിരഞ്ഞെടുത്ത റിസോൾവറുകളിലേക്ക് റൂട്ട് ചെയ്യാം എന്ന് രേഖപ്പെടുത്തുന്നു; ആ സ്കോപ്പ് ചെയ്ത ബ്ലോക്കുകൾ വെളിപ്പെടുത്തുന്നത് അതേ സംവിധാനമാണ്.

ചോദ്യം തീരുമാനിക്കുന്ന പരിശോധന റിസോൾവർ ടണൽ ഇൻസ്റ്റാൾ ചെയ്ത പാതയിലുണ്ടോ എന്നതാണ്:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

route -n get റിസോൾവർ എൻട്രിയുമായി പൊരുത്തപ്പെടാത്ത ഗേറ്റ്വേയും ഇന്റർഫേസും തിരികെ നൽകിയാൽ, വിലാസം തികച്ചും ശരിയായിരിക്കാം, എന്നിട്ടും എത്തിച്ചേരാൻ കഴിയില്ല. കോർപ്പറേറ്റ് സബ്നെറ്റുകൾ മാത്രം വഹിക്കുന്ന സ്പ്ലിറ്റ് ടണൽ അവയ്ക്ക് പുറത്തുള്ള DNS സെർവറിലേക്കുള്ള ക്വറികൾ വലിച്ചെറിയുന്നു, പരാജയം ടൈംഔട്ടായി പ്രത്യക്ഷപ്പെടുന്നു, അതിനാൽ കോൺഫിഗറേഷൻ ഔട്ട്പുട്ട് ഇപ്പോഴും വൃത്തിയായി തോന്നുന്നു.

സിസ്റ്റം റിസോൾവറിനോട് ചോദിക്കുക, പിന്നെ സെർവറിനോട്

മൂന്ന് ഉപകരണങ്ങൾ മൂന്ന് വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, അവ കൂട്ടിക്കലർത്തുന്നത് ഈ മേഖലയിലെ മിക്ക തെറ്റായ നിഗമനങ്ങളും സൃഷ്ടിക്കുന്നു. dscacheutil -q host -a name സാധാരണ ആപ്പുകൾ ഉപയോഗിക്കുന്ന അതേ സിസ്റ്റം റിസോൾവറിലൂടെ കടന്നുപോകുന്നു, അതിനാൽ സ്കോപ്പ് ചെയ്തതും അനുബന്ധവുമായ ബ്ലോക്കുകൾ ബാധകമാണ്. സെർവർ ആർഗ്യുമെന്റ് ഇല്ലാതെ dig /etc/resolv.conf വായിക്കുന്നു, അത് macOS ൽ സ്കോപ്പ് ചെയ്ത റെസല്യൂഷനുള്ള സത്യത്തിന്റെ ഉറവിടമല്ല, ഡൊമെയിൻ തോറുമുള്ള നിയമങ്ങൾ പൂർണ്ണമായി ഒഴിവാക്കുന്നു. dig @address കൃത്യം ഒരു സെർവറിൽ എത്തുന്നു, തിരഞ്ഞെടുപ്പിനെക്കുറിച്ച് ഒന്നും പറയുന്നുമില്ല.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

ആദ്യ കമാൻഡ് ഉത്തരം നൽകിയും രണ്ടാമത്തേത് NXDOMAIN തിരികെ നൽകിയും ഇരുന്നാൽ, നിങ്ങൾ തിരഞ്ഞ വിഭജനം കണ്ടെത്തി, ഒന്നും തകർന്നിട്ടില്ല. ആദ്യത്തേത് സമയം കഴിഞ്ഞ് തീരുമ്പോൾ dig @10.20.0.53 ഉത്തരം നൽകുന്നുണ്ടെങ്കിൽ, റിസോൾവർ പ്രവർത്തിക്കുന്നു, പക്ഷേ ടണൽ തിരഞ്ഞെടുത്ത പാതയിൽ എത്തിച്ചേരാൻ കഴിയില്ല, അതിനാൽ അടുത്ത ഘട്ടം DNS ക്രമീകരണങ്ങൾ മാറ്റുന്നതല്ല, route -n get ആണ്. സ്വകാര്യ നാമങ്ങൾ ടിക്കറ്റിലോ പങ്കിട്ട കുറിപ്പിലോ ഒട്ടിക്കുന്ന ഒന്നിൽ നിന്നും പുറത്ത് സൂക്ഷിക്കുക.

ഔട്ട്പുട്ടിന് നിങ്ങൾക്ക് കാണിക്കാൻ കഴിയാത്തത്

റിസോൾവർ പട്ടികയുടെ മുകളിലോ വശത്തോ പല പാളികൾ ഇരിക്കുന്നു, ഓരോന്നിനും ഔട്ട്പുട്ട് ഒരിക്കലും പരാമർശിക്കാത്ത ഒരിടത്തേക്ക് ക്വറി അയയ്ക്കാം. സുരക്ഷിത DNS പ്രവർത്തനക്ഷമമായ ബ്രൗസർ അതിന്റെ സ്വന്തം എൻക്രിപ്റ്റ് ചെയ്ത ചാനലിലൂടെ റിസോൾവ് ചെയ്യാം, അതിനാൽ dscacheutil സമയം കഴിയുമ്പോൾ ഒരു പേജ് ലോഡ് ചെയ്യുന്നത് വൈരുദ്ധ്യമല്ല. സുരക്ഷാ സോഫ്റ്റ്വെയർ ഇൻസ്റ്റാൾ ചെയ്യുന്ന DNS പ്രോക്സി Network Extension ദാതാവായി പ്രവർത്തിച്ച് ക്വറികൾ സ്വയം ഫോർവേഡ് ചെയ്യുന്നു, scutil --dns എന്താണ് കോൺഫിഗർ ചെയ്തത് എന്ന് കാണിക്കുന്നു, പ്രോക്സി അവസാനം ഉപയോഗിച്ച അപ്സ്ട്രീം വിലാസമല്ല. തിരയൽ ഡൊമെയിനുകൾ മൂന്നാമത്തെ മടക്ക് ചേർക്കുന്നു: യോഗ്യതയില്ലാത്ത നാമത്തിൽ ലിസ്റ്റ് ചെയ്ത ഓരോ പ്രത്യയവും ക്രമത്തിൽ ചേർക്കുന്നു, അതിനാൽ ഉത്തരം നൽകിയ ബ്ലോക്ക് നിങ്ങൾ ഒരിക്കലും സംശയിച്ചിട്ടില്ലാത്ത ഒന്നായിരിക്കാം.

പഴയ ഉത്തരങ്ങൾ ഒഴിവാക്കാൻ ഏറ്റവും വിലകുറഞ്ഞതും ഏറ്റവും കൂടുതൽ വിട്ടുപോകുന്നതുമാണ്:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

ഫ്ലഷിന് ശേഷം ഔട്ട്പുട്ട് മാറിയാൽ, അവസ്ഥ കാഷെയിൽ ആയിരുന്നു, മുൻ ഔട്ട്പുട്ട് ഇനി നിലവിലില്ലാത്ത ഒരു ടണൽ വിവരിച്ചു. മാറിയില്ലെങ്കിൽ, കോൺഫിഗറേഷൻ അത് എങ്ങനെയുണ്ടോ അങ്ങനെയാണ്, ചോദ്യം റൂട്ടുകളിലേക്കും ആപ്പ് നയതന്ത്രത്തിലേക്കും നീങ്ങുന്നു.

മുമ്പും ശേഷവും ഉള്ള ഒരു ചെറിയ റൺബുക്ക്

നയം അനുവദിക്കുന്നിടത്ത് മാത്രം ബേസ്ലൈൻ എടുക്കുക, ഫയലുകൾ ഏതെങ്കിലും സിങ്ക് ചെയ്ത ഫോൾഡറിന് പുറത്ത് സൂക്ഷിക്കുക. താഴെയുള്ള ക്രമമാണ് ഞാൻ ക്ലയന്റ് മെഷീനുകളിൽ പ്രവർത്തിപ്പിക്കുന്നത്: ബേസ്ലൈൻ എടുക്കുക, കണക്ട് ചെയ്യുക, വീണ്ടും എടുക്കുക, പിന്നെ താരതമ്യം ചെയ്ത് തിരയുക.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

വ്യത്യാസം വരികൾക്കനുസരിച്ചല്ല, ബ്ലോക്കുകൾക്കനുസരിച്ച് വായിക്കുക. ടണൽ ഇന്റർഫേസ് ഇൻഡക്സും സ്വകാര്യ പ്രത്യയത്തിനുള്ള domain എൻട്രിയും വഹിക്കുന്ന പുതിയ സ്കോപ്പ് ചെയ്ത റിസോൾവർ ആണ് പ്രതീക്ഷിത രൂപം. പൊതു വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന പുതിയ ഡിഫോൾട്ട് റിസോൾവർ ക്ലയന്റ് പ്രൊഫൈലിന്റെ ഉടമയുടെ മുന്നിൽ ഉയർത്തേണ്ട കണ്ടെത്തലാണ്. പിന്നെ യഥാർത്ഥത്തിൽ പരാജയപ്പെട്ട ആപ്പിനുള്ളിൽ ലുക്കപ്പ് ആവർത്തിക്കുക, ഷെല്ലിൽ മാത്രമല്ല, ഫലത്തിനൊപ്പം route -n get ന്റെ ഇന്റർഫേസും കുറിച്ചുവയ്ക്കുക.

മാറ്റം പഴയപടിയാക്കാൻ വിച്ഛേദിച്ച് ബേസ്ലൈൻ എടുക്കൽ ആവർത്തിക്കുക. സ്കോപ്പ് ചെയ്ത ബ്ലോക്ക് പോയെങ്കിൽ, ക്ലയന്റ് തന്നെ വൃത്തിയാക്കി. ബ്ലോക്ക് ഇനി നിലവില്ലാത്ത ഇന്റർഫേസിനെതിരെ ഇപ്പോഴും ലിസ്റ്റ് ചെയ്തിട്ടുണ്ടെങ്കിൽ, അവസ്ഥ പഴയതാണ്, ആരും പ്രൊഫൈൽ തൊടുന്നതിന് മുമ്പ് ഫ്ലഷും വീണ്ടും കണക്ട് ചെയ്യലും ഏറ്റവും മൃദുവായ പരിഹാരമാണ്.

ഈ ക്രമത്തിൽ നാല് പരിശോധനകൾ: ഏതെങ്കിലും റിസോൾവർ ബ്ലോക്ക് നാമത്തിന്റെ ഏറ്റവും നീളമുള്ള പ്രത്യയവുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ; ആ ബ്ലോക്ക് ടണൽ ഇൻസ്റ്റാൾ ചെയ്ത ഇന്റർഫേസുമായി ബന്ധിപ്പിച്ചിട്ടുണ്ടോ; അതിന്റെ നെയിംസെർവറിലേക്കുള്ള റൂട്ട് ടണൽ ഉപയോഗിക്കുന്നുണ്ടോ; dig അല്ല, സിസ്റ്റം റിസോൾവർ ഉത്തരം തിരികെ നൽകുന്നുണ്ടോ. ആദ്യം പരാജയപ്പെടുന്ന പരിശോധന DNS നയം, ടണൽ റൂട്ടുകൾ അല്ലെങ്കിൽ ആപ്പ് മാറ്റണോ എന്ന് പറയും. നാലും കടന്നിട്ടും നാമം പരാജയപ്പെടുന്നുവെങ്കിൽ, പ്രശ്നം DNS-ന് മുകളിലാണ്, അടുത്ത് പരിശോധിക്കേണ്ടത് അതിന് മുന്നിൽ പോർട്ട് 53-ൽ ഉത്തരം നൽകുന്നതെല്ലാമാണ്.