
Alguém tem experiência com configuração do Cisco AnyConnect VPN? Temos um problema com a resolução de nomes DNS do cliente quando conectado por VPN.
Para mim, parece que o cliente Cisco AnyConnect VPN intercepta consultas DNS dos clientes.
- Alguém pode confirmar se o cliente VPN AnyConnect realmente faz isso (intercepta o tráfego DNS)?
- Onde isso está configurado no servidor VPN?
EDITAR:
Veja como a tabela de roteamento muda quando me conecto à 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
EDITAR 2:
O cara de TI fez “alguma coisa” no endpoint da VPN. Agora recebo "recursão não disponível" ao fazer nslookup
. Os servidores DNS têm recursão habilitada. Portanto, deve ser a interceptação de DNS da Cisco VPN que está atrapalhando tudo.
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
Responder1
Conforme mencionado em um comentário, descubra primeiro o seu tunelamento dividido (roteamento). O administrador do endpoint (Concentrador, ASA, PIX, etc.) geralmente tem controle total de como o cliente irá lidar com isso; algumas empresas apenas encapsularão sua rede (para que o DNS do seu cliente passe pelo ISP) e algumas exigem o encapsulamento de todo o tráfego pelo link (para que o DNS passe pelo link para a empresa). Na maioria das vezes, é uma decisão de negócios/TI.
Dê uma olhada na tabela de roteamento do cliente e veja como são os gateways e para onde o tráfego está sendo roteado em sua instância específica para fornecer o ponto inicial para sua depuração. Você pode então tentar consultas DNS diretas do cliente em um recurso público (ou seja, o novo DNS do Google) para ver quais são os resultados, enquanto usa o software do tipo TCPview (se o seu cliente for Windows) para observar os bits voando.
Responder2
Verifique qual endereço IP de origem aparente está sendo usado quando suas solicitações de DNS atingem o servidor DNS interno.
É provável que o servidor tenha sido configurado para fornecer apenasrecursivoserviço para solicitações que chegam de endereços IP internos conhecidos e, de outra forma, oferecer apenasautoritárioserviço para determinados nomes de domínio hospedados no mesmo servidor.
Se suas solicitações de DNS parecerem vir de um endereço IP fora da rede, elas receberão apenas respostas autorizadas e nenhuma resposta recursiva.