Nach der Aktualisierung auf OS X 10.6.5 (von .4) scheinen Anwendungen Hostnamen nicht in der richtigen Reihenfolge nach der Dienstreihenfolge in den Netzwerkeinstellungen zu suchen, wenn mein VPN verbunden ist.
Mein aktuelles Setup ist ein Cisco IPSec VPN-Dienst vor einem AirPort-Dienst. Die DNS-Server werden automatisch für die VPN-Verbindung eingerichtet (was in Ordnung ist), und der AirPort-Dienst-DNS zeigt auf meinen Router (192.168.1.1, der auf OpenDNS-Server verweist).
Wenn mein VPN angeschlossen ist, möchte ich, dass die DNS-Suchvorgänge zuerst die VPN-DNS-Server durchlaufen, aber alle meine Anwendungen (Firefox, Thunderbird, ssh) verwenden anscheinend zuerst meinen AirPort-DNS-Server (OpenDNS).
Das hat vor dem Update gut funktioniert.
Danke für jede Hilfe.
** bearbeiten **
Ich bin auf diesen Beitrag gestoßen und habe die Befehle in der akzeptierten Antwort ausgeführt. Es schien jedoch nicht zu helfen.
Nachdem ich ein wenig mehr gesucht hatte, stieß ich auf diesen Befehl: scutil --dns
Die Ausgabe des Befehls ist unten. Alles sieht korrekt aus, außer ich denke, dass Resolver # 2 an erster Stelle stehen sollte, und es gibt eine Suchdomäne in Resolver # 1 (es ist offensichtlich nicht foobar.com, sondern die echte VPN-Domäne). Ich denke, das ist, wo der Bug (oder was auch immer es ist) Lügen. Ich habe es nicht manuell angegeben und es befindet sich nicht auf der Registerkarte DNS für meine AirPort-Verbindung. Wenn das VPN getrennt wird, ist diese Suchdomäne nicht vorhanden, und Resolver Nr. 2 ist nicht mehr vorhanden, wie es sein sollte.
Nun, bis jemand meine Frage beantworten kann, habe ich ein Skript geschrieben, um die unten beschriebene Problemumgehung zu unterstützen. Es sollte ausgeführt werden, nachdem Sie Ihr VPN verbunden haben, und erneut, nachdem Sie die Verbindung getrennt haben (ich habe keinen Weg gefunden, es automatisch auszuführen). Ein paar Anmerkungen:
Mein Konto wird als Administrator mit nicht gesperrten Netzwerkeinstellungen ausgeführt, daher bin ich mir nicht sicher, wie dieses Skript auf alles andere als passen würde.
Sie müssen vpn_srvc_name im Skript auf Ihren vpn-Dienstnamen setzen.
Ich bin sicher, es gibt wahrscheinlich einen einfacheren Weg, dies zu tun, also zögern Sie nicht, Ihre Anmerkungen zu posten.
Das Skript:
#!/bin/bash function get_pri_srvc_id () { cat <<EOF | scutil | \ grep 'PrimaryService' | \ awk -F': ' '' show State:/Network/Global/IPv4 EOF } function get_srvc_name () { cat <<EOF | scutil | \ grep 'UserDefinedName' | \ awk -F': ' '' 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
** bearbeiten **
Es scheint, dass dies auch in Lion noch ein Problem ist. Ich aktualisiere den Titel und füge ein Tag hinzu.
** bearbeiten **
Anscheinend brachte Lion auch einige Änderungen im WLAN mit, darunter die Umbenennung des AirPort-Dienstes in Wi-Fi. Dies kann zu Problemen mit dem von mir bereitgestellten Workaround-Skript führen, wenn eine Verbindung zu ihrem VPN über eine drahtlose Verbindung hergestellt wird. Lion (aus irgendeinem Grund) hält den Dienst AirPort unter der Haube. Um dies zu beheben, müssen Sie Ihren Wi-Fi-Dienst in etwas anderes als AirPort umbenennen. Wenn Sie den Wi-Fi-Namen beibehalten möchten, müssen Sie ihn zunächst in einen anderen Namen umbenennen und ihn dann wieder in Wi-Fi umbenennen.
Wenn Sie in den Systemeinstellungen nachsehen und auf Netzwerke klicken, wählen Sie auf der linken Seite unter VPN-Verbindung die Option Erweitert (unten rechts). Sie sollten jetzt eine DNS-Registerkarte oben sehen. Auf der linken Seite befinden sich die IP-Adressen für das DNS und auf der rechten Seite wird Ihre Domäne angezeigt. Sind diese richtig (zeigt auf den VPN-DNS-Server)?
Everett vor 13 Jahren
0
Ja, das stimmt.
citrusmoose vor 13 Jahren
0
Die Zeile in set_dns_ips sollte `networksetup -setdnsservers" $ @ "` sein. Mein Mac Pro verfügt über zwei Ethernet-Verbindungen ("Ethernet 1" und "Ethernet 2" sind die Standardnamen) und müssen daher in Anführungszeichen gesetzt werden. EDIT: Warum das tun?
Chris R. Donnelly vor 11 Jahren
0
Du hast recht, @chris. Ich habe das Skript aktualisiert. Nicht sicher, was Sie mit "Warum dies tun" meinen.
citrusmoose vor 11 Jahren
0
Entschuldigung, @citrusmoose. Ich wollte nur sagen, warum ich den Kommentar bearbeitet habe. Ich schlug ein, dann wurde mir klar, dass ich nicht gesagt hatte, * warum *, um das zu ändern, und wollte nicht einfach nur aus gutem Grund die Änderung befürworten.
Chris R. Donnelly vor 11 Jahren
0
2 Antworten auf die Frage
1
KevinTM
In meinem Fall lösten sich FQDN-Anforderungen nicht an die richtige interne Adresse. Sie wiesen stattdessen auf die externe Adresse hin.
Ich verbinde mich über IPsec mit meinem Cisco ASA. Während die Reihenfolge in der Netzwerkverbindung korrekt eingerichtet ist, folgen die DNS-Anforderungen seit der Aktualisierung auf 10.6.5 nicht mehr der Reihenfolge.
Um dies zu umgehen, habe ich den DNS-Server für mein VPN der Flughafenverbindung manuell zugewiesen (da ich drahtlos bin). Nachdem ich mit der VPN-Verbindung fertig bin, entferne ich die manuell hinzugefügte DNS-Adresse.
Ja, das ist auch mein Workaround (aber sehr ärgerlich). Ich bin froh, dass jemand anderes dieses Problem hat, da es so aussieht, als wäre ich der einzige. Ich nehme an, dass andere dies möglicherweise nicht bemerken, da die meisten Suchvorgänge für interne Domänen fehlschlagen und auf die richtigen DNS-Server zurückgreifen. In meinem Fall gibt es jedoch nur wenige interne Domänen, die (aus irgendeinem Grund) Einträge in externen DNS-Servern haben.
citrusmoose vor 13 Jahren
0
Es muss einen besseren Ansatz geben als hier: @Citrusmoose. Hattest du Glück mit etwas weniger Manuellem und Robusterem?
MightyE vor 13 Jahren
0
Nein, ich bin noch nicht auf etwas gestoßen.
citrusmoose vor 13 Jahren
0
1
Antonio
To stop OS X 10.8 from creating a default route to your VPN connection, open Internet Connect (in Applications). Choose Options from the Connect menu, then uncheck the "Send all traffic over VPN connection" option. Click OK, and you're done.
To make a custom route to the subnet on the other side of the VPN connection, read the rest of the hint...
As root, create /etc/ppp/ip-up, and put in the following code:
#!/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
Notes:
Once you create the file, do a chmod u+x /etc/ppp/ip-up.
The $5 variable is your remote IP address (your IP address on the remote network).
In the first case statement, change the 192.168.x entry to the first three octets of your remote network. In this instance, the remote IP is 192.168.3.1, and the remote network is 192.168.30.0/24 (the remote VPN box is doing the routing -- this is so SAMBA will work without needing to proxy ARP).
Uncomment (remove the ##'s) from the debug lines to see what this script is doing. Output will be written to the /tmp/ip-up-debug.txt file. Remember to put the ##'s back in when you are done testing.
This script has options for three different VPN connections. Just change the 192.168.x entries to the different network addresses of your different VPNs.