உங்கள் மடிக்கணினி intranet.corp ஐ சுரங்கப்பாதை வழியாகத் தீர்க்கிறது, அதே நேரத்தில் gitlab.com சேவை வழங்குநரின் தீர்வியை நோக்கியே செல்கிறது, இதுவே வடிவமைப்பின்படி செயல்படும் அமைப்பு. இரண்டு தனித்தனி முடிவுகள் இதை உருவாக்கின: பெயர் பொருத்த விதி தீர்வியைத் தேர்ந்தெடுத்தது, ஒரு வழி பதிலை மீண்டும் கொண்டு வந்தது. எதையாவது உடைத்தால், வெளியிலிருந்து ஒரே மாதிரி தெரியும் தோல்வியை உலாவி காட்டும். பிரிக்கப்பட்ட DNS பற்றிய பெரும்பாலான அறிக்கைகள் இரண்டாவது தோல்வியை விவரித்து, முதல் பற்றிய சான்றுகளை மேற்கோள் காட்டுகின்றன.

இரு பகுதிகளும் வெவ்வேறு இடங்களில் வாழ்கின்றன, பொதுவாக வெவ்வேறு நபர்கள் அவற்றைத் திருத்துகிறார்கள். ஒன்று VPN சுயவிவரத்தில் இணைக்கப்பட்ட DNS கொள்கை, மற்றொன்று சுரங்கப்பாதை நிறுவும் அல்லது தடுத்து வைக்கும் வழி. எந்தப் பகுதி உண்மையில் நகர்ந்தது என்று யாரும் தீர்மானிக்காதபோது பிழைத்திருத்தம் நிற்கிறது.

ஒரே கோரிக்கையில் மறைந்திருக்கும் இரண்டு முடிவுகள்

பெயரின் பகுதி கொள்கைப் பொருள், வழி அல்ல. Windows இல் இது VPN சுயவிவரத்தில் பெயர் தீர்வுக் கொள்கை; Apple தளங்களில் DNS அமைப்புப் பொருளில் பொருந்தும் டொமைன்களின் தொகுப்பு; Linux இல் வழியமைப்பு டொமைன், பிரிக்கப்பட்ட தீர்வி வரி அல்லது பெயர் சேவை சுவிட்சின் வரிசை. பாதையின் பகுதி சாதாரண வழியமைப்பு, சுரங்கப்பாதையால் அல்லது கையால் நிறுவப்பட்டது, ஹோஸ்ட் பெயர் என்பது என்னவென்று அதற்குத் தெரியாது. பின்னொட்டை அனுமதிக்கும் சுயவிவரம் யார் பதிலளிப்பார் என்பதை மட்டும் தீர்மானிக்கிறது; பதிலை அது ஒருபோதும் அணுகக்கூடியதாக்குவதில்லை.

விரைவான அறிகுறிச் சோதனை அவற்றைப் பிரிக்கிறது: பெயருக்குப் பதிலாக ஒரு முகவரியை இடுங்கள். முகவரி செயல்பட்டால் பாதை சரியானது, விதி தவறானது. முகவரியும் தோல்வியுற்றால் விதி சரியாகவும் பாதை இல்லாமலும் இருக்கலாம்.

ஒவ்வொரு தளமும் அதே பெயர் விதியை எவ்வாறு வெளிப்படுத்துகிறது

நோக்கம் ஒன்றுதான், புலப் பெயர்கள் அல்ல. ஒரு கிளையன்டிலிருந்து மற்றொன்றுக்கு நகலெடுக்கப்பட்ட எடுத்துக்காட்டு தூய்மையாகப் பிரிக்கப்படுகிறது, ஒருபோதும் பொருந்தாது. மூன்று வடிவங்கள் இப்படித் தெரிகின்றன:

PlatformWhere the rule livesWhat usually breaks
Windowsname-resolution policy on the VPN profileprecedence against the interface suffix list
Apple platformsmatch domains on the DNS settings objectdomains attached to the wrong extension
Linuxrouting domain, split resolver, nsswitch orderthe suffix written the wrong way round

பொருத்தம் அல்லது வழியமைப்பு டொமைன் என்பது பின்னொட்டுச் சோதனை, எனவே intranet.corp git.intranet.corp ஐ உள்ளடக்கி corp.intranet ஐ உள்ளடக்காது, அதைத் திருப்புவதே முழு அமைப்பிலும் மிகவும் பொதுவான தவறு. Windows வரைபடத்தை சுயவிவரத்தில் இணைக்கப்பட்ட பெயர் தீர்வுக் கொள்கையாக எடுத்துச் செல்கிறது, இடைமுகத்திடம் ஏற்கனவே இருந்த எந்தப் பின்னொட்டுப் பட்டியலுக்கும் எதிரான அதன் சொந்த முன்னுரிமை வரிசையுடன். Apple தளங்கள் பொருந்தும் டொமைன்களை பிணைய நீட்டிப்பின் DNS அமைப்புப் பொருளுடன் இணைக்கின்றன, கணினம் அவற்றை ஒவ்வொரு வரம்புள்ள தீர்விக்கும் பயன்படுத்துகிறது. இந்த வடிவங்களில் எதுவும் வழி அல்ல, எதுவும் அணுக முடியாத முகவரியை அணுகக்கூடியதாக்க முடியாது. Windows பெயர் தீர்வுக் கொள்கை குறிப்பு அந்தத் தளத்தின் புலப் பெயர்களையும் முன்னுரிமை விதிகளையும் பட்டியலிடுகிறது, அவை Apple அல்லது systemd ஆவணங்கள் பயன்படுத்தும் விதிகள் அல்ல.

சரியான பதிலுக்கும் இன்னும் பாதை தேவை

தீர்வியின் பதில் ஒரு முகவரி மட்டுமே, பயன்பாடு இன்னும் அங்கு செல்ல வேண்டும். பிரிக்கப்பட்ட சுரங்கப்பாதை வடிவமைப்பு பெரும்பாலும் 10.20.0.0/16 ஐ தள்ளி இயல்புநிலை வழியைத் தடுத்து வைக்கிறது, எனவே உள் பெயர் தீர்க்கப்பட்டு பின்னர் இணைப்பு தொங்குகிறது. எதிர் நிலையும் அதே அளவு பொதுவானது: வழி உள்ளது, பொது தீர்வி தனிப்பட்ட பெயருக்கு NXDOMAIN உடன் பதிலளிக்கிறது, தோல்வி வழியமைப்புப் பிரச்சினையாகப் பதிவாகிறது. முதலில் பாதையைச் சோதித்தால் ஒருபோதும் தீர்க்கப்படாத பெயரின் வழிகளைப் பார்த்துக் கொண்டிருப்பீர்கள்.

எந்தப் பகுதியும் மறைக்காத மூன்றாவது வாசலும் உள்ளது. நுழைவாயிலில் ACL, ஃபயர்வால் விதி அல்லது கிளையன்ட் பக்கக் கொள்கை இரண்டு முடிவுகளும் சரியான பிறகும் இணைப்பை விழவைக்கலாம். பெயர் தீர்க்கப்பட்டு, வழி இருந்தும், இணைப்பு இன்னும் நேரம் முடிந்தால், DNS சோதிப்பதை நிறுத்துங்கள்.

நிர்ணயிக்கப்பட்ட வரிசையில் பெயர்களையும் பாதைகளையும் சோதித்தல்

ஒரு வரிசையைத் தேர்ந்தெடுத்து அதைப் பிடித்துக் கொள்ளுங்கள், இல்லையெனில் கடைசியாகத் தோல்வியடைந்த படிநிலையைத் துரத்துவீர்கள். ஆவணப்படுத்தப்பட்ட முழு உள் பெயரைத் தீர்க்கவும், பதில் வழி அட்டவணை சுமக்கக்கூடிய முகவரி என்பதை உறுதிசெய்யவும், பின்னர் பொது பெயருடன் மீண்டும் செய்து சுரங்கப்பாதை எல்லாவற்றையும் பிடிக்கவில்லை என்பதை நிரூபிக்கவும். systemd ஹோஸ்ட்டில் வினவலும் தீர்வியின் வழியமைப்பு டொமைனும் ஒரு கட்டளை இடைவெளியில் உள்ளன:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Windows கிளையன்ட் அதே இரண்டு கேள்விகளை வேறு cmdlet மூலம் கேட்கிறது. இரண்டாவது கணினி உண்மையில் பயன்படுத்தும் இடைமுகத்தைத் தெரிவிக்கிறது:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

தேடல் முகவரியைத் திருப்பினால், பாதைச் சரிபார்ப்பு இயற்பியல் இடைமுகத்தைக் குறிப்பிட்டால், பெயர் விதி வேலை செய்தது, வழி இல்லை. சிறிய பெயர் தோல்வியுற்று முழுப் பெயர் தீர்க்கப்பட்டால், பின்னொட்டுப் பட்டியலே தவறு, தீர்வி அல்ல.

ஒப்பீடு பொதுவாகத் தவறும் இடம்

முதல் தவறு தொடர்பில்லாத பொது தீர்வியிடம் தனிப்பட்ட பெயர் பற்றிக் கேட்டு, மறுப்பை VPN பற்றிய சான்றாகப் படிப்பது. இரண்டாவது வேலை செய்யும் பொது தேடல் சுரங்கப்பாதையின் தீர்வி பாதையை நிரூபிக்கும் என்று கருதுவது. மூன்றாவது பிரிக்கப்பட்ட சுரங்கப்பாதை மற்றும் பிரிக்கப்பட்ட DNS ஐ ஒரே வடிவமைப்பு முடிவாகக் கருதுவது, ஒரு பயன்பாட்டில் ஒன்றில் சரியாகவும் மற்றொன்றில் உடைந்தும் இருக்கலாம். ஒவ்வொரு தவறும் குற்றம் சாட்டப்பட்ட பகுதியை ஒருபோதும் பயிற்சி செய்யாத சோதனையிலிருந்து நம்பிக்கையான முடிவுகளைத் தருகிறது.

தனது சொந்தப் பாதுகாப்பான DNS உள்ள உலாவியும் கணினி விதியைத் தவிர்க்கலாம், அதனால் ஒரு உலாவி தோல்வியுற்று மற்றொன்று வெற்றிபெறுவது முரண்பாடு அல்ல. பதிலளித்த தீர்வியை ஒப்பிடுங்கள், புகார் செய்த உலாவியை அல்ல.

இரு பகுதிகளும் தெரிந்தபின் மீதமுள்ள கேள்வி தொழில்நுட்பமானது அல்ல, கொள்கை சார்ந்தது: எந்தப் பெயர் இடைவெளிகள் அமைப்புக்குச் சொந்தம், ஒவ்வொரு பதிலின் உரிமையாளர் யார், அவற்றில் எவை இயந்திரத்தை விட்டு வெளியேற வேண்டும். அதை சுயவிவரத்தின் அருகில் எழுதுங்கள், ஏனெனில் விதியைத் தொடும் அடுத்த நபருக்கு அது தேவைப்படும்.

தொடர்புடைய கட்டுரைகள்