Conexão VPN faz com que o DNS use um servidor DNS errado

17

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 /allquando 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:

insira a descrição da imagem aqui

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.32seguidos 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\sharevez 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.

— Bryan
fonte

Você nunca mencionou qual firewall está usando? Esse é um fator muito importante da IMO, pois acho que é aí que você provavelmente encontrará a resposta para essa pergunta.

— Hanny

@ qualquer firewall é fornecido pela tradução de endereços de rede nos modems ADSL nos dois sites. Provavelmente, posso fornecer números de modelo, se realmente necessário, mas eles serão apenas modems ADSL NATing padrão. Dado que estamos falando do AD com DNS integrado, não considero esses dispositivos relevantes, pois os problemas são puramente DNS.

— Bryan

Se a VPN não está sendo manipulada pelo firewall, mas pelo Windows, isso apresenta um envio diferente de parâmetros para trabalhar dentro, pois a VPN do Windows é bastante limitada em minha experiência. Por exemplo, com um encapsulamento ASA 5505 - split é algo realmente fácil de solucionar e há uma grande quantidade de configuração que pode ser feita, especialmente no que diz respeito a problemas de DNS e atribuição de DNS. Foi por isso que perguntei, obrigado por esclarecer.

— 21712 Hanny

Você poderia adicionar um route print(da conexão VPN) à postagem?

— florianb

Não há nada de errado com roteamento, como ele é capaz de se conectar através de IP, mas não DNS trough

— MichelZ

12

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.

A ordem de ligação é armazenada no registro no seguinte local: HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind. A lista inclui todos os GUIDs de dispositivo para adaptadores de rede e conexões ativas na ordem de prioridade de ligação.

Ao trabalhar com a chave do Registro, surgem os seguintes fatos:

Alterar a ordem dos GUIDs no registro afeta a ordem de ligação, inclusive para conexões VPN

Quaisquer alterações na chave entram em vigor imediatamente

Quando uma conexão VPN é concluída, o GUID da conexão é adicionado à parte superior da ordem de ligação, se ainda não existir.

Quando uma conexão VPN é fechada, a entrada GUID da conexão é removida

Se houver várias entradas GUID para a conexão, somente uma será removida quando a conexão for fechada

Esse mecanismo cria a possibilidade da seguinte solução alternativa:

Examine a chave do Registro Bind

Conecte-se à sua conexão VPN

Verifique a chave Bind novamente e copie o GUID que foi adicionado ao topo da lista

Cole a entrada GUID no final da lista 20 vezes

Exporte a chave e limpe o arquivo exportado para incluir apenas a chave de ligação

O resultado é uma chave que dará suporte ao comportamento desejado. Sempre que uma conexão VPN for estabelecida, uma vez que o GUID está presente, ele não será adicionado. Como o GUID está na parte inferior, a resolução do DNS será feita localmente no cliente. Quando a conexão é desconectada, uma entrada GUID será removida. Após 20 conexões VPN, o arquivo de registro exportado pode ser usado para reimportar a chave.

Obviamente, você pode colar o GUID mais vezes para reduzir a frequência com que precisa reimportar a chave.

Também é importante lembrar de refazer este procedimento se houver alguma alteração nos adaptadores de rede.

— ZnArK
fonte

Boa descoberta. Isso funciona muito bem, juntamente com um script de inicialização do computador para redefinir o valor da chave do Registro a cada inicialização, que deve ser uma ótima solução alternativa para o que não deve ser um problema em primeiro lugar. Muito Obrigado. Vou fazer alguns testes adicionais.

— Bryan

3

Eu recomendo criar uma tarefa agendada. Monitore o ID do evento 20226, que corresponde ao evento de desconexão da VPN. Em seguida, disparar um script powershell pequeno ( 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.

— 21713 Steve

4

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!

— ank
fonte

Interessante, olhando para a minha tabela de roteamento acima, a métrica na interface da LAN é a mais baixa (20), a conexão VPN tem uma métrica de 21. Dito isto, esse problema pode ser um tanto intermitente, e com a tabela de roteamento como exibida acima , tudo está funcionando corretamente no momento. Vou tentar recriar o problema e verificar novamente a tabela de roteamento.

— Bryan

Atualização, reabri o túnel e todas as minhas conexões com unidades caíram, mas a tabela de roteamento não é diferente da acima. ou seja, Metric 20 para LAN, Metric 21 para VPN.

— Bryan

1

@Bryan, este artigo da Microsoft ( support.microsoft.com/kb/299540 ), mais ou menos, verifica o que eu disse acima. Seria interessante ver o que acontece se você seguir o procedimento que escrevi acima quando tiver tempo. Outros relataram os problemas intermitentes exatos que você vê e os solucionaram conectando as métricas ( serverfault.com/questions/70792/… ). Infelizmente, atualmente não tenho uma configuração semelhante para fazer alguns testes.

— ank

Muito obrigado por esse @ank, certamente vou tentar mais tarde na próxima semana, quando voltar ao escritório. Artigo interessante BTW. Obrigado.

— Bryan

1

Ele fez o truque para mim! A metrix nas configurações de IPv4 para a NIC não parece ter nada a ver com a metrix na tabela de roteamento! Alterar a ordem do GUID em HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Linkage \ Bind como o ZnArK escreveu sobre não mudou nada em relação ao qual a NIC / DNS é usada. Isso é testado no Windows 10

— MrCalvin

4

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 ...

— Brennan
fonte

+1; Eu gosto da idéia de ter um sistema virtualizado dedicado para a tarefa, no entanto, não vejo isso funcionando bem aqui neste momento por várias razões. Definitivamente, essa será uma boa solução no futuro. Obrigado.

— Bryan

3

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:

interface netsh ipv4 delete dnsservers nome = " nome da VPN " endereço = todos validam = não

Você precisa fazer isso sempre que se conectar à rede VPN.

— MichelZ
fonte

FYI ... isso impede você de usar o DNS remoto (VPN).

— MichelZ

O problema é que, assim que o túnel terminar, já estou sofrendo com o problema descrito na minha pergunta, portanto o comando será tarde demais. Além disso, depois de experimentar isso, o comando não parece realmente fazer diferença ( nslookupainda usa o servidor DNS remoto, além de ipconfigainda 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.

— Bryan

1

Eu tentei isso porque tinha o mesmo problema e funcionou aqui. Você ajustou o " nome da VPN "? Além disso, se você está principalmente preocupado com isso um servidor onde suas unidades estão ligados a, adicioná-lo em seu arquivo hosts, e nada será capaz de substituí-lo

— MichelZ

Obrigado, tentei alterar o nome (recortar e colar da ipconfigsaída e, quando errei, recebi o erro The 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.

— Bryan

Eu apenas tentei o comando novamente e ele removeu o servidor DNS da conexão PPP. Você poderia verificar com ipconfig /all? Eu acho que, no entanto, a entrada de hosts deve ser a correção mais fácil para você.

— MichelZ

2

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.

— dunxd
fonte

Para informações, eu posso acessar os recursos de rede enquanto o túnel está aberto, é apenas a resolução do DNS que parece quebrar. Eu não estava familiarizado com o termo split tunnellingpara 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.

— 187 Bryan

1

Nesse caso, parece que a VPN do cliente não está configurada para DNS dividido. Com o DNS dividido, o concentrador de VPN fornece ao cliente VPN uma lista de servidores DNS (como atualmente funciona) e também uma lista de domínios que são os únicos domínios que devem ser usados com esses servidores DNS; todos os outros usariam o DNS padrão do seu sistema.

— precisa

0

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.comsomente domínios de empresa costumavam trabalhar nos quais estavam listados split-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-protocolcomando 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 ipv6na 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 :)

— Rsingh
fonte

0

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 !!!!

— Graham.Fraser
fonte

0

Simplesmente removo esta opção da configuração da VPN do cliente

setenv opt block-outside-dns

Resolveu o problema

— Ismail
fonte

0

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).

— Mohsen Bigdeli
fonte

-1

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.

— Ben Lessani - Sonassi
fonte

Não sei ao certo que essa é a causa dos meus problemas, mas o que sei é que os clientes do AD devem usar os servidores DNS usados para hospedar o AD, e esse não é o caso. Como o problema só aparece quando eu faço uma conexão VPN, e minha resolução de DNS fica confusa ao mesmo tempo, parece que o DNS é o candidato provável. Independentemente disso, não quero usar o servidor DNS remoto quando me conectar a outra rede usando VPN.

— Bryan

Você definiu um servidor WINS conforme minha sugestão? Não é típico do Windows usar o servidor DNS em uma VPN, a menos que um esteja definido ou "Usar gateway remoto configurado", que você disse estar desativado. Além disso, você está usando um IP estático no túnel da VPN. Por que você configurou as entradas DNS? Remova esses servidores DNS (192.168.0.16-17) ou defina um servidor WINS.

— Ben Lessani - Sonassi

Não, eu não tentei isso, pois não temos um servidor WINS para apontar os clientes. Não estou convencido de que o WINS ajudará a ser honesto, por isso não estou interessado em instalar um servidor WINS em nossa rede, pois isso pode ajudar. Certamente vou ter em mente a idéia, então obrigado. O IP é atribuído pelo servidor VPN e é dinâmico. Se eu não atribuir um servidor DNS para a conexão VPN, ele será atribuído dinamicamente pelo servidor. Eu até codifiquei meus próprios servidores DNS nas propriedades da conexão VPN, mas ele ainda usa os servidores DNS no site remoto.

— Bryan

Eu não preciso nem quero usar o servidor DNS remoto, nunca, eu sempre quero resolução de DNS para ser executada no servidor local, este irá resolver o meu problema, daí a minha pergunta com foco em DNS. Provavelmente eu poderia usar uma regra de firewall para bloquear o acesso ao servidor DNS remoto, mas isso não corrige o problema subjacente de configuração incorreta.

— Bryan

1

sua interpretação disso está incorreta. O endereço IP é atribuído pelo servidor PPTP, que na verdade não usa DHCP. O servidor PPTP possui um pool que ele pode alocar, mas esse não é o DHCP. No entanto, recebo um IP diferente sempre que me conecto. Além disso, também não marquei a caixa para usar o gateway remoto, como você pode ver claramente na tabela de roteamento.

— Bryan