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

Hosts என்பது உள்ளூர் மேலெழுதல், மண்டல புதுப்பிப்பு அல்ல

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

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

இரண்டு கட்டளைகள், இரண்டு வெவ்வேறு கூறுகள்

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

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

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

வரிசையை உள்ளமைக்கலாம், ஒரு குறிப்பிட்ட விநியோகம் பற்றி எதையும் முடிவு செய்வதற்கு முன் அதைச் சரிபார்ப்பது மதிப்புள்ளது. /etc/nsswitch.conf இல் உள்ள hosts: வரியைப் பாருங்கள்; hosts: files dns முதலில் கோப்புகளைப் பார்க்கிறது. வரிசையை மாற்றுவதற்காக மட்டும் அந்த உதாரணத்தை வேலை செய்யும் உள்ளமைவின் மீது நகலெடுக்க வேண்டாம், ஏனெனில் உண்மையான கணினிகள் உதாரணத்தில் இல்லாத கூடுதல் மூலங்களையும் நிபந்தனை சேவை உள்ளீடுகளையும் அடிக்கடி பட்டியலிடுகின்றன.

systemd-resolved சோதனையை மங்கலாக்குகிறது

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

resolvectl query build.corp.example
resolvectl status

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

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

VPN முழுவதும் ஒரு பெயரை உண்மையில் பகிர்வது எது

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

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

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

தீர்க்கப்பட்ட பெயர் ஒரு பாதை அல்ல

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

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

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

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