Cisco AnyConnect VPN 연결을 사용하는 DNS "재귀를 사용할 수 없음"

Cisco AnyConnect VPN 연결을 사용하는 DNS "재귀를 사용할 수 없음"

Cisco AnyConnect VPN 구성 경험이 있는 사람이 있습니까? VPN을 통해 연결된 경우 클라이언트 DNS 이름 확인에 문제가 있습니다.

제가 보기에는 Cisco AnyConnect VPN 클라이언트가 클라이언트의 DNS 쿼리를 가로채는 것처럼 보입니다.

  1. AnyConnect VPN 클라이언트가 실제로 이 작업을 수행하는지(DNS 트래픽 가로채기) 확인할 수 있습니까?
  2. 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:

IT 담당자가 VPN 엔드포인트에서 "뭔가"를 수행했습니다. 이제 nslookup. DNS 서버에 재귀가 활성화되어 있습니다. 따라서 이를 방해하는 것은 Cisco VPN DNS 가로채기임에 틀림없습니다.

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

답변1

댓글에서 언급했듯이 먼저 분할 터널링(라우팅)을 파악하세요. 엔드포인트(Concentrator, ASA, PIX 등) 관리자는 일반적으로 클라이언트가 이를 처리하는 방법을 완전히 제어할 수 있습니다. 일부 회사는 네트워크만 터널링하므로(클라이언트의 DNS가 ISP를 통과함) 일부 회사는 링크를 통해 모든 트래픽을 터널링해야 합니다(DNS가 회사 링크를 통해 이동함). 대부분의 경우 이는 비즈니스/IT 결정입니다.

클라이언트의 라우팅 테이블을 살펴보고 게이트웨이 등의 모양과 특정 인스턴스에서 트래픽이 라우팅되는 위치를 확인하여 디버깅의 시작점을 제공합니다. 그런 다음 공개 리소스(예: Google의 새로운 DNS 항목)에 대해 클라이언트에서 직접 DNS 쿼리를 시도하여 결과가 무엇인지 확인하고 TCPview(클라이언트가 Windows인 경우) 유형 소프트웨어를 사용하여 비트가 돌아다니는 것을 확인할 수 있습니다.

답변2

DNS 요청이 내부 DNS 서버에 도달할 때 어떤 명백한 소스 IP 주소가 사용되고 있는지 확인하세요.

서버가 다음을 제공하도록 구성되었을 가능성이 있습니다.재귀적알려진 내부 IP 주소에서 도착하는 요청에 대한 서비스, 그렇지 않은 경우에만 제공권위 있는동일한 서버에서 호스팅되는 특정 도메인 이름에 대한 서비스입니다.

DNS 요청이 오프넷 IP 주소에서 오는 것으로 나타나면 신뢰할 수 있는 답변만 얻게 되며 재귀적인 답변은 얻지 못합니다.

관련 정보