Partilhas de rede não aparecem numa VPN? A descoberta para

A partilha abre quando escreve o caminho, e o navegador de rede não mostra nada. Essa combinação é comum num túnel e normalmente não é avaria. A descoberta pergunta ao segmento local; a acessibilidade pergunta a um único anfitrião. Um túnel encaminhado transporta a segunda e não a primeira.

A descoberta e a acessibilidade são separadas

Uma lista de navegação é produzida por protocolos que anunciam serviços a um segmento local e escutam esses anúncios. Abrir uma partilha pelo nome é uma ligação direta a um único anfitrião. A primeira precisa de um domínio de difusão ou multidifusão; a segunda precisa de uma rota e uma porta.

Por um túnel, a segunda pode funcionar na perfeição enquanto a primeira devolve uma janela vazia. Tratar a janela vazia como a avaria leva-o a procurar um túnel avariado que está a fazer o seu trabalho.

Porque é que a lista de navegação fica vazia

O Windows retirou o serviço Computer Browser e desativou o SMB versão 1 por predefinição, o que removeu a maquinaria por trás do antigo Ambiente de Rede. Substitutos como WS-Discovery, SSDP e DNS multicast dirigem-se a grupos de difusão ou multidifusão que só existem numa ligação local. Um túnel ponto a ponto não tem essa ligação, e os routers não reencaminham esses grupos por predefinição. Todos os anfitriões podem estar acessíveis e a lista pode continuar vazia.

Alguns programas acrescentam o seu próprio assistente de descoberta. Quando esse assistente funciona, é uma funcionalidade do programa, não uma propriedade do túnel.

Use nomes explícitos e depois confirme o acesso

Um caminho UNC, uma unidade mapeada ou uma ligação do Finder a um endereço SMB funciona pelo túnel assim que o nome é resolvido e a porta está aberta. A resolução pode vir do DNS, de um sufixo de pesquisa fornecido pela VPN ou de uma entrada hosts gerida centralmente. Num domínio, uma consulta ao diretório pode listar objetos de computador, e essa lista costuma ser o substituto mais próximo de uma vista de navegação numa rede encaminhada. Uma análise de portas de prefixos conhecidos só é aceitável em redes que administra ou para as quais está explicitamente autorizado a testar.

Um anfitrião que responde não promete que a partilha abra. Um NAS pode ter uma lista de permitidos limitada à sua própria sub-rede, que rejeita endereços do conjunto VPN. A regra de firewall de um servidor de ficheiros pode nomear apenas a sub-rede local. A conta que fornece para a partilha pode ser uma conta local que nunca foi criada nesse servidor, e ligar-se pela VPN não a cria.

Alguns programas empresariais bloqueiam deliberadamente o tráfego local e o de máquinas virtuais enquanto o túnel está ativo. Esse acesso em falta é política, e a correção pertence ao administrador, não à tabela de rotas do programa.

Uma ordem de diagnóstico que vale a pena repetir

Percorra as camadas por ordem: alcance o endereço, resolva o nome, abra a porta 445, autentique-se e depois leia as permissões da partilha. Cada resposta é separada, e saltar à frente produz uma conclusão errada com confiança. Só depois de todas passarem vale a pena investigar a descoberta.

nslookup fileserver.example.com
nc -vz fileserver.example.com 445
smbclient -L //fileserver.example.com -U EXAMPLE/jdoe

Deixe uma nota com o nome do servidor, o caminho da partilha, o endereço para que foi resolvido e a conta que funcionou. Se a lista de navegação mais tarde se preencher após reiniciar um serviço, trate isso como uma esquisitice da descoberta e não como prova de que a rota anterior estava errada. A nota é o que permite à pessoa seguinte saltar a janela vazia.