En agemount Laufwierk, dat am Büro funktionéiert an doheem an den Timeout leeft, gëtt fir sech selwer bal keng nëtzlech Informatioun. Den Tunnel transportéiert kloer Paketen, soss géif näischt de Server erreechen. Wat fehlgeschloen ass, läit an enger vun dräi Schichten: den Numm gouf op déi falsch Adress opgeléist, de Client huet refuséiert d'Sessioun z'ënnerschreiwen, oder eng al Sessioun huet d'Verbindung iwwerlieft, déi se gedroen huet. Jiddwereng huet eng aner Reparatur, an zwou vun den dräi si clientseiteg.

Dräi Feelere droen déiselwecht Fehlermeldung

De Laufwierksbuschtaf seet net, wéi eng Schicht gebrach ass, an den Feelertext ass meeschtens allgemeng genuch fir op all dräi ze passen. Trennt se mat zwou séiere Froen: äntwert de Server op senger IP-Adress, an hëlt Port 445 eng Verbindung un?

Déi Äntwerten erginn eng Entscheedungstabell amplaz engem Guess. Wann IP funktionéiert an den Numm net, weist dat op d'Nummopliesung. Wann dat zweemol funktionéiert an de Login ofgelehnt gëtt, weist dat op d'Ënnerschrëft. Wann dat zweemol funktionéiert an e Fichierliesen nom Tunnelausfall hänkt, weist dat op eng al Sessioun.

SymptomLayer to inspect
IP works, hostname times outDNS or subnet overlap
TCP 445 opens, logon refusedSMB signing policy
Hangs after reconnectSession state and timers

Schafft se an där Reihenfolg of, well en Numm, deen op de falschen Host opgeléist gëtt, all spéideren Test bedeitungslos mécht.

Léist den Numm op, ier Dir d'Deelung beréiert

Wann de Server op senger Adress äntwert an den Deelungsnumm an den Timeout leeft, mécht den Tunnel seng Aarbecht an de Client sicht op der falscher Plaz. Beim Fernzougang erklären zwou Ursaachen de meeschten Deel dovun.

Déi éischt ass eng Adressiwwerlappung. Wann de Büro 192.168.70.0/24 benotzt an den Heemrouter deeselwechten Beräich vergëtt, kann en Hostnumm, deen op 192.168.70.20 opgeléist gëtt, op en lokalen Apparat weisen amplaz op de Server hannert dem Tunnel. Windows kann d'Ufro dann lokal schécken, d'Route refuséieren oder op en Drécker opléisen, deen zoufälleg déi Adress huet. D'Reparatur ass eng Säit nei ze nummeréieren, net eng aner Route bäizefügen.

Déi zweet ass den DNS-Beräich. En VPN-Adapter ouni internen DNS-Server, oder mat engem, deen duerch den Tunnel net erreechbar ass, léisst kuerz Nimm op e ëffentleche Resolver goen. Liest dem Adapter seng DNS-Andräg an a frot den internen Numm direkt, ier Dir d'Deelung beréiert:

> 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

Wann déi Ufro déi erwaart Adress zréckgëtt, ass d'Nummopliesung gekläert an de Problem läit méi héich am Stack.

Liest d'Ënnerschrëftsfuerderung op béide Säiten

En erreechbare Server, deen all Login ofleent, ass d'Zeeche vun enger Richtlinnendivergenz an net vun engem Netzwierkfehler. Windows kann d'SMB-Ënnerschrëft um Client fuerderen, an en Server oder NAS, deen net ënnerschreift, kann d'Sessioun net ofschléissen, egal wéi gesond den Tunnel ass.

Dir kënnt d'Client-Astellung liesen, ouni de Richtlinneneditor ze duerchsichen:

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

De passende Wäert op der Serversäit steet an der SMB-Konfiguratioun vum Server, an déi zwéin mussen iwwereneestëmmen. An engem gemellte Fall hat de Client d'Fuerderung duerch lokal Richtlinn ageschalt, wärend de Server guer net ënnerschriwwen huet; d'Deaktivéieren an e spontantt gpupdate /force huet d'Deelung direkt erëmbruecht. Dat ass en diagnostesche Schrëtt fir d'Ursaach ze bestätegen, keng permanent Léisung.

Bevirzugt d'Ënnerschrëft op béide Säiten anzeschalten, wou de Server et ënnerstëtzt. D'Ännerung vun enger Sécherheetsastellung, fir eng Deelung ze fonctionéieren, soll mat hirem virege Wäert an dem Grond dokumentéiert ginn, sou datt kee se beim nächsten Audit erëm entdecke muss.

Rumt déi al Sessioun op, ier Dir d'Timer justéiert

Eng Deelung, déi nëmmen hänkt, nodeems d'VPN fält a sech erëm verbënnt, hält meeschtens eng Sessioun, déi de Server schonn decidéiert huet. De Server schléisst inaktiv SMB-Sessiounen um Autodisconnect-Timer ënner LanmanServer\Parameters, deen standardméisseg 15 Minutten ass, wärend de Client säin eegenen SessTimeout ënner LanmanWorkstation\Parameters huet. En Ausfall, deen méi laang wéi déi Wäerter dauert, léisst béid Säiten mat engem anere Bild vun der Sessioun.

Reproduzéiert et an enger fester Reihenfolg, sou datt d'Resultat eppes bedeit: verbënnt den Tunnel, öffnet d'Deelung, trennt den Tunnel fir zwou Minutten, stellt en erëm hier, a probéiert dann eng Datei ze liesen. Wann d'Montage sech selwer erholle kritt, loosst d'Timer a Rou. Wann et hänkt, bis Dir nei montéiert, verbënnt d'Deelung nei, nodeems den Tunnel steet amplaz se ze montéieren, ier se existéiert, a kontrolléiert, ob den Montagehëllef nach eng Kéier probéiert.

Timeouten ze erhéijen ass eng raisonnabel lescht Schrëtt fir eng onbestänneg Verbindung, awer et behandelt de Symptom. En Client, dee méi laang op eng Sessioun waart, déi de Server vergiess huet, waart nach ëmmer.

Schléisst of, andeems Dir eng Datei iwwer d'Montage liest an dann den Tunnel nach eng Kéier trennt an erëm hierstellt. Dee Akzeptanztest deckt all dräi Schichten gläichzäiteg of, an et ass den eenzegen Test, deen deem entsprécht, wat de Benotzer tatsächlech mécht.

Ähnlech Artikelen