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

Question

Eu tenho um PC com Windows 7 na rede da empresa (que é um membro do nosso Active Directory). Tudo funciona bem até eu abrir uma conexão VPN para o site de um cliente.

Quando me conecto, perco o acesso à rede para compartilhamentos na rede, incluindo diretórios como 'Dados de aplicativo' para os quais temos uma diretiva de redirecionamento de pastas. Como você pode imaginar, isso dificulta muito o trabalho no PC, pois os atalhos da área de trabalho param de funcionar, o software pára de funcionar corretamente devido à remoção dos dados de aplicativos.

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.

Eu acompanhei o problema até ser relacionado ao DNS. Assim que eu abro o túnel VPN, todo meu tráfego DNS passa pela rede remota, o que explica a perda de recursos locais, mas a minha pergunta é, como eu posso forçar consultas DNS locais a ir aos nossos servidores DNS locais em vez de nossos clientes?

A saída de ipconfig /all quando não está conectada à 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 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 de interface de 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:

EunãoconfigureiotúnelVPNparausarogatewaypadrãonofinalremoto,eoscomandosderedeparanósemambasasredesestãobem.(ouseja,possofazerpingemqualquernóemnossaredeounarederemota).

EumodifiqueiaspropriedadesdeconexãoPPTPparausarosservidoresDNS10.58.3.32seguidopor192.168.0.16,masaconsultaaindavaipara192.168.0.16.

Editar:

OsrecursoslocaisquedesaparecemsãohospedadosnasraízesdodomínioDFS,oquepode(ounão)serrelevante.

Ediçãoadicional:

IssopareceestarafetandoapenasasraízesdodomínioDFS.Seeufizerreferênciaaocompartilhamentopelonomedoservidor(porexemplo,\server\shareemvezde\dfsroot\share),possoacessaroscompartilhamentos.

Deacordocomomeucomentárioemrelaçãoa esta resposta , descobri que posso adicionar o nome DNS do domínio ao meu arquivo de hosts que impede que minhas unidades de rede (DFS) desapareçam, mas eu ainda gostaria da parte corajosa da minha pergunta (acima) respondendo se alguém tem alguma idéia.

    

Answer 1

OK, encontrei um excelente recurso aqui: link

Não é perfeito, mas pode funcionar.

The binding order is stored in the registry in the following location: HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind. The list includes all the device GUIDs for network adapters and active connections in the binding priority order.

When working with the registry key, the following facts emerge:

Changing the order of the GUIDs in the registry does impact the binding order, including for VPN connections

• Any changes to the key take effect immediately
• When a VPN connection is completed, the GUID for the connection is added to the top of the bind order if it does not already exist
• When a VPN connection is closed, the GUID entry for the connection is removed
• If there are multiple GUID entries for the connection, only one is removed when the connection is closed

This mechanism creates the possibility of the following workaround:

1. Examine the Bind registry key
2. Connect to your VPN connection
3. Check the Bind key again and copy the GUID that was added to the top of the list
4. Paste the GUID entry at the bottom of the list 20 times
5. Export the key and clean up the exported file to only include the bind key

The result is a key that will support the desired behavior. Every time a VPN connection is established, since the GUID is present, it will not be added. Since the GUID is at the bottom, DNS resolution will be done locally to the client. When the connection is disconnected, one GUID entry will be removed. After 20 VPN connections, the exported registry file can be used to reimport the key.

Of course, you can paste the GUID more times to reduce how often you have to reimport the key.

Also important to remember to redo this procedure if there are any changes to network adapters.

    

Answer 2

Parece-me que o túnel VPN tem alguma precedência sobre a interface de área local que direciona 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, já que a ordem de ligação indica de maneira diferente. De acordo com esta poste 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 na ordem de ligação do adaptador. Então, para testar, tente o seguinte para alterar este comportamento automático: 1) vá para Conexões de rede e para cada um faça 2) Propriedades IP v4 3) Avançado 4) Desabilite "Métrica automática" 5) Coloque manualmente uma métrica de 1 para seu local conexão e uma métrica de 2 em sua conexão VPN (PPP). Dessa forma, será mais difícil direcionar o caminho para os servidores DNS locais, de acordo com o DNS remoto.

Espero que isso ajude!

    

Answer 3

Como afirmado, essa é uma questão de encapsulamento dividido.

Três correções, recomendamos # 2 porque é fácil e terá um bom desempenho se usar uma boa caixa com o VMware Workstation 8

1 - Habilite o 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 vai acabar com você.

2 - Abordagem de desktops virtualizados - P2V seu desktop 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 ela e para fora conforme necessário.

3 - Abordagem de servidor virtualizado - P2V seu desktop existente e transformá-lo em uma VM, em seguida, colocá-lo 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 ...

    

Answer 4

O 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 o impedirá de acessar recursos em sua própria rede enquanto o túnel estiver funcionando.

Para que você (ou seu cliente) precise ativar o tunelamento dividido, ou você precisa de uma conexão de rede extra e uma tabela de rotas personalizada para acessar as duas redes ao mesmo tempo.

    

Answer 5

Infelizmente, o Windows VPN não consegue fazer "Split-DNS". No entanto, você pode remover o servidor DNS da conexão VPN depois de se conectar ao site remoto.

Você pode fazer isso emitindo:

netsh interface ipv4 delete dnsservers name="name of the VPN" address=all validate=no

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

    

Answer 6

Embora essa pergunta tenha sido feita há muito tempo, mas postar essa resposta, isso pode ajudar outras pessoas. Eu tive o mesmo problema com VPN, quando os usuários costumavam se conectar ao VPN remoto seu DNS externo usado para parar por exemplo. google.com apenas os domínios da empresa usados para trabalhar, listados em split-dns .

O problema foi quando a máquina local usada faz o tráfego de consulta dns ir para o túnel vpn e se o dns é permitido no túnel ele cai de volta. Quando ele é usado, ele usa o ipv6 como resolução e depois nunca retorna ao ipv4.

Então, para testar os resultados, primeiro desativamos o ipv6 na máquina local que ele começou a funcionar. Para consertá-lo permanentemente para todos os usuários, habilitamos o comando client-bypass-protocol no firewall ASA, que ignorou o IPv6, se não estiver configurado nos pools vpn.

então, se você não pode controlar o firewall e conhecer o túnel dividido e o dns dividido está em vigor, mas está falhando, você pode tentar desabilitar ipv6 na máquina local e, se puder controlá-lo, habilite o comando acima como contanto que você não use ipv6 em sua rede remota.

Isso me ajudou, espero que isso ajude os outros:)

    

Answer 7

Yay algo que eu tenho experiência com!

Defina a conexão VPN com o servidor DNS local e conecte-se à VPN usando o nslookup para consultar o nome de domínio da VPN. Você deve obter uma resposta com um IP que seja local para a 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 seu DNS local ou ISP. um Volia !!! use a tecla de seta e repita a consulta nslookup. Você receberá um IP público que significa que você usou seu servidor DNS local / ISP para resolver a consulta do domínio VPN. Bam !!!!

    

Answer 8

Por que você acha que seu DNS?

Se você perder o acesso aos seus compartilhamentos de rede quando se conectar à VPN - parece quase certo que sua máquina está tendo dificuldades com o WINS / NETBIOS.

Defina um servidor WINS e teste novamente.