Eu tenho um PC com Windows 7 na rede da empresa (que é membro do nosso Active Directory). Tudo funciona bem até eu abrir uma conexão VPN no site de um cliente.
Quando me conecto, perco o acesso da rede a compartilhamentos na rede, incluindo diretórios como 'Dados do Aplicativo' para os quais temos uma política de redirecionamento de pastas. Como você pode imaginar, isso torna o trabalho no PC muito difícil, pois os atalhos da área de trabalho param de funcionar, o software para de funcionar corretamente devido à remoção de 'Application Data'.
Nossa rede é roteada (10.58.5.0/24), com outras sub-redes locais existentes no escopo de 10.58.0.0/16. A rede remota está em 192.168.0.0/24.
Rastreei o problema por estar relacionado ao DNS. Assim que abro o túnel da VPN, todo o meu tráfego DNS passa pela rede remota, o que explica a perda de recursos locais, mas minha pergunta é: como forçar as consultas DNS locais a irem para os servidores DNS locais em vez de para os clientes ?
A saída de ipconfig /all
quando não está conectado à VPN está abaixo:
Windows IP Configuration
Host Name . . . . . . . . . . . . : 7k5xy4j
Primary Dns Suffix . . . . . . . : mydomain.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : mydomain.local
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : mydomain.local
Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
Default Gateway . . . . . . . . . : 10.58.5.1
DHCP Server . . . . . . . . . . . : 10.58.3.32
DHCPv6 IAID . . . . . . . . . . . : 250629538
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA
DNS Servers . . . . . . . . . . . : 10.58.3.32
10.58.3.33
NetBIOS over Tcpip. . . . . . . . : Enabled
Esta é a saída do mesmo comando com o túnel da VPN conectado:
Windows IP Configuration
Host Name . . . . . . . . . . . . : 7k5xy4j
Primary Dns Suffix . . . . . . . : mydomain.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : mydomain.local
PPP adapter Customer Domain:
Connection-specific DNS Suffix . : customerdomain.com
Description . . . . . . . . . . . : CustomerDomain
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.0.85(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 192.168.0.16
192.168.0.17
Primary WINS Server . . . . . . . : 192.168.0.17
NetBIOS over Tcpip. . . . . . . . : Disabled
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : mydomain.local
Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
Default Gateway . . . . . . . . . : 10.58.5.1
DHCP Server . . . . . . . . . . . : 10.58.3.32
DHCPv6 IAID . . . . . . . . . . . : 250629538
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA
DNS Servers . . . . . . . . . . . : 10.58.3.32
10.58.3.33
NetBIOS over Tcpip. . . . . . . . : Enabled
Tabela de roteamento
Métrica da interface do gateway de máscara de rede de destino de rede
0.0.0.0 0.0.0.0 10.58.5.1 10.58.5.89 20
10.58.5.0 255.255.255.0 On-link 10.58.5.89 276
10.58.5.89 255.255.255.255 On-link 10.58.5.89 276
10.58.5.255 255.255.255.255 On-link 10.58.5.89 276
91.194.153.42 255.255.255.255 10.58.5.1 10.58.5.89 21
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.0.0 255.255.255.0 192.168.0.95 192.168.0.85 21
192.168.0.85 255.255.255.255 On-link 192.168.0.85 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 10.58.5.89 276
224.0.0.0 240.0.0.0 On-link 192.168.0.85 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 10.58.5.89 276
255.255.255.255 255.255.255.255 On-link 192.168.0.85 276
A ordem de ligação para as interfaces é a seguinte:
Não configurei o túnel da VPN para usar o gateway padrão na extremidade remota, e as comunicações de rede para os nós nas duas redes estão corretas. (ou seja, eu posso executar ping em qualquer nó da nossa rede ou da rede remota).
Modifiquei as propriedades da conexão PPTP para usar os servidores DNS 10.58.3.32
seguidos por 192.168.0.16
, mas a consulta ainda vai para 192.168.0.16.
Editar:
Os recursos locais que desaparecem estão hospedados nas raízes do DFS do domínio, que podem (ou não) ser relevantes.
Edição adicional:
Isso parece afetar apenas as raízes do DFS do domínio. Se eu referenciar o compartilhamento através do nome do servidor (ou seja, em \\server\share
vez de \\dfsroot\share
), posso acessar os compartilhamentos.
De acordo com meu comentário sobre esta resposta , descobri que posso adicionar o nome DNS do domínio ao meu arquivo de hosts, o que impede que minhas unidades de rede (DFS) desapareçam, mas ainda assim gostaria da parte mais ousada da minha pergunta (acima ) respondendo se alguém tiver alguma idéia.
route print
(da conexão VPN) à postagem?Respostas:
OK, encontrei um ótimo recurso aqui: http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/
Não é perfeito, mas pode funcionar.
fonte
powershell -File c:\scripts\fixdnsbind.ps1
) que contém:$val = Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind; $val.Bind += "\Device\{D7D0BD5E-B65C-4239-BA4D-D309186E9524}"; Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind -Value $val.Bind
. (não esqueça de adaptar o ID do adaptador). Você também executa esse script uma vez antes de se conectar à VPN.Parece-me que o túnel da VPN, de alguma forma, tem precedência sobre a interface da área local, direcionando o tráfego DNS para os servidores DNS da VPN (você pode verificar a solicitação nesses servidores para verificar esse comportamento se tiver acesso a eles ou alguém puder verificar esse comportamento para você).
Isso não posso explicar inteiramente, pois a ordem de ligação indica de maneira diferente. De acordo com esta postagem aqui (veja a resposta de pontuação mais alta), o Windows tem uma percepção diferente quando se trata disso, escolhendo um canal de prioridade mais alta dependendo da velocidade da conexão, NÃO da ordem de ligação do adaptador. Portanto, para testar, tente o seguinte para alterar esse comportamento automático: 1) vá para Conexões de rede e, para cada um, faça 2) Propriedades do IP v4 3) Avançado 4) Desative a "Métrica automática" 5) Coloque manualmente uma métrica de 1 para o seu local conexão e uma métrica de 2 na sua conexão VPN (PPP). Dessa forma, ele meio que ligará o caminho para os servidores DNS locais, de preferência ao DNS remoto.
Espero que isto ajude!
fonte
Como afirmado, esse é um problema de tunelamento dividido.
Três correções, recomende o número 2 porque é fácil e terá bom desempenho se você usar uma boa caixa com o VMware Workstation 8
1 - Ativar tunelamento dividido - inseguro e pode exigir trabalho do lado do cliente. Não é provável que isso aconteça, a gestapo de segurança de TI o desligará.
2 - Abordagem da área de trabalho virtualizada - P2V sua área de trabalho existente e transformá-lo em uma VM. Use a VM para VPN para o cliente. Você mantém sua área de trabalho e pode alternar para dentro e fora dela, conforme necessário.
3 - Abordagem de servidor virtualizado - P2V seu desktop existente e transformá-lo em uma VM e, em seguida, coloque-o em uma versão gratuita do ESXi. Você mantém sua área de trabalho e pode alternar para a VM conforme necessário por meio de um console. Isso pode ser lento ...
fonte
Infelizmente, a VPN do Windows não pode executar o "DNS Split". No entanto, você pode remover o servidor DNS da conexão VPN depois de se conectar ao site remoto.
Você pode fazer isso emitindo:
Você precisa fazer isso sempre que se conectar à rede VPN.
fonte
nslookup
ainda usa o servidor DNS remoto, além deipconfig
ainda listar o servidor DNS remoto). Também editei as configurações de DNS da conexão de túnel da VPN para usar minhas próprias configurações de DNS interno, mas isso é ignorado, todo o meu tráfego de DNS ainda parece estar indo para o servidor DNS remoto.ipconfig
saída e, quando errei, recebi o erroThe filename, directory name, or volume label syntax is incorrect
), por isso tenho certeza de ter acertado o comando. Pode ser algo no servidor PPTP remoto que não permita que eu substitua a configuração de DNS. Vou investigar, mas gosto da ideia de entrada de arquivo de hosts. Vou tentar. Veja também minha edição da pergunta.ipconfig /all
? Eu acho que, no entanto, a entrada de hosts deve ser a correção mais fácil para você.Seu túnel VPN está entre o cliente e a rede do cliente. Parece que ele não está usando o tunelamento dividido, o que impedirá o acesso a recursos em sua própria rede enquanto o túnel estiver ativo.
Portanto, você (ou seu cliente) precisa ativar o túnel dividido, ou precisa de uma conexão de rede extra e uma tabela de rotas personalizada para acessar as duas redes ao mesmo tempo.
fonte
split tunnelling
para ser honesto, mas, tanto quanto posso dizer, isso envolve apenas garantir que eu não esteja usando o gateway padrão no site remoto, o que, apesar de eu não especificar, já estou fazendo. Obrigado pela resposta, vou editar minha pergunta para refletir isso.Embora essa pergunta tenha sido feita há muito tempo, mas postar essa resposta, pois isso pode ajudar outras pessoas. Eu tive o mesmo problema com a VPN em que quando os usuários costumavam se conectar ao VPN remoto, seus dns externos costumavam parar por exemplo.
google.com
somente domínios de empresa costumavam trabalhar nos quais estavam listadossplit-dns
.O problema era quando a máquina local usada faz o tráfego de consulta de DNS ir para o túnel VPN e se o DNS for permitido no túnel, ele recua. Quando faz o fallback, ele escolhe primeiro o ipv6 como resolução e nunca mais volta ao ipv4.
Portanto, para testar os resultados, primeiro desabilitamos o ipv6 na máquina local em que ele começou a funcionar. Para corrigi-lo permanentemente para todos os usuários, habilitamos o
client-bypass-protocol
comando no firewall ASA, que ignorava o IPv6, se não estiver configurado nos conjuntos de VPNs.Portanto, se você não pode controlar o firewall e saber que o túnel dividido e o DNS dividido estão em vigor, mas está falhando, tente desativar
ipv6
na máquina local e, se puder controlá-lo, poderá ativar o comando acima, desde que não use o ipv6 na sua rede remota.Isso me ajudou, espero que ajude os outros :)
fonte
Yay algo que eu tenho experiência com!
Defina a conexão VPN com o servidor DNS local e conecte-se à VPN usada para consultar o nome de domínio da VPN. Você deve obter uma resposta com um IP local na LAN da VPN. Isso significa que você usou os servidores DNS da VPN para resolver a consulta.
Agora abra sua conexão LAN e defina manualmente o DNS para o DNS local ou do ISP. um Volia !!! use a tecla de seta e repita a consulta nslookup. Você receberá um IP público, o que significa que você usou o servidor DNS local / ISP para resolver a consulta do domínio da VPN. Bam !!!!
fonte
Simplesmente removo esta opção da configuração da VPN do cliente
setenv opt block-outside-dns
Resolveu o problema
fonte
Eu tive esse problema há alguns anos e, corrigido editando o arquivo de conexão VPN, basta abrir um arquivo vpn.pbk (você pode encontrá-lo no google) através do editor de texto, como o bloco de notas, e alterar o valor de UseRasCredentials para zero e o problema será resolvido. mas o único problema é que a prioridade do DNS nas conexões locais se torna mais alta que o DNS da VPN e a resolução de nomes leva mais tempo (se a VPN for usada para conectar-se à Internet).
fonte
Por que você acha que é o DNS?
Se você perder o acesso aos seus compartilhamentos de rede ao se conectar à VPN - parece quase certo que sua máquina está tendo dificuldades com o WINS / NETBIOS.
Defina um servidor WINS e teste novamente.
fonte