குறுகிய உள் பெயர்கள் VPN இல் தோல்வியடைகின்றன: நீங்கள் ஒருபோதும் பார்க்காத பின்னொட்டு
குறுகிய பெயர் செயல்படுவதற்குக் காரணம் ஒரு தேடல் பின்னொட்டு அதை நிறைவு செய்வதே. பின்னொட்டு இல்லாமைக்கும் தீர்வியின் தோல்விக்கும் இடையே வேறுபடுத்த முழுப் பெயரையும் குறுகிய பெயரையும் ஒப்பிடுங்கள்.
குறுகிய பெயர் அலுவலகத்தில் செயல்பட்டது, VPN இல் தோல்வியடைகிறது; அதே நேரத்தில் முழுப் பெயர் எந்தச் சிக்கலும் இல்லாமல் தீர்க்கப்படுகிறது. எதுவும் உடைந்துவிடவில்லை. intranet போன்ற வெற்றுப் பெயர் முழுப் பெயர் அல்ல; வாடிக்கையாளர் தனது தேடல் பட்டியலிலிருந்து ஒரு பின்னொட்டைச் சேர்த்து முடிவைக் கேட்கிறார். VPN சுயவிவரம் அந்தப் பின்னொட்டை வழங்கவில்லை என்றால், பரிச்சயமான குறுகிய வடிவம் இனி இருக்காது.
அதுதான் முழுப் புராணம். DNS உடையவில்லை, தேடல் கொள்கை மாறியது.
வெற்றுப் பெயர் பெயர் அல்ல
நீங்கள் ஒரு லேபிளைத் தட்டச்சு செய்யும்போது, தீர்வி என்ன கேட்பது என்று முடிவு செய்ய வேண்டும். அது கொடுக்கப்பட்ட பெயரை அப்படியே முயற்சிக்கிறது, பின்னர் ஏதாவது பதிலளிக்கும் வரை தேடல் பட்டியலின் உள்ளீடுகளை ஒவ்வொன்றாகச் சேர்க்கிறது. Linux இல், resolv.conf search மற்றும் ndots அமைப்புகளுடன் அந்த வரிசையைக் கட்டுப்படுத்துகிறது. Windows இல், பின்னொட்டுப் பட்டியலும் பெயர் தீர்வுக் கொள்கையும் அதையே செய்கின்றன. பின்னொட்டை அகற்றுங்கள், தீர்விக்குச் சேர்ப்பதற்கு எதுவும் இருக்காது.
எனவே செயல்படும் குறுகிய பெயர் ஒரு கொள்கையின் சான்று, ஆரோக்கியமான DNS சேவையகத்தின் சான்று அல்ல.
பின்னொட்டுப் பட்டியலும் தீர்வி முகவரியும் செய்வது
இவை இரண்டும் தொடர்ந்து குழப்பப்படுகின்றன. தீர்வி முகவரி யாரைக் கேட்பது என்பதைச் சொல்கிறது; பின்னொட்டுப் பட்டியல் எந்தப் பெயரைப் பற்றிக் கேட்பது என்பதைச் சொல்கிறது. VPN உங்களுக்கு பின்னொட்டு இல்லாத தனிப்பட்ட தீர்வியையோ, தவறான தீர்வியுடன் பின்னொட்டையோ தரலாம். அந்தத் தோல்விகளில் ஒன்று மட்டுமே DNS தடங்கலாகத் தெரிகிறது.
அவற்றைத் தனித்தனியாகச் சரிபார்க்கவும், ஏனெனில் தவறானதைச் சரிசெய்வது ஆதரவு சாளரத்தை எரிக்கிறது.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
மூன்று அறிகுறிகள், மூன்று வெவ்வேறு பொறுப்பாளர்கள்.
முதலில் முழுப் பெயரைச் சோதிக்கவும்
ஊகம் அல்ல, நிர்வாகி ஆவணப்படுத்திய முழுமையாகத் தகுதிபெற்ற பெயரைக் கேளுங்கள். செயல்படும் FQDN தீர்வி அணுகக்கூடியது மற்றும் பதிவு உள்ளது என்பதை நிரூபிக்கிறது, இது ஒரே வினவலில் சாத்தியமான பாதி காரணங்களை நீக்குகிறது. எந்தச் சேவையகம் பதிலளித்தது எனக் காட்டும் கருவியைப் பயன்படுத்துங்கள், தற்காலிகச் சேமிப்பு முடிவைப் படிக்காதிருக்க.
சோதனையைத் தனிப்பட்டதாக வைத்திருங்கள். உள் வடிவங்களைப் பொது தீர்விக்கு அனுப்புவது பெயர்களை வெளிப்படுத்தி, யாரும் நோக்காத கொள்கையைச் சோதிக்கிறது.
திருத்தம் எங்கு பொருந்துகிறது
உரிமையாளர் சுயவிவரத்தையோ அதை உருவாக்கும் நிர்வாக முறையையோ திருத்துங்கள். உள்ளூர் தீர்வி உள்ளமைவில் கைமுறையாகச் செய்யும் மாற்றம் பொதுவாக மீண்டும் இணைக்கும்போது மறைந்துவிடும், அல்லது இயந்திரம் இணையும் ஒவ்வொரு பிணையத்திற்கும் பொருந்தும், இது மிகவும் மோசம்.
Windows இல், நினைவில் இருக்கும் தேர்வுப்பெட்டிக்குப் பதிலாக நடைமுறையில் உள்ள கொள்கையைச் சரிபார்க்கவும். Get-DnsClientNrptPolicy உண்மையில் நடைமுறையில் உள்ள பெயர் தீர்வு விதிகளைக் காட்டுகிறது.
macOS இல், scutil --dns ஒவ்வொரு எல்லை இடைமுகத்திற்கும் தீர்வி உள்ளமைவை, VPN தள்ளிய தேடல் களங்கள் உட்பட, அச்சிடுகிறது.
Linux இல், /etc/resolv.conf இல் உள்ள search வரியைப் படியுங்கள், ஆனால் VPN வாடிக்கையாளர் அதை மீண்டும் எழுதியதா எனச் சரிபார்க்கவும். கோப்பு நிர்வகிக்கப்படுகிறது என்றால், வழங்கப்பட்ட கோப்புக்குப் பதிலாக உண்மையின் மூலத்தைத் திருத்துங்கள். முந்தைய பிணையத்திலிருந்து எஞ்சிய பழைய search வரி பொதுவான காரணம்.
சுயவிவரத்துடன் எதை வைத்திருக்க வேண்டும்
திருத்தப்பட்ட முழுப் பெயர், பின்னொட்டுப் பட்டியல் மற்றும் தீர்வி முகவரியை வாடிக்கையாளர் சுயவிவரத்திற்கு அருகில் வைத்திருங்கள். intranet தளம் வேலை செய்யவில்லை எனப் புகாரளிக்கும் அடுத்த நபர் வெற்றுப் பக்கத்திலிருந்து தொடங்குவதற்குப் பதிலாக மூன்று தெரிந்த மதிப்புகளை ஒப்பிடலாம்.
குறுகிய வடிவம் மட்டும் தோல்வியடைந்தால், அதை டிக்கெட்டில் குறிப்பிடுங்கள். அந்த வாக்கியம் தீர்விக் குழுவிற்கு ஒரு பிற்பகலைச் சேமிக்கிறது.