SMB-Freigabe scheitert nur über VPN: Signierung oder Subnetz-Konflikt?

Ein zugeordnetes Laufwerk, das im Büro funktioniert und zu Hause in einen Timeout läuft, liefert für sich genommen fast keine brauchbare Information. Der Tunnel transportiert offensichtlich Pakete, sonst würde überhaupt nichts den Server erreichen. Was ausgefallen ist, liegt auf einer von drei Ebenen: Der Name wurde zur falschen Adresse aufgelöst, der Client verweigerte die Signierung der Sitzung, oder eine alte Sitzung überlebte die Verbindung, die sie getragen hat. Jede hat eine andere Reparatur, und zwei der drei liegen auf Client-Seite.

Drei Fehler tragen dieselbe Meldung

Der Laufwerksbuchstabe sagt nicht, welche Ebene kaputt ist, und der Fehlertext ist meist allgemein genug, um auf alle drei zu passen. Trennen Sie sie mit zwei schnellen Fragen: Antwortet der Server unter seiner IP-Adresse, und nimmt Port 445 eine Verbindung an?

Diese Antworten ergeben eine Entscheidungstabelle statt einer Vermutung. IP funktioniert und der Name nicht, deutet auf die Auflösung. Beides funktioniert und die Anmeldung wird abgelehnt, deutet auf die Signierung. Beides funktioniert und ein Lesezugriff hängt nach einem Tunnelausfall, deutet auf eine veraltete Sitzung.

Arbeiten Sie sie in dieser Reihenfolge ab, denn ein Name, der auf den falschen Host zeigt, macht jeden späteren Test bedeutungslos.

Lösen Sie den Namen auf, bevor Sie die Freigabe anfassen

Wenn der Server unter seiner Adresse antwortet und der Freigabename in einen Timeout läuft, erledigt der Tunnel seine Aufgabe und der Client sucht an der falschen Stelle. Beim Fernzugriff erklären zwei Ursachen den größten Teil davon.

Die erste ist eine Adressüberschneidung. Wenn das Büro 192.168.70.0/24 verwendet und der Heimrouter denselben Bereich vergibt, kann ein Hostname, der auf 192.168.70.20 aufgelöst wird, auf ein lokales Gerät statt auf den Server hinter dem Tunnel zeigen. Windows sendet die Anfrage dann möglicherweise lokal, lehnt die Route ab oder löst auf einen Drucker auf, der zufällig diese Adresse hat. Die Reparatur besteht darin, eine Seite neu zu nummerieren, nicht darin, eine weitere Route hinzuzufügen.

Die zweite ist der DNS-Bereich. Ein VPN-Adapter ohne internen DNS-Server oder mit einem, der durch den Tunnel nicht erreichbar ist, lässt kurze Namen an einen öffentlichen Resolver gehen. Lesen Sie die DNS-Einträge des Adapters und fragen Sie den internen Namen direkt ab, bevor Sie die Freigabe anfassen:

> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15

Wenn diese Abfrage die erwartete Adresse zurückgibt, ist die Auflösung geklärt und das Problem liegt weiter oben im Stack.

Lesen Sie die Signierungsanforderung auf beiden Seiten

Ein erreichbarer Server, der jede Anmeldung ablehnt, ist das Kennzeichen einer Richtlinienabweichung und nicht eines Netzwerkfehlers. Windows kann SMB-Signierung auf dem Client verlangen, und ein Server oder NAS, der nicht signiert, kann die Sitzung nicht abschließen, egal wie gesund der Tunnel ist.

Sie können die Client-Einstellung lesen, ohne sich durch den Richtlinieneditor zu suchen:

> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnection

Der passende Wert auf Serverseite steht in der SMB-Konfiguration des Servers, und beide müssen übereinstimmen. In einem gemeldeten Fall hatte der Client die Anforderung per lokaler Richtlinie aktiviert, während der Server überhaupt nicht signierte; das Deaktivieren und ein anschließendes gpupdate /force brachte die Freigabe sofort zurück. Das ist ein diagnostischer Schritt, um die Ursache zu bestätigen, keine dauerhafte Lösung.

Bevorzugen Sie es, die Signierung an beiden Enden einzuschalten, wo der Server sie unterstützt. Das Ändern einer Sicherheitseinstellung, damit eine Freigabe funktioniert, sollte mit ihrem vorherigen Wert und dem Grund dokumentiert werden, damit niemand sie beim nächsten Audit neu entdecken muss.

Räumen Sie die veraltete Sitzung auf, bevor Sie Timer justieren

Eine Freigabe, die erst hängt, nachdem das VPN getrennt und wieder verbunden wurde, hält meist eine Sitzung, die der Server bereits verworfen hat. Der Server schließt untätige SMB-Sitzungen über den Autodisconnect-Timer unter LanmanServer\Parameters, der standardmäßig 15 Minuten beträgt, während der Client seinen eigenen SessTimeout unter LanmanWorkstation\Parameters hat. Ein Ausfall, der länger als diese Werte dauert, hinterlässt an beiden Enden eine unterschiedliche Vorstellung von der Sitzung.

Reproduzieren Sie es in einer festen Reihenfolge, damit das Ergebnis etwas bedeutet: Tunnel verbinden, Freigabe öffnen, Tunnel für zwei Minuten trennen, ihn wiederherstellen und dann versuchen, eine Datei zu lesen. Wenn das Laufwerk von selbst zurückkommt, lassen Sie die Timer in Ruhe. Wenn es hängt, bis Sie neu einbinden, verbinden Sie die Freigabe neu, nachdem der Tunnel steht, statt sie vorher einzubinden, und prüfen Sie, ob der Einbindungshelfer es erneut versucht.

Timeouts zu erhöhen ist ein vernünftiger letzter Schritt bei einer instabilen Verbindung, aber es behandelt das Symptom. Ein Client, der länger auf eine Sitzung wartet, die der Server vergessen hat, wartet trotzdem.

Schließen Sie ab, indem Sie eine Datei über das Laufwerk lesen und den Tunnel noch einmal trennen und wiederherstellen. Dieser Abnahmetest deckt alle drei Ebenen auf einmal ab, und er ist der einzige Test, der dem entspricht, was der Nutzer tatsächlich tut.