Zure CIFS muntaiak huts egiten du VPN bidez, nsswitch-en ordenagatik

Partekatzeak helbidearen bidez erantzuten du eta izenaren bidez zintzilik geratzen da, beraz bilaketa SMB hasi baino lehenago hiltzen da. Alderatu getent host-ekin, eta gero irakurri hosts lerroa ordenan.

Tunela martxan dago. Fitxategi zerbitzariak ping bati erantzuten dio helbidearen bidez. Ondoren mount.cifs ostalari-izenarekin han eserita egoten da denbora batez eta ostalaria eskuragaitza dela jakinarazten du, eta zu inoiz arazoa izan ez zen VPN profil bat berreraikitzen hasten zara. Linuxen glibc-k izena ebazten du SMB paketerik existitu aurretik, eta resolver horretako ordenak bilaketa amai dezake DNS inoiz galdetu aurretik. Hau da nik egiten dudan ibilbidea, huts egin zuen komandotik hasita, ez bezerotik.

Irakurri hutsa leku egokian

Bi tresnek bide ezberdinak egiten dituzte izen berera, eta haiek alderatzeak komando bat kostatzen du. getent konfiguratutako izen-zerbitzuen pilan zehar ibiltzen da; host eta dig DNS zuzenean galdetzen dute eta pila hori ez dute kontuan hartzen. Galdeketak zuzenean helbide bat itzultzen badu eta getent ezer itzultzen ez badu, DNS zerbitzaria eskuragarri dago eta zure resolver konfigurazioa da huts egiten duena.

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

Hirugarren komandoa da erabakigarria: DNS iturria behartzen du eta pilaren gainerakoa saltatzen du. Hori funtzionatzen duenean eta getent soilak ez, frogatu duzu ordena dela errua, ez tunela eta ez zerbitzaria.

hosts lerroa goiz gelditzen den segida da

glibc resolver-ak /etc/nsswitch.conf irakurtzen du eta hosts: sarrera ezkerretik eskuinera ibiltzen du. Banaketa askok multicast bilaketa lehenengo duen lerroa eramaten dute, itzulera goiztiarreko ekintza bat erantsita. Ekintza ez da apaingarria: mDNS-ek “not found” erantzuten duenean, [NOTFOUND=return]-k bilaketa osoa amaitzen du, beraz enpresako izena ez zaio inoiz VPN-ak bultzatutako resolver-ari bidaltzen. Ezerk ez du hori erregistratzen, ez baitzen inolako galdeketarik bidali resolver-ak bazter zezan. Horregatik muntaiak zintzilik dirudi eta gero ostalari eskuragaitza jakinarazten du.

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

Jarri DNS itzulera goiztiarreko ekintzaren aurretik mDNS ezabatu beharrean, eta aldatu konfigurazio kudeaketaren bidez. Eskuzko aldaketak hurrengo irudiaren build-era arte irauten du, eta gero ticket bera beste makina batetik iristen da konponbidea gogoratzen ez duena.

Resolver bat ez da bilaketa domeinua

Ebazpenak izena probatzea ere behar du. fileserver bezalako izen ez-kalifikatu bat fileserver.corp.example bihurtzen da soilik bilaketa domeinu bat galdeketa daraman interfazeari erantsita dagoenean. Bilaketa zerrendarik gabe DNS zerbitzari bat bultzatzen duen VPN-ak oso bereizketa zehatza sortzen du: izen erabat kalifikatua ebazten da eta izen labur guztiek huts egiten dute.

Probatu bi formak profila editatu aurretik, huts egiteek norabide ezberdinak seinalatzen dituztelako. systemd-resolved duen ostalari batean tunelaren estekatzaileak bere zerbitzariak eta bideratze domeinuak ditu, beraz irakurri estekatzailea, ez fitxategi globala.

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

Galdeketa tunela eramaten ez duen estekatzaile bati egozten bazaio, bideratze domeinua falta da DNS helbidea present egon arren. Hori resolved konfigurazioko politika arazoa da, ez tunelaren bideratze arazoa.

Edukiontziek erantzunaren beren kopia eramaten dute

Irudi orokor batetik eraikitako edukiontziak normalean resolv.conf finko bat eramaten du. Ostalarian egindako resolver aldaketek ez diote heltzen, ezta bilaketa domeinuak ere, beraz tunelaren bidez partekatze bat muntatzen duen build lanak huts egiten du, komando berak edukiontzitik kanpo funtzionatzen duen bitartean. Eman edukiontziari bere DNS eta bilaketa ezarpenak compose fitxategian edo run argumentuetan, ez ostalariaren profilean soilik.

Egiaztatu edukiontziaren barruan irudia errudun egin aurretik. Bi komandok diagnosi osoa segundo batzuetan erreproduzitzen dute, eta bigarrenak frogatzen du zein resolver-ek erantzun zuen benetan.

Orduan soilik begiratu partekatzeari eta iragazkiari

Izena ebazten denean, gainerako hutsegiteak sare arruntak dira. SMB-k TCP 445 behar du zerbitzarirako, eta lan-talde zerrenda arakatzeak tunelek ziurrenik aurrera eramaten ez dituen izen zerbitzuen mende dago. Mapatu ostalari-izenaren arabera zerrenda bat betetzea itxaron beharrean, eta utzi bezeroari esaten zer fasera iritsi den. Ukatutako konexio bat eta isilpeko timeout bat ere bereiztea merezi du, lehenak zerbait-ek erantzun zuela esan ohi baitu eta bigarrenak ezerk ez.

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 portua ukatu edo denbora amaitu zaion helbide ebatzian, beste aldeko suebaki edo listener arazoa da. Ebaztu gabeko izena resolver-aren arazoa da. Eta autentifikatu baina baimen erroreak ematen dituen muntaia ez da bietako bat ere, beraz ez berrireki sare galdera sesioa finkatuta dagoenean.

Eduki ezazu ondorioa ebidentzia bezain estu. Helbidea funtzionatzen duenean eta izenak ez, tunelak bere lana egiten du eta konponbidea resolver ordenan, bilaketa domeinuan edo edukiontziaren beraren konfigurazioan dago.

Erlazionatutako artikuluak