nsswitch வரிசையின் காரணமாக உங்கள் CIFS மவுண்ட் VPN வழியாகத் தோல்வியடைகிறது

சுரங்கப்பாதை இயங்குகிறது. கோப்பு சேவையகம் ping-க்கு முகவரியால் பதிலளிக்கிறது. பின்னர் mount.cifs ஹோஸ்ட் பெயருடன் சிறிது நேரம் அப்படியே நின்று, ஹோஸ்டை அடைய முடியாது என்று தெரிவிக்கிறது, நீங்கள் ஒருபோதும் பிரச்சினையாக இல்லாத VPN சுயவிவரத்தை மீண்டும் கட்டத் தொடங்குகிறீர்கள். Linux-இல் எந்த SMB பொதியும் தோன்றுவதற்கு முன்பே glibc பெயரைத் தீர்க்கிறது, அந்த ரிசால்வரில் உள்ள வரிசை DNS-ஐக் கேட்பதற்கு முன்பே தேடலை முடித்துவிடலாம். இதுதான் நான் நடக்கும் பாதை, வாடிக்கையாளரிடமிருந்து அல்ல, தோல்வியடைந்த கட்டளையிலிருந்து தொடங்குகிறது.

தோல்வியைச் சரியான இடத்தில் படியுங்கள்

இரு கருவிகள் ஒரே பெயருக்கு வெவ்வேறு பாதைகளில் செல்கின்றன, அவற்றை ஒப்பிட ஒரு கட்டளை போதும். getent அமைக்கப்பட்ட பெயர் சேவை அடுக்கு வழியாகச் செல்கிறது; host மற்றும் dig DNS-ஐ நேரடியாகக் கேட்டு அந்த அடுக்கைப் புறக்கணிக்கின்றன. நேரடி வினவல் ஒரு முகவரியைத் திருப்பித் தந்து getent எதையும் தராவிட்டால், DNS சேவையகம் அணுகக்கூடியது, தோல்வியடைவது உங்கள் ரிசால்வர் அமைப்பே.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

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

hosts வரி விரைவில் நிற்கும் ஒரு வரிசை

glibc ரிசால்வர் /etc/nsswitch.conf-ஐப் படித்து hosts: உள்ளீட்டை இடமிருந்து வலமாகச் செல்கிறது. பல விநியோகங்கள் multicast தேடல் முதலில் வந்து, அதனுடன் முன்கூட்டியே திரும்பும் செயல் இணைக்கப்பட்ட வரியை வழங்குகின்றன. அந்தச் செயல் அலங்காரம் அல்ல: mDNS “not found” என்று பதிலளிக்கும்போது, [NOTFOUND=return] முழுத் தேடலையும் முடிக்கிறது, எனவே நிறுவனப் பெயர் VPN திணித்த ரிசால்வருக்கு ஒருபோதும் அனுப்பப்படுவதில்லை. எதுவும் அதைப் பதிவு செய்யவில்லை, ஏனெனில் ரிசால்வர் நிராகரிக்கக்கூடிய வினவலே அனுப்பப்படவில்லை. அதனால்தான் மவுண்ட் தொங்குவதுபோல் தெரிந்து பின்னர் ஹோஸ்டை அடைய முடியாது என்று தெரிவிக்கிறது.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

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

ரிசால்வர் என்பது தேடல் களம் அல்ல

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

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

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

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

கொள்கலன்கள் பதிலின் சொந்த நகலைச் சுமக்கின்றன

பொதுவான image-இல் இருந்து கட்டப்பட்ட கொள்கலன் பொதுவாக நிலையான resolv.conf-ஐக் கொண்டு வரும். ஹோஸ்டில் செய்யப்பட்ட ரிசால்வர் மாற்றங்கள் அதை அடையாது, தேடல் களமும் அடையாது, எனவே சுரங்கப்பாதை வழியாகப் பங்கீட்டை மவுண்ட் செய்யும் build வேலை தோல்வியடைகிறது, அதே கட்டளை கொள்கலனுக்கு வெளியே வேலை செய்கிறது. கொள்கலனுக்கு அதன் சொந்த DNS மற்றும் தேடல் அமைப்புகளை compose கோப்பில் அல்லது run வாதங்களில் கொடுங்கள், ஹோஸ்ட் சுயவிவரத்தில் மட்டும் அல்ல.

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

அதன்பிறகே பங்கீட்டையும் வடிகட்டியையும் பாருங்கள்

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

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

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

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