Ordem de pesquisa de DNS do OS X> 10.6.5 com VPN


13

Após a atualização para o OS X 10.6.5 (de .4), os aplicativos não parecem procurar nomes de host na ordem correta (de acordo com a ordem de serviço em Preferências de Rede) quando minha VPN está conectada.

Minha configuração atual é um serviço Cisco IPSec VPN na frente de um serviço AirPort. Os servidores DNS são configurados automaticamente para a conexão VPN (o que é bom) e o DNS do serviço AirPort está apontando para o meu roteador (192.168.1.1, apontado para os servidores OpenDNS).

Quando minha VPN está conectada, eu gostaria que as pesquisas de DNS passassem primeiro pelos servidores DNS da VPN, mas todos os meus aplicativos (Firefox, Thunderbird, ssh) parecem estar usando meu servidor DNS do AirPort primeiro (OpenDNS).

Isso estava funcionando muito bem antes da atualização.

Obrigado por qualquer ajuda.

** editar **

Me deparei com este post e executei os comandos na resposta aceita. Não pareceu ajudar, no entanto.

Depois de pesquisar um pouco mais, deparei-me com este comando: scutil --dns

A saída do comando está abaixo. Tudo parece correto, exceto que eu acho que o resolvedor nº 2 deve vir primeiro, e há um domínio de pesquisa no resolvedor nº 1 (obviamente não é foobar.com, mas o domínio VPN real). Eu acho que esse é o problema (ou o que quer que seja) mentiras. Não o especifiquei manualmente e não está na guia DNS da minha conexão AirPort. Quando a VPN é desconectada, esse domínio de pesquisa não existe e o resolvedor nº 2 desaparece, como deveria ser.

resolver #1
  search domain[0] : foobar.com
  nameserver[0] : 192.168.1.1
  order   : 200000

resolver #2
  domain : foobar.com
  nameserver[0] : 172.30.50.100
  nameserver[1] : 172.30.50.80
  order   : 100200

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

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

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

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

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

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

** editar **

Bem, até que alguém possa responder à minha pergunta, escrevi um script para ajudar na solução alternativa mencionada abaixo. Ele deve ser executado depois que você conectar sua VPN e executar novamente depois que você se desconectar (não encontrei uma maneira de executá-lo automaticamente). Algumas notas:

  1. Minha conta é executada como um administrador com as preferências de rede desbloqueadas, por isso não tenho certeza de como esse script seria justo em nada.

  2. Você precisa definir vpn_srvc_name no script como seu, você adivinhou, nome do serviço vpn.

  3. Tenho certeza de que provavelmente existe uma maneira mais fácil de fazer isso, fique à vontade para postar seus comentários.

O script:

#!/bin/bash

function get_pri_srvc_id ()
{
  cat <<EOF | scutil | \
    grep 'PrimaryService' | \
    awk -F': ' '{print $2}'
show State:/Network/Global/IPv4
EOF
}

function get_srvc_name ()
{
  cat <<EOF | scutil | \
    grep 'UserDefinedName' | \
    awk -F': ' '{print $2}'
show Setup:/Network/Service/$1
EOF
}

function get_srvc_ids ()
{
  cat <<EOF | scutil | \
    sed -nEe '
/ServiceOrder/ {
  :ids
  n
  /[0-9]+ :/ {
    s/ *[0-9]+ : ([0-9A-Z-]+) */\1/p
    b ids
  }
}'
show Setup:/Network/Global/IPv4
EOF
}

function get_srvc_id_by_name ()
{
  local srvc_ids=$(get_srvc_ids)

  for srvc_id in $srvc_ids
  do
    local srvc_name=$(get_srvc_name "$srvc_id")
    if [[ "$srvc_name" == "$1" ]]
    then
      echo $srvc_id
      return
    fi
  done
}

function get_dns_ips ()
{
  local srvc_id=$(get_srvc_id_by_name "$1")

  cat <<EOF | scutil | \
    sed -nEe '
/ServerAddresses/ {
  :ips
  n
  /[0-9]+ :/ {
    s/ *[0-9]+ : ([0-9.]+) */\1/p
    b ips
  }
}'
show $2:/Network/Service/$srvc_id/DNS
EOF
}

function set_dns_ips ()
{
  networksetup -setdnsservers "$@"
}

vpn_srvc_name='NAME OF VPN SERVICE'
ip_file='/tmp/setup_dns_ips'

pri_srvc_id=$(get_pri_srvc_id)
pri_srvc_name=$(get_srvc_name "$pri_srvc_id")

if [[ ! -e "$ip_file" ]]
then
  setup_dns_ips=$(get_dns_ips "$pri_srvc_name" "Setup")
  state_dns_ips=$(get_dns_ips "$pri_srvc_name" "State")
  vpn_ips=$(get_dns_ips "$vpn_srvc_name" "State")

  set_dns_ips "$pri_srvc_name" $vpn_ips $setup_dns_ips $state_dns_ips

  if [[ -z "$setup_dns_ips" ]]
  then
    setup_dns_ips="Empty"
  fi

  echo $setup_dns_ips >$ip_file
else
  setup_dns_ips=$(cat $ip_file)

  set_dns_ips "$pri_srvc_name" $setup_dns_ips

  rm $ip_file
fi

** editar **

Parece que isso ainda é um problema no Lion também. Estou atualizando o título e adicionando uma tag.

** editar **

Aparentemente, o Lion também trouxe algumas mudanças sem fio, incluindo renomear o serviço AirPort para Wi-Fi. Isso pode causar problemas com o script da solução alternativa que forneci se alguém se conectar à VPN por uma conexão sem fio. Lion (por algum motivo) mantém o serviço chamado AirPort embaixo do capô. Para corrigi-lo, você precisa renomear seu serviço Wi-Fi para algo diferente do AirPort. Se você deseja manter o nome do Wi-Fi, renomeie-o para algo diferente primeiro e depois renomeie-o novamente para Wi-Fi.


Ao procurar em Preferências do sistema e clicar em redes, na conexão VPN no lado esquerdo, selecione avançado (corener do canto inferior direito). Agora você deve ver uma guia DNS na parte superior. À esquerda, estão os IPs para o DNS e a direita mostra seu domínio. Eles estão corretos (apontando para o servidor DNS da VPN)?
Everett

Sim, eles estão corretos.
citrusmoose

A linha em set_dns_ips deve ser networksetup -setdnsservers "$@". O meu Mac Pro possui duas conexões Ethernet ("Ethernet 1" e "Ethernet 2" são os nomes padrão) e, portanto, devem ser citadas. EDIT: por que fazer isso
Chris R. Donnelly

Você está certo, @chris. Eu atualizei o script. Não sei o que você quer dizer com "por que fazer isso".
precisa saber é o seguinte

Desculpe, @citrusmoose. Estava apenas tentando dizer por que editei o comentário; Cliquei em enviar e percebi que não disse por que mudar isso e não queria parecer apenas advogando a mudança sem uma boa razão.
Chris R. Donnelly

Respostas:


1

No meu caso, as solicitações de FQDN não estavam resolvendo para o endereço interno correto. Em vez disso, eles estavam apontando para o endereço externo.

Eu conecto ao meu Cisco ASA via IPsec. Enquanto o pedido está configurado corretamente na conexão de rede, as solicitações de DNS não seguem o pedido desde a atualização para 10.6.5.

Para contornar isso, atribuai manualmente o servidor DNS da minha VPN à conexão do aeroporto (já que sou sem fio). Depois de concluir a conexão VPN, removo o endereço DNS adicionado manualmente.


Sim, esta também é minha solução alternativa (mas muito irritante). Fico feliz que alguém esteja tendo esse problema, pois parece que fui o único. Suponho que outras pessoas talvez não notem, pois a maioria das pesquisas de domínios internos falhará e voltará aos servidores DNS corretos. No meu caso, no entanto, existem poucos domínios internos que (por algum motivo) possuem entradas em servidores DNS externos.
citrusmoose

Deve haver uma abordagem melhor do que essa, @Citrusmoose, você teve alguma sorte com algo menos manual e mais robusto?
MightyE

Não, eu ainda não encontrei nada.
Citusmoose

1

Para impedir que o OS X 10.8 crie uma rota padrão para sua conexão VPN, abra o Internet Connect (em Aplicativos). Escolha Opções no menu Conectar e desmarque a opção "Enviar todo o tráfego pela conexão VPN". Clique em OK e pronto.

Para fazer uma rota personalizada para a sub-rede do outro lado da conexão VPN, leia o restante da dica ...

Como root, crie / etc / ppp / ip-up e insira o seguinte código:

#!/bin/sh
# When the ppp link comes up, this script is called with the following
# parameters
#       $1      the interface name used by pppd (e.g. ppp3)
#       $2      the tty device name
#       $3      the tty device speed
#       $4      the local IP address for the interface
#       $5      the remote IP address
#       $6      the parameter specified by the 'ipparam' option to pppd

DEBUGFILE=/tmp/ip-up-debug.txt
## echo "1:$1 2:$2 3:$3 4:$4 5:$5 6:$6" > $DEBUGFILE
NET=`echo $5 | cut -d. -f1,2,3`
## echo $NET >> $DEBUGFILE

case $NET in 192.168.3)
     ## echo "CASE1" >> $DEBUGFILE
     RESULT=`/sbin/route add -net 192.168.30.0 $5 255.255.255.0`
     ##echo $RESULT >> $DEBUGFILE
     ;;
     192.168.2)
     ## echo "CASE2" >> $DEBUGFILE
     RESULT=`/sbin/route add -net 192.168.20.0 netmask 255.255.255.0 gw $5`
     ## echo $RESULT >> $DEBUGFILE
     ;;
     192.168.1)
     ## echo "CASE3" >> $DEBUGFILE
     RESULT=`/sbin/route add -net 192.168.10.0 netmask 255.255.255.0 gw $5`
     ## echo $RESULT >> $DEBUGFILE
     ;;
     *)
     ## echo "No match" >> $DEBUGFILE
     ;;
esac

Notas:

  1. Depois de criar o arquivo, faça um chmod u+x /etc/ppp/ip-up.
  2. A variável $ 5 é o seu endereço IP remoto (seu endereço IP na rede remota).
  3. Na primeira declaração de caso, altere a entrada 192.168.x para os três primeiros octetos da sua rede remota. Nesse caso, o IP remoto é 192.168.3.1 e a rede remota é 192.168.30.0/24 (a caixa VPN remota está fazendo o roteamento - é para que o SAMBA funcione sem a necessidade de proxy ARP).
  4. Remova o comentário (remova os ##) da linha de depuração para ver o que esse script está fazendo. A saída será gravada no arquivo /tmp/ip-up-debug.txt. Lembre-se de colocar os ## de volta quando terminar de testar.
  5. Este script tem opções para três conexões VPN diferentes. Basta alterar as entradas 192.168.x para os diferentes endereços de rede das suas diferentes VPNs.

Encontrado aqui

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.