Unidade mapeada através de uma VPN site: DNS, SMB e o caminho UNC

A página Rede do Explorador mostra os dispositivos que se anunciaram no segmento local, e um túnel encaminhado não transporta nenhum desses anúncios. Por isso um servidor pode estar perfeitamente acessível enquanto a janela à frente do utilizador permanece vazia. Um caminho UNC nomeado não depende de todo da descoberta, e a solução é fazer com que o nome resolva e a porta responda. A janela vazia é um sintoma da camada errada, não de uma partilha avariada.

Descobrir não é o mesmo que alcançar

O Windows descobre máquinas próximas através de protocolos concebidos para um domínio de difusão e depois apresenta o que encontrou como uma lista de conveniência. Nada nessa lista é necessário para aceder a ficheiros por SMB. Um cliente que conhece o nome do servidor e alcança TCP 445 abrirá a partilha, apareça ou não a máquina alguma vez em Rede.

As duas camadas falham de forma independente, e por isso "não o vejo" e "não consigo abri-lo" merecem testes diferentes. Olhar para a lista diz algo sobre a descoberta; abrir o caminho diz algo sobre o serviço.

Nomeie o servidor antes de mapear a partilha

Publique o servidor de ficheiros no DNS com o endereço que tem do outro lado e aponte o site do cliente para um resolver que consiga responder por essa zona. Um nome totalmente qualificado evita depender de uma lista local de sufixos de pesquisa, que é a razão habitual para um nome curto funcionar num site e falhar noutro.

Se o ambiente usar Active Directory, a resolução de nomes também faz parte da autenticação: o cliente tem de alcançar um controlador de domínio para o Kerberos, e um relógio demasiado desfasado fará falhar a troca de bilhetes. Isso é um problema diferente da acessibilidade SMB e parece um erro de credenciais. Teste o controlador de domínio antes de voltar a escrever a palavra-passe.

Encaminhar e filtrar nos dois sentidos

Um túnel site a site precisa do prefixo remoto na tabela de rotas local e do prefixo local na remota, e a firewall de cada lado tem de permitir o tráfego que chega. Uma configuração unilateral produz uma ligação que abre e nunca responde, o que os utilizadores descrevem como a partilha estar lenta. Verifique primeiro os contadores do próprio túnel. Se os pacotes saem e nada volta, procure a rota de retorno ou o filtro remoto.

Com o WireGuard, os IP permitidos do par e as rotas do sistema operativo têm de concordar com esse desenho. O túnel transporta pacotes; não fornece registos DNS nem permissões de partilha em nenhum dos lados.

Baseie a regra de firewall na rede de origem real que se vai ligar e anote a exceção. Se o desenho traduzir endereços em algum ponto do caminho, a regra tem de usar a origem traduzida, e o endereço original do cliente já não é visível nos registos.

Autentique-se e depois mapeie a unidade

Percorra as camadas com comandos em vez de com a janela do Explorador:

Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:no

O segundo comando prova o caminho TCP, não o direito a ler nada. O terceiro é onde a autenticação e a autorização são exercidas, e uma falha aí deve encaminhá-lo para as permissões da partilha e do sistema de ficheiros, e não de volta para o router.

Mantenha intactas a assinatura SMB e a política de autenticação existente. Reativar o SMB1 ou reencaminhar difusões de descoberta pelo túnel não é necessário para um caminho explícito, e o TCP 445 deve ficar no caminho privado e não num reencaminhamento exposto à internet. Dê aos utilizadores um atalho gerido ou uma unidade mapeada para o nome aprovado, e a página Rede vazia deixa de importar.