Compartilhamento SMB falha apenas pela VPN: assinatura ou conflito de sub-rede?

Uma unidade mapeada que funciona no escritório e expira em casa não diz quase nada de útil por si só. O túnel está claramente a transportar pacotes, ou nada chegaria ao servidor. O que falhou está numa de três camadas: o nome foi resolvido para o endereço errado, o cliente recusou-se a assinar a sessão, ou uma sessão antiga sobreviveu à ligação que a transportava. Cada uma tem uma reparação diferente, e duas das três estão do lado do cliente.

Três falhas carregam o mesmo erro

A letra da unidade não diz qual camada falhou, e o texto do erro costuma ser genérico o suficiente para servir às três. Separe-as com duas perguntas rápidas: o servidor responde pelo endereço IP, e a porta 445 aceita uma ligação?

Essas respostas produzem uma tabela de decisão em vez de um palpite. Se o IP funciona e o nome não, o problema é a resolução. Se ambos funcionam e o início de sessão é recusado, o problema é a assinatura. Se ambos funcionam e uma leitura de ficheiro bloqueia após uma queda do túnel, o problema é uma sessão obsoleta.

Percorra-as nessa ordem, porque um nome que se resolve para o anfitrião errado torna inútil qualquer teste posterior.

Resolva o nome antes de tocar no compartilhamento

Se o servidor responde no seu endereço e o nome do compartilhamento expira, o túnel está a fazer o seu trabalho e o cliente está a procurar no lugar errado. No acesso remoto, duas causas explicam a maior parte disto.

A primeira é uma sobreposição de endereços. Quando o escritório usa 192.168.70.0/24 e o router de casa entrega o mesmo intervalo, um nome de anfitrião que se resolve em 192.168.70.20 pode apontar para um dispositivo local em vez do servidor atrás do túnel. O Windows pode então enviar o pedido localmente, recusar a rota, ou resolver para uma impressora que por acaso tem esse endereço. A reparação é renumerar um lado, não acrescentar outra rota.

A segunda é o âmbito DNS. Um adaptador VPN sem servidor DNS interno, ou com um inalcançável através do túnel, deixa os nomes curtos irem para um resolver público. Leia as entradas DNS do adaptador e consulte o nome interno diretamente antes de tocar no compartilhamento:

> 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 essa consulta devolver o endereço esperado, a resolução está esclarecida e o problema está mais acima na pilha.

Leia o requisito de assinatura nas duas pontas

Um servidor acessível que recusa todos os inícios de sessão é o sinal de um desalinhamento de política e não de uma falha de rede. O Windows pode exigir a assinatura SMB no cliente, e um servidor ou NAS que não assina não consegue completar a sessão, por muito saudável que esteja o túnel.

Pode ler a definição do cliente sem percorrer o editor de políticas:

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

O valor correspondente do lado do servidor está na configuração SMB do servidor, e os dois têm de concordar. Num caso reportado, o cliente tinha o requisito ativado por política local enquanto o servidor não assinava de todo, e desativá-lo e executar gpupdate /force restaurou o compartilhamento de imediato. É um passo de diagnóstico para confirmar a causa, não uma correção permanente.

Prefira ativar a assinatura nas duas pontas onde o servidor a suporta. Alterar uma definição de segurança para pôr um compartilhamento a funcionar deve ser registado com o valor anterior e o motivo, para que ninguém tenha de o redescobrir na próxima auditoria.

Limpe a sessão obsoleta antes de ajustar os temporizadores

Um compartilhamento que só bloqueia depois de a VPN cair e voltar a ligar costuma manter uma sessão que o servidor já descartou. O servidor fecha as sessões SMB inativas com o temporizador Autodisconnect em LanmanServer\Parameters, que por omissão são 15 minutos, enquanto o cliente tem o seu próprio SessTimeout em LanmanWorkstation\Parameters. Uma queda mais longa do que esses valores deixa cada ponta com uma ideia diferente da sessão.

Reproduza-o numa ordem fixa para que o resultado signifique alguma coisa: ligue o túnel, abra o compartilhamento, corte o túnel durante dois minutos, restabeleça-o e tente ler um ficheiro. Se a montagem recuperar sozinha, deixe os temporizadores em paz. Se bloquear até voltar a montar, volte a ligar o compartilhamento depois de o túnel estar de pé em vez de o montar antes de existir, e verifique se o assistente de montagem tenta novamente.

Aumentar os tempos limite é um último passo razoável para uma ligação instável, mas trata o sintoma. Um cliente que espera mais tempo por uma sessão que o servidor esqueceu continua à espera.

Termine lendo um ficheiro através da montagem e depois cortando e restabelecendo o túnel mais uma vez. Esse teste de aceitação cobre as três camadas de uma vez, e é o único que corresponde ao que o utilizador faz de facto.