☰

DNS „Rekursion nicht verfügbar“ bei Verwendung einer Cisco AnyConnect VPN-Verbindung

tag-icon • tag-icon domain-name-system vpn cisco anyconnect
DNS „Rekursion nicht verfügbar“ bei Verwendung einer Cisco AnyConnect VPN-Verbindung

Hat jemand Erfahrung mit der Konfiguration von Cisco AnyConnect VPN? Wir haben ein Problem mit der DNS-Namensauflösung des Clients, wenn eine Verbindung über VPN besteht.

Für mich sieht es so aus, als würde der Cisco AnyConnect VPN-Client DNS-Anfragen der Clients abfangen.

  1. Kann jemand bestätigen, dass der AnyConnect VPN-Client dies tatsächlich tut (DNS-Verkehr abfängt)?
  2. Wo wird dies auf dem VPN-Server konfiguriert?

BEARBEITEN:

So ändert sich die Routing-Tabelle, wenn ich eine Verbindung zum VPN herstelle:

[~]
$ diff -u /tmp/route_normal /tmp/route_vpn 
--- /tmp/route_normal   2010-01-20 19:23:47.000000000 +0100
+++ /tmp/route_vpn      2010-01-20 19:24:46.000000000 +0100
@@ -1,6 +1,10 @@
 Kernel IP routing table
 Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
+xxx.xxx.xx.xx.i 10.0.0.1        255.255.255.255 UGH   0      0        0 ath0
 172.16.53.0     *               255.255.255.0   U     0      0        0 vmnet1
 10.0.0.0        *               255.255.255.0   U     0      0        0 ath0
+172.17.20.0     *               255.255.255.0   U     0      0        0 cscotun
0
+192.168.111.0   172.17.20.212   255.255.255.0   UG    0      0        0 cscotun
0
 172.16.140.0    *               255.255.255.0   U     0      0        0 vmnet8
+172.16.0.0      172.17.20.212   255.255.0.0     UG    0      0        0 cscotun
0
 default         10.0.0.1        0.0.0.0         UG    0      0        0 ath0

BEARBEITEN 2:

Der IT-Typ hat „irgendetwas“ am VPN-Endpunkt getan. Jetzt bekomme ich beim Ausführen die Meldung „Rekursion nicht verfügbar“ nslookup. Die DNS-Server haben Rekursion aktiviert. Es muss also die DNS-Interception von Cisco VPN sein, die das durcheinander bringt.

ubuntu@domU-12-31-39-00-ED-14:~$ /opt/cisco/vpn/bin/vpn connect xxx.xxxxxx.xx
...
  >> Please enter your username and password
...
  >> notice: Establishing VPN...
  >> state: Connected
  >> notice: VPN session established to ...
ubuntu@domU-12-31-39-00-ED-14:~$ nslookup www.vg.no
;; Got recursion not available from ..., trying next server
;; Got recursion not available from ..., trying next server
;; Got recursion not available from ..., trying next server
;; Got recursion not available from ..., trying next server
Server:         172.16.0.23
Address:        172.16.0.23#53

** server can't find www.vg.no.compute-1.internal: REFUSED

ubuntu@domU-12-31-39-00-ED-14:~$ ping 195.88.55.16
PING 195.88.55.16 (195.88.55.16) 56(84) bytes of data.
64 bytes from 195.88.55.16: icmp_seq=1 ttl=240 time=110 ms
64 bytes from 195.88.55.16: icmp_seq=2 ttl=240 time=111 ms
64 bytes from 195.88.55.16: icmp_seq=3 ttl=240 time=109 ms
^C
--- 195.88.55.16 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2017ms
rtt min/avg/max/mdev = 109.953/110.379/111.075/0.496 ms

Antwort1

Wie in einem Kommentar erwähnt, überlegen Sie sich zuerst, wie Sie Split-Tunneling (Routing) einrichten. Der Administrator des Endpunkts (Konzentrator, ASA, PIX usw.) hat normalerweise die volle Kontrolle darüber, wie der Client damit umgeht. Einige Unternehmen tunneln nur ihr Netzwerk (so dass der DNS Ihres Clients über den ISP läuft), und andere verlangen, dass der gesamte Datenverkehr über die Verbindung getunnelt wird (so dass der DNS über die Verbindung zum Unternehmen läuft). Meistens ist es eine geschäftliche/IT-Entscheidung.

Werfen Sie einen Blick auf die Routing-Tabelle auf dem Client und sehen Sie, wie die Gateways und dergleichen aussehen und wohin der Datenverkehr in ihrer jeweiligen Instanz geleitet wird, um den Ausgangspunkt für Ihr Debugging zu schaffen. Sie können dann versuchen, direkte DNS-Abfragen vom Client an eine öffentliche Ressource (z. B. Googles neues DNS-Ding) zu richten, um die Ergebnisse zu sehen, während Sie mit einer Software vom Typ TCPview (wenn Ihr Client Windows ist) zusehen, wie die Bits herumfliegen.

Antwort2

Überprüfen Sie, welche scheinbare Quell-IP-Adresse verwendet wird, wenn Ihre DNS-Anfragen den internen DNS-Server erreichen.

Es ist wahrscheinlich, dass der Server so konfiguriert wurde, dass er nurrekursivService für Anfragen, die von bekannten internen IP-Adressen kommen, und ansonsten nurmaßgebendDienst für bestimmte Domänennamen, die auf demselben Server gehostet werden.

Wenn Ihre DNS-Anfragen scheinbar von einer Off-Net-IP-Adresse kommen, erhalten Sie nur autoritative und keine rekursiven Antworten.

verwandte Informationen