Inici de sessió de convidat SMB per VPN: Windows encara vol una identitat
Un túnel VPN que funciona no fa autenticat un inici de sessió SMB anònim. Llegeix la política del client, confirma l'esdeveniment 31017 i després fes servir un compte de compartició amb nom.
Connectar-se a la VPN de l'oficina fa que el servidor de fitxers sigui abastable i, tot i així, la compartició continua rebutjant l'accés, cosa que convida a concloure que el túnel està espatllat. Normalment no ho està. SMB autentica cada sessió per separat, i Windows ha anat endurint què accepta com a inici de sessió anònim. Un camí de xarxa i una identitat d'usuari són requisits diferents, i l'error tracta del segon.
Per què el túnel no pot substituir una identitat SMB
Compartir una subxarxa amb un servidor mai no ha implicat permís per llegir-ne els fitxers; només elimina el problema d'encaminament. Windows registra l'esdeveniment 31017 quan el seu client bloca un inici de sessió de convidat insegur, i això és una decisió presa a la teva màquina, no al servidor. El túnel transporta els paquets SMB fidelment mentre es rebutja la sessió de convidat. Per això un portàtil en xarxes domèstiques idèntiques funciona i un altre no.
Tracta l'esdeveniment com a prova d'una política, no com una avaria de xarxa. La solució és a la identitat o a l'aparell.
Llegeix la política del client i l'esdeveniment de rebuig
Dues sortides resolen la qüestió de pressa: la configuració efectiva del client i els esdeveniments de rebuig recents.
Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017Un paràmetre de convidat fals combinat amb un requisit de signatura explica la fallada abans de qualsevol investigació addicional. El registre d'esdeveniments confirma que el client va rebutjar la sessió, no que el servidor rebutgés una credencial. Anota el camí de la compartició i el compte emprats en un intent que funcioni en una altra màquina, perquè una sessió en memòria cau pot fer que dues proves semblin idèntiques quan no ho són. Neteja les connexions existents amb net use abans de comparar, perquè una sessió antiga no respongui per la nova.
Fes servir un compte amb nom i mantén la signatura
La solució duradora és un compte que el servidor conegui, proporcionat explícitament, amb la política de signatura i xifratge intacta. Proporciona la credencial a la connexió en lloc d'escriure un nom a l'atzar al diàleg.
net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnectionUn inici de sessió amb nom produeix una sessió que el servidor pot auditar, i Get-SmbConnection mostra el dialecte i si la signatura està activa. Les sessions de convidat no poden satisfer els requisits de signatura o xifratge, així que activar un indicador de convidat no pot salvar una política que els exigeix. Quan un aparell antic no té model de comptes, tracta l'accés de convidat com una excepció explícita i documentada amb un pla de substitució. No debilitis la signatura a totes les connexions per encabir un sol dispositiu.
Quan l'aparell només parla de convidat
Alguns equips NAS de consum exposen comparticions sense cap concepte de compte, cosa que deixa dues opcions honestes: aïllar l'aparell o substituir-lo. Posa'l en un segment sense ruta a res sensible i no deixis que una excepció de comoditat esdevingui el valor per defecte de tot el client. Una compartició de convidat amb còpies de seguretat o credencials és un problema d'exposició de dades, no una molèstia de Windows. Si una actualització de firmware afegeix comptes d'usuari, aquesta és la resposta més barata a llarg termini.
Registra el compte acceptat i els valors de la política al tiquet. Si no, la persona següent tornarà a executar la prova del túnel i arribarà al mateix rebuig.