SMB-deling fejler kun over VPN: signering eller subnetsammenfald?

Et tilknyttet drev, der virker på kontoret og får timeout derhjemme, giver dig næsten ingen brugbar information i sig selv. Tunnelen transporterer tydeligvis pakker, ellers ville intet nå serveren. Det, der fejlede, ligger i et af tre lag: navnet blev opløst til den forkerte adresse, klienten nægtede at signere sessionen, eller en gammel session overlevede den forbindelse, der bar den. Hvert lag har sin egen reparation, og to af de tre ligger på klientsiden.

Tre fejl bærer samme fejlmeddelelse

Drevbogstavet fortæller ikke, hvilket lag der brast, og fejlteksten er normalt generisk nok til at passe på alle tre. Skeln dem med to hurtige spørgsmål: svarer serveren på sin IP-adresse, og accepterer port 445 en forbindelse?

De svar giver en beslutningstabel i stedet for et gæt. Virker IP men ikke navnet, peger det på navneopløsningen. Virker begge, men logon afvises, peger det på signeringen. Virker begge, men en fillæsning hænger efter et tunneludfald, peger det på en forældet session.

Arbejd dig igennem dem i den rækkefølge, for et navn, der peger på den forkerte vært, gør enhver senere test meningsløs.

Opløs navnet, før du rører delingen

Hvis serveren svarer på sin adresse, og delingsnavnet får timeout, gør tunnelen sit arbejde, og klienten leder det forkerte sted. Ved fjernadgang forklarer to årsager det meste af dette.

Den første er adresseoverlap. Når kontoret bruger 192.168.70.0/24, og hjemmerouteren uddeler samme interval, kan et værtsnavn, der opløses til 192.168.70.20, pege på en lokal enhed i stedet for serveren bag tunnelen. Windows kan derefter sende anmodningen lokalt, afvise ruten eller opløse til en printer, der tilfældigvis har den adresse. Reparationen er at omnummerere den ene side, ikke at tilføje endnu en rute.

Den anden er DNS-omfang. En VPN-adapter uden intern DNS-server, eller med en, der ikke kan nås gennem tunnelen, lader korte navne gå til en offentlig resolver. Læs adapterens DNS-poster, og forespørg det interne navn direkte, før du rører delingen:

> 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

Hvis den forespørgsel returnerer den forventede adresse, er opløsningen afklaret, og problemet ligger højere oppe i stakken.

Læs signeringskravet i begge ender

En nåbar server, der afviser hver logon, er kendetegnet på en politikafvigelse snarere end en netværksfejl. Windows kan kræve SMB-signering på klienten, og en server eller NAS, der ikke signerer, kan ikke gennemføre sessionen, uanset hvor sund tunnelen er.

Du kan læse klientindstillingen uden at lede i politikeditoren:

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

Den tilsvarende værdi på serversiden findes i serverens SMB-konfiguration, og de to skal stemme overens. I et rapporteret tilfælde havde klienten kravet slået til via lokal politik, mens serveren slet ikke signerede, og at slå det fra plus køre gpupdate /force gendannede delingen med det samme. Det er et diagnostisk skridt for at bekræfte årsagen, ikke en permanent løsning.

Foretræk at slå signering til i begge ender, hvor serveren understøtter det. Ændring af en sikkerhedsindstilling for at få en deling til at virke bør registreres med den tidligere værdi og årsagen, så ingen skal genopdage den ved næste revision.

Ryd den forældede session, før du justerer timere

En deling, der først hænger, efter at VPN’en falder og genopretter, holder normalt en session, som serveren allerede har kasseret. Serveren lukker inaktive SMB-sessioner med Autodisconnect-timeren under LanmanServer\Parameters, som standard er 15 minutter, mens klienten har sin egen SessTimeout under LanmanWorkstation\Parameters. Et udfald længere end de værdier efterlader hver ende med en forskellig opfattelse af sessionen.

Genskab det i fast rækkefølge, så resultatet betyder noget: tilslut tunnelen, åbn delingen, afbryd tunnelen i to minutter, genopret den, og prøv derefter at læse en fil. Hvis monteringen kommer sig af sig selv, så lad timerne være. Hvis den hænger, indtil du monterer igen, så genopret delingen, efter at tunnelen er oppe i stedet for at montere den, før den findes, og kontroller, om monteringshjælperen prøver igen.

At hæve timeouts er et rimeligt sidste skridt for en ustabil forbindelse, men det behandler symptomet. En klient, der venter længere på en session, som serveren har glemt, venter stadig.

Afslut med at læse en fil gennem monteringen og derefter afbryde og genoprette tunnelen endnu en gang. Den accepttest dækker alle tre lag på én gang, og det er den eneste test, der svarer til, hvad brugeren faktisk gør.