உள் பெயர்கள் VPN-இல் தோல்வியடைகின்றன, பொது தளங்கள் சரியாகத் தீர்க்கப்படுகின்றன

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

ஒரே குறை அல்லாத இரண்டு அறிகுறிகள்

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

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

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

எந்த அடாப்டரின் தீர்வி கேள்வியைப் பெறுகிறது

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

பிணைப்பு வரிசை முதல் பாதி மட்டுமே. எந்தப் பெயர்கள் அந்த அடாப்டருக்குச் சொந்தம் என்பதையும் கிளையண்ட் தெரிந்து கொள்ள வேண்டும், அது வரிசைக் கேள்வி அல்ல, பின்னொட்டுக் கேள்வி.

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

குறுகிய பெயருக்கு வழிக்கு முன் பின்னொட்டு தேவை

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

வேலை செய்யும் கணினியின் பின்னொட்டை VPN அடாப்டரின் IPv4 பண்புகளில் DNS தாவலில் நகலெடுத்து, பின்னர் மீண்டும் இணைக்கவும். Linux-இல் இதற்கு இணையானது சுரங்கப்பாதை இணைப்பில் உள்ள தேடல் களம், அதை systemd-resolved உலகளாவியதாக அல்ல, இணைப்பு வாரியாக வெளிப்படுத்துகிறது.

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

தீர்வியை நேரடியாகக் கேளுங்கள், பின்னர் பெயரை

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

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

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

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

Linux-இல், மீண்டும் எழுதும் VPN கிளையண்ட் /etc/resolv.conf உள்ளூர் தீர்விகளை முழுமையாக மாற்றுகிறது. அதைத் தடுக்க vpnc DNSUpdate no ஐ வெளிப்படுத்துகிறது, மேலும் systemd-resolved பட்டியலிடப்பட்ட களங்களை மட்டும் சுரங்கப்பாதை இணைப்புக்கு வழிமாற்ற முடியும். இரண்டு அணுகுமுறைகளும் பொது பெயர்களை உள்ளூர் தீர்வியில் வைத்துக்கொண்டு உள் பெயர்களை அலுவலகத்திற்கு அனுப்புகின்றன.

கசிவுகள் ஒரு விதி, ஒரு தேர்வுப்பெட்டி அல்ல

பெயர் தீர்மானம் என்பது போர்ட் 53-க்கு UDP பரிமாற்றம், எனவே வலைப் போக்குவரத்தைக் கொண்டு செல்லும் ஆனால் UDP-ஐ அல்ல சுரங்கப்பாதை வினவலை இயற்பியல் பாதையில் விட்டுவிடும். பொது பெயர் தீர்க்கப்படும் போது இயற்பியல் NIC-இல் பிடித்து அதை நிரூபிக்கவும். அந்த இடைமுகத்தில் படிக்கக்கூடிய வடிவில் தெரியும் வினவல் என்பது சுரங்கப்பாதை அதைக் கொண்டு செல்லவில்லை என்பதாகும்.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

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

கடைசிப் பகுதி தோன்றுவதை விட முக்கியம். OpenVPN-ஐ route-nopull உடன் தொடங்கினால், தள்ளப்பட்ட DNS விருப்பம் வழித்தடங்களுடன் மறைந்துவிடும், இழுப்பு வடிகட்டி அதைத் தக்கவைக்க விரிவாக்கப்படாவிட்டால். மேலும் dhcp-option DNS ஐ புறக்கணிக்கும் கிளையண்ட் முன்பு இருந்ததைத் தொடர்ந்து பயன்படுத்தும். சேவையகப் பக்கத்தில் எந்த மாற்றமும் நடைமுறைக்கு வர புதிய அமர்வு தேவை, ஏனெனில் தீர்வி பட்டியல் சுரங்கப்பாதை எழும்போது வழங்கப்படுகிறது, பழைய அமர்வு பழைய நிலையையே காட்டும்.

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