Ihr CIFS-Mount scheitert über VPN an der Reihenfolge in nsswitch

Der Tunnel steht. Der Dateiserver antwortet auf einen Ping per Adresse. Dann sitzt mount.cifs mit dem Hostnamen eine Weile da und meldet, der Host sei nicht erreichbar, und Sie beginnen, ein VPN-Profil neu zu bauen, das nie das Problem war. Unter Linux löst glibc den Namen auf, bevor irgendein SMB-Paket existiert, und die Reihenfolge in diesem Resolver kann die Auflösung beenden, bevor DNS überhaupt gefragt wird. Hier ist der Weg, den ich gehe, beginnend bei dem Befehl, der fehlgeschlagen ist, nicht beim Client.

Lesen Sie den Fehler an der richtigen Stelle

Zwei Werkzeuge nehmen verschiedene Wege zum selben Namen, und ihr Vergleich kostet einen Befehl. getent läuft durch den konfigurierten Namensdienst-Stack; host und dig fragen DNS direkt und ignorieren diesen Stack. Wenn die direkte Abfrage eine Adresse zurückgibt und getent nichts, dann ist der DNS-Server erreichbar und Ihre Resolver-Konfiguration ist es, die scheitert.

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

Der dritte Befehl ist der Entscheider: Er erzwingt die DNS-Quelle und überspringt den Rest des Stacks. Wenn er funktioniert und der einfache getent nicht, haben Sie bewiesen, dass die Reihenfolge schuld ist, nicht der Tunnel und nicht der Server.

Die hosts-Zeile ist eine Abfolge, die früh abbricht

Der glibc-Resolver liest /etc/nsswitch.conf und geht den hosts:-Eintrag von links nach rechts durch. Viele Distributionen liefern eine Zeile, in der die Multicast-Suche zuerst kommt und eine Aktion für frühe Rückkehr daran hängt. Die Aktion ist keine Zierde: Wenn mDNS “not found” antwortet, beendet [NOTFOUND=return] die gesamte Auflösung, sodass der Firmenname nie an den Resolver geht, den das VPN durchgesetzt hat. Nichts protokolliert das, weil keine Abfrage gesendet wurde, die der Resolver hätte ablehnen können. Deshalb scheint der Mount zu hängen und meldet danach einen nicht erreichbaren 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

Setzen Sie DNS vor die Aktion für frühe Rückkehr, statt mDNS zu löschen, und ändern Sie es über Konfigurationsmanagement. Eine Handänderung überlebt bis zum nächsten Image-Build, und dann kommt dasselbe Ticket von einer anderen Maschine, die von der Korrektur nichts weiß.

Ein Resolver ist keine Suchdomäne

Zur Auflösung gehört auch, dass der Name versucht wird. Ein unqualifizierter Name wie fileserver wird erst dann fileserver.corp.example, wenn eine Suchdomäne an das Interface gehängt ist, das die Abfrage trägt. Ein VPN, das einen DNS-Server ohne Suchliste durchsetzt, erzeugt eine sehr bestimmte Teilung: der voll qualifizierte Name wird aufgelöst und jeder kurze Name scheitert.

Testen Sie beide Formen, bevor Sie das Profil bearbeiten, denn die beiden Fehler zeigen in verschiedene Richtungen. Auf einem systemd-resolved-Host besitzt die Tunnel-Schnittstelle ihre eigenen Server und Routing-Domänen, also lesen Sie die Schnittstelle statt der globalen Datei.

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

Wird die Abfrage einer Schnittstelle zugeordnet, die den Tunnel nicht trägt, fehlt die Routing-Domäne, obwohl die DNS-Adresse vorhanden ist. Das ist ein Policy-Problem in der resolved-Konfiguration, kein Routing-Problem im Tunnel.

Container tragen ihre eigene Kopie der Antwort

Ein Container aus einem generischen Image bringt meist eine feste resolv.conf mit. Resolver-Änderungen auf dem Host erreichen ihn nicht, und die Suchdomäne ebenso wenig, also scheitert ein Build-Job, der eine Freigabe über den Tunnel mountet, während derselbe Befehl außerhalb des Containers funktioniert. Geben Sie dem Container eigene DNS- und Sucheinstellungen in der Compose-Datei oder in den Run-Argumenten, nicht nur im Host-Profil.

Prüfen Sie im Container, bevor Sie das Image beschuldigen. Zwei Befehle wiederholen die ganze Diagnose in wenigen Sekunden, und der zweite beweist, welcher Resolver tatsächlich geantwortet hat.

Erst dann schauen Sie auf die Freigabe und den Filter

Sobald der Name aufgelöst ist, sind die übrigen Fehler gewöhnliche Netzwerkfehler. SMB braucht TCP 445 zum Server, und das Durchblättern einer Arbeitsgruppenliste hängt von Namensdiensten ab, die der Tunnel wahrscheinlich nicht weiterleitet. Binden Sie per Hostname ein, statt auf eine gefüllte Liste zu warten, und lassen Sie den Client sagen, welche Stufe er erreicht hat. Eine abgelehnte Verbindung und ein stummer Timeout sind ebenfalls auseinanderzuhalten, denn der erste bedeutet meist, dass etwas geantwortet hat, und der zweite, dass nichts geantwortet hat.

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

Eine aufgelöste Adresse mit abgelehntem oder ausgelaufenem Port 445 ist ein Firewall- oder Listener-Problem auf der Gegenseite. Ein unaufgelöster Name ist das Resolver-Problem. Und ein Mount, der sich authentifiziert, aber Berechtigungsfehler zurückgibt, ist keines von beiden, also öffnen Sie die Netzwerkfrage nicht erneut, wenn die Sitzung steht.

Halten Sie die Schlussfolgerung so eng wie die Beweise. Wenn die Adresse funktioniert und der Name nicht, macht der Tunnel seine Arbeit, und die Korrektur gehört in die Resolver-Reihenfolge, die Suchdomäne oder die eigene Konfiguration des Containers.