SMB-delning misslyckas bara över VPN: signering eller subnätskrock?

En mappad enhet som fungerar på kontoret och får timeout hemma ger dig nästan ingen användbar information i sig. Tunneln transporterar uppenbarligen paket, annars skulle inget nå servern. Det som misslyckades ligger i ett av tre lager: namnet löstes till fel adress, klienten vägrade signera sessionen, eller en gammal session överlevde anslutningen som bar den. Varje lager har en egen reparation, och två av tre ligger på klientsidan.

Tre fel bär samma felmeddelande

Enhetsbokstaven säger inte vilket lager som brast, och feltexten är oftast allmän nog att passa alla tre. Skilj dem med två snabba frågor: svarar servern på sin IP-adress, och tar port 445 emot en anslutning?

De svaren ger en beslutstabell i stället för en gissning. Fungerar IP men inte namnet pekar det på namnuppslagningen. Fungerar båda men avvisas inloggningen pekar det på signeringen. Fungerar båda men hänger en filläsning efter ett tunnelavbrott pekar det på en gammal session.

Arbeta igenom dem i den ordningen, för ett namn som pekar på fel värd gör varje senare test meningslöst.

Lös namnet innan du rör delningen

Om servern svarar på sin adress och delningsnamnet får timeout gör tunneln sitt jobb och klienten letar på fel ställe. Vid fjärråtkomst förklarar två orsaker det mesta av detta.

Den första är adressöverlapp. När kontoret använder 192.168.70.0/24 och hemroutern delar ut samma intervall kan ett värdnamn som löses till 192.168.70.20 peka på en lokal enhet i stället för servern bakom tunneln. Windows kan då skicka begäran lokalt, avvisa rutten eller lösa till en skrivare som råkar ha den adressen. Reparationen är att numrera om ena sidan, inte att lägga till en annan rutt.

Den andra är DNS-omfång. En VPN-adapter utan intern DNS-server, eller med en som inte går att nå via tunneln, låter korta namn gå till en offentlig resolver. Läs adapterns DNS-poster och fråga det interna namnet direkt innan du rör delningen:

> 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

Om den frågan returnerar den förväntade adressen är namnuppslagningen avklarad och problemet ligger högre upp i stacken.

Läs signeringskravet i båda ändar

En nåbar server som avvisar varje inloggning är kännetecknet på en policyavvikelse snarare än ett nätverksfel. Windows kan kräva SMB-signering på klienten, och en server eller NAS som inte signerar kan inte slutföra sessionen, hur frisk tunneln än är.

Du kan läsa klientinställningen utan att söka i principeditorn:

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

Motsvarande värde på serversidan finns i serverns SMB-konfiguration, och de två måste stämma överens. I ett rapporterat fall hade klienten kravet påslaget via lokal princip medan servern inte signerade alls, och att stänga av det plus köra gpupdate /force återställde delningen direkt. Det är ett diagnostiskt steg för att bekräfta orsaken, inte en permanent åtgärd.

Föredra att slå på signering i båda ändar där servern stöder det. Att ändra en säkerhetsinställning för att få en delning att fungera bör dokumenteras med det tidigare värdet och orsaken, så att ingen behöver upptäcka den igen vid nästa revision.

Rensa den gamla sessionen innan du justerar tidsgränser

En delning som bara hänger sig efter att VPN:et faller och återansluter håller oftast en session som servern redan har kastat. Servern stänger inaktiva SMB-sessioner med Autodisconnect-timern under LanmanServer\Parameters, som standard är 15 minuter, medan klienten har sin egen SessTimeout under LanmanWorkstation\Parameters. Ett avbrott längre än de värdena lämnar varje ände med en annan bild av sessionen.

Reproducera det i fast ordning så att resultatet betyder något: anslut tunneln, öppna delningen, koppla ner tunneln i två minuter, återställ den och försök sedan läsa en fil. Om monteringen återhämtar sig själv, låt timrarna vara. Om den hänger sig tills du monterar om, återanslut delningen efter att tunneln är uppe i stället för att montera den innan den finns, och kontrollera om monteringshjälparen försöker igen.

Att höja tidsgränserna är ett rimligt sista steg för en instabil länk, men det behandlar symtomet. En klient som väntar längre på en session som servern har glömt väntar fortfarande.

Avsluta med att läsa en fil genom monteringen och sedan koppla ner och återställa tunneln en gång till. Det acceptanstestet täcker alla tre lagren på en gång, och det är det enda test som motsvarar vad användaren faktiskt gör.