Via CIFS-muntado malsukcesas tra VPN pro la ordo de nsswitch

La tunelo estas supre. La dosier-servilo respondas al ping laŭ adreso. Poste mount.cifs kun la gastiga nomo sidas tie dum tempo kaj raportas, ke la gastigo neatingeblas, kaj vi komencas rekonstrui VPN-profilon, kiu neniam estis la problemo. En Linux la nomon solvas glibc antaŭ ol ekzistas ajna SMB-paketo, kaj la ordo en tiu solvilo povas fini la serĉon antaŭ ol DNS eĉ demandiĝas. Jen la vojo, kiun mi iras, komencante per la ordono, kiu malsukcesis, ne per la kliento.

Legu la malsukceson en la ĝusta loko

Du iloj iras diversajn vojojn al la sama nomo, kaj kompari ilin kostas unu ordonon. getent trairas la agorditan nomservan stakon; host kaj dig demandas DNS rekte kaj ignoras tiun stakon. Se la rekta demando redonas adreson kaj getent redonas nenion, la DNS-servilo estas atingebla kaj via solvila agordo estas tiu, kiu malsukcesas.

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

La tria ordono estas la decidanto: ĝi devigas la DNS-fonton kaj saltas la reston de la stako. Kiam ĝi funkcias kaj la ordinara getent ne, vi pruvis, ke la ordo kulpas, ne la tunelo kaj ne la servilo.

La linio hosts estas sinsekvo, kiu haltas frue

La glibc-solvilo legas /etc/nsswitch.conf kaj trairas la eron hosts: de maldekstre dekstren. Multaj distribuaĵoj liveras linion, en kiu multicast-serĉo venas unue kun frua-revena ago alkroĉita. La ago ne estas ornamaĵo: kiam mDNS respondas “not found”, [NOTFOUND=return] finas la tutan serĉon, do la entreprena nomo neniam sendiĝas al la solvilo, kiun la VPN enmetis. Nenio protokolas tion, ĉar neniu demando sendiĝis, kiun la solvilo povus malakcepti. Tial la muntado ŝajnas pendi kaj poste raportas neatingeblan gastigon.

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

Movu DNS antaŭ la frua-revena ago anstataŭ forigi mDNS, kaj ŝanĝu tion per agorda administrado. Mana redakto vivas ĝis la sekva bilda konstruo, kaj tiam la sama bileto alvenas el alia maŝino, kiu ne memoras la riparon.

Solvilo ne estas serĉa domajno

Solvado ankaŭ bezonas, ke la nomo estu provata. Nekvalifika nomo kiel fileserver nur iĝas fileserver.corp.example kiam serĉa domajno estas alkroĉita al la interfaco, kiu portas la demandon. VPN, kiu enmetas DNS-servilon sen serĉlisto, produktas tre specifan dividon: la plene kvalifikita nomo solviĝas kaj ĉiu mallonga nomo malsukcesas.

Testu ambaŭ formojn antaŭ ol redakti la profilon, ĉar la du malsukcesoj montras al diversaj direktoj. Ĉe gastigo kun systemd-resolved la tunela ligilo posedas siajn proprajn servilojn kaj enkursigajn domajnojn, do legu la ligilon, ne la ĝeneralan dosieron.

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

Se la demando estas atribuata al ligilo, kiu ne portas la tunelon, la enkursiga domajno mankas eĉ se la DNS-adreso ĉeestas. Tio estas politika problemo en la resolved-agordo, ne enkursiga problemo en la tunelo.

Ujoj portas sian propran kopion de la respondo

Ujo konstruita el ĝenerala bildo kutime liveras fiksan resolv.conf. Solvilaj ŝanĝoj faritaj ĉe la gastigo ne atingas ĝin, kaj same la serĉa domajno, do konstrua tasko, kiu muntas kunhavaĵon tra la tunelo, malsukcesas dum la sama ordono ekster la ujo funkcias. Donu al la ujo proprajn DNS- kaj serĉ-agordojn en la compose-dosiero aŭ en la rulaj argumentoj, ne nur en la gastiga profilo.

Kontrolu ene de la ujo antaŭ ol kulpigi la bildon. Du ordonoj reproduktas la tutan diagnozon en kelkaj sekundoj, kaj la dua pruvas, kiu solvilo vere respondis.

Nur tiam rigardu la kunhavaĵon kaj la filtrilon

Post kiam la nomo solviĝas, la restantaj malsukcesoj estas ordinaraj retaj. SMB bezonas TCP 445 al la servilo, kaj foliumi laborgrupan liston dependas de nomservoj, kiun la tunelo verŝajne ne plusendas. Mapu laŭ gastiga nomo anstataŭ atendi, ke listo pleniĝu, kaj lasu la klienton diri al vi, kiun etapon ĝi atingis. Rifuzita konekto kaj silenta timeout ankaŭ indas apartigi, ĉar la unua kutime signifas, ke io respondis, kaj la dua, ke nenio respondis.

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

Solvita adreso kun rifuzita aŭ tempolima pordo 445 estas problemo de fajroŝirmilo aŭ aŭskultanto ĉe la alia flanko. Nesolvita nomo estas la solvila problemo. Kaj muntado, kiu aŭtentikigas sed redonas permesajn erarojn, estas nek unu nek la alia, do ne remalfermu la retan demandon post kiam la seanco estas establita.

Tenu la konkludon tiel mallarĝa kiel la pruvoj. Kiam la adreso funkcias kaj la nomo ne, la tunelo faras sian taskon kaj la ripeto apartenas al la solvila ordo, la serĉa domajno aŭ la propra agordo de la ujo.