Jou CIFS-monte misluk oor VPN weens die nsswitch-volgorde

Die tonnel is aan. Die lêerbediener antwoord ’n ping op adres. Dan sit mount.cifs met die gasheernaam ’n ruk lank en rapporteer dat die gasheer onbereikbaar is, en jy begin ’n VPN-profiel herbou wat nooit die probleem was nie. Op Linux word die naam deur glibc opgelos voordat enige SMB-pakket bestaan, en die volgorde in daardie oplosser kan die opsoek beëindig voordat DNS ooit gevra word. Hier is die stappie wat ek doen, begin by die opdrag wat gefaal het eerder as by die kliënt.

Lees die mislukking op die regte plek

Twee gereedskapstukke gebruik verskillende paaie na dieselfde naam, en om hulle te vergelyk kos een opdrag. getent loop deur die opgestelde naambediener-stapel; host en dig vra DNS direk en ignoreer daardie stapel. As die direkte navraag ’n adres teruggee en getent niks teruggee nie, is die DNS-bediener bereikbaar en is dit jou oplosser-konfigurasie wat faal.

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

Die derde opdrag is die beslisser: dit dwing die DNS-bron en slaan die res van die stapel oor. Wanneer dit werk en die gewone getent nie, het jy bewys die fout is die volgorde, nie die tonnel en nie die bediener nie.

Die hosts-reël is ’n reeks wat vroeg stop

Die glibc-oplosser lees /etc/nsswitch.conf en loop die hosts:-inskrywing van links na regs. Baie verspreidings lewer ’n reël waar multicast-opsoek eerste kom met ’n vroeë-terugkeer-aksie daarby. Die aksie is nie versiering nie: wanneer mDNS “not found” antwoord, beëindig [NOTFOUND=return] die hele opsoek, so die korporatiewe naam word nooit na die oplosser gestuur wat die VPN gepush het nie. Niks teken dit aan nie, want daar was nooit ’n navraag om te verwerp nie. Dit is hoekom die monte lyk of dit hang en dan ’n onbereikbare gasheer rapporteer.

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

Skuif DNS voor die vroeë-terugkeer-aksie eerder as om mDNS te verwyder, en verander dit deur konfigurasiebestuur. ’n Handmatige wysiging oorleef tot die volgende beeldbou, en dan kom dieselfde kaartjie van ’n ander masjien af met geen herinnering aan die regstelling nie.

’n Oplosser is nie ’n soekdomein nie

Oplossing het ook nodig dat die naam probeer word. ’n Ongekwalifiseerde naam soos fileserver word net fileserver.corp.example wanneer ’n soekdomein aan die koppelvlak geheg is wat die navraag dra. ’n VPN wat ’n DNS-bediener push sonder ’n soeklys lewer ’n baie spesifieke splitsing: die volle gekwalifiseerde naam los op en elke kort naam misluk.

Toets beide vorme voordat jy die profiel wysig, want die twee mislukkings wys in verskillende rigtings. Op ’n systemd-resolved-gasheer het die tonnelkoppeling sy eie bedieners en roeteringsdomeine, so lees die koppeling eerder as die globale lêer.

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

As die navraag toegeskryf word aan ’n koppeling wat nie die tonnel dra nie, ontbreek die roeteringsdomein al is die DNS-adres teenwoordig. Dit is ’n beleidsprobleem in die resolved-konfigurasie, nie ’n roeteringsprobleem in die tonnel nie.

Houers dra hul eie kopie van die antwoord

’n Houer wat uit ’n generiese beeld gebou is, lewer gewoonlik ’n vaste resolv.conf. Oplosser-veranderinge op die gasheer bereik dit nie, en die soekdomein ook nie, so ’n bouwerk wat ’n deel oor die tonnel monteer, misluk terwyl dieselfde opdrag buite die houer werk. Gee die houer sy eie DNS- en soekinstellings in die compose-lêer of die run-argumente, nie net in die gasheerprofiel nie.

Kontroleer binne die houer voordat jy die beeld blameer. Twee opdragte herhaal die hele diagnose in ’n paar sekondes, en die tweede een bewys watter oplosser werklik geantwoord het.

Kyk eers dan na die deel en die filter

Sodra die naam oplos, is die oorblywende mislukkings gewone netwerkprobleme. SMB benodig TCP 445 na die bediener, en om ’n werkgroeplys te blaai hang af van naambedieners wat die tonnel waarskynlik nie deurstuur nie. Kaart per gasheernaam eerder as om te wag dat ’n lys vul, en laat die kliënt vir jou sê watter fase dit bereik het. ’n Geweierde verbinding en ’n stil tydverskeiding is ook werd om te skei, want die eerste beteken gewoonlik iets het geantwoord en die tweede beteken niks het nie.

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

’n Opgeloste adres met poort 445 geweier of wat tyd uit is, is ’n brandmuur- of luisteraarprobleem aan die ander kant. ’n Naam wat nie oplos nie, is die oplosserprobleem. En ’n monte wat verifieer maar toestemmingsfoute teruggee, is nie een van die twee nie, so moenie die netwerkvraag weer oopmaak sodra die sessie op is nie.

Hou die gevolgtrekking so eng soos die bewyse. Wanneer die adres werk en die naam nie, doen die tonnel sy werk en hoort die regstelling in die oplosser-volgorde, die soekdomein of die houer se eie konfigurasie.