nsswitch ക്രമം കാരണം VPN-ലൂടെയുള്ള CIFS മൗണ്ട് പരാജയപ്പെടുന്നു

ഷെയർ വിലാസം കൊണ്ട് ഉത്തരം നൽകുന്നു, പേരുകൊണ്ട് തൂങ്ങിക്കിടക്കുന്നു, അതിനാൽ SMB തുടങ്ങുന്നതിന് മുൻപേ ലുക്കപ്പ് മരിക്കുന്നു. getent-നെ host-മായി താരതമ്യം ചെയ്ത്, പിന്നീട് hosts വരി ക്രമത്തിൽ വായിക്കുക.

ടണൽ പ്രവർത്തിക്കുന്നു. ഫയൽ സർവർ വിലാസം കൊണ്ട് 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 പ്രശ്നമാണ്. നിർണ്ണയിക്കപ്പെടാത്ത പേര് റിസോൾവർ പ്രശ്നമാണ്. ഒപ്പം പ്രാമാണീകരണം നടത്തിയിട്ട് അനുമതി പിശകുകൾ തിരികെ നൽകുന്ന മൗണ്ട് രണ്ടുമല്ല, അതിനാൽ സെഷൻ സ്ഥാപിച്ചതിന് ശേഷം നെറ്റ്വർക്ക് ചോദ്യം വീണ്ടും തുറക്കരുത്.

തെളിവുകൾക്കൊപ്പം മാത്രം തീരുമാനം ചുരുക്കിപ്പിടിക്കുക. വിലാസം പ്രവർത്തിക്കുകയും പേര് പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്താൽ, ടണൽ തന്റെ ജോലി ചെയ്യുന്നു, തിരുത്ത് റിസോൾവർ ക്രമത്തിലോ സെർച്ച് ഡൊമെയ്നിലോ കണ്ടെയ്നറിന്റെ സ്വന്തം കോൺഫിഗറേഷനിലോ ആണ്.

അനുബന്ധ ലേഖനങ്ങൾ