resolv.conf உங்கள் VPN DNS ஐக் காட்டும் ஆனால் தேடல்கள் அதைப் புறக்கணிப்பது ஏன்

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

resolv.conf எனப்படும் மூன்று பொருள்கள்

resolved உள்ள ஹோஸ்ட்டில் /etc/resolv.conf பொதுவாக /run/systemd/resolve/stub-resolv.conf க்கான குறியீட்டு இணைப்பு. அந்த இலக்கில் உள்ளூர் stub கேட்பானின் முகவரி, 127.0.0.53, மற்றும் resolved கணக்கிட்ட தேடல் களங்கள் உள்ளன. இது நிலையின் பார்வை, நிலையே அல்ல.

நிலை resolved இன் ஒவ்வொரு இணைப்பிற்கான உள்ளமைவில் வாழ்கிறது, அதனால்தான் resolvectl status கோப்புடன் முரண்பட்டாலும் சரியாக இருக்க முடியும். ஒவ்வொரு இணைப்பும் அதன் சொந்த சேவையகங்களையும் அதன் சொந்த வழிப்படுத்தல் களங்களையும் சுமக்கிறது, வினவல் வரும்போது stub அந்தத் தரவைப் பார்க்கிறது. systemd-resolved கையேடு உருவாக்கப்படும் கோப்புகளையும் ஒவ்வொரு இணைப்பின் மாதிரியையும் விவரிக்கிறது; பார்வைக்கும் நிலைக்கும் இடையிலான பிரிவே நினைவில் வைக்கத் தகுந்த பகுதி. குறியீட்டு இணைப்பின் இலக்கை மாற்றுவது பாரம்பரிய வாடிக்கையாளர்கள் படிப்பதை மாற்றுகிறது, தீர்வி அறிவதை அல்ல.

மூன்றாவது பொருள், /run/systemd/resolve/resolv.conf, ஒவ்வொரு இணைப்பையும் ஒரே சேவையகப் பட்டியலாகத் தட்டையாக்குகிறது. அந்தக் கோப்பை நோக்கிய நிரல் வினவல்களை நேரடியாகப் பட்டியலிட்ட சேவையகங்களுக்கு அனுப்பி stub ஐத் தவிர்க்கிறது, எனவே ஒவ்வொரு இணைப்பின் கொள்கை இனி அதற்குப் பொருந்தாது. எனவே ஒரே இயந்திரத்தில் உள்ள இரண்டு நிரல்கள் ஒரே பெயருக்கு வெவ்வேறாகப் பதிலளிக்கலாம், எதுவும் உடைந்ததில்லை.

NSS வழியாக ஒரு தேடலைப் பின்தொடரவும்

ஒரு பெயருக்கு யார் பதிலளிப்பார் என முடிவெடுக்க glibc /etc/nsswitch.conf ஐப் படிக்கிறது. resolve உள்ள hosts வரி கேள்வியை nss-resolve க்கு அனுப்புகிறது, அது D-Bus வழியாக resolved ஐக் கேட்டு ஒவ்வொரு இணைப்பின் பதிலைப் பெறுகிறது. files dns மட்டும் உள்ள வரி வினவலை /etc/resolv.conf வைத்திருக்கும் முகவரிக்கு அனுப்புகிறது.

அந்த ஒரு வரியே உலாவிக்கும் dig க்கும் இடையிலான பெரும்பாலான வேறுபாடுகளை விளக்குகிறது. dig resolv.conf ஐ நேரடியாகப் படித்து NSS ஐ ஒருபோதும் தொடுவதில்லை, எனவே பயன்பாடு பயன்படுத்தும் பாதையை விட stub அல்லது மேல் சேவையகத்தைச் சோதிக்கிறது. getent hosts internal.example NSS வழியாகச் செல்கிறது, அதன் பதிலை dig இன் பதிலுடன் ஒப்பிடுவதே முதல் பயனுள்ள அளவீடு.

தங்கள் சொந்தத் தீர்வியைக் கொண்டு வரும் அல்லது நிலையான முடிவுப்புள்ளிக்கு HTTPS மூலம் DNS பேசும் பயன்பாடுகள் இரண்டு பாதைகளையும் தவிர்க்கின்றன. resolv.conf இலோ resolved நிலையிலோ எதுவும் அவற்றைக் கட்டுப்படுத்தவில்லை.

கோப்பு யாருடையது, எங்கு சுட்டுகிறது எனச் சரிபார்க்கவும்

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

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

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

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

இணைப்பின் உரிமையாளரிடம் சரிசெய்யவும்

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

ஏற்கனவே உள்ள இணைப்பில், இயக்கநேர அமைப்புகள் வழிமுறையைக் காட்டுகின்றன. resolvectl dns tun0 10.40.0.53 ஒரு சேவையகத்தை இணைக்கிறது, resolvectl domain tun0 '~corp.example' ஒரு வழிப்படுத்தல் களத்தை இணைக்கிறது. டில்டா (~) சுமையைத் தாங்கும் எழுத்து: அது அந்தப் பின்னொட்டின் வினவல்களை இந்த இணைப்பில் மட்டுப்படுத்தி மற்ற அனைத்தையும் அமைதியாக விடுகிறது, அது இல்லாமல் அதே மதிப்பு தேடல் களமாகி பிரிவு ஆவியாகிறது. அந்த முகவரிகள் ஆய்வக எடுத்துக்காட்டுகள், நிரந்தர உள்ளமைவு அல்ல. resolvectl query host.corp.example மூலம் உறுதிசெய்து எந்த இணைப்பு பதிலளித்தது எனப் படியுங்கள்.

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

செயல்படும் நிலை எப்படி இருக்கும்

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

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