El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo Cisco OS® maneja las consultas DNS y los efectos en la resolución de nombres de dominio con Cisco AnyConnect y tunelización dividida o completa.
No hay requisitos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Cuando utiliza la tunelización split-include, estas son las tres opciones que tiene para el Sistema de nombres de dominio (DNS):
Nota: El comando split-tunnel-all-dns se implementó por primera vez en la versión 8.2(5) de ASA. Antes de esta versión, solo podía dividir DNS o DNS estándar.
En todos los casos, las consultas DNS que se definen para moverse a través del túnel, van a cualquier servidor DNS que sea definido por ASA. Si ASA no ha definido ningún servidor DNS, los parámetros de DNS del túnel estarán vacíos. Si no tiene DNS dividido definido, todas las consultas DNS se envían a los servidores DNS definidos por el ASA. Sin embargo, los comportamientos que se describen en este documento pueden ser diferentes, en función del sistema operativo (SO).
Nota: evite el uso de NSLookup cuando pruebe la resolución de nombres en el cliente. En su lugar, confíe en un navegador o utilice el comando ping. Esto se debe a que NSLookup no depende de la resolución DNS del sistema operativo. AnyConnect no fuerza la solicitud de DNS a través de una interfaz determinada, pero la permite o la rechaza en función de la configuración de DNS dividido. Para obligar a la resolución de DNS a probar un servidor DNS aceptable para una solicitud, es importante que la prueba de DNS dividido sólo se realice con aplicaciones que dependen de la resolución de DNS nativo para la resolución de nombres de dominio (todas las aplicaciones excepto NSLookup, Dig y aplicaciones similares que controlan la resolución de DNS por sí mismas, por ejemplo).
La versión 2.4 de AnyConnect admite la reserva de DNS dividido (DNS dividido según el mejor esfuerzo), que no es el verdadero DNS dividido y se encuentra en el cliente IPsec heredado. Si la solicitud coincide con un dominio DNS dividido, AnyConnect permite que la solicitud se tunelice en el ASA. Si el servidor no puede resolver el nombre de host, la resolución de DNS continúa y envía la misma consulta al servidor DNS asignado a la interfaz física.
Por otro lado, si la solicitud no coincide con ninguno de los dominios DNS divididos, AnyConnect no lo tuneliza en el ASA. En su lugar, genera una respuesta DNS para que la resolución de DNS retroceda y envíe la consulta al servidor DNS asignado a la interfaz física. Es por eso que esta función no se llama split DNS, sino DNS fallback para split tunneling. AnyConnect no solo garantiza que solo se tunelizan las solicitudes que tienen como destino dominios DNS divididos, sino que también se basa en el comportamiento de resolución de DNS del sistema operativo del cliente para la resolución de nombres de host.
Esto plantea problemas de seguridad debido a una posible filtración de nombres de dominio privado. Por ejemplo, el cliente DNS nativo puede enviar una consulta para un nombre de dominio privado a un servidor DNS público específicamente cuando el servidor de nombres DNS VPN no pudo resolver la consulta DNS.
Consulte Cisco bug ID CSCtn14578, actualmente resuelto en Microsoft Windows solamente, a partir de la versión 3.0(4235). La solución implementa un verdadero DNS dividido, consulta estrictamente los nombres de dominio configurados que coinciden y se les permite a los servidores DNS VPN. El resto de las consultas sólo se permiten a otros servidores DNS, como los configurados en los adaptadores físicos.
Nota: Solo los usuarios registrados de Cisco tienen acceso a la información y las herramientas internas de Cisco.
Cuando se inhabilita la tunelización dividida (la configuración Tunnel-all), el tráfico DNS se permite estrictamente a través del túnel. La configuración Tunnel-all DNS (configurada en la política de grupo) envía todas las búsquedas de DNS a través del túnel, junto con algún tipo de tunelización dividida, y el tráfico DNS se permite estrictamente a través del túnel.
Esto es coherente en todas las plataformas con una advertencia en Microsoft Windows: cuando se configura cualquier DNS Tunnel-all o Tunnel-all, AnyConnect permite el tráfico DNS estrictamente a los servidores DNS que se configuran en el gateway seguro (aplicado al adaptador VPN). Se trata de una mejora de la seguridad implementada junto con la solución de DNS dividido verdadero mencionada anteriormente.
Si esto resulta problemático en ciertos escenarios (por ejemplo, las solicitudes de actualización/registro de DNS se deben enviar a servidores DNS que no sean VPN), siga estos pasos:
Este problema de Microsoft Windows es predominante en las siguientes condiciones:
Este problema se resuelve en AnyConnect versión 3.0(4235). Consulte los ID de bug Cisco CSCtq02141 y el ID de bug Cisco CSCtn14578, junto con la introducción a la solución de DNS dividido verdadero mencionada anteriormente, para obtener más información.
Nota: Solo los usuarios registrados de Cisco tienen acceso a la información y las herramientas internas de Cisco.
Si no se puede implementar una actualización, estas son las soluciones alternativas posibles:
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
<LocalLanAccess UserControllable="true">true</LocalLanAccess>
Los distintos sistemas operativos de Cisco gestionan las búsquedas de DNS de distintas formas cuando se utilizan con tunelación dividida (sin DNS dividido) para AnyConnect. Esta sección describe esas diferencias.
En los sistemas Microsoft Windows, la configuración de DNS es por interfaz. Si se utiliza la tunelización dividida, las consultas DNS pueden recurrir a los servidores DNS del adaptador físico después de que fallan en el adaptador de túnel VPN. Si se define la tunelización dividida sin DNS dividido, la resolución de DNS interno y externo funciona porque recurre a los servidores DNS externos.
Se ha producido un cambio en el comportamiento del mecanismo DNS que gestiona esto en AnyConnect para Windows, en la versión 4.2 después de la corrección del error de Cisco con ID CSCuf07885.
Nota: Solo los usuarios registrados de Cisco tienen acceso a la información y las herramientas internas de Cisco.
Configuración de túnel completo (y túnel dividido con DNS de túnel completo habilitado)
Antes de AnyConnect 4.2:
Sólo se permiten las solicitudes DNS a servidores DNS configurados en la directiva de grupo (servidores DNS de túnel). El controlador de AnyConnect responde a todas las demás solicitudes con una respuesta de "no existe tal nombre". Como resultado, la resolución de DNS solo se puede realizar con los servidores DNS de túnel.
AnyConnect 4.2+
Se permiten las solicitudes DNS a cualquier servidor DNS, siempre que se originen en el adaptador VPN y se envíen a través del túnel. El resto de las solicitudes se responden con ningún nombre , y la resolución de DNS solo se puede realizar a través del túnel VPN.
Antes de la corrección del Id. de error de Cisco CSCuf07885, AC restringía los servidores DNS de destino; sin embargo, con la corrección de este error, ahora restringe qué adaptadores de red pueden iniciar solicitudes DNS.
Nota: Solo los usuarios registrados de Cisco tienen acceso a la información y las herramientas internas de Cisco.
El controlador de AnyConnect no interfiere con la resolución DNS nativa. Por lo tanto, la resolución de DNS se realiza en función del orden de los adaptadores de red, donde AnyConnect es siempre el adaptador preferido cuando se conecta VPN. Además, una consulta de DNS se envía primero a través del túnel y, si no se resuelve, la resolución intenta resolverla a través de la interfaz pública. La lista de acceso split-include incluye la subred que cubre los servidores DNS del túnel. Para empezar con AnyConnect 4.2, el cliente AnyConnect agrega automáticamente las rutas de host para los servidores DNS del túnel como redes de inclusión dividida (rutas seguras) y, por lo tanto, la lista de acceso de inclusión dividida ya no requiere la adición explícita de la subred del servidor DNS del túnel.
El controlador de AnyConnect no interfiere con la resolución DNS nativa. Por lo tanto, la resolución de DNS se realiza en función del orden de los adaptadores de red, donde AnyConnect es siempre el adaptador preferido cuando se conecta VPN. Además, una consulta de DNS se envía primero a través del túnel y, si no se resuelve, la resolución intenta resolverla a través de la interfaz pública. La lista de acceso split-exclude no debe incluir la subred que cubre los servidores DNS de túnel. Para empezar con AnyConnect 4.2, las rutas de host para los servidores DNS de túnel se agregan automáticamente como redes split-include (rutas seguras) por el cliente AnyConnect y, por lo tanto, evita el error de configuración en la lista de acceso split-exclude.
Anterior a AnyConnect 4.2
Las solicitudes DNS, que coinciden con los dominios split-dns, pueden tunelizar servidores DNS, pero no se permiten a otros servidores DNS. Para evitar que estas consultas de DNS internas se filtren por el túnel, el controlador de AnyConnect responde con "no existe tal nombre" si la consulta se envía a otros servidores DNS. Por lo tanto, los dominios split-dns sólo se pueden resolver a través de servidores DNS de túnel.
Las solicitudes DNS, que no coinciden con los dominios split-dns, se permiten a otros servidores DNS, pero no a los servidores DNS de túnel. Incluso en este caso, el controlador de AnyConnect responde con "no existe tal nombre" si se intenta realizar una consulta de dominios no split-dns a través del túnel. Por lo tanto, los dominios sin split-dns sólo se pueden resolver a través de servidores DNS públicos fuera del túnel.
AnyConnect 4.2+
Las solicitudes DNS, que coinciden con los dominios split-dns, se permiten a cualquier servidor DNS, siempre que se originen desde el adaptador VPN. Si la consulta es originada por la interfaz pública, el controlador de AnyConnect responde con un "no tal nombre" para forzar a la resolución a utilizar siempre el túnel para la resolución de nombres. Por lo tanto, los dominios split-dns sólo se pueden resolver a través del túnel.
Las solicitudes DNS, que no coinciden con los dominios split-dns, se permiten en cualquier servidor DNS siempre que se originen en el adaptador físico. Si la consulta la origina el adaptador VPN, AnyConnect responde con "no existe tal nombre" para forzar a la resolución a intentar siempre la resolución del nombre a través de la interfaz pública. Por lo tanto, los dominios no split-dns sólo se pueden resolver a través de una interfaz pública.
En los sistemas Macintosh, la configuración DNS es global. Si se utiliza la tunelización dividida, pero no se utiliza el DNS dividido, no es posible que las consultas DNS alcancen a los servidores DNS fuera del túnel. Sólo se puede resolver internamente, no externamente.
Esto se documenta en el ID de bug de Cisco CSCtf20226 y el ID de bug de Cisco CSCtz86314. En ambos casos, esta solución alternativa debe resolver el problema:
El caso de DNS dividido se resuelve en AnyConnect versión 3.1. Sin embargo, debe asegurarse de que se cumple una de estas condiciones:
Nota: AnyConnect no cambia el archivo resolv.conf en Macintosh OS X, sino que cambia la configuración DNS específica de OS X. Macintosh OS X mantiene actualizado el archivo resolv.conf por motivos de compatibilidad. Utilice el comando scutil —dns para ver la configuración de DNS en Macintosh OS X.
Cuando AnyConnect está conectado, solo los servidores DNS de túnel se mantienen en la configuración DNS del sistema y, por lo tanto, las solicitudes DNS solo se pueden enviar a los servidores DNS de túnel.
AnyConnect no interfiere con la resolución DNS nativa. Los servidores DNS de túnel se configuran como resolvers preferidos, lo que tiene prioridad sobre los servidores DNS públicos, por lo que garantiza que la solicitud DNS inicial para una resolución de nombre se envíe a través del túnel. Dado que la configuración de DNS es global en Mac OS X, no es posible que las consultas DNS utilicen servidores DNS públicos fuera del túnel como se documenta en el ID de bug de Cisco CSCtf2026 . Para empezar con AnyConnect 4.2, el cliente AnyConnect agrega automáticamente las rutas de host para los servidores DNS del túnel como redes de inclusión dividida (rutas seguras) y, por lo tanto, la lista de acceso de inclusión dividida ya no requiere la adición explícita de la subred del servidor DNS del túnel.
AnyConnect no interfiere con la resolución DNS nativa. Los servidores DNS de túnel se configuran como resolvers preferidos, tienen prioridad sobre los servidores DNS públicos, por lo que esto garantiza que la solicitud DNS inicial para una resolución de nombre se envíe a través del túnel. Dado que la configuración de DNS es global en Mac OS X, no es posible que las consultas DNS utilicen servidores DNS públicos fuera del túnel como se documenta en el ID de bug de Cisco CSCtf2026 . Para empezar con AnyConnect 4.2, el cliente AnyConnect agrega automáticamente las rutas de host para los servidores DNS del túnel como redes de inclusión dividida (rutas seguras) y, por lo tanto, la lista de acceso de inclusión dividida ya no requiere la adición explícita de la subred del servidor DNS del túnel.
Si split-DNS está habilitado para ambos protocolos IP (IPv4 e IPv6) o sólo está habilitado para un protocolo y no hay ningún conjunto de direcciones configurado para el otro protocolo:
Se aplica un split-DNS real similar a Windows. True split-DNS significa que las solicitudes que coinciden con los dominios split-DNS sólo se resuelven a través del túnel, no se filtran a los servidores DNS fuera del túnel.
Si split-DNS está habilitado solo para un protocolo y se asigna una dirección de cliente para el otro protocolo, solo se aplica el último recurso de DNS para la tunelización dividida. Esto significa que AC solo permite la solicitud DNS que coincide con los dominios split-DNS a través del túnel (otras solicitudes son contestadas por AC con respuesta "rechazada" para forzar la conmutación por fallas a los servidores DNS públicos), pero no puede hacer cumplir la solicitud que coincide con los dominios split-DNS que no se envían en forma clara, a través del adaptador público.
Cuando AnyConnect está conectado, solo los servidores DNS de túnel se mantienen en la configuración DNS del sistema y, por lo tanto, las solicitudes DNS solo se pueden enviar a los servidores DNS de túnel.
AnyConnect no interfiere con la resolución DNS nativa. Los servidores DNS de túnel se configuran como resolvers preferidos, lo que tiene prioridad sobre los servidores DNS públicos, por lo que garantiza que la solicitud DNS inicial para una resolución de nombre se envíe a través del túnel.
AnyConnect no interfiere con la resolución DNS nativa. Los servidores DNS de túnel se configuran como resolvers preferidos, lo que tiene prioridad sobre los servidores DNS públicos, por lo que garantiza que la solicitud DNS inicial para una resolución de nombre se envíe a través del túnel.
Si split-DNS está habilitado, solo se aplica el respaldo DNS para la tunelización dividida. Esto significa que AC solo permite la solicitud DNS que coincide con los dominios split-DNS a través del túnel (otras solicitudes son contestadas por AC con respuesta "rechazada" para forzar la conmutación por fallas a los servidores DNS públicos), pero no puede hacer cumplir esa solicitud que coincide con los dominios split-DNS que no se envían en forma clara, a través del adaptador público.
El iPhone es el opuesto completo del sistema Macintosh y no es similar a Microsoft Windows. Si se define la tunelización dividida pero no se define el DNS dividido, las consultas DNS salen a través del servidor DNS global definido. Por ejemplo, las entradas de dominio DNS dividido son obligatorias para la resolución interna. Este comportamiento se documenta en el ID de bug de Cisco CSCtq09624 y se corrige en la versión 2.5.4038 para el cliente de Apple iOS AnyConnect.
Nota: Tenga en cuenta que las consultas de DNS del iPhone ignoran los dominios .locales. Esto se documenta con el ID de bug de Cisco CSCts89292. Los ingenieros de Apple confirman que el problema se debe a la funcionalidad del sistema operativo. Este es el comportamiento diseñado, y Apple confirma que no hay cambios para él.
Nota: Solo los usuarios registrados de Cisco tienen acceso a la información y las herramientas internas de Cisco.
Id. de error de Cisco CSCtn14578: AnyConnect para admitir DNS dividido verdadero; no reserva
ID de bug de Cisco CSCts89292 - AC para consultas de DNS de iPhone ignorar dominios .locales
Revisión | Fecha de publicación | Comentarios |
---|---|---|
3.0 |
23-May-2024 |
Recertificación |
1.0 |
12-Jun-2014 |
Versión inicial |