Inicio de sesión de invitado SMB por VPN: Windows sigue queriendo una identidad

Conectarse a la VPN de la oficina hace que el servidor de archivos sea accesible y, aun así, el recurso compartido sigue negando el acceso, lo que invita a concluir que el túnel está roto. Normalmente no lo está. SMB autentica cada sesión por separado, y Windows ha ido endureciendo qué acepta como inicio de sesión anónimo. Una ruta de red y una identidad de usuario son requisitos distintos, y el error trata del segundo.

Por qué el túnel no puede sustituir una identidad SMB

Compartir una subred con un servidor nunca implicó permiso para leer sus archivos; solo elimina el problema de enrutamiento. Windows registra el evento 31017 cuando su cliente bloquea un inicio de sesión de invitado inseguro, y esa es una decisión tomada en su máquina, no en el servidor. El túnel transporta los paquetes SMB fielmente mientras se rechaza la sesión de invitado. Por eso un portátil en redes domésticas idénticas funciona y otro no.

Trate el evento como prueba de una política, no como una avería de red. La solución está en la identidad o en el dispositivo.

Lea la política del cliente y el evento de rechazo

Dos salidas resuelven la cuestión rápidamente: la configuración efectiva del cliente y los eventos de rechazo recientes.

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

Un parámetro de invitado falso combinado con un requisito de firma explica el fallo antes de cualquier investigación adicional. El registro de eventos confirma que el cliente rechazó la sesión, no que el servidor rechazara una credencial. Anote la ruta del recurso y la cuenta usadas en un intento correcto en otra máquina, porque una sesión en caché puede hacer que dos pruebas parezcan idénticas cuando no lo son. Limpie las conexiones existentes con net use antes de comparar, para que una sesión antigua no responda por la nueva.

Use una cuenta con nombre y mantenga la firma

La solución duradera es una cuenta que el servidor conozca, facilitada explícitamente, con la política de firma y cifrado intacta. Proporcione la credencial en la conexión en lugar de escribir un nombre al azar en el diálogo.

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

Un inicio de sesión con nombre produce una sesión que el servidor puede auditar, y Get-SmbConnection muestra el dialecto y si la firma está activa. Las sesiones de invitado no pueden cumplir los requisitos de firma o cifrado, así que activar un indicador de invitado no puede salvar una política que los exige. Cuando un dispositivo heredado no tiene modelo de cuentas, trate el acceso de invitado como una excepción explícita y documentada con un plan de sustitución. No debilite la firma en todas las conexiones para acomodar un solo dispositivo.

Cuando el dispositivo solo habla de invitado

Algunos equipos NAS de consumo exponen recursos compartidos sin ningún concepto de cuenta, lo que deja dos opciones honestas: aislar el dispositivo o sustituirlo. Póngalo en un segmento sin ruta a nada sensible y no deje que una excepción de comodidad se convierta en el valor predeterminado de todo el cliente. Un recurso de invitado con copias de seguridad o credenciales es un problema de exposición de datos y no una molestia de Windows. Si una actualización de firmware añade cuentas de usuario, esa es la respuesta más barata a largo plazo.

Registre la cuenta aceptada y los valores de la política en el tique. De lo contrario, la siguiente persona repetirá la prueba del túnel y llegará al mismo rechazo.