Seguridad : Cliente de movilidad Cisco AnyConnect Secure

Diferencias del comportamiento con respecto a las interrogaciones DNS y resolución del Domain Name en diversos OS

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe cómo diversas interrogaciones del Domain Name System (DNS) de la manija de los sistemas operativos (OS) y las influencias en la resolución del Domain Name con Cisco AnyConnect y fractura o Tunelización lleno.

Contribuido por los ingenieros de Cisco TAC.

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 que se configuran en el movimiento adaptante del dispositivo de seguridad de Cisco (ASA) a través del túnel (a los servidores DNS que se definen en el ASA, por ejemplo) y otros no hacen.

  2. TÚNEL-TODO-DNS - Solamente el tráfico DNS a los servidores DNS que se definen en el ASA se permite. Esta configuración se configura en la directiva del grupo.

  3. DNS estándar - Todas las interrogaciones DNS se mueven a través de los servidores DNS que son definidos por el ASA. En el caso de una respuesta negativa, las interrogaciones DNS pudieron también ir a los servidores DNS que se configuran 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 que se definen para moverse a través del túnel van a cualquier servidor DNS que se defina en el ASA. Si no hay servidores DNS definidos en el ASA, después las configuraciones DNS son en blanco para el túnel. Si usted no hace el DNS dividido definir, después todas las interrogaciones DNS se envían a los servidores DNS que son definidos por el ASA. Sin embargo, los comportamientos que se describen en este documento pueden ser diferentes, dependiente sobre el operating system (OS).

Nota: Evite el uso del NSLookup cuando usted prueba la resolución de nombre en el cliente. En lugar, confíe en un navegador o utilice el comando ping. Esto es porque NSLookup no confía en el solucionador de DNS OS. AnyConnect no fuerza la petición DNS vía una cierta interfaz sino la permite o la rechaza dependiente sobre la configuración del DNS dividido. Para forzar el solucionador de DNS para intentar a un servidor DNS aceptable para una 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 (todas las aplicaciones excepto NSLookup, el empuje, y las aplicaciones similares que manejan la resolución de DNS solo, por ejemplo).

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 que se asocia 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 que se asocia a la interfaz física. Por eso esta característica no se llama DNS dividido, sino retraso DNS para el Túnel dividido. No sólo AnyConnect asegura que solamente las peticiones que apuntan los dominios del DNS dividido son tunneled adentro, él también confía 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 a un 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 Id. de bug Cisco CSCtn14578, resuelto actualmente en Microsoft 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 (el túnel toda la configuración), el tráfico DNS se permite estrictamente vía el túnel. El túnel toda la Configuración de DNS (configurada en la directiva del grupo) envía todas las búsquedas de DNS a través del túnel, junto con algún tipo de Túnel dividido, y el tráfico DNS se permite estrictamente vía el túnel.

Esto es constante a través de las Plataformas con una advertencia en Microsoft Windows: cuando se configura cualquier túnel todo o hace un túnel todo el DNS, AnyConnect permite el tráfico DNS estrictamente a los servidores DNS que se configuran 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 se debe enviar a los servidores DNS NON-VPN), después complete estos pasos:

  1. Si la configuración actual es túnel todo, después el permiso fractura-excluye el Tunelización. Cualquier solo host, fractura-excluye la red es aceptable para el uso, tal 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(4235) de AnyConnect

Este problema de Microsoft Windows es sobre todo inferior frecuente estas condiciones:

  • Con la configuración casera del router, asignan el DNS y los servidores DHCP 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.

  • Se utiliza una Túnel-toda configuración.

  • La resolución de nombre es realizada por un nombre del host NON-calificado, que implica que el software de resolución de nombres debe intentar varios sufijos DNS en todos los servidores DNS disponibles hasta que intenten el que está relevante al nombre del host preguntado.

Este problema es debido al cliente DNS nativo que intenta enviar las interrogaciones DNS vía el adaptador físico, que AnyConnect bloquea (dado la túnel-toda configuración). Esto lleva a un retardo de la resolución de nombre que pueda ser significativo, especialmente si un gran número de sufijos DNS son avanzados por el headend. El cliente DNS debe recorrer a través de todas las interrogaciones y servidores DNS disponibles hasta que reciba una respuesta positiva.

Este problema se resuelve en la versión 3.0(4235) de AnyConnect. Refiérase al bug Cisco ID CSCtq02141 y CSCtn14578, junto con la introducción a la solución verdadera anterior-mencionada del DNS dividido, para más información.

Si una actualización no puede ser implementada, después aquí están las soluciones alternativas posibles:

  • El permiso fractura-excluye el Tunelización para una dirección IP, 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 el Tunelización de la fractura-exclusión, habilite 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, realice estos cambios de configuración:

    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 debe 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 casilla de verificación del acceso del LAN local del permiso.

  • Utilice los nombres de dominio completamente calificado (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.

DNS con el Túnel dividido en diversos OS

Diversa manija DNS OS busca en las maneras diferentes cuando está utilizada con el Túnel dividido (sin el DNS dividido) para AnyConnect. Esta sección describe esas diferencias.

Microsoft Windows

En los sistemas de Microsoft Windows, las configuraciones DNS son por interface. Si se utiliza el Túnel dividido, las interrogaciones DNS pueden recurrir a los servidores DNS físicos del adaptador después de que fallen 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

En los sistemas Macintosh, las configuraciones DNS son globales. Si se utiliza el Túnel dividido, pero el DNS dividido no se utiliza, no es posible que las interrogaciones DNS alcancen 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 directiva del grupo y utilice un FQDN para las interrogaciones de los DN internos.

  • Si los nombres externos son resolvable a través del túnel, después navegue a avanzado > Túnel dividido y inhabilite el DNS dividido vía el retiro de los nombres DNS que se configuran en la directiva del grupo. Esto requiere el uso de un FQDN para las interrogaciones de los DN internos.

El caso del DNS dividido se ha resuelto en la versión 3.1 de AnyConnect. Sin embargo, usted debe asegurarse de que una de estas condiciones esté cumplido:

  • El DNS dividido se debe habilitar para ambos protocolos IP, que requiere la Versión de ASA 9.0 de Cisco o más adelante.

  • El DNS dividido se debe habilitar para uno protocolo IP. Si usted ejecuta la Versión de ASA 9.0 de Cisco o más adelante, después utilice el protocolo de puente del cliente para el otro protocolo IP. Por ejemplo, asegúrese de que no haya agrupación de direcciones y de que el protocolo de puente del cliente está habilitado en la directiva del grupo. Alternativamente, si usted funciona con una Versión de ASA que sea anterior que la versión 9.0, después asegúrese de que no haya agrupación de direcciones configurada para la otra protocolo IP. Esto implica que el otro protocolo IP es IPv6.

Nota: AnyConnect no cambia el archivo resolv.conf en el Macintosh OS X, sino cambia bastante las configuraciones X-específicas OS DNS. El Macintosh OS X mantiene el resolv.conffile actual por los motivos de compatibilidad. Utilice el scutil--comando dns para ver las configuraciones DNS en el Macintosh OS X.

iPhone

El iPhone es el contrario completo del sistema Macintosh y no es similar al Microsoft Windows. Si se define el Túnel dividido pero el DNS dividido no se define, después el DNS pregunta la salida a través del servidor DNS global se define que. 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 versión 2.5.4038 para el cliente IOS AnyConnect de Apple.

Nota: Sea consciente que las interrogaciones del iPhone DNS ignoran los dominios .local. Esto se documenta 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



Document ID: 116016