SMB-deling feiler bare over VPN: signering eller subnettkollisjon?

En tilordnet stasjon som fungerer på kontoret og får tidsavbrudd hjemme, gir deg nesten ingen nyttig informasjon i seg selv. Tunnelen frakter tydeligvis pakker, ellers ville ingenting nå serveren. Det som feilet, ligger i ett av tre lag: navnet ble slått opp til feil adresse, klienten nektet å signere økten, eller en gammel økt overlevde forbindelsen som bar den. Hvert lag har sin egen reparasjon, og to av tre ligger på klientsiden.

Tre feil bærer samme feilmelding

Stasjonsbokstaven sier ikke hvilket lag som brast, og feilteksten er vanligvis generisk nok til å passe alle tre. Skill dem med to raske spørsmål: svarer serveren på IP-adressen sin, og tar port 445 imot en tilkobling?

Svarene gir en beslutningstabell i stedet for en gjetning. Virker IP men ikke navnet, peker det på navneoppslaget. Virker begge, men pålogging avvises, peker det på signeringen. Virker begge, men en fillesing henger etter et tunnelutfall, peker det på en gammel økt.

Arbeid deg gjennom dem i den rekkefølgen, for et navn som peker på feil vert gjør hver senere test meningsløs.

Slå opp navnet før du rører delingen

Hvis serveren svarer på adressen sin og delingsnavnet får tidsavbrudd, gjør tunnelen jobben sin, og klienten leter på feil sted. Ved fjernaksess forklarer to årsaker det meste av dette.

Den første er adresseoverlapp. Når kontoret bruker 192.168.70.0/24 og hjemmeruteren deler ut samme område, kan et vertsnavn som slås opp til 192.168.70.20 peke på en lokal enhet i stedet for serveren bak tunnelen. Windows kan da sende forespørselen lokalt, avvise ruten eller slå opp til en skriver som tilfeldigvis har den adressen. Reparasjonen er å nummerere om én side, ikke å legge til en annen rute.

Den andre er DNS-omfang. En VPN-adapter uten intern DNS-server, eller med en som ikke er tilgjengelig gjennom tunnelen, lar korte navn gå til en offentlig resolver. Les adapterens DNS-oppføringer og spør direkte etter det interne navnet 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 det oppslaget returnerer den forventede adressen, er oppslaget avklart, og problemet ligger høyere opp i stakken.

Les signeringskravet i begge ender

En nåbar server som avviser hver pålogging, er kjennetegnet på en policyavvikelse snarere enn en nettverksfeil. Windows kan kreve SMB-signering på klienten, og en server eller NAS som ikke signerer, kan ikke fullføre økten, uansett hvor sunn tunnelen er.

Du kan lese klientinnstillingen uten å lete i policyeditoren:

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

Den tilsvarende verdien på serversiden finnes i serverens SMB-konfigurasjon, og de to må være enige. I ett rapportert tilfelle hadde klienten kravet slått på via lokal policy mens serveren ikke signerte i det hele tatt, og å slå det av pluss kjøre gpupdate /force gjenopprettet delingen umiddelbart. Det er et diagnostisk trinn for å bekrefte årsaken, ikke en permanent løsning.

Foretrekk å slå på signering i begge ender der serveren støtter det. Endring av en sikkerhetsinnstilling for å få en deling til å virke bør registreres med den tidligere verdien og årsaken, slik at ingen må gjenoppdage den ved neste revisjon.

Tøm den gamle økten før du justerer tidsavbruddene

En deling som først henger etter at VPN-en faller og kobler til igjen, holder vanligvis en økt som serveren allerede har forkastet. Serveren lukker inaktive SMB-økter med Autodisconnect-timeren under LanmanServer\Parameters, som standard er 15 minutter, mens klienten har sin egen SessTimeout under LanmanWorkstation\Parameters. Et utfall lengre enn de verdiene etterlater hver ende med en forskjellig oppfatning av økten.

Reproduser det i fast rekkefølge slik at resultatet betyr noe: koble til tunnelen, åpne delingen, bryt tunnelen i to minutter, gjenopprett den og prøv deretter å lese en fil. Hvis monteringen kommer seg av seg selv, la timerne være. Hvis den henger til du monterer på nytt, koble til delingen igjen etter at tunnelen er oppe i stedet for å montere den før den finnes, og sjekk om monteringshjelperen prøver på nytt.

Å øke tidsavbruddene er et rimelig siste trinn for en ustabil linje, men det behandler symptomet. En klient som venter lenger på en økt som serveren har glemt, venter fortsatt.

Avslutt med å lese en fil gjennom monteringen og deretter bryte og gjenopprette tunnelen én gang til. Den aksepttesten dekker alle tre lagene på én gang, og det er den eneste testen som samsvarer med det brukeren faktisk gjør.