Seguridad : Cliente de movilidad Cisco AnyConnect Secure

Interrogaciones VPN, DNS, y variantes FAQ del sistema operativo/de la plataforma

6 Febrero 2014 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (28 Enero 2014) | Comentarios

Introducción

Este documento describe cómo diversas interrogaciones del Domain Name System (DNS) de la manija del Operations Support Systems (OSS) y su influencia en la resolución del Domain Name con AnyConnect.

Contribuido por los ingenieros de Cisco TAC.

¿Cuáles son las diferencias en las diversas OSS interrogaciones de la manija DNS de las Plataformas de las maneras, y cómo hace esa resolución del Domain Name de la influencia con AnyConnect y partir o el Tunelización lleno?

Fractura contra el DNS estándar

Cuando usted utiliza fractura-incluya el Tunelización, usted tienen tres opciones para el DNS:

  1. DNS dividido - Las interrogaciones DNS que hacen juego los Domain Name configurados en el dispositivo de seguridad adaptante de Cisco (ASA) pasan con el túnel, por ejemplo, a los servidores DNS definidas en el ASA, y otros no hacen.

  2. Túnel-todo-DNS - solamente el tráfico DNS a los servidores DNS definido en el ASA se permite. Esta configuración se configura en la directiva del grupo.

  3. DNS estándar - todas las interrogaciones DNS pasan a través de los servidores DNS definidas por el ASA y, en el caso de una respuesta negativa, pudieron también ir a los servidores DNS configurados en el adaptador físico.

Nota: El comando fractura-túnel-todo-dns primero fue implementado en la Versión de ASA 8.2(5). Antes de esta versión, usted podría hacer solamente el DNS dividido o el dns estándar.

En todos los casos, las interrogaciones DNS definidas para pasar a través del túnel van a cualquier servidor DNS definido en el ASA. Particularmente, si no hay servidores DNS definidos en el ASA, después las configuraciones DNS son en blanco para el túnel. Esto también significa eso, idealmente, si usted no hace el DNS dividido definir, después todas las interrogaciones DNS se envían al servidor DNS definidas por el ASA. Sin embargo, en la realidad, los comportamientos descritos en este documento pueden ser diferentes, dependiente en el sistema operativo.

Nota: Evite usando NSLookup cuando usted prueba la resolución de nombre en el cliente. En lugar, confíe en un navegador o utilice el ping. Esto es porque NSLookup no confía en el solucionador de DNS del operating system (OS), y por lo tanto, AnyConnect no fuerza la petición DNS vía una cierta interfaz. Lo permite solamente o lo rechaza, según la configuración del DNS dividido. Para forzar el solucionador de DNS para intentar un servidor DNS aceptable para esa petición, es importante que la prueba del DNS dividido está realizada solamente con las aplicaciones que confían en el solucionador de DNS nativo para la resolución del Domain Name. Por ejemplo, todas las aplicaciones excepto NSLookup, el empuje, y las aplicaciones similares, que manejan la resolución de DNS solo.

Verdad contra el mejor DNS dividido de esfuerzo

La versión 2,4 de AnyConnect soporta el retraso del DNS dividido (el mejor DNS dividido de esfuerzo), que no es el DNS dividido verdadero encontrado en el cliente IPSec de la herencia. Si la petición corresponde con un dominio del DNS dividido, AnyConnect permite la petición de ser tunneled adentro al ASA. Si el servidor no puede resolver el nombre del host, el solucionador de DNS continúa y envía la misma interrogación al servidor DNS asociado a la interfaz física. Por otra parte, si la petición no hace juego los dominios uces de los del DNS dividido, AnyConnect no la hace un túnel adentro al ASA. En lugar, construye una respuesta de DNS de modo que el solucionador de DNS baje y envíe la interrogación al servidor DNS asociado a la interfaz física. Por eso esta característica no se llama DNS dividido, sino retraso DNS para el Túnel dividido. Es decir no sólo AnyConnect asegura que solamente las peticiones qué dominios del DNS dividido de la blanco son tunneled adentro, él también confían en el comportamiento del solucionador de DNS del OS cliente para la resolución de nombre del host.

Esto despierta los problemas de seguridad debido al escape privado potencial del Domain Name. Por ejemplo, el cliente DNS nativo puede enviar una interrogación para un Domain Name privado a un servidor DNS público, específicamente cuando el servidor del nombre DNS VPN no podría resolver la interrogación DNS.

Refiera al bug CSCtn14578, resuelto actualmente en Microsoft (MS) Windows solamente, a partir de la versión 3.0.4235. La solución implementa el DNS dividido verdadero; pregunta estrictamente los Domain Name configurados que hacen juego y se permiten a los servidores DNS VPN. El resto de las interrogaciones se permiten solamente a otros servidores DNS, tales como ésos configurados en el adaptador físico.

“Haga un túnel todos” y “haga un túnel todo el DNS”

Cuando se inhabilita el Túnel dividido (la túnel-toda configuración), el tráfico DNS se permite estrictamente vía el túnel. Semejantemente, cuando el túnel toda la Configuración de DNS, que envía todas las búsquedas de DNS a través del túnel, se configura en la directiva del grupo, junto con algún tipo de Túnel dividido, tráfico DNS se permite estrictamente vía el túnel.

Esto es constante a través de las Plataformas, con estas advertencias en MS Windows:

Cuando ninguno de túnel-todo o hace un túnel todo el DNS se configura, AnyConnect permite el tráfico DNS estrictamente a los servidores DNS configurados en el gateway seguro (aplicado al adaptador VPN). Esto es una mejora de la seguridad implementada junto con la solución verdadera previamente mencionada del DNS dividido.

Si esto prueba problemático en ciertos escenarios (por ejemplo, la actualización DNS/los pedidos de inscripción necesita ser enviada a los servidores DNS NON-VPN), la solución alternativa de dos etapas es:

  1. Si la configuración actual es túnel-toda: el permiso fractura-excluye el Tunelización, cualquier un host falso fractura-excluye los trabajos de la red, tales como una dirección local del link.
  2. Asegúrese de que el túnel todo el DNS no esté configurado en la directiva del grupo.

Problema de rendimiento de DNS resuelto en la versión 3.0.4325 de AnyConnect

Este problema Windows-específico MS es sobre todo inferior frecuente estas condiciones:

  • Router casero puesto: esto donde el DNS y los servidores DHCP se asignan la misma dirección IP (AnyConnect crea una ruta necesario al servidor DHCP);
  • Un gran número de dominios DNS están en la directiva del grupo;
  • Túnel-toda configuración;
  • La resolución de nombre se realizó por un nombre del host NON-calificado, que implica que el software de resolución de nombres necesita intentar varios sufijos DNS en todos los servidores DNS disponibles hasta que el que está relevante al nombre del host preguntado se intente.

El problema es debido al cliente DNS nativo que intenta enviar las interrogaciones DNS vía el adaptador físico, cuyo AnyConnect bloquea (dado la túnel-toda configuración). Esto lleva a un retardo de la resolución de nombre. De la experiencia del cliente, este retardo es a veces significativo, especialmente para un gran número de sufijos DNS avanzados por el headend, puesto que el cliente DNS necesita recorrer a través de todos (y de todos los servidores DNS disponibles) hasta que reciba una respuesta positiva.

Este problema se resuelve en la versión 3.0.4325 (combinación del Id. de bug Cisco CSCtq02141 y CSCtn14578, junto con la introducción de la solución verdadera anterior-mencionada del DNS dividido).

Sin embargo, si una actualización no puede ser implementada, después las soluciones alternativas posibles son:

  • El permiso fractura-excluye el Tunelización para una dirección IP falsa, que permite las peticiones del DNS local de atravesar el adaptador físico. Usted puede utilizar un direccionamiento de la subred linklocal 169.254.0.0/16 porque es inverosímil que cualquier dispositivo envía el tráfico a uno de esos IP Addresses sobre el VPN. Después de que usted habilite la fractura excluya, recuerde habilitar el acceso en el perfil del cliente o en el cliente sí mismo del LAN local, y inhabilite el túnel todo el DNS. En el ASA, los cambios de configuración se enumeran aquí:

    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


    En el perfil del cliente, usted necesita solamente agregar esta línea:

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


    Usted puede también habilitar esto sobre una base del por-cliente en el cliente GUI de AnyConnect. Navegue al menú de la preferencia de AnyConnect, y marque la opción del acceso del LAN local del permiso.

  • Utilice los nombres de dominio completamente calificados (FQDN) en vez de los nombres del host incompetentes para las resoluciones de nombre.

  • Utilice una diversa dirección IP para el servidor DNS en la interfaz física.

¿Cómo cada sistema operativo trata del DNS?

Hay una diferencia de la manera diversos OS que la manija DNS busca cuando está utilizada con el Túnel dividido (sin el DNS dividido) para AnyConnect.

MS Windows

En MS Windows, las configuraciones DNS son por interface. Esto significa que, si se utiliza el Túnel dividido, las interrogaciones DNS pueden recurrir a los servidores DNS del adaptador físico si la interrogación falló en el adaptador del túnel VPN. Si el Túnel dividido sin el DNS dividido se define, después la resolución de DNS interna y externa trabaja porque recurre a los servidores DNS externos.

Macintosh

Con Macintosh (MAC), las configuraciones DNS son globales. Así, si se utiliza el Túnel dividido, solamente DNS dividido no se utiliza, él no es posible para que las interrogaciones DNS vayan a los servidores DNS fuera del túnel. Usted puede resolver solamente internamente, no externamente. Esto se documenta en el bug Cisco ID CSCtf20226 y CSCtz86314. En ambos casos, esta solución alternativa debe resolver el problema:

  • Especifique una dirección IP externa del servidor DNS bajo grupo-directiva y el uso FQDN para las interrogaciones de los DN internos.
  • Si los nombres externos son resolvable vía el túnel, inhabilite el DNS dividido quitando los nombres DNS configurados en la directiva del grupo, bajo avanzado > Túnel dividido. Esto requiere usando el FQDN para las interrogaciones de los DN internos.

El caso del DNS dividido se ha resuelto en AnyConnect 3,1, con estas advertencias:

  • El DNS dividido se debe habilitar para ambos protocolos IP (requiere ASA v9.0 o más adelante).


  • O

  • El DNS dividido se debe habilitar para uno protocolo IP.

       y
      
    • (Si el ASA tiene versión 9.0 o posterior: protocolo de puente del cliente para el otro protocolo IP, es decir, ninguna agrupación de direcciones y protocolo de ClientBypass habilitado en la directiva del grupo.

    •    o

    • Si el ASA es anterior que la versión 9.0: ninguna agrupación de direcciones configurada para la otra protocolo IP; esto implica que este otro protocolo IP es IPv6.)

Nota: AnyConnect no cambia el archivo resolv.conf directo en MAC OS X, sino cambia bastante las configuraciones X-específicas OS DNS. El OS X guarda resolv.confup-to-date por los motivos de compatibilidad. Utilice el scutil--comando dns de mirar las configuraciones DNS en OS X.

iPhone

El iPhone es el contrario completo del MAC, y no es lo mismo que MS Windows. Si se define el Túnel dividido pero el DNS dividido no se define, después las interrogaciones DNS salen a través del servidor DNS global definidas. Por ejemplo, las entradas de dominio del DNS dividido son obligatorias para la resolución interna. Este comportamiento se documenta en el Id. de bug Cisco CSCtq09624 y se repara en la última versión 2.5.4038 para el cliente IOS AnyConnect.

Nota: Sea consciente que las interrogaciones del iPhone DNS ignora los dominios .local, documentados en el Id. de bug Cisco CSCts89292. Los ingenieros de Apple confirman que el problema es causado por las funciones del OS. Éste es el comportamiento diseñado, y Apple confirma allí no es ningún cambio para él.

Información Relacionada


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 116016