SMB-deling feilar berre over VPN: signering eller subnettkollisjon?

Ein tilordna stasjon som fungerer på kontoret og får tidsavbrot heime, gjev deg nesten ingen nyttig informasjon i sjølv. Tunnelen fraktar tydeleg pakkar, elles ville ingenting nå serveren. Det som feila, ligg i eitt av tre lag: namnet vart slått opp til feil adresse, klienten nekta å signere økta, eller ei gamal økt overlevde sambandet som bar ho. Kvart lag har si eiga reparasjon, og to av tre ligg på klientsida.

Tre feil ber same feilmelding

Stasjonsbokstaven seier ikkje kva lag som braut, og feilteksten er vanlegvis generisk nok til å passe alle tre. Skil dei med to raske spørsmål: svarar serveren på IP-adressa si, og tek port 445 imot ei tilkopling?

Svara gjev ein beslutningstabell i staden for ei gjetning. Verkar IP men ikkje namnet, peikar det på namneoppslaget. Verkar begge, men pålogging vert avvist, peikar det på signeringa. Verkar begge, men ei fillesing heng etter eit tunnelutfall, peikar det på ei gamal økt.

Arbeid deg gjennom dei i den rekkjefølgja, for eit namn som peikar på feil vert gjer kvar seinare test meiningslaus.

Slå opp namnet før du rører delinga

Viss serveren svarar på adressa si og delingsnamnet får tidsavbrot, gjer tunnelen jobben sin, og klienten leitar på feil stad. Ved fjernaksess forklarer to årsaker det meste av dette.

Den første er adresseoverlapp. Når kontoret brukar 192.168.70.0/24 og heimerutaren deler ut same område, kan eit vertsnamn som vert slått opp til 192.168.70.20 peike på eit lokalt apparat i staden for serveren bak tunnelen. Windows kan då sende førespurnaden lokalt, avvise ruta eller slå opp til ein skrivar som tilfeldigvis har den adressa. Reparasjonen er å nummerere om éi side, ikkje å leggje til ei anna rute.

Den andre er DNS-omfang. Ein VPN-adapter utan intern DNS-server, eller med ein som ikkje er tilgjengeleg gjennom tunnelen, lèt korte namn gå til ein offentleg resolver. Les DNS-oppføringane til adapteren og spør direkte etter det interne namnet før du rører delinga:

> 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

Viss det oppslaget returnerer den forventa adressa, er oppslaget avklart, og problemet ligg høgare oppe i stakken.

Les signeringskravet i begge endar

Ein nåbar server som avviser kvar pålogging, er kjenneteiknet på eit policyavvik snarare enn ein nettverksfeil. Windows kan krevje SMB-signering på klienten, og ein server eller NAS som ikkje signerer, kan ikkje fullføre økta, uansett kor sunn tunnelen er.

Du kan lese klientinnstillinga utan å leite i policyeditoren:

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

Den tilsvarande verdien på serversida finst i SMB-konfigurasjonen til serveren, og dei to må vere samde. I eitt rapportert tilfelle hadde klienten kravet slått på via lokal policy medan serveren ikkje signerte i det heile, og å slå det av pluss køyre gpupdate /force gjenoppretta delinga med det same. Det er eit diagnostisk steg for å stadfeste årsaka, ikkje ei permanent løysing.

Føretrekk å slå på signering i begge endar der serveren støttar det. Endring av ei sikkerheitsinnstilling for å få ei deling til å verke bør registrerast med den tidlegare verdien og årsaka, slik at ingen må gjenoppdage henne ved neste revisjon.

Tøm den gamle økta før du justerer tidsavbrota

Ei deling som først heng etter at VPN-en fell og koplar til igjen, held vanlegvis ei økt som serveren allereie har forkasta. Serveren lukkar inaktive SMB-økter med Autodisconnect-timeren under LanmanServer\Parameters, som standard er 15 minutt, medan klienten har sin eigen SessTimeout under LanmanWorkstation\Parameters. Eit utfall lengre enn dei verdiane lèt kvar ende sitje att med ei ulik oppfatning av økta.

Reproduser det i fast rekkjefølgje slik at resultatet betyr noko: kople til tunnelen, opne delinga, bryt tunnelen i to minutt, gjenopprett han og prøv deretter å lese ei fil. Viss monteringa kjem seg av seg sjølv, la timerane vere. Viss ho heng til du monterer på nytt, kople til delinga igjen etter at tunnelen er oppe i staden for å montere henne før ho finst, og sjekk om monteringshjelparen prøver på nytt.

Å auke tidsavbrota er eit rimeleg siste steg for ei ustabil linje, men det behandlar symptomet. Ein klient som ventar lengre på ei økt som serveren har gløymt, ventar framleis.

Avslutt med å lese ei fil gjennom monteringa og deretter bryte og gjenopprette tunnelen ein gong til. Den aksepttesten dekkjer alle tre laga på ein gong, og det er den einaste testen som svarar til det brukaren faktisk gjer.