SMB-gästinloggning via VPN: Windows vill fortfarande ha en identitet
En fungerande VPN-tunnel gör inte en anonym SMB-inloggning autentiserad. Läs klientpolicyn, bekräfta händelse 31017 och använd sedan ett namngivet dela-konto.
Att ansluta till kontorets VPN gör filservern nåbar och ändå nekar delningen åtkomst, vilket inbjuder till slutsatsen att tunneln är trasig. Oftast är den inte det. SMB autentiserar varje session för sig och Windows har successivt skärpt vad det accepterar som anonym inloggning. En nätverkssökväg och en användaridentitet är olika krav, och det är den andra som felet handlar om.
Varför tunneln inte kan ersätta en SMB-identitet
Att dela ett subnät med en server har aldrig inneburit tillstånd att läsa dess filer; det tar bara bort routingproblemet. Windows registrerar händelse 31017 när dess klient blockerar en osäker gästinloggning, och det är ett beslut som fattas på din maskin och inte på servern. Tunneln transporterar SMB-paketen troget medan gästsessionen avvisas. Därför fungerar en bärbar dator på identiska hemmanätverk och en annan inte.
Behandla händelsen som bevis på en policy, inte som ett nätverksfel. Rättelsen ligger i identiteten eller i enheten.
Läs klientpolicyn och avvisningshändelsen
Två utdata avgör frågan snabbt: den effektiva klientkonfigurationen och de senaste avvisningshändelserna.
Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017En falsk gästinställning kombinerad med ett krav på signering förklarar felet innan någon ytterligare undersökning. Händelseloggen bekräftar att klienten avvisade sessionen, inte att servern avvisade en autentiseringsuppgift. Notera delningssökvägen och kontot som användes vid ett lyckat försök på en annan maskin, eftersom en cachelagrad session kan få två tester att se identiska ut när de inte är det. Rensa befintliga anslutningar med net use innan du jämför, så att en gammal session inte svarar för den nya.
Använd ett namngivet konto och behåll signeringen
Den hållbara lösningen är ett konto som servern känner till, angivet uttryckligen, med policyn för signering och kryptering orörd. Ange autentiseringsuppgiften på anslutningen i stället för att skriva ett slumpmässigt namn i dialogrutan.
net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnectionEn namngiven inloggning ger en session som servern kan granska, och Get-SmbConnection visar dialekten och om signeringen är aktiv. Gästsessioner kan inte uppfylla krav på signering eller kryptering, så en gästflagga kan inte rädda en policy som kräver dem. Där en äldre enhet saknar kontomodell ska gäståtkomst behandlas som ett uttryckligen dokumenterat undantag med en utbytesplan. Försvaga inte signeringen för varje anslutning för att tillgodose en enda enhet.
När enheten bara känner till gäst
Vissa konsument-NAS-lådor exponerar delningar utan något kontobegrepp, vilket lämnar två ärliga alternativ: isolera enheten eller byta ut den. Placera den på ett segment utan rutt till något känsligt och låt inte ett bekvämlighetsundantag bli standard för hela klienten. En gästdelning med säkerhetskopior eller autentiseringsuppgifter är ett problem med dataexponering och inte en Windows-irritation. Om en firmwareuppdatering lägger till användarkonton är det det billigare långsiktiga svaret.
Registrera det accepterade kontot och policyvärdena i ärendet. Annars kör nästa person tunneltestet igen och hamnar i samma avvisning.