Navegue pelas unidades de rede mapeadas quando conectado via VPN

1

Tenho usuários que viajam constantemente fora do escritório.

Internamente, eles mapearam unidades de rede.

Eles então vão para fora e se conectam via VPN, que quando conectados conectam e os colocam na mesma sub-rede. Eles podem pingar recursos na rede pela VPN sem qualquer problema.

Quando eles tentam se conectar à mesma unidade de rede pelo nome, leva muito tempo para se conectar e, em seguida, informa que o nome do compartilhamento não pode ser encontrado.

Os detalhes são os seguintes:

  1. Internamente, tudo funciona bem
  2. Estou executando o WINS no servidor ao qual eles estão tentando se conectar.
  3. Este servidor WINS é fornecido nas opções de DHCP para clientes VPN
  4. O DNS é fornecido na opção DHCP para clientes VPN Para ligações do adaptador
  5. Em propriedades do adaptador de rede de clientes do Windows 7, assegurei que as conexões remotas são a principal prioridade sobre conexões locais
  6. Se a conexão por endereço IP for usada, ela funcionará, mas falhará ao se conectar pelo nome da máquina

Que outras etapas devo tentar resolver acima?

    
por g18c 30.08.2012 / 07:03

3 respostas

2

Você está tomando cuidado para usar a mesma nomenclatura ao solucionar problemas como ao se conectar ao compartilhamento de rede? Por exemplo, você está pingando:

ping servername.domain

Mas conectando-se a um compartilhamento de servidor:

\servername\share

Se você conseguir fazer ping com um fqdn, tente configurar os compartilhamentos de rede do usuário da mesma maneira. Eu já vi problemas antes, onde não especificar o nome do domínio quando na VPN tenta acessar a rede local do usuário.

Também estou curioso para saber se você está obtendo um IP externo ao fazer o ping dos recursos da rede. Eu vi conexões VPN para uma rede que é o domínio do Windows também é o site da empresa, e ping servername.domain.com acaba recebendo um resultado de um servidor web pega-tudo em vez do recurso interno.

    
por 30.08.2012 / 18:18
0

As coisas óbvias primeiro: Nos casos em que isso acontece, há perda significativa de pacotes na conexão VPN? Tente executar o ping com o aumento do tamanho do pacote:

ping -l 1200 servername.your.internal.domain

Eu fiz uma experiência ruim mesmo com pequena perda de pacotes (~ 1-10%) e muitas retransmissões TCP na conexão que transporta a carga útil SMB (portas tcp / 445 e tcp / 139 no lado do servidor).

O outro é a resolução de nomes: a primeira solução seria tentar uma conexão de rede usando o endereço IP do servidor em vez do nome. Então deixe alguém tentar

net use X: \10.0.1.200\sharename

e veja se isso acontece.

Se isso "consertar", observe a resolução de nomes de perto. Não tenho certeza sobre o WINS, mas talvez desconfigure isso e tente confiar no DNS. Qual é o servidor de nomes DNS primário e secundário ( ipconfig /all )? verifique se ambos fornecem o endereço IP correto:

nslookup servername.your.internal.domain 10.0.1.1
nslookup servername.your.internal.domain 10.0.1.2

(10.0.1.1 e 10.0.1.2 seriam os servidores DNS)

Talvez o Windows tente uma conexão por meio do IPv6 e que seja silenciosamente descartado? Tente desativar temporariamente o protocolo IPv6 nos adaptadores ativos.

Boa sorte!

    
por 30.08.2012 / 17:55
-2

Uma maneira rápida e suja de corrigir isso seria usar o arquivo hosts.ini.

Localização:

\ Windows \ system32 \ drivers \ etc \

Certifique-se de editar como administrador na máquina.

Comece na parte inferior e adicione os servidores de que eles precisam para se conectar. Digite o endereço IP privado, clique na guia e digite o nome de domínio totalmente qualificado (FQDN). Em seguida, salve.

O usuário agora deve poder se conectar ao servidor usando o nome.

Se você preferir não usar o arquivo Hosts.ini, verifique como a máquina remota está lidando com o DNS. Mais do que provável, é aí que está o problema.

    
por 30.08.2012 / 17:40