O recurso compartido SMB falla só por VPN: sinatura ou conflito de subrede?

Unha unidade asignada que funciona na oficina e caduca na casa non lle dá case ningunha información útil por si mesma. O túnel transporta paquetes con claridade, ou nada chegaría ao servidor. O que fallou está nunha de tres capas: o nome resolveuse ao enderezo incorrecto, o cliente negouse a asinar a sesión, ou unha sesión antiga sobreviviu á conexión que a levaba. Cada unha ten unha reparación distinta, e dúas das tres están do lado do cliente.

Tres fallos levan o mesmo erro

A letra da unidade non di que capa se rompeu, e o texto do erro adoita ser o bastante xenérico para encaixar nas tres. Sepáreas con dúas preguntas rápidas: responde o servidor no seu enderezo IP, e acepta o porto 445 unha conexión?

Eses respostas producen unha táboa de decisión en lugar dunha conxectura. Se o IP funciona e o nome non, apunta á resolución de nomes. Se ambos funcionan e rexéitase o inicio de sesión, apunta á sinatura. Se ambos funcionan e a lectura dun ficheiro colga tras unha caída do túnel, apunta a unha sesión antiga.

Percórreas nesa orde, porque un nome que se resolve ao servidor incorrecto fai que toda proba posterior careza de sentido.

Resolva o nome antes de tocar o recurso

Se o servidor responde no seu enderezo e o nome do recurso caduca, o túnel está a facer o seu traballo e o cliente busca no lugar incorrecto. No acceso remoto, dúas causas explican a maior parte disto.

A primeira é un solapamento de enderezos. Cando a oficina usa 192.168.70.0/24 e o router doméstico entrega o mesmo rango, un nome de host que se resolve a 192.168.70.20 pode apuntar a un dispositivo local en lugar do servidor detrás do túnel. Windows pode entón enviar a solicitude en local, rexeitar a ruta ou resolvela a unha impresora que casualmente ten ese enderezo. A reparación é renumerar un lado, non engadir outra ruta.

A segunda é o ámbito de DNS. Un adaptador VPN sen servidor DNS interno, ou cun inalcanzable a través do túnel, deixa que os nomes curtos vaian a un resolvedor público. Lea as entradas DNS do adaptador e consulte o nome interno directamente antes de tocar o 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

Se esa consulta devolve o enderezo esperado, a resolución de nomes está aclarada e o problema está máis arriba na pila.

Lea o requisito de sinatura en ambos extremos

Un servidor accesible que rexeita todos os inicios de sesión é o sinal dun desaxuste de política e non dun fallo de rede. Windows pode esixir a sinatura SMB no cliente, e un servidor ou NAS que non asina non pode completar a sesión, por moi san que estea o túnel.

Pode ler a configuración do cliente sen percorrer o editor de políticas:

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

O valor correspondente no servidor está na configuración SMB do servidor, e ambos deben coincidir. Nun caso reportado, o cliente tiña o requisito activado por política local mentres o servidor non asinaba en absoluto; desactivalo e executar gpupdate /force restaurou o recurso de inmediato. Ese é un paso de diagnóstico para confirmar a causa, non unha solución permanente.

Preferide activar a sinatura en ambos extremos onde o servidor o admite. Cambiar un axuste de seguridade para que funcione un recurso debe rexistrarse co seu valor anterior e o motivo, para que ninguén teña que redescubrilo na próxima auditoría.

Limpe a sesión antiga antes de axustar os temporizadores

Un recurso que só colga despois de que a VPN cae e se reconecta adoita manter unha sesión que o servidor xa descartou. O servidor pecha as sesións SMB inactivas co temporizador Autodisconnect en LanmanServer\Parameters, que por defecto son 15 minutos, mentres o cliente ten o seu propio SessTimeout en LanmanWorkstation\Parameters. Unha caída máis longa que eses valores deixa a cada extremo cunha idea distinta da sesión.

Reproduzao nunha orde fixa para que o resultado signifique algo: conecte o túnel, abra o recurso, corte o túnel durante dous minutos, restablézao e despois intente ler un ficheiro. Se a montaxe se recupera soa, deixe os temporizadores en paz. Se colga ata que volve montar, reconecte o recurso unha vez levantado o túnel en lugar de montalo antes de que exista, e comprobe se o asistente de montaxe reintenta.

Subir os tempos de espera é un último paso razoable para unha ligazón inestable, pero trata o síntoma. Un cliente que espera máis tempo unha sesión que o servidor esqueceu segue esperando.

Remate lendo un ficheiro a través da montaxe e despois cortando e restablecendo o túnel unha vez máis. Esa proba de aceptación cobre as tres capas á vez, e é a única que coincide co que o usuario fai realmente.