તમારું CIFS માઉન્ટ VPN પર nsswitch ના ક્રમને કારણે નિષ્ફળ થાય છે

ટનલ ચાલુ છે. ફાઇલ સર્વર સરનામાથી 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 ને વહેલા-પરત થવાની ક્રિયા પહેલાં ખસેડો, અને તેને કન્ફિગરેશન મેનેજમેન્ટ દ્વારા બદલો. હાથે કરેલો ફેરફાર આગલા ઇમેજ બિલ્ડ સુધી ટકે છે, અને પછી એ જ ટિકિટ બીજી મશીનથી આવે છે જેને સુધારો યાદ નથી.

રિઝોલ્વર એ શોધ ડોમેન નથી

ઉકેલ માટે નામ પ્રયત્ન કરવો પણ જરૂરી છે. fileserver જેવું અ-લાયકાતવાળું નામ ત્યારે જ fileserver.corp.example બને છે જ્યારે ક્વેરી વહન કરતા ઇન્ટરફેસ સાથે શોધ ડોમેન જોડાયેલું હોય. જે VPN શોધ યાદી વગર DNS સર્વર દબાણ કરે છે તે ખૂબ ચોક્કસ વિભાજન ઉત્પન્ન કરે છે: સંપૂર્ણ લાયકાતવાળું નામ ઉકેલાય છે અને દરેક ટૂંકું નામ નિષ્ફળ જાય છે.

પ્રોફાઇલ સંપાદિત કરતા પહેલાં બંને સ્વરૂપો ચકાસો, કારણ કે બે નિષ્ફળતાઓ બે અલગ દિશા તરફ ઈશારો કરે છે. systemd-resolved ધરાવતા હોસ્ટ પર ટનલ લિંકના પોતાના સર્વર અને રાઉટિંગ ડોમેન હોય છે, તેથી ગ્લોબલ ફાઇલ નહીં પણ લિંક વાંચો.

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

જો ક્વેરી ટનલ ન વહન કરતી લિંકને આભારી હોય, તો DNS સરનામું હાજર હોવા છતાં રાઉટિંગ ડોમેન ખૂટે છે. તે resolved કન્ફિગરેશનમાં નીતિની સમસ્યા છે, ટનલમાં રાઉટિંગની સમસ્યા નથી.

કન્ટેનર પોતાની જવાબની નકલ લઈને ચાલે છે

સામાન્ય ઇમેજમાંથી બનેલું કન્ટેનર સામાન્ય રીતે નિશ્ચિત resolv.conf સાથે આવે છે. હોસ્ટ પર કરેલા રિઝોલ્વર ફેરફારો ત્યાં પહોંચતા નથી, શોધ ડોમેન પણ નહીં, તેથી ટનલ દ્વારા શેર માઉન્ટ કરતું બિલ્ડ કામ નિષ્ફળ જાય છે જ્યારે એ જ કમાન્ડ કન્ટેનરની બહાર કામ કરે છે. કન્ટેનરને તેના પોતાના DNS અને શોધ સેટિંગ compose ફાઇલમાં કે run આર્ગ્યુમેન્ટમાં આપો, ફક્ત હોસ્ટ પ્રોફાઇલમાં નહીં.

ઇમેજને દોષ આપતા પહેલાં કન્ટેનરની અંદર તપાસો. બે કમાન્ડ થોડી સેકંડમાં આખું નિદાન પુનરાવર્તિત કરે છે, અને બીજી સાબિત કરે છે કે કયા રિઝોલ્વરે ખરેખર જવાબ આપ્યો.

ત્યારે જ શેર અને ફિલ્ટર તરફ જુઓ

નામ ઉકેલાઈ ગયા પછી, બાકીની નિષ્ફળતાઓ સામાન્ય નેટવર્કની છે. 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 પોર્ટ નકારેલો કે સમય વીતી ગયેલો હોવો એ સામેની બાજુએ ફાયરવોલ કે listener ની સમસ્યા છે. ન ઉકેલાયેલું નામ એ રિઝોલ્વરની સમસ્યા છે. અને જે માઉન્ટ પ્રમાણીકરણ કરે પણ પરવાનગીની ભૂલો પરત આપે તે બંનેમાંથી કોઈ નથી, તેથી સત્ર સ્થપાયા પછી નેટવર્કનો પ્રશ્ન ફરી ન ખોલો.

નિષ્કર્ષને પુરાવા જેટલો સાંકડો રાખો. જ્યારે સરનામું કામ કરે અને નામ ન કરે, ત્યારે ટનલ પોતાનું કામ કરે છે અને સુધારો રિઝોલ્વર ક્રમ, શોધ ડોમેન કે કન્ટેનરની પોતાની કન્ફિગરેશનમાં આવે છે.