Sinu CIFS-montaaž ebaõnnestub VPN-i taga nsswitchi järjekorra tõttu

Jagatud ressurss vastab aadressi järgi ja jääb nime järgi rippuma, nii et otsing sureb enne, kui SMB algab. Võrdle getenti hostiga ja seejärel loe hosts-rida järjekorras.

Tunnel on püsti. Failiserver vastab pingile aadressi järgi. Siis istub mount.cifs hostinimega mõnda aega ja teatab, et host on kättesaamatu, ja sina hakkad ümber ehitama VPN-profiili, mis ei olnud kunagi probleem. Linuxis lahendab nime glibc enne, kui ükski SMB-pakett olemaski on, ja selle resolveri järjekord võib otsingu lõpetada enne, kui DNS-i üldse küsitakse. Siin on tee, mida ma käin, alustades käsust, mis ebaõnnestus, mitte kliendist.

Loe viga õigest kohast

Kaks tööriista lähevad sama nime poole erinevat teed, ja nende võrdlemine maksab ühe käsu. getent käib läbi seadistatud nimeteenuse virna; host ja dig küsivad DNS-i otse ja eiravad seda virna. Kui otsepäring tagastab aadressi ja getent ei tagasta midagi, on DNS-server kättesaadav ja ebaõnnestub sinu resolveri seadistus.

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

Kolmas käsk on otsustaja: see sunnib DNS-i allikat ja jätab virna ülejäänud osa vahele. Kui see töötab ja tavaline getent mitte, oled tõestanud, et süüdi on järjekord, mitte tunnel ja mitte server.

hosts-rida on jada, mis peatub vara

glibci resolver loeb /etc/nsswitch.conf ja käib hosts: kirje läbi vasakult paremale. Paljud distributsioonid tarnivad rea, kus multicast-otsing tuleb esimesena ja selle küljes on varajase tagastuse tegevus. Tegevus ei ole ehteks: kui mDNS vastab “not found”, lõpetab [NOTFOUND=return] kogu otsingu, nii et ettevõtte nime ei saadeta kunagi resolverile, mille VPN peale surus. Miski ei logi seda, sest ühtegi päringut ei saadetud, mida resolver oleks saanud tagasi lükata. Sellepärast näib montaaž rippuvat ja teatab seejärel kättesaamatust hostist.

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

Liiguta DNS varajase tagastuse tegevuse ette, selle asemel et mDNS-i kustutada, ja muuda seda konfiguratsioonihalduse kaudu. Käsitsi tehtud parandus elab järgmise kujutise buildini ja siis saabub sama pilet teiselt masinalt, mis parandust ei mäleta.

Resolver ei ole otsingudomeen

Lahendamine vajab ka seda, et nime proovitaks. Kvalifitseerimata nimi nagu fileserver muutub fileserver.corp.exampleiks alles siis, kui päringut kandva liidese külge on kinnitatud otsingudomeen. VPN, mis surub peale DNS-serveri ilma otsinguloendita, tekitab väga konkreetse lõhe: täielikult kvalifitseeritud nimi laheneb ja iga lühike nimi ebaõnnestub.

Katseta mõlemat vormi enne profiili muutmist, sest kaks ebaõnnestumist osutavad eri suundadesse. systemd-resolvediga hostis on tunneli lingil oma serverid ja marsruutimisdomeenid, seega loe linki, mitte globaalset faili.

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

Kui päring omistatakse lingile, mis tunnelit ei kanna, on marsruutimisdomeen puudu ka siis, kui DNS-aadress on olemas. See on resolved-konfiguratsiooni poliitikaprobleem, mitte tunneli marsruutimisprobleem.

Konteinerid kannavad oma koopiat vastusest

Üldisest kujutisest ehitatud konteiner tarnib tavaliselt fikseeritud resolv.conf. Hostis tehtud resolveri muudatused sinna ei jõua, samuti mitte otsingudomeen, seega build-töö, mis monteerib jagatud ressursi üle tunneli, ebaõnnestub, samal ajal kui sama käsk väljaspool konteinerit töötab. Anna konteinerile oma DNS-i ja otsingu seaded compose-failis või run-argumentides, mitte ainult hosti profiilis.

Kontrolli konteineri sees enne, kui kujutist süüdistad. Kaks käsku kordavad kogu diagnoosi mõne sekundiga ja teine tõestab, milline resolver tegelikult vastas.

Alles siis vaata jagatud ressurssi ja filtrit

Kui nimi on lahendatud, on ülejäänud ebaõnnestumised tavalised võrguvead. SMB vajab TCP 445 serverini ja töögrupi loendi sirvimine sõltub nimeteenustest, mida tunnel tõenäoliselt edasi ei anna. Kaardista hostinime järgi, selle asemel et oodata loendi täitumist, ja lase kliendil öelda, millisele etapile see jõudis. Tagasilükatud ühendus ja vaikne timeout tasub samuti eristada, sest esimene tähendab tavaliselt, et miski vastas, ja teine, et ei vastanud miski.

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

Lahendatud aadress, mille puhul port 445 on tagasi lükatud või aegunud, on tulemüüri või listeneri probleem teisel pool. Lahendamata nimi on resolveri probleem. Ja montaaž, mis autendib end, kuid tagastab õiguste vead, ei ole kumbki, seega ära ava võrgu küsimust uuesti, kui sessioon on loodud.

Hoia järeldus sama kitsas kui tõendid. Kui aadress töötab ja nimi mitte, teeb tunnel oma tööd ja parandus kuulub resolveri järjekorda, otsingudomeeni või konteineri enda seadistusse.

Seotud artiklid