Jo CIFS-mount mislearret oer VPN troch de folchoarder yn nsswitch

De dieling antwurdet op adres en hinget op namme, dus de syktocht stjert foar't SMB begjint. Fergelykje getent mei host en lês dan de hosts-regel yn folchoarder.

De tunnel is oan. De triemtsjinner antwurdet in ping op adres. Dan sit mount.cifs mei de hostnamme in skoft dêr en meldt dat de host net berikber is, en jo begjinne in VPN-profyl op 'e nij te bouwen dat nea it probleem wie. Op Linux wurdt de namme troch glibc oplost foar't der hokker SMB-pakket dan ek bestiet, en de folchoarder yn dy resolver kin de syktocht einigje foar't DNS ea frege wurdt. Hjir is de wei dy't ik rin, te begjinnen by it kommando dat mislearre, net by de klant.

Lês de mislearring op it goede plak

Twa helpmiddelen geane ferskillende wegen nei deselde namme, en se fergelykje kostet ien kommando. getent rint troch de ynstelde nammetsjinst-stapel; host en dig freegje DNS streekrjocht en negearje dy stapel. As de streekrjochte fraach in adres weromjout en getent neat, dan is de DNS-tsjinner berikber en is it jo resolver-konfiguraasje dy't mislearret.

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

It tredde kommando is de beslisser: it twingt de DNS-boarne en slacht de rest fan 'e stapel oer. As dat wurket en it gewoane getent net, dan hawwe jo bewiisd dat de folchoarder de skuld is, net de tunnel en net de tsjinner.

De hosts-regel is in rige dy't betiid stopt

De glibc-resolver lêst /etc/nsswitch.conf en rint de hosts:-ynfier fan links nei rjochts. In protte distribúsjes leverje in regel wêr't multicast-syktocht earst komt mei in iere-weromkomst-aksje deroan fêst. De aksje is gjin fersiering: as mDNS “not found” antwurdet, einiget [NOTFOUND=return] de hiele syktocht, sadat de bedriuwsnamme nea nei de resolver stjoerd wurdt dy't it VPN trochdrukt hat. Neat logt it, om't der nea in fraach stjoerd is dy't de resolver ôfwize koe. Dêrom liket de mount te hingjen en meldt dan in net berikbere 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

Set DNS foar de iere-weromkomst-aksje yn plak fan mDNS te wiskjen, en feroarje it fia konfiguraasjebehear. In hânmjittige bewurking oerlibbet oant de folgjende image-build, en dan komt itselde ticket fan in oare masine dy't de fix net mear wit.

In resolver is gjin sykdomein

Oplossing hat ek nedich dat de namme besocht wurdt. In net-kwalifisearre namme lykas fileserver wurdt pas fileserver.corp.example as in sykdomein oan 'e ynterface fêst sit dy't de fraach draacht. In VPN dy't in DNS-tsjinner trochdrukt sûnder syklist jout in hiel spesifike splitsing: de folslein kwalifisearre namme wurdt oplost en elke koarte namme mislearret.

Test beide foarmen foar't jo it profyl bewurkje, om't de twa mislearrings yn ferskillende rjochtingen wize. Op in systemd-resolved-host hat de tunnelkeppeling syn eigen tsjinners en routingdomeinen, dus lês de keppeling, net it globale triem.

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

As de fraach taskreaun wurdt oan in keppeling dy't de tunnel net draacht, dan ûntbrekt it routingdomein ek al is it DNS-adres oanwêzich. Dat is in beliedsprobleem yn 'e resolved-konfiguraasje, gjin routingprobleem yn 'e tunnel.

Konteners drage har eigen kopy fan it antwurd

In kontener boud fan in generyk image levert meastentiids in fêst resolv.conf. Resolverferoarings op 'e host berikke it net, en it sykdomein ek net, dus in build-taak dy't in dieling oer de tunnel mount, mislearret wylst itselde kommando bûten de kontener wurket. Jou de kontener syn eigen DNS- en sykynstellingen yn it compose-triem of yn 'e run-arguminten, net allinne yn it hostprofyl.

Kontrolearje binnen de kontener foar't jo it image de skuld jouwe. Twa kommando's reprodusearje de hiele diagnoaze yn in pear sekonden, en it twadde bewissiget hokker resolver echt antwurde.

Pas dan moat jo nei de dieling en it filter sjen

As de namme ienris oplost is, binne de oerbleaune mislearrings gewoane netwurkproblemen. SMB hat TCP 445 nedich nei de tsjinner, en in wurkgroep-list browsen hinget ôf fan nammetsjinsten dy't it VPN wierskynlik net trochjout. Map op hostnamme yn plak fan te wachtsjen oant in list fol is, en lit de klant jo fertelle hokker stap it berikt hat. In wegere ferbining en in stille timeout binne ek de muoite wurdich te skieden, om't it earste meastentiids betsjut dat eat antwurde en it twadde dat neat.

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

In oplost adres mei poarte 445 wegere of ferfallen is in firewall- of listenerprobleem oan 'e oare kant. In net oploste namme is it resolverprobleem. En in mount dy't autentisearret mar tastimmingflaters weromjout is gjin fan beide, dus iepenje de netwurkfraach net opnij as de sesje ienris stiet.

Hâld de konklúzje sa nau as it bewiis. As it adres wurket en de namme net, docht de tunnel syn wurk en heart de fix by de resolver-folchoarder, it sykdomein of de eigen konfiguraasje fan 'e kontener.

Relatearre artikelen