Início de sessão de convidado SMB por VPN: o Windows continua a exigir uma identidade

Ligar-se à VPN do escritório torna o servidor de ficheiros acessível e, mesmo assim, a partilha continua a negar o acesso, o que leva à conclusão de que o túnel está avariado. Normalmente não está. O SMB autentica cada sessão em separado, e o Windows tem vindo a tornar mais rigoroso o que aceita como início de sessão anónimo. Um caminho de rede e uma identidade de utilizador são requisitos diferentes, e o erro diz respeito ao segundo.

Porque o túnel não pode substituir uma identidade SMB

Partilhar uma sub-rede com um servidor nunca implicou permissão para ler os seus ficheiros; apenas remove o problema de encaminhamento. O Windows registra o evento 31017 quando o seu cliente bloqueia um início de sessão de convidado inseguro, e essa é uma decisão tomada na sua máquina, não no servidor. O túnel transporta os pacotes SMB fielmente enquanto a sessão de convidado é recusada. É por isso que um portátil em redes domésticas idênticas funciona e outro não.

Trate o evento como prova de uma política, não como uma avaria de rede. A correção está na identidade ou no aparelho.

Leia a política do cliente e o evento de recusa

Duas saídas resolvem a questão rapidamente: a configuração efetiva do cliente e os eventos de recusa recentes.

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

Uma definição de convidado falsa combinada com um requisito de assinatura explica a falha antes de qualquer investigação adicional. O registo de eventos confirma que o cliente recusou a sessão, e não que o servidor recusou uma credencial. Anote o caminho da partilha e a conta usados numa tentativa bem-sucedida noutra máquina, porque uma sessão em cache pode fazer duas provas parecerem idênticas quando não o são. Limpe as ligações existentes com net use antes de comparar, para que uma sessão antiga não responda pela nova.

Use uma conta com nome e mantenha a assinatura

A solução duradoura é uma conta que o servidor conhece, fornecida explicitamente, com a política de assinatura e cifragem intacta. Forneça a credencial na ligação em vez de escrever um nome ao acaso na caixa de diálogo.

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

Um início de sessão com nome produz uma sessão que o servidor pode auditar, e Get-SmbConnection mostra o dialeto e se a assinatura está ativa. As sessões de convidado não conseguem satisfazer requisitos de assinatura ou cifragem, por isso ativar um indicador de convidado não pode salvar uma política que os exige. Onde um aparelho antigo não tem modelo de contas, trate o acesso de convidado como uma exceção explícita e documentada com um plano de substituição. Não enfraqueça a assinatura em todas as ligações para acomodar um único dispositivo.

Quando o aparelho só fala de convidado

Algumas caixas NAS de consumo expõem partilhas sem qualquer noção de conta, o que deixa duas opções honestas: isolar o aparelho ou substituí-lo. Coloque-o num segmento sem rota para nada sensível e não deixe que uma exceção de conveniência se torne a predefinição de todo o cliente. Uma partilha de convidado com cópias de segurança ou credenciais é um problema de exposição de dados, não um incómodo do Windows. Se uma atualização de firmware acrescentar contas de utilizador, essa é a resposta mais barata a longo prazo.

Registe a conta aceite e os valores da política no ticket. Caso contrário, a pessoa seguinte voltará a executar o teste do túnel e chegará à mesma recusa.