VPN DNS வேலை செய்கிறது, ஆனால் .local பெயர்கள் இன்னும் தோல்வியடைகின்றன: அவற்றை யார் தீர்க்கிறார்கள்?

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

இரண்டு தீர்விகள், இரண்டு வெவ்வேறு பதில்கள்

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

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

எந்தக் கட்டளை உண்மையில் உங்கள் தீர்வியைக் கேட்டது

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

ஏன் .local உங்கள் unicast மண்டலத்தைத் தவிர்க்கிறது

systemd-resolved-இன் குறிப்பு கூறுகிறது: .local-இல் முடியும் பல-லேபிள் பெயர்கள், mDNS இயக்கப்பட்டிருக்கும்போது சாதாரண unicast DNS-க்குப் பதிலாக பொதுவாக multicast DNS-க்குச் செல்கின்றன. RFC 6762 அந்தப் பெயர் இடத்தை link-local multicast-க்கு ஒதுக்குகிறது, எனவே ஒரு நிறுவன மண்டலம் அந்தப் பின்னொட்டுக்கு ஒருபோதும் கேட்கப்படாத சரியான பதிவை வைத்திருக்கலாம். சுரங்கப்பாதை தீர்வியைச் சரியாக வழிநடத்தியும் இன்னும் பந்தயத்தில் தோற்கலாம். தற்காலிகச் சேமிப்பிலிருந்து வெற்றிகரமான ping, இப்போது நடந்த தேடலைப் பற்றி எதுவும் கூறவில்லை.

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

குறுகிய விதிவிலக்கு உலகளாவிய மறுவரிசையை வெல்கிறது

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

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

மாற்றத்திற்குப் பிறகு எதை நிரூபிக்க வேண்டும்

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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