Mount yako ya CIFS inashindwa kupitia VPN kwa sababu ya mpangilio wa nsswitch

Sehemu inayoshirikiwa hujibu kwa anwani na huning'inia kwa jina, kwa hivyo utafutaji hufa kabla SMB kuanza. Linganisha getent na host, kisha soma mstari wa hosts kwa mpangilio.

Handaki iko juu. Seva ya faili hujibu ping kwa anwani. Kisha mount.cifs na jina la mwenyeji hukaa hapo kwa muda na kuripoti kwamba mwenyeji hafikiwi, na unaanza kujenga upya wasifu wa VPN ambao haukuwa tatizo kamwe. Kwenye Linux jina hutatuliwa na glibc kabla ya pakiti yoyote ya SMB kuwepo, na mpangilio katika kitatuzi hicho unaweza kumaliza utafutaji kabla DNS haijaulizwa hata mara moja. Hii ndiyo njia ninayopita, nikianza na amri iliyoshindwa na si kwa mteja.

Soma kushindwa mahali sahihi

Zana mbili hupita njia tofauti kuelekea jina moja, na kuzilinganisha hugharimu amri moja. getent hupitia safu ya huduma za majina iliyowekwa; host na dig huuliza DNS moja kwa moja na kupuuza safu hiyo. Ikiwa swali la moja kwa moja linarudisha anwani na getent halirudishi kitu, seva ya DNS inafikiwa na usanidi wako wa kitatuzi ndio unashindwa.

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

Amri ya tatu ndiyo inayoamua: inalazimisha chanzo cha DNS na kuruka safu iliyobaki. Inapofanya kazi na getent ya kawaida haifanyi kazi, umethibitisha kwamba kosa ni mpangilio, si handaki na si seva.

Mstari wa hosts ni mfuatano unaosimama mapema

Kitatuzi cha glibc kinasoma /etc/nsswitch.conf na kupita ingizo la hosts: kutoka kushoto kwenda kulia. Usambazaji mwingi huleta mstari ambapo utafutaji wa multicast huja kwanza ukiwa na kitendo cha kurudi mapema kimeambatishwa. Kitendo hicho si pambo: mDNS inapojibu “not found”, [NOTFOUND=return] humaliza utafutaji wote, kwa hivyo jina la shirika huwahi kutumwa kwa kitatuzi ambacho VPN ilisukuma. Hakuna kinachoiweka kwenye kumbukumbu, kwa sababu hakuna swali lililotumwa ambalo kitatuzi kingelikataa. Ndiyo sababu mount inaonekana kuning'inia kisha kuripoti mwenyeji asiyefikiwa.

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

Weka DNS mbele ya kitendo cha kurudi mapema badala ya kufuta mDNS, na ubadilishe kupitia usimamizi wa usanidi. Uhariri wa mkono hudumu hadi ujenzi wa image unaofuata, kisha tiketi hiyo hiyo inakuja kutoka mashine nyingine isiyokumbuka marekebisho.

Kitatuzi si kikoa cha utafutaji

Utatuzi pia unahitaji jina kujaribiwa. Jina lisilokamilika kama fileserver huwa fileserver.corp.example tu wakati kikoa cha utafutaji kimeambatishwa kwenye kiolesura kinachobeba swali. VPN inayosukuma seva ya DNS bila orodha ya utafutaji huzalisha mgawanyiko mahususi sana: jina lililokamilika hutatuliwa na kila jina fupi hushindwa.

Jaribu aina zote mbili kabla ya kuhariri wasifu, kwa sababu kushindwa huku kuwili kunaonyesha mielekeo tofauti. Kwenye mwenyeji wa systemd-resolved kiungo cha handaki kina seva na vikoa vyake vya uelekezaji, kwa hivyo soma kiungo na si faili ya jumla.

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

Ikiwa swali litahusishwa na kiungo kisichobeba handaki, kikoa cha uelekezaji kinakosekana ingawa anwani ya DNS ipo. Hiyo ni tatizo la sera katika usanidi wa resolved, si tatizo la uelekezaji katika handaki.

Makontena hubeba nakala yao ya jibu

Kontena lililojengwa kutoka image ya jumla kawaida huleta resolv.conf isiyobadilika. Mabadiliko ya kitatuzi yaliyofanywa kwenye mwenyeji hayafiki kwake, na wala kikoa cha utafutaji, kwa hivyo kazi ya build inayoweka sehemu inayoshirikiwa kupitia handaki hushindwa wakati amri hiyo hiyo inafanya kazi nje ya kontena. Ipe kontena mipangilio yake ya DNS na utafutaji katika faili ya compose au katika hoja za run, si kwenye wasifu wa mwenyeji tu.

Angalia ndani ya kontena kabla ya kulaumu image. Amri mbili huzalisha tena utambuzi wote kwa sekunde chache, na ya pili inathibitisha ni kitatuzi gani kilijibu kwa kweli.

Ndipo tu uangalie sehemu inayoshirikiwa na kichujio

Jina linapotatuliwa, kushindwa kunakobaki ni matatizo ya kawaida ya mtandao. SMB inahitaji TCP 445 kwa seva, na kuvinjari orodha ya kikundi cha kazi kunategemea huduma za majina ambazo handaki pengine haipitishi. Ramani kwa jina la mwenyeji badala ya kusubiri orodha ijae, na acha mteja akuambie alifikia hatua gani. Muunganisho uliokataliwa na timeout ya kimya pia yanafaa kutenganishwa, kwa sababu ya kwanza kwa kawaida humaanisha kitu fulani kilijibu na ya pili hakuna kilichojibu.

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

Anwani iliyotatuliwa na bandari 445 ikikataliwa au muda wake kuisha ni tatizo la firewall au msikilizaji upande wa pili. Jina lisilotatuliwa ni tatizo la kitatuzi. Na mount inayothibitisha lakini inarudisha makosa ya ruhusa si mojawapo, kwa hivyo usifungue tena swali la mtandao baada ya kipindi kuanzishwa.

Weka hitimisho nyembamba kama ushahidi. Anwani inapofanya kazi na jina halifanyi kazi, handaki linafanya kazi yake, na marekebisho yapo kwenye mpangilio wa kitatuzi, kikoa cha utafutaji au usanidi wa kontena yenyewe.

Makala zinazohusiana