Resolução de DNS do Windows 10 via conexão VPN não está funcionando


49

No Windows 10, quando conectado a uma VPN com o Split Tunneling ativado (Gateway desativado), a resolução DNS sempre usa os servidores DNS da LAN, ignorando os servidores DNS e o Sufixo DNS definido na conexão VPN.

O comportamento esperado é usar os servidores DNS da VPN, caso contrário, torna-se impossível resolver as entradas DNS na rede remota (como computadores de domínio).

Isso estava funcionando corretamente na versão anterior do Windows.

Isso foi amplamente discutido neste tópico de respostas da Microsoft .


Não está claro em sua pergunta qual é o seu problema (você deseja que ele use o servidor DNS especificado pela VPN?), Edite-o.
Máté Juhász

Editado como sugerido.
ECC-Dan

TB: Então, há algo errado com seus servidores. A primeira solicitação DNS sempre deve atingir os servidores locais. Somente se o host não puder ser resolvido, o sistema deve tentar consultar o DNS remoto. Seu problema pode ser que as redes locais e remotas estejam sendo executadas nas mesmas sub-redes, portanto a local está reivindicando "ser capaz de resolver a consulta", mas fornece "host não encontrado"? (Se um servidor configurado para servidor da sub-rede abcd não pode resolver uma série, não mais dns-server para esta sub-rede é consultado, a não ser primário estiver offline, já que eles devem estar em sincronia - daí ele assume o anfitrião é desconhecido)
dognose

Respostas:


55

Corrigi esse problema permanentemente, definindo manualmente a métrica da minha conexão LAN como mais alta (15) do que aquela que o Windows atribui à minha VPN (11).

Isso pode ser feito de duas maneiras:

  • Por meio da GUI: Conexões de rede, Propriedades, Propriedades TCP / IP v4, Avançadas, Definir métrica para 15;
  • Linha de comando: netsh int ip set interface interface="LAN CONNECTION NAME" metric=15

O efeito é imediato (pelo menos ao usar a linha de comando) e as pesquisas de DNS agora passam pela minha VPN conforme o esperado.

Isso funciona com o Split Tunneling e é uma correção permanente nas reconexões e reinicializações.

Observe que você também pode alterar a métrica da VPN em vez da conexão LAN, mas isso não seria permanente, pois o Windows redefine a métrica quando a conexão é estabelecida.

Dependendo do seu ambiente, você pode ter uma métrica padrão diferente para sua conexão LAN e VPN. Simplesmente ajuste de acordo para que sua VPN tenha uma métrica menor que a sua conexão LAN.

Além disso, se você achar que não pode editar as propriedades TCP / IP da sua VPN porque isso também foi quebrado no Windows 10 , você pode definir a maioria das propriedades através do Powershell :

1. Get-VpnConnection
2. Set-VpnConnection -Name "myVPN" -SplitTunneling $True
3. Set-VpnConnection -Name "myVPN" -DnsSuffix yourdomain.local

2
Para mim isso não funciona ... Eu tenho duas máquinas com o Windows 10, uma funciona bem e outra é problemática com a VPN. I capaz de resolver o gateway padrão permitindo que o SplitTunneling, mas o DNS de VPN ainda não reconhece tanto quando eu alterar a métrica ...
ceinmart

3
Isso corrigiu o problema para nós (e estamos lutando há algum tempo), com uma importante etapa adicional - desativar o IPv6. Nossa VPN não faz IPv6, mas meu entendimento é que qualquer resolvedor de IPv6 terá precedência sobre os IPv4. Depois que desabilitamos o IPv6 nos adaptadores, ajustamos o DNS de túnel dividido de métricas que continuava funcionando. Se sua VPN suportar IPv6, isso provavelmente não será necessário e se o ajuste de métrica por si só corrige o DNS para você manter o IPv6 ativado no seu adaptador.
Adam Strohl 30/01

Curiosidade: para mim, o problema era "vice-versa" - quando conectado à VPN, o Windows não conseguia resolver os FQDNs locais ... Estava configurando a métrica padrão para a "Conexão VPN" para 1 - por isso forneci ao local conexão um número menor que resolveu meu problema. (Meus servidores locais estão configurados corretamente, portanto, qualquer nome não resolvível será consultado na conexão de "segunda preferência" - que faz com que o DNS local e o remoto funcionem conforme o esperado enquanto a VPN é estabelecida.)
encerre

Alguma idéia de por que essa correção é necessária apenas quando eu conectar através de um ISP, mas não do outro (ambos os cabos coaxiais conectados)?
Gaia

De alguma forma, eu entendi o problema inverso: meu laptop Win10 local usa automaticamente apenas o DNS na VPN (na maioria das vezes) e, como esse DNS na VPN interna (ainda) não está (ainda) configurado para fornecer o serviço DNS, posso não navegue em nenhum site da Internet durante o período de ativação da minha VPN. Então, eu uso essa solução de maneira inversa, ou seja, definindo minha conexão LAN local para um número tão pequeno quanto 1, o que aparentemente resolve o problema por enquanto. FWIW, no entanto, não sei o valor métrico da minha conexão VPN, porque não há botão "Avançado" na janela pop-up de propriedades da conexão VPN.
RayLuo # 29/16

11

Eu instalei uma nova instalação do Windows 10 em uma VM para testar depois de ver esse problema em todas as máquinas Win10 físicas que tenho. Testei todas as respostas neste tópico e nenhuma delas funcionou. Descobri que a solução é combinar as respostas postadas aqui por "Keenans" e "ECC-Dan":

http://answers.microsoft.com/en-us/windows/forum/windows_10-networking/win-10-dns-resolution-of-remote-network-via-vpn/513bdeea-0d18-462e-9ec3-a41129eec736? page = 1

Painel de controle> Central de Rede e Compartilhamento> Alterar configurações do adaptador> Clique com o botão direito do mouse em seu adaptador Ethernet ou Wifi> Propriedades> clique duas vezes em IPv4> Avançado> Desmarque Métrica Automática> Digite 15 para a métrica da interface> OK> OK.

Na mesma página de Propriedades, clique duas vezes em IPv6> Avançado> Desmarque Métrica Automática> Digite 15 para a métrica da interface> OK> OK.

Somente depois de alterar essas duas configurações é que o problema é resolvido. Eu testei mudando uma das costas e ela quebra novamente. Depois de alterar os dois, executei o nslookup na linha de comando e ele retornou o servidor DNS na rede remota à qual a VPN está conectada e, caso contrário, retornaria o servidor DNS local. Em seguida, usei a captura do Wireshark na interface Ethernet, fiz alguns pings para sites aleatórios e verifiquei que não havia pacotes DNS capturados. Isso prova que, depois de fazer as alterações, as consultas DNS estão sendo enviadas SOMENTE pela conexão VPN e não simultaneamente por todas as conexões (conhecida como vazamento de DNS do Win10). Portanto, isso também faz parte da solução para o vazamento de DNS do Win10:

https://medium.com/@ValdikSS/beware-of-windows-10-dns-resolver-and-dns-leaks-5bc5bfb4e3f1#.7ppsn1nda

Observe que, para corrigir o vazamento de DNS, primeiro você precisa executar as etapas acima. Então você precisa definir dois valores do registro. Os artigos vinculados listam apenas um que, por si só, não corrige o problema nas versões mais recentes do Win10. Defina estes valores do registro:

Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient
Value:  DisableSmartNameResolution
Data:  1

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Value: DisableParallelAandAAAA
Data:  1

Somente depois de fazer tudo isso, o comportamento do cliente DNS estará de volta ao que era no Win7. Você deve se perguntar como isso passou pelo controle de qualidade na Microsoft.


1

Ele não funciona, mesmo que eu mudei as métricas no IPv4 e IPv6 e usei o registro DisableSmartNameResolution e DisableParallelAandAAAA com o Windows 10 Edu atual (em dezembro de 2018) quando o cliente está conectado por cabo UTP e o protocolo IPv6 é suportado na LAN local (por exemplo, cliente tem endereço IPv6 público / global).

É suficiente desativar o protocolo IPv6 na interface UTP / LAN usada pela VPN para fazê-lo funcionar (para remover / não usar o endereço IPv6 global no cliente).

Funciona sem problemas quando o cliente está conectado à Internet por Wi-Fi e o IPv6 está disponível (o cliente possui endereço IPv6 global e não possui conexão UTP / LAN).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.