Interoperabilidade entre o AnyConnect e o OpenDNS Roaming Client

Introdução

Este documento descreve algumas das limitações atuais e soluções alternativas disponíveis para fazer o AnyConnect e o OpenDNS Roaming Client trabalharem juntos. Os clientes da Cisco dependem do AnyConnect VPN Client para uma comunicação segura e criptografada com suas redes corporativas. Da mesma forma, o cliente de roaming do OpenDNS oferece aos usuários a capacidade de usar com segurança os serviços DNS com a ajuda de servidores públicos OpenDNS. Esses dois clientes adicionam um amplo conjunto de recursos de segurança ao endpoint e, portanto, é importante que eles interoperem entre si.

Pré-requisitos

Conhecimento prático do AnyConnect e do cliente de roaming do OpenDNS.

Familiaridade com a configuração de headend do ASA ou IOS/IOS-XE (tunnel-group/group-policy) para AnyConnect VPN.

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Headend ASA ou IOS/IOS-XE
• Endpoint que executa o AnyConnect VPN Client e o OpenDNS Roaming Client

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• ASA headend executando a versão 9.4
• Windows 7
• AnyConnect Client 4.2.00096
• Cliente de roaming OpenDNS 2.0.154

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Informações de Apoio

O OpenDNS está desenvolvendo um plugin do AnyConnect com a equipe do Cisco AnyConnect para estar disponível no futuro. Embora nenhuma data tenha sido definida, essa integração permitirá que o cliente de roaming trabalhe com o cliente AnyConnect sem as soluções resolvidas. Isso também permitirá que o AnyConnect seja um mecanismo de entrega para o cliente de roaming. 

Funcionalidade

Tratamento de DNS do AnyConnect

O headend da VPN pode ser configurado de duas maneiras diferentes para lidar com o tráfego do cliente AnyConnect.

1. Configuração completa do túnel (tunnel-all): isso força todo o tráfego do endpoint a ser enviado pelo túnel VPN criptografado e, portanto, o tráfego nunca deixa o adaptador de interface pública em texto claro
2. Configuração de túnel dividido:

a. Encapsulamento Split-include : Tráfego destinado somente a sub-redes ou hosts específicos definidos no headend da VPN é enviado pelo túnel, todo o tráfego restante é enviado para fora do túnel em texto claro

b. Encapsulamento Split-exclude: o tráfego destinado apenas a sub-redes ou hosts específicos definidos no ponto inicial da VPN é excluído da criptografia e deixa a interface pública em texto não criptografado, todo o tráfego restante é criptografado e enviado apenas pelo túnel

Cada uma dessas configurações determina como a resolução DNS é tratada pelo cliente AnyConnect, dependendo do sistema operacional no endpoint. Houve uma mudança no comportamento do mecanismo de tratamento de DNS no AnyConnect para Windows, na versão 4.2 após a correção para CSCuf07885.

Windows 7 e posteriores

Configuração de túnel completo (e separação de túneis com DNS de túnel completo habilitado)

Antes do AnyConnect 4.2:

Somente solicitações DNS para servidores DNS configurados sob a política de grupo (servidores DNS de túnel) são permitidas. O driver do AnyConnect responde a todas as outras solicitações com uma resposta de 'no such name'. Como resultado, a resolução DNS só pode ser executada usando os servidores DNS do túnel.

AnyConnect 4.2 +

As solicitações DNS para qualquer servidor DNS são permitidas, desde que sejam originadas do adaptador VPN e sejam enviadas pelo túnel. Todas as outras solicitações são respondidas com a resposta 'no such name', e a resolução DNS só pode ser executada através do túnel VPN

Antes da correção CSCuf07885, o AC restringia os servidores DNS de destino; no entanto, com a correção para CSCuf07885, ele restringia quais adaptadores de rede podem iniciar solicitações DNS.

Configuração split-include (DNS tunnel-all desabilitado e sem DNS dividido)

O driver do AnyConnect não interfere no resolvedor de DNS nativo. Portanto, a resolução DNS é executada com base na ordem dos adaptadores de rede, e o AnyConnect é sempre o adaptador preferencial quando a VPN está conectada. Assim, uma consulta DNS será enviada primeiro pelo túnel e, se não for resolvida, o resolvedor tentará resolvê-la pela interface pública. A lista de acesso split-include terá que incluir a sub-rede que cobre o(s) servidor(es) DNS do túnel. Começando com o AnyConnect 4.2, as rotas de host para os servidores DNS de túnel são adicionadas automaticamente como redes com divisão de inclusão (rotas seguras) pelo cliente AnyConnect e, portanto, a lista de acesso com divisão de inclusão não exige mais a adição explícita da sub-rede do servidor DNS de túnel.

Configuração split-exclude (DNS de túnel total desabilitado e sem DNS dividido)

O driver do AnyConnect não interfere no resolvedor de DNS nativo. Portanto, a resolução DNS é executada com base na ordem dos adaptadores de rede, e o AnyConnect é sempre o adaptador preferencial quando a VPN está conectada. Assim, uma consulta DNS será enviada primeiro pelo túnel e, se não for resolvida, o resolvedor tentará resolvê-la pela interface pública. A lista de acesso split-exclude não deve incluir a sub-rede que cobre o(s) servidor(es) DNS de túnel. Começando com o AnyConnect 4.2, as rotas de host para os servidores DNS de túnel são automaticamente adicionadas como redes com divisão de inclusão (rotas seguras) pelo cliente AnyConnect e, portanto, isso evitará erros de configuração na lista de acesso com divisão de exclusão.

DNS dividido (DNS túnel-tudo desabilitado, split-include configurado)

Pré-AnyConnect 4.2

As solicitações DNS que correspondem aos domínios split-dns têm permissão para criar túneis de servidores DNS, mas não para outros servidores DNS. Para evitar que essas consultas de DNS interno vazem pelo túnel, o driver do AnyConnect responde com 'no such name' se a consulta for enviada para outros servidores DNS. Assim, os domínios split-dns só podem ser resolvidos através dos servidores DNS do túnel.

As solicitações DNS que não correspondem aos domínios split-dns são permitidas para outros servidores DNS, mas não podem criar túneis de servidores DNS. Mesmo nesse caso, o driver do AnyConnect responde com 'no such name' se uma consulta para domínios não split-dns for tentada por meio do túnel. Assim, os domínios não split-dns podem ser resolvidos apenas por meio de servidores DNS públicos fora do túnel.

AnyConnect 4.2 +

As solicitações DNS que correspondem aos domínios split-dns são permitidas a qualquer servidor DNS, desde que se originem do adaptador VPN. Se a consulta for originada pela interface pública, o driver do AnyConnect responde com um 'no such name' para forçar o resolvedor a sempre usar o túnel para a resolução de nomes. Assim, os domínios split-dns só podem ser resolvidos através do túnel.

As solicitações DNS que não correspondem aos domínios split-dns são permitidas para qualquer servidor DNS desde que se originem do adaptador físico. Se a consulta for originada pelo adaptador VPN, o AnyConnect responde com 'no such name' para forçar o resolvedor a sempre tentar a resolução de nome através da interface pública. Assim, os domínios não split-dns só podem ser resolvidos por meio da interface pública.

Mac OS X

Configuração de túnel completo (e separação de túneis com DNS de túnel completo habilitado)

Quando o AnyConnect está conectado, somente os servidores DNS de túnel são mantidos na configuração DNS do sistema e, portanto, as solicitações DNS só podem ser enviadas aos servidores DNS de túnel.

Configuração split-include (DNS tunnel-all desabilitado e sem DNS dividido)

O AnyConnect não interfere no resolvedor de DNS nativo. Os servidores DNS do túnel são configurados como resolvedores preferenciais, tendo precedência sobre os servidores DNS públicos, garantindo assim que a solicitação DNS inicial para uma resolução de nome seja enviada pelo túnel. Como as configurações de DNS são globais no Mac OS X, não é possível para consultas de DNS usar servidores DNS públicos fora do túnel conforme documentado em CSCtf2026 . Começando com o AnyConnect 4.2, as rotas de host para os servidores DNS de túnel são adicionadas automaticamente como redes com divisão de inclusão (rotas seguras) pelo cliente AnyConnect e, portanto, a lista de acesso com divisão de inclusão não exige mais a adição explícita da sub-rede do servidor DNS de túnel.

Configuração split-exclude (DNS de túnel total desabilitado e sem DNS dividido)

O AnyConnect não interfere no resolvedor de DNS nativo. Os servidores DNS do túnel são configurados como resolvedores preferenciais, tendo precedência sobre os servidores DNS públicos, garantindo assim que a solicitação DNS inicial para uma resolução de nome seja enviada pelo túnel. Como as configurações de DNS são globais no Mac OS X, não é possível para consultas de DNS usar servidores DNS públicos fora do túnel conforme documentado em CSCtf2026 . Começando com o AnyConnect 4.2, as rotas de host para os servidores DNS de túnel são adicionadas automaticamente como redes com divisão de inclusão (rotas seguras) pelo cliente AnyConnect e, portanto, a lista de acesso com divisão de inclusão não exige mais a adição explícita da sub-rede do servidor DNS de túnel.

DNS dividido (DNS túnel-tudo desabilitado, split-include configurado)

Se o DNS dividido estiver habilitado para ambos os protocolos IP (IPv4 e IPv6) ou estiver habilitado apenas para um protocolo e não houver nenhum pool de endereços configurado para o outro protocolo:
Um split-DNS real, semelhante ao do Windows, é aplicado. O DNS dividido verdadeiro significa que as solicitações correspondentes aos domínios DNS dividido são resolvidas apenas por meio do túnel, elas não vazam para os servidores DNS fora do túnel.

Se split-DNS for ativado para apenas um protocolo e um endereço de cliente for atribuído para o outro protocolo, somente "fallback de DNS para split-tunneling" será aplicado. Isso significa que a AC permite somente solicitações DNS correspondentes aos domínios split-DNS através do túnel (outras solicitações são respondidas pela AC com resposta "recusada" para forçar o failover para servidores DNS públicos), mas não pode impor que as solicitações correspondentes aos domínios split-DNS não sejam enviadas de forma limpa, através do adaptador público.

Linux

Configuração de túnel completo (e separação de túneis com DNS de túnel completo habilitado)

Quando o AnyConnect está conectado, somente os servidores DNS de túnel são mantidos na configuração DNS do sistema e, portanto, as solicitações DNS só podem ser enviadas aos servidores DNS de túnel.

Configuração split-include (DNS tunnel-all desabilitado e sem DNS dividido)

O AnyConnect não interfere no resolvedor de DNS nativo. Os servidores DNS do túnel são configurados como resolvedores preferenciais, tendo precedência sobre os servidores DNS públicos, garantindo assim que a solicitação DNS inicial para uma resolução de nome seja enviada pelo túnel.

Configuração split-exclude (DNS de túnel total desabilitado e sem DNS dividido)

O AnyConnect não interfere no resolvedor de DNS nativo. Os servidores DNS do túnel são configurados como resolvedores preferenciais, tendo precedência sobre os servidores DNS públicos, garantindo assim que a solicitação DNS inicial para uma resolução de nome seja enviada pelo túnel.

DNS dividido (DNS túnel-tudo desabilitado, split-include configurado)

Se split-DNS estiver habilitado, somente o "fallback de DNS para split-tunneling" será imposto. Isso significa que a AC permite somente solicitações DNS correspondentes aos domínios split-DNS através do túnel (outras solicitações são respondidas pela AC com resposta "recusada" para forçar o failover para servidores DNS públicos), mas não pode impor que as solicitações correspondentes aos domínios split-DNS não sejam enviadas de forma limpa, através do adaptador público.

Cliente de roaming do OpenDNS

O cliente de roaming é um software que gerencia serviços DNS no endpoint e utiliza os servidores DNS públicos OpenDNS para proteger e criptografar o tráfego DNS.

Idealmente, o cliente deve estar em um estado protegido e criptografado. No entanto, se o cliente não conseguir estabelecer uma sessão TLS com o servidor de resolvedor público OpenDNS (208.67.222.222), ele tentará enviar o tráfego DNS não criptografado na porta UDP 53 para 208.67.222.222. O cliente de roaming usa exclusivamente o endereço IP do resolvedor público do OpenDNS 208.67.222.222 (há alguns outros, como 208.67.220.220, 208.67.222.220 e 208.67.220.222). Uma vez instalado, o cliente de roaming define 127.0.0.1 (localhost) como o servidor DNS local e substitui as configurações DNS por interface atuais. As configurações atuais do DNS são armazenadas em arquivos resolv.conf locais (mesmo no Windows) na pasta de configuração do Roaming Client. O OpenDNS fará backup até mesmo dos servidores DNS que são aprendidos através do adaptador AnyConnect. Por exemplo, se 192.168.92.2 for o servidor DNS no adaptador público, o OpenDNS criará o resolv.conf no seguinte local:

C:\ProgramData\OpenDNS\ERC\Resolver1-LocalAreaConnection-resolv.conf
nameserver 192.168.92.2

O cliente de roaming criptografará cada pacote definido para o OpenDNS; no entanto, ele não inicia nem usa um túnel de criptografia para 208.67.222.222. O cliente de roaming tem um recurso de Imposição de Camada IP opcional que abrirá uma conexão IPSec para fins não-DNS para bloquear endereços IP. Isso será desabilitado automaticamente na presença de uma conexão ativa do AnyConnect. Ele também se vincula a 127.0.0.1:53 para receber consultas geradas localmente no computador. Quando o endpoint precisa resolver um nome, as consultas locais são direcionadas para 127.0.0.1 devido à substituição e, em seguida, o processo dnscrypt-proxy subjacente do cliente de roaming as encaminha para os servidores públicos OpenDNS pelo canal criptografado.

Se o DNS não tiver permissão para fluir para 127.0.0.1:53, o cliente de roaming não poderá funcionar e ocorrerá o seguinte. Se o cliente não puder acessar os servidores DNS públicos ou o endereço associado 127.0.0.1:53, ele fará a transição para um estado de abertura de falha e restaurará as configurações DNS nos adaptadores locais. Em segundo plano, ele continua a enviar sondas para 208.67.222.222 e pode fazer a transição para o modo ativo se a conexão segura for restabelecida.

Limitações

Depois de examinar a funcionalidade de alto nível de ambos os clientes, é evidente que o cliente de roaming precisa ter a capacidade de alterar as configurações locais do DNS e vincular a 127.0.0.1:53 para encaminhar consultas pelo canal seguro. Quando a VPN está conectada, as únicas configurações em que o AnyConnect não interfere no resolvedor de DNS nativo são split-include e split-exclude (com DNS split-tunnel-all desabilitado). Portanto, atualmente é recomendável usar uma dessas configurações, quando o cliente de roaming também estiver em uso. O cliente de roaming permanecerá em um estado desprotegido/não criptografado se a configuração tunnel-all for usada ou se o DNS split-tunnel-all estiver habilitado, como mostrado na imagem.

Solução

Se a intenção for proteger a comunicação entre o cliente de roaming e os servidores OpenDNS usando o túnel VPN, uma lista de acesso split-exclude fictícia poderá ser usada no headend da VPN. Isso será o mais próximo de uma configuração de túnel completo. Se não houver tal requisito, a divisão-inclusão pode ser usada onde a lista de acesso não inclui os servidores públicos OpenDNS, ou a divisão-exclusão pode ser usada onde a lista de acesso inclui os servidores públicos OpenDNS.

Além disso, ao usar o cliente de roaming, os modos split-DNS não podem ser usados, pois isso resultará em uma perda de resolução de DNS local. O DNS Split-tunnel-all também deve permanecer desabilitado; no entanto, ele tem suporte parcial e deve permitir que o cliente de roaming se torne criptografado após o failover. 

Configurações

Tráfego de túnel OpenDNS

Este exemplo usa um endereço IP fictício na lista de acesso split-exclude. Com essa configuração, toda a comunicação com 208.67.222.222 acontece através do túnel VPN, e o cliente de roaming opera em um estado criptografado e protegido.

ciscoasa# sh run access-li split
access-list split standard permit host 2.2.2.2

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy excludespecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

Excluir o tráfego do OpenDNS do túnel VPN

Este exemplo usa o endereço do resolvedor OpenDNS na lista de acesso split-exclude. Com essa configuração, toda a comunicação com 208.67.222.222 acontece fora do túnel VPN, e o cliente de roaming opera em um estado criptografado e protegido.

ciscoasa# sh run access-li split
access-list split standard permit host 208.67.222.222

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy excludespecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

Este exemplo mostra uma configuração split-include para uma sub-rede 192.168.1.0/24 interna . Com essa configuração, o cliente de roaming ainda operará em um estado criptografado e protegido, já que o tráfego para 208.67.222.222 não é enviado através do túnel.

ciscoasa# sh run access-li split
access-list split standard permit 192.168.1.0 255.255.255.0

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

Note: Split-tunnel-all-dns must be disabled in all of the  scenarios

Verificar

Quando a VPN está conectada, o cliente de roaming deve mostrar-se protegido e criptografado, como mostra a imagem: