Nabibigo ang iyong CIFS mount sa VPN dahil sa ayos sa nsswitch

Nakataas ang tunnel. Sumasagot ang file server sa ping sa pamamagitan ng address. Pagkatapos ay nakaupo lang ang mount.cifs kasama ang hostname nang ilang sandali at nag-uulat na hindi maabot ang host, at sinisimulan mong muling buuin ang isang profile ng VPN na hindi naman kailanman ang problema. Sa Linux, nire-resolve ng glibc ang pangalan bago pa umiral ang anumang SMB packet, at ang ayos sa resolver na iyon ay maaaring tapusin ang lookup bago pa man tanungin ang DNS. Ito ang tinatahak ko, simula sa command na nabigo at hindi sa client.

Basahin ang kabiguan sa tamang lugar

Dalawang tool ang dumadaan sa magkaibang landas patungo sa iisang pangalan, at ang paghahambing sa kanila ay isang command lang. Ang getent ay dumadaan sa naka-configure na name-service stack; ang host at dig ay direktang nagtatanong sa DNS at binabalewala ang stack na iyon. Kung ang direktang query ay nagbabalik ng address at ang getent ay walang ibinabalik, maabot ang DNS server at ang configuration ng resolver mo ang nabigo.

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

Ang ikatlong command ang tagapagpasya: pinipilit nito ang DNS source at nilalaktawan ang natitirang stack. Kapag gumana iyon at ang plain getent ay hindi, napatunayan mong ang ayos ang may kasalanan, hindi ang tunnel at hindi ang server.

Ang hosts line ay isang pagkakasunod-sunod na humihinto nang maaga

Binabasa ng glibc resolver ang /etc/nsswitch.conf at nilalakbay ang hosts: entry mula kaliwa pakanan. Maraming distribusyon ang nagpapadala ng line kung saan nauuna ang multicast lookup na may nakakabit na aksyon ng maagang pagbabalik. Ang aksyon ay hindi palamuti: kapag sumagot ang mDNS ng “not found”, tinatapos ng [NOTFOUND=return] ang buong lookup, kaya hindi kailanman naipapadala ang corporate name sa resolver na itinulak ng VPN. Walang naglo-log nito, dahil walang query na naipadala para tanggihan ng resolver. Iyon ang dahilan kung bakit parang nag-hang ang mount at pagkatapos ay nag-uulat ng hindi maabot na host.

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

Ilagay ang DNS bago ang aksyon ng maagang pagbabalik sa halip na tanggalin ang mDNS, at baguhin ito sa pamamagitan ng configuration management. Ang manu-manong pag-edit ay nabubuhay hanggang sa susunod na build ng image, at pagkatapos ay darating ang parehong ticket mula sa ibang makina na hindi natatandaan ang pag-aayos.

Ang resolver ay hindi search domain

Kailangan din ng resolution na masubukan ang pangalan. Ang hindi kwalipikadong pangalan tulad ng fileserver ay nagiging fileserver.corp.example lamang kapag may search domain na nakakabit sa interface na nagdadala ng query. Ang VPN na nagtutulak ng DNS server na walang search list ay gumagawa ng napakaespesipikong paghahati: nare-resolve ang buong kwalipikadong pangalan at nabibigo ang bawat maikling pangalan.

Subukan ang parehong anyo bago i-edit ang profile, dahil ang dalawang kabiguan ay tumuturo sa magkaibang direksyon. Sa host na may systemd-resolved, may sariling servers at routing domains ang tunnel link, kaya basahin ang link at hindi ang global file.

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

Kung ang query ay nauugnay sa isang link na hindi nagdadala ng tunnel, kulang ang routing domain kahit naroon ang DNS address. Iyon ay problema sa patakaran sa resolved configuration, hindi problema sa routing sa tunnel.

May sariling kopya ng sagot ang mga container

Ang container na ginawa mula sa generic na image ay karaniwang may dalang fixed na resolv.conf. Hindi umaabot doon ang mga pagbabago sa resolver sa host, at gayundin ang search domain, kaya nabibigo ang build job na nag-mount ng share sa tunnel habang gumagana ang parehong command sa labas ng container. Bigyan ang container ng sarili nitong DNS at search settings sa compose file o sa run arguments, hindi lang sa host profile.

Suriin sa loob ng container bago sisihin ang image. Dalawang command ang nagre-reproduce ng buong diagnosis sa ilang segundo, at ang pangalawa ay nagpapatunay kung aling resolver ang talagang sumagot.

Pagkatapos lang tingnan ang share at ang filter

Kapag na-resolve na ang pangalan, ang natitirang kabiguan ay ordinaryong problema sa network. Kailangan ng SMB ng TCP 445 patungo sa server, at ang pag-browse ng workgroup list ay nakadepende sa mga name service na malamang hindi ipinapasa ng tunnel. I-map ayon sa hostname sa halip na maghintay na mapuno ang isang listahan, at hayaang sabihin ng client kung saang yugto ito umabot. Sulit ding ihiwalay ang refused connection at ang tahimik na timeout, dahil ang una ay karaniwang may sumagot at ang pangalawa ay walang sumagot.

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

Ang na-resolve na address na may port 445 na refused o nag-time out ay problema sa firewall o listener sa kabilang panig. Ang hindi na-resolve na pangalan ay problema sa resolver. At ang mount na nag-authenticate pero nagbabalik ng permission errors ay wala sa dalawa, kaya huwag nang buksan muli ang tanong sa network kapag establisado na ang session.

Panatilihing kasingkitid ng ebidensya ang konklusyon. Kapag gumagana ang address at hindi ang pangalan, ginagawa ng tunnel ang trabaho nito, at ang pag-aayos ay nasa ayos ng resolver, search domain, o sariling configuration ng container.