Accesso ospite SMB tramite VPN: Windows vuole ancora un'identità

Collegarsi alla VPN dell'ufficio rende raggiungibile il file server e la condivisione continua comunque a negare l'accesso, il che porta a concludere che il tunnel sia guasto. Di solito non lo è. SMB autentica ogni sessione separatamente, e Windows ha reso sempre più rigido ciò che accetta come accesso anonimo. Un percorso di rete e un'identità utente sono requisiti diversi, e l'errore riguarda il secondo.

Perché il tunnel non può sostituire un'identità SMB

Condividere una sottorete con un server non ha mai implicato il permesso di leggerne i file; elimina solo il problema di routing. Windows registra l'evento 31017 quando il suo client blocca un accesso ospite non sicuro, ed è una decisione presa sulla tua macchina, non sul server. Il tunnel trasporta fedelmente i pacchetti SMB mentre la sessione ospite viene rifiutata. Ecco perché un portatile su reti domestiche identiche funziona e un altro no.

Tratta l'evento come prova di un criterio, non come guasto di rete. La correzione sta nell'identità o nell'apparecchio.

Leggi i criteri del client e l'evento di rifiuto

Due output risolvono la questione rapidamente: la configurazione effettiva del client e gli eventi di rifiuto recenti.

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017

Un'impostazione ospite falsa combinata con un requisito di firma spiega il guasto prima di qualsiasi indagine ulteriore. Il registro eventi conferma che il client ha rifiutato la sessione, non che il server abbia rifiutato una credenziale. Annota il percorso della condivisione e l'account usati in un tentativo riuscito su un'altra macchina, perché una sessione in cache può far sembrare identici due test che non lo sono. Cancella le connessioni esistenti con net use prima di confrontare, così che una vecchia sessione non risponda al posto della nuova.

Usa un account con nome e mantieni la firma

La soluzione duratura è un account che il server conosce, fornito esplicitamente, con i criteri di firma e crittografia lasciati intatti. Fornisci la credenziale sulla connessione invece di digitare un nome casuale nella finestra di dialogo.

net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnection

Un accesso con nome produce una sessione che il server può verificare, e Get-SmbConnection mostra il dialetto e se la firma è attiva. Le sessioni ospite non possono soddisfare i requisiti di firma o crittografia, quindi abilitare un flag ospite non può salvare criteri che li impongono. Dove un apparecchio legacy non ha un modello di account, tratta l'accesso ospite come un'eccezione esplicita e documentata con un piano di sostituzione. Non indebolire la firma su ogni connessione per accontentare un solo dispositivo.

Quando l'apparecchio parla solo ospite

Alcuni box NAS consumer espongono condivisioni senza alcun concetto di account, il che lascia due opzioni oneste: isolare l'apparecchio o sostituirlo. Mettilo su un segmento senza rotta verso nulla di sensibile e non lasciare che un'eccezione di comodità diventi l'impostazione predefinita per l'intero client. Una condivisione ospite con backup o credenziali è un problema di esposizione dei dati, non un fastidio di Windows. Se un aggiornamento del firmware aggiunge account utente, quella è la risposta più economica a lungo termine.

Registra l'account accettato e i valori dei criteri nel ticket. Altrimenti la persona successiva rieseguirà il test del tunnel e arriverà allo stesso rifiuto.