OS X> 10.6.5 Ordine di ricerca DNS con VPN


13

Dopo l'aggiornamento a OS X 10.6.5 (da .4), le applicazioni non sembrano cercare i nomi host nell'ordine corretto (in base all'ordine di servizio in Preferenze di rete) quando la mia VPN è connessa.

La mia configurazione attuale è un servizio VPN Cisco IPSec di fronte a un servizio AirPort. I server DNS vengono automaticamente configurati per la connessione VPN (che è OK) e il servizio DNS AirPort punta al mio router (192.168.1.1, che punta ai server OpenDNS).

Quando la mia VPN è connessa, vorrei che le ricerche DNS passassero prima attraverso i server DNS VPN, ma tutte le mie applicazioni (Firefox, Thunderbird, ssh) sembrano utilizzare prima il mio server DNS AirPort (OpenDNS).

Funzionava bene prima dell'aggiornamento.

Grazie per qualsiasi aiuto.

** modifica **

Mi sono imbattuto in questo post ed ho eseguito i comandi nella risposta accettata. Non sembra aiutare però.

Dopo aver cercato un po 'di più, mi sono imbattuto in questo comando: scutil --dns

L'output del comando è sotto. Tutto sembra corretto, tranne che penso che il risolutore n. 2 dovrebbe venire prima, e c'è un dominio di ricerca nel risolutore n. 1 (ovviamente non è foobar.com, ma il vero dominio VPN). Penso che questo sia il bug (o qualunque cosa sia) bugie. Non l'ho specificato manualmente e non si trova nella scheda DNS per la mia connessione AirPort. Quando la VPN viene disconnessa, quel dominio di ricerca non è presente e il risolutore n. 2 scompare, come dovrebbe essere.

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

** modifica **

Bene, finché qualcuno non sarà in grado di rispondere alla mia domanda, ho scritto una sceneggiatura per aiutare con la soluzione menzionata di seguito. Dovrebbe essere eseguito dopo aver collegato la tua VPN e riprovare dopo aver disconnesso (non ho trovato il modo di eseguirlo automaticamente). Alcune note:

  1. Il mio account viene eseguito come un amministratore con le preferenze di rete sbloccate, quindi non sono sicuro di come questo script sarebbe giusto su qualsiasi cosa.

  2. Devi impostare vpn_srvc_name nello script sul tuo, hai indovinato, nome del servizio vpn.

  3. Sono sicuro che probabilmente c'è un modo più semplice per farlo, quindi sentiti libero di pubblicare le tue osservazioni.

Il copione:

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

** modifica **

Sembra che questo sia ancora un problema anche in Lion. Sto aggiornando il titolo e aggiungendo un tag.

** modifica **

Apparentemente Lion ha anche apportato alcune modifiche wireless, tra cui la ridenominazione del servizio AirPort in Wi-Fi. Ciò può causare problemi con la soluzione alternativa che ho fornito se uno si connette alla propria VPN tramite una connessione wireless. Lion (per qualche motivo) mantiene il servizio denominato AirPort sotto il cofano. Per risolverlo, devi rinominare il tuo servizio Wi-Fi in qualcosa di diverso da AirPort. Se desideri mantenere il nome Wi-Fi, devi prima rinominarlo in qualcosa di diverso, quindi rinominarlo in Wi-Fi.


Quando guardi in Preferenze di Sistema e fai clic su reti, sotto la connessione VPN sul lato sinistro seleziona avanzato (corener in basso a destra). Ora dovresti vedere una scheda DNS in alto. Sulla sinistra ci sono gli IP per il DNS e la destra mostra il tuo dominio. Sono corretti (puntando al server DNS VPN)?
Everett,

Sì, sono corretti.
citrusmoose,

La riga in set_dns_ips dovrebbe essere networksetup -setdnsservers "$@". Il mio Mac Pro ha due connessioni Ethernet ("Ethernet 1" e "Ethernet 2" sono i nomi predefiniti) e quindi devono essere quotate. EDIT: perché farlo
Chris R. Donnelly,

Hai ragione, @chris. Ho aggiornato lo script. Non sono sicuro di cosa intendi per "perché farlo".
citrusmoose,

Siamo spiacenti, @citrusmoose. Stavo solo cercando di dire perché ho modificato il commento; Ho premuto Invia, poi mi sono reso conto che non avevo detto perché cambiarlo e non volevo smettere di sostenere il cambiamento senza una buona ragione.
Chris R. Donnelly,

Risposte:


1

Nel mio caso, le richieste FQDN non si stavano risolvendo all'indirizzo interno corretto. Invece, stavano indicando l'indirizzo esterno.

Mi collego al mio Cisco ASA tramite IPsec. Mentre l'ordine è impostato correttamente nella connessione di rete, le richieste DNS non seguono l'ordine dall'aggiornamento alla 10.6.5.

Per aggirare il problema, ho assegnato manualmente il server DNS per la mia VPN alla connessione dell'aeroporto (dato che sono wireless). Dopo aver terminato la connessione VPN, rimuovo l'indirizzo DNS aggiunto manualmente.


Sì, anche questa è la mia soluzione (ma molto fastidiosa). Sono contento che qualcun altro stia riscontrando questo problema, in quanto sembra che io sia stato l'unico. Suppongo che altri potrebbero non accorgersene poiché la maggior parte delle ricerche per domini interni fallirà e tornerà ai server DNS corretti. Nel mio caso, tuttavia, ci sono pochi domini interni che (per qualche ragione) hanno voci in server DNS esterni.
citrusmoose,

Deve esserci un approccio migliore di questo, @Citrusmoose, hai avuto fortuna con qualcosa di meno manuale e più robusto?
Possente

No, non ho ancora trovato nulla.
citrusmoose,

1

Per impedire a OS X 10.8 di creare una route predefinita alla connessione VPN, apri Connessione Internet (in Applicazioni). Scegli Opzioni dal menu Connetti, quindi deseleziona l'opzione "Invia tutto il traffico tramite connessione VPN". Fai clic su OK e il gioco è fatto.

Per creare un percorso personalizzato verso la sottorete sull'altro lato della connessione VPN, leggi il resto del suggerimento ...

Come root, crea / etc / ppp / ip-up e inserisci il seguente codice:

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

Appunti:

  1. Dopo aver creato il file, eseguire un chmod u+x /etc/ppp/ip-up.
  2. La variabile $ 5 è il tuo indirizzo IP remoto (il tuo indirizzo IP sulla rete remota).
  3. Nella prima istruzione case, modifica la voce 192.168.x nei primi tre ottetti della tua rete remota. In questo caso, l'IP remoto è 192.168.3.1 e la rete remota è 192.168.30.0/24 (la casella VPN remota sta eseguendo il routing - in questo modo SAMBA funzionerà senza necessità di proxy ARP).
  4. Rimuovi commento (rimuovi i ##) dalle righe di debug per vedere cosa sta facendo questo script. L'output verrà scritto nel file /tmp/ip-up-debug.txt. Ricorda di reinserire # # quando hai terminato il test.
  5. Questo script ha opzioni per tre diverse connessioni VPN. Basta modificare le voci 192.168.x nei diversi indirizzi di rete delle diverse VPN.

Trovato qui

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.