உங்கள் 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-க்கு பதிலளிப்பது எதுவோ அதுவே.