Opção 1: Transmitindo para o servidor
Uma solução conceitualmente simples, mas difícil de implementar, é conectar seu laptop usando um adaptador TAP VPN em vez de um TUN e conectá-lo à interface LAN do servidor VPN. Do ponto de vista do laptop, ele está diretamente conectado ao mesmo segmento que o servidor de arquivos.
No entanto, existem desvantagens além da complexidade, e você realmente está tentando fazer com que um protocolo baseado em broadcast funcione de uma maneira que não foi projetada.
Opção 2: resolução de nomes locais
Se estiver interessado apenas em poder digitar o caminho UNC ( \Server1\share
) e não navegar na rede local / grupo de trabalho, então, um LMHOSTS arquivo no seu laptop deve ser tudo o que é necessário.
Quando você digita um caminho UNC para um servidor, o cliente Windows verifica em quatro locais (ordem dependendo da configuração atual e da versão) ignorando aqueles que estão desabilitados / não configurados:
- Um servidor WINS, que possui entradas dinâmicas ou estáticas para o destino. Como o destino, neste caso, não é um dispositivo Windows, você precisa configurá-lo para saber onde o servidor WINS está, se quiser entradas dinâmicas ou configurar as entradas estáticas. O WINS aqui é o protocolo, uma vez que o serviço WINS em si só está disponível no Windows Server, você pode configurá-lo usando o Samba, mas pode não valer a pena o esforço.
- Uma transmissão para a rede local "Alguém usa o nome
Server1
?". Por design, essa transmissão não cruza roteadores (ou seja, seu servidor VPN). - Uma consulta ao servidor DNS, possivelmente adicionando o sufixo DNS da rede local "Você sabe quem é
Server1
? Que talServer1.atmyhome.local
?". - Um arquivo LMHOSTS, que fornece as mesmas informações que uma transmissão local ou uma consulta WINS, mas a partir do disco, para que esteja sempre disponível, consistente e rápido.
Como você tem uma implantação pequena, e ela será alterada muito raramente, a abordagem LMHOSTS parece ser a melhor.