El recurso compartido SMB falla solo por VPN: ¿firma o conflicto de subred?

Una unidad asignada que funciona en la oficina y expira en casa no le dice casi nada útil por sí sola. El túnel transporta paquetes con claridad, o no llegaría nada al servidor. Lo que falló está en una de tres capas: el nombre se resolvió a la dirección equivocada, el cliente se negó a firmar la sesión, o una sesión antigua sobrevivió a la conexión que la transportaba. Cada una tiene una reparación distinta, y dos de las tres están del lado del cliente.

Tres fallos llevan el mismo error

La letra de unidad no le dice qué capa se rompió, y el texto del error suele ser lo bastante genérico para encajar en las tres. Sepárelas con dos preguntas rápidas: ¿responde el servidor por dirección IP, y el puerto 445 acepta una conexión?

Esas respuestas producen una tabla de decisión en lugar de una conjetura. Si la IP funciona y el nombre no, el problema es la resolución. Si ambas funcionan y se rechaza el inicio de sesión, el problema es la firma. Si ambas funcionan y una lectura de archivo se cuelga tras una caída del túnel, el problema es una sesión obsoleta.

Recórralas en ese orden, porque un nombre que se resuelve al host equivocado vuelve inútil toda prueba posterior.

Resuelva el nombre antes de tocar el recurso

Si el servidor responde en su dirección y el nombre del recurso expira, el túnel hace su trabajo y el cliente busca en el lugar equivocado. En acceso remoto, dos causas explican la mayor parte de esto.

La primera es una superposición de direcciones. Cuando la oficina usa 192.168.70.0/24 y el router doméstico entrega el mismo rango, un nombre de host que se resuelve a 192.168.70.20 puede apuntar a un dispositivo local en lugar del servidor tras el túnel. Windows puede entonces enviar la solicitud en local, rechazar la ruta o resolver a una impresora que casualmente tiene esa dirección. La reparación es renumerar un lado, no añadir otra ruta.

La segunda es el alcance de DNS. Un adaptador VPN sin servidor DNS interno, o con uno inalcanzable a través del túnel, deja que los nombres cortos vayan a un resolutor público. Lea las entradas DNS del adaptador y consulte el nombre interno directamente antes de tocar el recurso:

> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15

Si esa consulta devuelve la dirección esperada, la resolución está aclarada y el problema está más arriba en la pila.

Lea el requisito de firma en ambos extremos

Un servidor accesible que rechaza todo inicio de sesión es la firma de un desajuste de directiva y no de un fallo de red. Windows puede exigir la firma SMB en el cliente, y un servidor o NAS que no firma no puede completar la sesión por muy sano que esté el túnel.

Puede leer la configuración del cliente sin recorrer el editor de directivas:

> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnection

El valor correspondiente en el servidor está en la configuración SMB del servidor, y ambos deben coincidir. En un caso reportado, el cliente tenía el requisito activado por directiva local mientras el servidor no firmaba en absoluto, y desactivarlo y ejecutar gpupdate /force restauró el recurso de inmediato. Ese es un paso de diagnóstico para confirmar la causa, no una solución permanente.

Prefiera activar la firma en ambos extremos donde el servidor lo admita. Cambiar un ajuste de seguridad para que un recurso funcione debe registrarse con su valor anterior y el motivo, para que nadie tenga que redescubrirlo en la próxima auditoría.

Limpie la sesión obsoleta antes de ajustar los temporizadores

Un recurso que solo se cuelga tras caer y reconectar la VPN suele retener una sesión que el servidor ya descartó. El servidor cierra las sesiones SMB inactivas con el temporizador Autodisconnect en LanmanServer\Parameters, que por defecto son 15 minutos, mientras el cliente tiene su propio SessTimeout en LanmanWorkstation\Parameters. Una caída más larga que esos valores deja a cada extremo con una idea distinta de la sesión.

Repródúzcalo en un orden fijo para que el resultado signifique algo: conecte el túnel, abra el recurso, corte el túnel dos minutos, restablézcalo y luego intente leer un archivo. Si el montaje se recupera solo, deje los temporizadores en paz. Si se cuelga hasta que vuelve a montar, reconecte el recurso una vez levantado el túnel en lugar de montarlo antes de que exista, y compruebe si el asistente de montaje reintenta.

Subir los tiempos de espera es un último paso razonable para un enlace inestable, pero trata el síntoma. Un cliente que espera más tiempo una sesión que el servidor ha olvidado sigue esperando.

Termine leyendo un archivo a través del montaje y luego cortando y restableciendo el túnel una vez más. Esa prueba de aceptación cubre las tres capas a la vez, y es la única que coincide con lo que el usuario hace en realidad.