Je CIFS-mount faalt over VPN door de volgorde in nsswitch

De tunnel staat. De fileserver antwoordt een ping op adres. Dan blijft mount.cifs met de hostnaam een tijdje hangen en meldt dat de host onbereikbaar is, en je begint een VPN-profiel opnieuw op te bouwen dat nooit het probleem was. Op Linux lost glibc de naam op voordat er ook maar één SMB-pakket bestaat, en de volgorde in die resolver kan de opzoeking beëindigen voordat DNS ooit gevraagd wordt. Dit is de route die ik loop, beginnend bij de opdracht die faalde en niet bij de client.

Lees de fout op de juiste plek

Twee hulpmiddelen nemen verschillende routes naar dezelfde naam, en ze vergelijken kost één opdracht. getent loopt door de geconfigureerde naamdienst-stack; host en dig vragen DNS rechtstreeks en negeren die stack. Als de directe query een adres teruggeeft en getent niets, dan is de DNS-server bereikbaar en faalt je resolverconfiguratie.

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

De derde opdracht is de beslisser: hij forceert de DNS-bron en slaat de rest van de stack over. Als die werkt en de gewone getent niet, heb je bewezen dat de volgorde de schuldige is, niet de tunnel en niet de server.

De hosts-regel is een reeks die vroeg stopt

De glibc-resolver leest /etc/nsswitch.conf en loopt de hosts:-regel van links naar rechts door. Veel distributies leveren een regel waarin multicast-zoekopdracht eerst komt met een vroege-terugkeer-actie eraan vast. Die actie is geen versiering: wanneer mDNS “not found” antwoordt, beëindigt [NOTFOUND=return] de hele opzoeking, zodat de bedrijfsnaam nooit naar de resolver gaat die de VPN heeft doorgeduwd. Niets logt dat, omdat er geen query is verzonden die de resolver kon weigeren. Daarom lijkt de mount te hangen en meldt hij daarna een onbereikbare 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

Zet DNS vóór de vroege-terugkeer-actie in plaats van mDNS te verwijderen, en wijzig het via configuratiebeheer. Een handmatige aanpassing overleeft tot de volgende image-build, en dan komt hetzelfde ticket van een andere machine die de fix niet meer kent.

Een resolver is geen zoekdomein

Voor resolutie moet de naam ook geprobeerd worden. Een niet-gekwalificeerde naam zoals fileserver wordt pas fileserver.corp.example wanneer er een zoekdomein aan de interface hangt die de query draagt. Een VPN die een DNS-server doordrukt zonder zoeklijst levert een heel specifieke splitsing op: de volledig gekwalificeerde naam wordt opgelost en elke korte naam faalt.

Test beide vormen voordat je het profiel aanpast, want de twee fouten wijzen in verschillende richtingen. Op een systemd-resolved-host heeft de tunnel-link zijn eigen servers en routingdomeinen, dus lees de link en niet het globale bestand.

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

Als de query wordt toegeschreven aan een link die de tunnel niet draagt, ontbreekt het routingdomein ook al is het DNS-adres aanwezig. Dat is een beleidsprobleem in de resolved-configuratie, geen routingprobleem in de tunnel.

Containers dragen hun eigen kopie van het antwoord

Een container gebouwd uit een generiek image levert meestal een vaste resolv.conf. Resolverwijzigingen op de host bereiken hem niet, en het zoekdomein ook niet, dus een build-taak die een share over de tunnel mount faalt terwijl dezelfde opdracht buiten de container werkt. Geef de container zijn eigen DNS- en zoekinstellingen in het compose-bestand of in de run-argumenten, niet alleen in het hostprofiel.

Controleer binnen de container voordat je het image de schuld geeft. Twee opdrachten reproduceren de hele diagnose in een paar seconden, en de tweede bewijst welke resolver echt antwoordde.

Pas dan kijk je naar de share en het filter

Zodra de naam oplost, zijn de resterende fouten gewone netwerkfouten. SMB heeft TCP 445 naar de server nodig, en door een werkgroeplijst bladeren hangt af van naamdiensten die de tunnel waarschijnlijk niet doorstuurt. Mappen op hostnaam in plaats van wachten tot een lijst volloopt, en laat de client je vertellen welke fase hij bereikte. Een geweigerde verbinding en een stille timeout zijn ook de moeite waard te scheiden, want de eerste betekent meestal dat iets antwoordde en de tweede dat niets dat deed.

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

Een opgelost adres met poort 445 geweigerd of verlopen is een firewall- of listenerprobleem aan de andere kant. Een niet-opgeloste naam is het resolverprobleem. En een mount die authenticeert maar permissiefouten teruggeeft is geen van beide, dus heropen de netwerkvraag niet zodra de sessie staat.

Houd de conclusie zo smal als het bewijs. Als het adres werkt en de naam niet, doet de tunnel zijn werk en hoort de fix in de resolvervolgorde, het zoekdomein of de eigen configuratie van de container.