Segurança : Cliente de mobilidade Cisco AnyConnect Secure

Perguntas VPN, DNS, e variações FAQ do sistema operacional/plataforma

6 Fevereiro 2014 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (28 Janeiro 2014) | Feedback

Introdução

Este documento descreve como perguntas diferentes do Domain Name System (DNS) do punho do Operations Support Systems (OSS) e sua influência na definição do Domain Name com AnyConnect.

Contribuído por engenheiros de TAC da Cisco.

Que são as diferenças nas perguntas diferentes do punho DNS das Plataformas das maneiras OSS, e como fazem essa definição do Domain Name da influência com AnyConnect e para rachar ou o Tunelamento completo?

Separação contra o DNS padrão

Quando você se usa separação-inclua o Tunelamento, você têm três opções de DNS:

  1. DNS em divisão - As perguntas DNS que combinam os Domain Name configurados na ferramenta de segurança adaptável de Cisco (ASA) atravessam o túnel, por exemplo, aos servidores DNS definidas no ASA, e outro não fazem.

  2. Túnel-todo-DNS - somente o tráfego DNS aos servidores DNS definido no ASA é permitido. Este ajuste é configurado na política do grupo.

  3. DNS padrão - todas as perguntas DNS atravessam os servidores DNS definidas pelo ASA e, no caso de uma resposta negativa, puderam igualmente ir aos servidores DNS configurados no adaptador físico.

Nota: O comando separação-túnel-todo-dns foi executado primeiramente na versão ASA 8.2(5). Antes desta versão, você poderia somente fazer o DNS em divisão ou o dns padrão.

Em todos os casos, as perguntas DNS definidas para atravessar o túnel vão a todos os servidores DNS definidos no ASA. Em particular, se não há nenhum servidor DNS definido no ASA, a seguir os ajustes DNS estão vazios para o túnel. Isto igualmente significa aquele, idealmente, se você não tem o DNS em divisão definido, a seguir todas as perguntas DNS estão enviadas ao servidor DNS definidas pelo ASA. Contudo, na realidade, os comportamentos descritos neste documento podem ser diferentes, dependente do sistema operacional.

Nota: Evite usar NSLookup quando você testa a resolução de nome no cliente. Em lugar de, confie em um navegador ou use o sibilo. Isto é porque NSLookup não confia no solucionador DNS do operating system (OS), e consequentemente, AnyConnect não força o pedido DNS através de uma determinada interface. Permite-o somente ou rejeita-o, de acordo com a configuração do DNS em divisão. A fim forçar o solucionador DNS para tentar um servidor DNS aceitável para esse pedido, é importante que o teste do DNS em divisão está executado somente com as aplicações que confiam no solucionador DNS nativo para a definição do Domain Name. Por exemplo, todas as aplicações exceto NSLookup, escavação, e as aplicações similares, que seguram a resolução de DNS sós.

Rectifique contra o melhor DNS em divisão do esforço

A liberação 2,4 de AnyConnect apoia a reserva do DNS em divisão (o melhor DNS em divisão do esforço), que não é o DNS em divisão verdadeiro encontrado no cliente de IPSec do legado. Se o pedido combina um domínio do DNS em divisão, AnyConnect permite que o pedido esteja escavado um túnel dentro ao ASA. Se o server não pode resolver o nome de host, o solucionador DNS continua e envia a mesma pergunta ao servidor DNS traçado à interface física. Por outro lado, se o pedido não combina alguns dos domínios do DNS em divisão, AnyConnect não o escava um túnel dentro ao ASA. Em lugar de, constrói uma resposta de DNS de modo que o solucionador DNS recue e envie a pergunta ao servidor DNS traçado à interface física. Esta característica não é chamada é por isso DNS em divisão, mas reserva DNS para o Split Tunneling. Ou seja faz não somente AnyConnect asseguram que somente os pedidos que domínios do DNS em divisão do alvo são escavados um túnel dentro, ele igualmente confiam no comportamento do solucionador DNS do SO de cliente para a resolução de nome do host.

Isto levanta os interesses de segurança devido ao escape privado potencial do Domain Name. Por exemplo, o cliente de DNS nativo pode enviar uma pergunta para um Domain Name privado a um servidor DNS público, especificamente quando o server de nome de DNS VPN não poderia resolver a pergunta DNS.

Consulte para introduzir erros de funcionamento CSCtn14578, resolvido atualmente em Microsoft (MS) Windows somente, até à data da versão 3.0.4235. A solução executa o DNS em divisão verdadeiro; pergunta restrita os Domain Name configurados que combinam e são permitidos aos servidores DNS VPN. Todas perguntas restantes são permitidas somente a outros servidores DNS, tais como aquelas configuradas no adaptador físico.

“Escave um túnel tudo” e “escave um túnel todo o DNS”

Quando o Split Tunneling estiver desabilitado (túnel-toda configuração), o tráfego DNS está permitido restrita através do túnel. Similarmente, quando o túnel toda a Configuração de DNS, que envia todas as pesquisas de DNS através do túnel, é configurado na política do grupo, junto com algum tipo de Split Tunneling, tráfego DNS é permitido restrita através do túnel.

Isto é consistente através das Plataformas, com estas advertências em MS Windows:

Quando algum do túnel-todo ou escavar um túnel todo o DNS é configurado, AnyConnect permite o tráfego DNS restrita aos servidores DNS configurados no Gateway seguro (aplicado ao adaptador de VPN). Este é um aprimoramento de segurança executado junto com a solução verdadeira previamente mencionada do DNS em divisão.

Se isto prova problemático em determinadas encenações (por exemplo, a actualização DNS/requisições de registro precisa de ser enviada aos servidores DNS NON-VPN), a ação alternativa do pas-de-deux é:

  1. Se a configuração atual é túnel-toda: permita separação-excluem o Tunelamento, todo o um host falso separação-excluem trabalhos da rede, tais como um endereço local de link.
  2. Assegure-se de que o túnel todo o DNS não esteja configurado na política do grupo.

Edição de desempenho DNS resolvida na versão 3.0.4325 de AnyConnect

Esta edição Windows-específica MS é na maior parte predominante sob estas condições:

  • Roteador home setup: isto onde o DNS e os servidores DHCP são atribuídos o mesmo endereço IP de Um ou Mais Servidores Cisco ICM NT (AnyConnect cria uma rota necessária ao servidor DHCP);
  • Um grande número domínios de DNS estão na política do grupo;
  • Túnel-toda configuração;
  • A resolução de nome executou por um nome de host NON-qualificado, que implicasse que o resolver precisa de tentar um número de sufixos DNS em todos os servidores DNS disponíveis até que esse relevante ao nome de host perguntado esteja tentado.

A edição é devido ao cliente de DNS nativo que tenta enviar perguntas DNS através do adaptador físico, de que AnyConnect obstrui (dado túnel-toda configuração). Isto conduz a um atraso da resolução de nome. Da experiência do cliente, este atraso é às vezes significativo, especialmente para um grande número sufixos DNS empurrados pelo final do cabeçalho, desde que o cliente de DNS precisa de andar através de todo (e de todos os servidores DNS disponíveis) até que receba uma resposta positiva.

Este problema é resolvido na versão 3.0.4325 (combinação da identificação de bug Cisco CSCtq02141 e CSCtn14578, junto com a introdução da solução verdadeira precedente-mencionada do DNS em divisão).

Contudo, se uma elevação não pode ser executada, a seguir as alternativas possíveis são:

  • Enable separação-exclui o Tunelamento para um endereço IP de Um ou Mais Servidores Cisco ICM NT falso, que permite pedidos do DNS local correr através do adaptador físico. Você pode usar um endereço da sub-rede linklocal 169.254.0.0/16 porque é improvável que qualquer dispositivo envia o tráfego a um daqueles endereços IP de Um ou Mais Servidores Cisco ICM NT sobre o VPN. Depois que você permite a separação exclua, recorde-o permitir o acesso no perfil do cliente ou no cliente próprio do LAN local, e desabilite-o o túnel todo o DNS. No ASA, as alterações de configuração são alistadas aqui:

    access-list acl_linklocal_169.254.1.1 standard permit host 169.254.1.1
    group-policy gp_access-14 attributes
    split-tunnel-policy excludespecified
    split-tunnel-network-list value acl_linklocal_169.254.1.1
    split-tunnel-all-dns disable
    exit


    No perfil do cliente, você precisa somente de adicionar esta linha:

    <LocalLanAccess UserControllable="true">true</LocalLanAccess>


    Você pode igualmente permitir este em uma base do por-cliente no cliente GUI de AnyConnect. Navegue ao menu da preferência de AnyConnect, e verifique a opção do acesso do LAN local da possibilidade.

  • Use os nomes de domínio totalmente qualificados (FQDNs) em vez dos nomes de host incompetentes para as resoluções de nome.

  • Use um endereço IP de Um ou Mais Servidores Cisco ICM NT diferente para o servidor DNS na interface física.

Como cada sistema operacional trata o DNS?

Há uma diferença na maneira OS que diferentes o punho DNS procurara quando usado com Split Tunneling (sem DNS em divisão) por AnyConnect.

MS Windows

Em MS Windows, os ajustes DNS são interface per. Isto significa que, se o Split Tunneling é usado, as perguntas DNS podem cair de volta aos servidores DNS do adaptador físico se a pergunta falhou no adaptador do túnel VPN. Se o Split Tunneling sem DNS em divisão é definido, a seguir a resolução de DNS interna e externo trabalha porque cai de volta aos servidores DNS externos.

Macintosh

Com Macintosh (MAC), os ajustes DNS são globais. Assim, se o Split Tunneling é usado, mas DNS em divisão não é usado, ele não é possível para que as perguntas DNS vão aos servidores DNS fora do túnel. Você pode somente resolver internamente, não externamente. Isto é documentado no Bug da Cisco ID CSCtf20226 e CSCtz86314. Em ambos os casos, esta ação alternativa deve resolver a edição:

  • Especifique um endereço IP de Um ou Mais Servidores Cisco ICM NT externo do servidor DNS sob o FQDN da grupo-política e do uso para perguntas dos DN internos.
  • Se os nomes externos são solucionáveis através do túnel, desabilite o DNS em divisão removendo os nomes de DNS configurados na política do grupo, sob avançado > Split Tunneling. Isto exige usando o FQDN para perguntas dos DN internos.

O exemplo do DNS em divisão foi resolvido em AnyConnect 3,1, com estas advertências:

  • O DNS em divisão deve ser permitido para ambos os protocolos IP (exige ASA v9.0 ou mais tarde).


  • OU

  • O DNS em divisão deve ser permitido para um protocolo IP.

       e
      
    • (Se o ASA tem a versão 9.0 ou mais recente: protocolo do desvio do cliente para o outro protocolo IP, isto é, nenhuns conjunto de endereços e protocolo de ClientBypass permitido na política do grupo.

    •    ou

    • Se o ASA está mais adiantado do que a versão 9.0: nenhum conjunto de endereços configurado para o outro protocolo IP; isto implica que este outro protocolo IP é IPv6.)

Nota: AnyConnect não muda o arquivo resolv.conf direto em MAC OS X, mas muda um pouco ajustes X-específicos do OS DNS. O OS X mantem resolv.confup-to-date para razões de compatibilidade. Use o scutil--comando dns olhar ajustes DNS no OS X.

iPhone

O iPhone é o oposto completo do MAC, e não é o mesmo que MS Windows. Se o Split Tunneling é definido mas o DNS em divisão não está definido, a seguir as perguntas DNS saem através do servidor DNS global definidas. Por exemplo, as entradas de domínio do DNS em divisão são imperativas para a definição interna. Este comportamento é documentado na identificação de bug Cisco CSCtq09624 e fixado na versão 2.5.4038 a mais atrasada para o cliente iOS AnyConnect.

Nota: Esteja ciente que perguntas do iPhone DNS ignora os domínios .local, documentados na identificação de bug Cisco CSCts89292. Os coordenadores de Apple confirmam que a edição está causada pela funcionalidade do OS. Este é o comportamento projetado, e Apple não confirma lá é nenhuma mudança para ela.

Informações Relacionadas


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 116016