Inicio de sesión de convidado SMB por VPN: Windows segue querendo unha identidade

Conectarse á VPN da oficina fai que o servidor de ficheiros sexa accesible e, aínda así, a compartición segue negando o acceso, o que invita a concluír que o túnel está roto. Normalmente non o está. SMB autentica cada sesión por separado, e Windows foi endurecendo o que acepta como inicio de sesión anónimo. Unha ruta de rede e unha identidade de usuario son requisitos distintos, e o erro trata do segundo.

Por que o túnel non pode substituír unha identidade SMB

Compartir unha subrede cun servidor nunca implicou permiso para ler os seus ficheiros; só elimina o problema de encamiñamento. Windows rexistra o evento 31017 cando o seu cliente bloquea un inicio de sesión de convidado inseguro, e esa é unha decisión tomada na súa máquina, non no servidor. O túnel transporta os paquetes SMB fielmente mentres se rexeita a sesión de convidado. Por iso un portátil en redes domésticas idénticas funciona e outro non.

Trate o evento como proba dunha política, non como unha avaría de rede. A solución está na identidade ou no dispositivo.

Lea a política do cliente e o evento de rexeitamento

Dúas saídas resolven a cuestión rapidamente: a configuración efectiva do cliente e os eventos de rexeitamento recentes.

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

Un parámetro de convidado falso combinado cun requisito de sinatura explica o fallo antes de calquera investigación adicional. O rexistro de eventos confirma que o cliente rexeitou a sesión, non que o servidor rexeitase unha credencial. Anote a ruta da compartición e a conta usadas nun intento correcto noutra máquina, porque unha sesión en caché pode facer que dúas probas parezan idénticas cando non o son. Limpe as conexións existentes con net use antes de comparar, para que unha sesión antiga non responda pola nova.

Use unha conta con nome e manteña a sinatura

A solución duradeira é unha conta que o servidor coñeza, proporcionada explicitamente, coa política de sinatura e cifrado intacta. Proporcione a credencial na conexión en lugar de escribir un nome ao azar no diálogo.

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

Un inicio de sesión con nome produce unha sesión que o servidor pode auditar, e Get-SmbConnection mostra o dialecto e se a sinatura está activa. As sesións de convidado non poden cumprir os requisitos de sinatura ou cifrado, así que activar un indicador de convidado non pode salvar unha política que os esixe. Cando un dispositivo antigo non ten modelo de contas, trate o acceso de convidado como unha excepción explícita e documentada cun plan de substitución. Non debilite a sinatura en todas as conexións para acomodar un só dispositivo.

Cando o dispositivo só fala de convidado

Algúns equipos NAS de consumo expoñen comparticións sen ningún concepto de conta, o que deixa dúas opcións honestas: illar o dispositivo ou substituílo. Póñao nun segmento sen ruta a nada sensible e non deixe que unha excepción de comodidade se converta no valor predeterminado de todo o cliente. Unha compartición de convidado con copias de seguridade ou credenciais é un problema de exposición de datos e non unha molestia de Windows. Se unha actualización de firmware engade contas de usuario, esa é a resposta máis barata a longo prazo.

Rexiste a conta aceptada e os valores da política no tícket. Se non, a seguinte persoa repetirá a proba do túnel e chegará ao mesmo rexeitamento.