VPN இல் உள் ஹோஸ்ட் பெயர்கள் dig இல் ஏன் தீர்க்கப்படுகின்றன ஆனால் curl இல் தோல்வியடைகின்றன

உங்கள் மடிக்கணினி VPN இல் உள்ளது, dig service.internal.example 10.x முகவரியுடன் பதிலளிக்கிறது, curl இன்னும் Could not resolve host உடன் வெளியேறுகிறது. சுரங்கப்பாதை பிரச்சினை அல்ல: அது dig வினவலைப் புகார் இல்லாமல் எடுத்துச் சென்றது. வேறுபாடு கேள்வியை யார் கேட்கிறார் என்பதில் உள்ளது. dig நீங்கள் பெயரிடும் ஒரு சேவையகத்திற்கு ஒரு வினவலை அனுப்புகிறது, ஆனால் curl இயக்க முறைமையின் தேடல் சங்கிலி வழியாகச் செல்கிறது, அந்தச் சங்கிலிக்கு எந்தச் சேவையகத்திடம் கேட்பது என்பதற்கான அதன் சொந்த விதிகள் உள்ளன.

ஒரே பெயருக்கு இரு தேடல்கள்

dig அதன் சொந்த stub resolver. அது /etc/resolv.conf படிக்கிறது, ஒரு பெயர் சேவையகத்தைத் தேர்ந்தெடுக்கிறது, ஒரே ஒரு A அல்லது AAAA வினவலை அனுப்பி பதிலை அச்சிடுகிறது. அது nsswitch ஐ முழுவதுமாகத் தவிர்க்கிறது, மேலும் systemd-resolved அல்லது NetworkManager அந்தக் கோப்பிற்கு வெளியே வைத்திருக்கும் இணைப்பு வாரியான நிலையைப் பற்றி எதுவும் அறியாது, அதனால்தான் dig பதில் சரியாக இருக்க முடியும், இருப்பினும் உங்கள் பயன்பாடு என்ன காணும் என்பதைப் பற்றி எதுவும் சொல்ல முடியாது.

பயன்பாடுகள் getaddrinfo ஐ அழைக்கின்றன, getaddrinfo நீண்ட சங்கிலியைக் கடக்கிறது: nsswitch தொகுதிகளின் வரிசை, பின்னர் பெயரைக் கையாளும் தொகுதி, இறுதியாக தற்போதைய இணைப்பு உள்ளமைவிலிருந்து கட்டப்பட்ட resolver. systemd இயந்திரத்தில் வினவல் 127.0.0.53 க்குச் செல்கிறது, systemd-resolved tun இடைமுகத்துடன் இணைந்த வழிசெலுத்தல் களத்தின் அடிப்படையில் ஒவ்வொரு இணைப்பிற்கும் மேல்நிலை சேவையகத்தைத் தேர்ந்தெடுக்கிறது.

இரு கட்டளைகள் இந்த அடுக்குகளை ஊகிக்காமல் பிரிக்கின்றன:

getent ahosts service.internal.example
resolvectl query service.internal.example

getent curl எடுக்கும் அதே பாதையை எடுக்கிறது, எனவே இயங்கும் dig அருகில் getent தோல்வியடைவது பிழையைப் பாக்கெட் வழிசெலுத்தலில் அல்ல, தேடல் கொள்கையில் கண்டறிகிறது. resolvectl query பதிலளித்த இடைமுகத்தையும் மேல்நிலை சேவையகத்தையும் அச்சிடுகிறது, இது சுரங்கப்பாதை இணைப்பா அல்லது இயற்பியல் இணைப்பா வென்றது என்பதைக் காட்டுகிறது.

பயன்பாடு உண்மையில் பயன்படுத்தும் resolver ஐப் படியுங்கள்

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

NetworkManager அமைப்புகளில் முடிவு /etc/NetworkManager/NetworkManager.conf இல் உள்ள backend ஐப் பொறுத்தது:

[main]
dns=systemd-resolved

dns=default உடன் வாடிக்கையாளரின் சேவையகங்கள் வெல்லும் வரிசையில் resolv.conf இல் இணைக்கப்படுகின்றன, தனிப்பட்ட வினவல் இன்னும் பொது resolver க்குச் செல்லலாம். இணைப்புகளைப் புரிந்துகொள்ளும் backend உடன், systemd-resolved அல்லது dnsmasq, சுரங்கப்பாதையின் சேவையகங்கள் சுரங்கப்பாதைக்கே வரம்பிடப்படுகின்றன, அதன் வழிசெலுத்தல் களத்துடன் பொருந்தும் பெயர்கள் மட்டுமே அங்கு செல்கின்றன. இந்த வரம்பே நடைமுறையில் split DNS என்பதன் பொருள், மேலும் ஒரு வாடிக்கையாளர் அதை ஆதரிப்பதாகக் கூறும்போது பெரும்பாலும் இந்தப் பகுதியே இல்லாதிருக்கிறது.

எதையும் மாற்றுவதற்கு முன் நிலையைப் படியுங்கள்:

resolvectl status
resolvectl dns tun0

tun இடைமுகம் DNS சேவையகத்துடனும் தனிப்பட்ட பின்னொட்டுக்கான வழிசெலுத்தல் களத்துடனும் பட்டியலிடப்பட்டு, ~internal.example ஆகக் காட்டப்படுவதைப் பார்க்க விரும்புகிறீர்கள். இணைப்பில் சேவையகம் இல்லாதது வாடிக்கையாளர் எதுவும் அனுப்பவில்லை என்பதைக் குறிக்கிறது. களம் இல்லாத சேவையகம் வினவல்கள் அனைத்தும் அங்கு செல்கின்றன அல்லது எதுவும் செல்லவில்லை என்பதைக் குறிக்கிறது, வாடிக்கையாளரைப் பொறுத்து, இரண்டுமே split DNS அல்ல.

nsswitch தேடலை முன்கூட்டியே முடிக்கும் இடம்

டெஸ்க்டாப்பின் வழக்கமான வரி இப்படித் தோன்றுகிறது:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

mdns4_minimal மல்டிகாஸ்ட் DNS ஐக் கையாள்கிறது, .local இல் முடியும் ஒவ்வொரு பெயரையும் உரிமை கொள்ளுகிறது. api.infra.svc.cluster.local போன்ற Kubernetes சேவையும் .local இல் முடிகிறது. mDNS தொகுதி NOTFOUND தெரிவிக்கும்போது, [NOTFOUND=return] செயல் dns தொகுதிக்குத் தொடர்வதற்குப் பதிலாக முழுத் தேடலையும் முடிக்கிறது, எனவே பெயர் ஒருபோதும் VPN resolver க்கு அனுப்பப்படுவதில்லை. dig கோப்பை முழுவதுமாகத் தவிர்க்கிறது, அதனால்தான் இரு கருவிகளும் ஒத்துப்போவதில்லை.

இது இந்தப் பிரச்சினையின் கூர்மையான முரண்பாடு, அது உங்கள் VPN ஐ விடப் பழமையான உள்ளமைவுக் கோப்பில் ஒரு சொல்லில் நிற்கிறது. செயலை [NOTFOUND=continue] ஆக மாற்றினால் அச்சுப்பொறிகள் மற்றும் உள்ளூர் சாதனங்களுக்கு mDNS தங்கும், அதே நேரம் DNS பெயரைப் பார்க்க முடியும். வரியை hosts: files dns ஆல் மாற்றுவதும் வேலை செய்கிறது, மேலும் கரடுமுரடானது: நீங்கள் உண்மையில் பயன்படுத்தும் அச்சுப்பொறிக்கான .local தீர்வை விட்டுவிடுகிறது.

சரியாக ஒரு நெட்வொர்க்கில் வாழும் பெயர்கள்

தனியார் மண்டலங்கள் சரியாக ஒரே இடத்தில் அதிகாரம் கொண்டவை. ip-10-0-4-31.eu-west-1.compute.internal போன்ற AWS பெயர் அந்தப் பிராந்தியத்தின் VPC resolver வழியாகப் பதிலளிக்கப்படுகிறது, உங்கள் VPN முனை வளம் உள்ள அதே பிராந்தியத்தில் இருக்கும் வரை மட்டுமே. பிராங்பேர்ட் முனையுடன் இணைந்து, அயர்லாந்தின் compute.internal பெயரைக் கேட்டால், எந்த உள்ளூர் அமைப்பும் உதவாது: பதிவை வைத்திருக்கும் மண்டலம் அங்கிருந்து அணுக முடியாதது.

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

நிர்வகிக்கப்பட்ட வாடிக்கையாளர்கள் கணினி resolver க்கு மேலே மூன்றாவது அடுக்கைச் சேர்க்கின்றனர். Windows VPN சுயவிவரம் அதன் சொந்த பெயர் தீர்வுக் கொள்கை, ஒவ்வொரு பயன்பாட்டிற்கான விதிகள் மற்றும் சுரங்கப்பாதை அணைந்திருக்கும்போதும் பொருந்தும் NRPT அட்டவணையைக் கொண்டு வரலாம். சொந்த DNS தற்காலிக சேமிப்பு கொண்ட பயன்பாடுகள், .NET மற்றும் Java இயக்கச் சூழல்களில் பொதுவானவை, சங்கிலி சரிசெய்யப்பட்ட பிறகும் பழைய தோல்வியை நீண்ட நேரம் வைத்திருக்கின்றன. Apple வாடிக்கையாளர்கள் split DNS ஐ DNS அமைப்புகளில் உள்ள பொருந்தும் களங்கள் மூலம் அமைக்கின்றனர், resolv.conf மூலம் அல்ல, Chromium அல்லது Firefox பாதுகாப்பான DNS பயன்முறையில் பொது பெயர்களுக்கு கணினி resolver ஐத் தவிர்க்கலாம். VPN பெயர் தீர்வு பற்றிய Microsoft குறிப்பு அந்தக் கொள்கை அடுக்கின் Windows பக்கத்தை விவரிக்கிறது.

எந்த அடுக்கைச் சரிசெய்வது என முடிவு செய்யுங்கள்

திருத்தங்களை வரிசையாக முயற்சிப்பதற்குப் பதிலாக அறிகுறியிலிருந்து அடுக்கை நோக்கிச் செல்லுங்கள்:

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

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

உள்ளமைவுக் கோப்பைத் திருத்துவதற்கு முன் நிலையைப் பதிவு செய்யுங்கள், திருத்தம் ஏதாவது செய்ததா எனச் சொல்ல முடியும்:

resolvectl status > before.txt
getent ahosts service.internal.example >> before.txt

சரிபார்ப்புகளை இந்த வரிசையில் இயக்கி முதல் தோல்வியில் நிறுத்துங்கள். getent மற்றும் resolvectl query ஒத்துப்போக வேண்டும்; getent தோல்வியடைந்து dig பதிலளித்தால், தேடல் சங்கிலியிலேயே இருங்கள், வழிசெலுத்தலைத் தொடாதீர்கள். resolvectl status tun இடைமுகத்தில் DNS சேவையகத்தையும் வழிசெலுத்தல் களத்தையும் காட்ட வேண்டும். nsswitch சோதிக்கப்படும் பின்னொட்டுக்கு NOTFOUND உடன் முன்கூட்டியே திரும்பக்கூடாது. பெயர் உங்கள் முனை இணைந்துள்ள நெட்வொர்க்கில் அதிகாரம் கொண்டதாக இருக்க வேண்டும், இறுதியில் புள்ளியுடன் சோதிக்கப்பட்டது. பயன்பாடு அதன் சொந்த தற்காலிக சேமிப்பையோ பாதுகாப்பான DNS மீறலையோ வைத்திருக்கக்கூடாது.

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