Mac OS X Mountain Lion - A resolução de DNS usa ordem incorreta na VPN via conexão discada

Estou usando um MacBook com Mac OS X 10.8.2 e me conecto à rede da minha empresa via VPN. Tudo funciona muito bem ao estabelecer a conexão VPN via LAN ou WLAN. No entanto, quando eu uso uma conexão dial-up (Huawei HSDPA USB Stick), os nomes de host não são resolvidos corretamente nos aplicativos (por exemplo, navegador da Web). Ferramentas de linha de comando como host nameresolverão corretamente o endereço IP, ping namenão serão resolvidas.

Usando scutil --dnsDespejei a configuração do DNS ao conectar-se via WLAN vs. discagem. Há uma diferença notável na ordem de pesquisa:

connecting using WLAN:

resolver #1
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 6 (ppp0)
  reach    : Reachable,Transient Connection
  order    : 100000

resolver #2
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 6 (ppp0)
  reach    : Reachable,Transient Connection
  order    : 200000

resolver #3
  domain   : local
  options  : mdns
  timeout  : 5
  order    : 300000

resolver #4
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  order    : 300200

resolver #5
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300400

resolver #6
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300600

resolver #7
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300800

resolver #8
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 301000

DNS configuration (for scoped queries)

resolver #1
  nameserver[0] : 192.168.1.1
  if_index : 4 (en0)
  flags    : Scoped
  reach    : Reachable,Directly Reachable Address

resolver #2
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 6 (ppp0)
  flags    : Scoped
  reach    : Reachable,Transient Connection

A conexão ppp0 é a conexão VPN. Como você pode ver, dois servidores estão conectados e eles respondem corretamente na linha de comando e nos aplicativos.

Connecting via UMTS:

resolver #1
  nameserver[0] : 139.7.30.126
  nameserver[1] : 139.7.30.125
  if_index : 6 (ppp0)
  reach    : Reachable,Transient Connection
  order    : 100000

resolver #2
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 7 (ppp1)
  reach    : Reachable,Transient Connection
  order    : 100000

resolver #3
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 7 (ppp1)
  reach    : Reachable,Transient Connection
  order    : 200000

resolver #4
  domain   : local
  options  : mdns
  timeout  : 5
  order    : 300000

resolver #5
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  order    : 300200

resolver #6
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300400

resolver #7
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300600

resolver #8
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300800

resolver #9
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 301000

DNS configuration (for scoped queries)

resolver #1
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 7 (ppp1)
  flags    : Scoped
  reach    : Reachable,Transient Connection

resolver #2
  nameserver[0] : 139.7.30.126
  nameserver[1] : 139.7.30.125
  if_index : 6 (ppp0)
  flags    : Scoped
  reach    : Reachable,Transient Connection

Desta vez, ppp1 é a conexão VPN e ppp0 é a conexão UMTS. Desde os tempos de resposta dos comandos (usando o nome de host inexistente foo.bar.local), deduzo que pingusa a primeira cadeia de resolvedores, em que as hostusa a configuração de consulta com escopo definido. pingleva 5 segundos para retornar "host desconhecido", hostvolta imediatamente. Presumo que o ping seja executado no tempo limite de 5 segundos do resolvedor mdns.

Para corrigir meu problema com as pesquisas de DNS interrompidas ao discar via VPN via modem, preciso alterar a ordem dos resolvedores. Até agora não encontrei uma maneira de fazer isso.

Todas as idéias são bem-vindas.

Eu tinha o mesmo problema no meu Mac e, depois de corrigi-lo, descobri que foi causado pelo FortiClient (cliente VPN). Mesmo quando o FortiClient foi desconectado - o DNS ainda apareceu no scutil.

A solução para mim foi:

scutil
> list ".*DNS"

Isso mostrará uma lista de todas as configurações de DNS, que serão parecidas com:

subKey [0] = State:/Network/Global/DNS <br>
subKey [1] = State:/Network/MulticastDNS<br>
subKey [2] = State:/Network/OpenVPN/DNS<br>
subKey [3] = State:/Network/OpenVPN/OldDNS<br>
subKey [4] = State:/Network/PrivateDNS<br>
subKey [5] = State:/Network/Service/forticlientsslvpn/DNS <br>

Para verificar cada um deles, execute: (até encontrar o problemático)

> get key_name
> d.show

… E para corrigi-lo, execute:

> get key_name
> d.remove ServerAddresses
> set key_name

É assim que parecia na minha máquina:

> get State:/Network/Service/forticlientsslvpn/DNS 
> d.show
<dictionary> {
  ServerAddresses : <array> {
    0 : 192.168.30.6
    1 : 192.168.30.15
  }
  SupplementalMatchDomains : <array> {
    0 :
  }
  SupplementalMatchOrders : <array> {
    0 : 100000
  }
}
> d.remove ServerAddresses
> d.show
<dictionary> {
  SupplementalMatchDomains : <array> {
    0 :
  }
  SupplementalMatchOrders : <array> {
    0 : 100000
  }
}
> set State:/Network/Service/forticlientsslvpn/DNS
> exit

Tente alterar a ordem das entradas DNS no painel de preferências de rede:

1. Abra Preferências do Sistema → Rede .

2. Selecione seu serviço de rede na lista à esquerda.

3. Desbloqueie o painel de preferências usando a trava no canto inferior esquerdo.

4. Clique em Avançado… e escolha a guia DNS .

5. Altere a ordem dos servidores DNS, arrastando-os para cima / baixo.

   

Encontrei uma solução alternativa: o DNS da VPN ainda será ignorado e apenas o DNS com 3G-dongle será usado, mas apenas a adição do DNS da VPN à lista na interface 3G é suficiente ... O principal problema é que o gerenciador de conectividade 3G substitui a configuração toda vez você clica em conectar e precisa do gerenciador de conectividade para ativar o rádio no dongle 3G ... então misturei as duas soluções em uma:

1. Conecte-se à sua VPN e anote seu DNS (eu tenho 2 na lista). Você pode verificá-lo em Preferências de rede → Avançado → guia DNS. Desconecte a VPN. Você precisa se conectar à VPN porque o DNS é atribuído dinamicamente na conexão…

2. Conecte-se ao seu 3G e faça o mesmo: escreva o DNS no papel. Em seguida, desconecte o 3G.

3. Vá para Preferências de rede → clique na interface 3G → Avançado → Guia DNS e, na tabela DNS (que normalmente ficará vazia quando você não está conectado), clique em '+'. Adicione todos os servidores DNS (os de 3G primeiro e depois adicione a VPN mais tarde). Clique em OK e em Aplicar.

4. A partir de agora , para conectar-se ao 3G, basta conectar o USB e aguardar a cobertura 3G (será necessário abrir o gerenciador de conectividade 3G), mas não use o gerenciador de conectividade fornecido para conectar-se. E se ele se conectar automaticamente, vá para preferências e desmarque essa opção. Você precisa desse gerente apenas para ligar o rádio no Dongle USB, nada mais.

   Se você clicar em "conectar" no seu gerenciador 3G, ele substituirá a configuração na sua interface 3G e você precisará repetir a etapa 3 novamente.

5. Vá para Rede → Preferências e clique na interface 3G. Depois clique em conectar. Ele se conectará ao seu 3G usando os servidores DNS configurados (em vez de recebidos dinamicamente), que incluem o DNS "público" e o DNS da VPN.

6. Conecte-se à sua VPN. Funcionará como esperado.

Esteja ciente de que:

• Se o seu DNS da VPN mudar, você precisará alterá-lo manualmente. Isso pode ser verificado facilmente em Rede → Interface VPN w Avançado → guia DNS, pois o DNS da VPN ainda é atribuído dinamicamente à interface (embora ignorado pelo OS X).

• Se o seu DNS 3G mudar (improvável), você também precisará alterá-lo manualmente. Se algo der errado e você não puder navegar, precisará passar pelo gerenciador de conectividade 3G, clique em "Conectar" e veja o DNS atribuído dinamicamente ... Isso exigirá que você volte para a etapa 3 e a reconfigure.

Eu tive o mesmo problema por muito tempo, mas agora tive tempo de encontrar uma solução que funcione para mim. Não mudei a ordem do servidor DNS, mas estou usando o servidor DNS atrás da VPN permanentemente.

1. Conecte-se via conexão discada.

2. Conecte a conexão VPN e copie os IPs do servidor DNS e o domínio de pesquisa em Conexão VPN → Avançado → DNS.

3. Desconecte a conexão VPN.

4. Ping <name>ou <hostname>do seu servidor VPN e anote o IP.

5. Desconecte a conexão dial-up.

6. Duplique a conexão dial-up (por exemplo, denomine "3G for VPN").

7. Digite os IPs e o domínio de pesquisa na guia DNS da conexão dial-up. Eles serão armazenados e usados ​​permanentemente.

8. Conecte-se através da nova conexão dial-up.

9. Agora você não tem acesso aos servidores de nomes (porque eles são protegidos pela VPN) - você precisa editar o endereço do servidor da conexão VPN. Substitua o host pelo IP.

10. Conecte-se via conexão VPN e você poderá usá-lo.

Nota: Em geral, os nomes de host não mudam, mas os IPs podem. Então, se não estiver funcionando algum dia, execute as etapas novamente ...

o que você disse me deu uma dica, então eu adicionei o IP DNS na conexão VPN à lista DNS na conexão principal (nada sofisticado, basta usar a interface gráfica para preferências de rede). Não tenho certeza se o que você lidar com é diferente, mas funcionou comigo.

Isso ainda está acontecendo na versão 10.13.0

Abri um relatório de erro com a Apple. Não é normal que "ping internalhostname" funcione, mas "host internalhostname" ou "nslookup internalhostname" falhem com VPNs de túnel dividido (baseado em Cisco IPSec ou IKEv2).

Além disso, como alguns notaram, as conexões Cisco IPsec e IKEv2 não podem ser priorizadas com "Definir ordem de serviço", diferentemente do L2TP / IPsec que pode.

Outro ponto que eu gostaria de destacar é que as VPNs Cisco IPSec ou IKEv2 de túnel dividido não mostram servidores DNS ou Domínios de pesquisa em suas configurações avançadas, mesmo que essas informações apareçam com "scutil --dns". As VPNs L2TP / IPsec mostram essas informações muito bem.

Algo tem que dar e a Apple precisa fornecer algumas explicações / correções.

Não funciona no Lion / Mountain Lion, devido a um erro que faz com que o servidor DNS local seja sempre usado em vez do servidor DNS da rede remota, mesmo quando o DNS dividido está configurado corretamente no roteador VPN.

No entanto, se você usar um roteador Cisco ASA IPSEC, poderá forçar o uso de servidores DNS remotos sempre que estabelecer uma conexão VPN:

Se estiver usando o Cisco ASDM, acesse Configuração> Acesso à rede (cliente)> Diretivas de grupo> (seu grupo de VPN para OSX / iPhones)> Avançado> Split Tunneling

Lá está definido: Nomes DNS (desmarque "herdar" e defina os nomes de domínio DNS interno, por exemplo, myoffice.local) Enviar todas as pesquisas DNS através do túnel: definido como YES (essa é a configuração importante)

Salve-o e não esqueça de guardar no flash para uso futuro.

Se você usar a linha de comando do IOS, defina:

group-policy <your-tunnel-group-name> attributes
 split-dns value myoffice.local
 split-tunnel-all-dns enable`

Você pode corrigir isso ajustando a ordem de serviço das conexões de rede. Mova a VPN para o topo da lista e a ordem do resolvedor será seguida.

http://support.apple.com/kb/PH14006