DNS "рекурсия недоступна" с использованием VPN-подключения Cisco AnyConnect
У кого-нибудь есть опыт настройки Cisco AnyConnect VPN? У нас проблема с разрешением DNS-имени клиента при подключении через VPN.
Для меня это выглядит так, как будто VPN-клиент Cisco AnyConnect перехватывает DNS-запросы от клиентов.
- Может ли кто-нибудь подтвердить, что клиент AnyConnect VPN фактически делает это (перехватывает трафик DNS)?
- Где это настроено на сервере VPN?
РЕДАКТИРОВАТЬ:
Вот как меняется таблица маршрутизации при подключении к VPN:
[~]
$ 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
РЕДАКТИРОВАТЬ 2:
ИТ-специалист сделал "что-то" на конечной точке VPN. Теперь я получаю "рекурсия недоступна" при выполнении nslookup, На DNS-серверах включена рекурсия. Таким образом, это должно быть перехват DNS Cisco VPN, портящий это.
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
2 ответа
Как уже упоминалось в комментарии, сначала разберитесь с разделением туннелирования (маршрутизации). Администратор конечной точки (Concentrator, ASA, PIX и т. Д.) Обычно полностью контролирует, как клиент будет это обрабатывать; некоторые компании только туннелируют свою сеть (поэтому DNS вашего клиента будет проходить через интернет-провайдера), а некоторые требуют туннелирования всего трафика по каналу (поэтому DNS будет проходить через канал к корпоративной сети). Это бизнес /IT решение в большинстве случаев.
Пик таблицы маршрутизации на клиенте и посмотреть, как выглядят шлюзы и тому подобное, и куда направляется трафик в их конкретном экземпляре, чтобы обеспечить начальную точку для вашей отладки. Затем вы можете попробовать направить DNS-запросы от клиента к общедоступному ресурсу (то есть, к новому DNS-компоненту Google), чтобы увидеть, каковы результаты, при использовании программного обеспечения типа TCPview (если ваш клиент - Windows), чтобы наблюдать за тем, как летают биты.
Проверьте, какой очевидный IP-адрес источника используется, когда ваши DNS-запросы попадают на внутренний DNS-сервер.
Вероятно, сервер был настроен на предоставление рекурсивного обслуживания только для запросов, поступающих с известных внутренних IP-адресов, и в противном случае предлагать только авторизованный сервис для определенных доменных имен, размещенных на одном и том же сервере.
Если ваши DNS-запросы приходят с IP-адреса вне сети, тогда они получат только достоверные ответы, а не рекурсивные.