Sécurité : Client à mobilité sécurisé Cisco AnyConnect

VPN, requêtes DNS, et Foire aux questions de variantes de système d'exploitation/plate-forme

6 février 2014 - Traduction automatique
Autres versions: PDFpdf | Anglais (28 janvier 2014) | Commentaires

Introduction

Ce document décrit comment différentes requêtes de Système de noms de domaine (DNS) de traitement de systèmes de support d'exécutions (SYSTÈMES D'EXPLOITATION) et leur affect sur la résolution de nom de domaine avec AnyConnect.

Contribué par des ingénieurs TAC Cisco.

Quelles sont les différences dans les différentes requêtes DNS de traitement de Plateformes de SYSTÈMES D'EXPLOITATION de manières, et comment font cette résolution de nom de domaine d'affect avec AnyConnect et séparer ou plein Tunnellisation ?

Fractionnement contre les DN standard

Quand vous utilisez fractionnement-incluez le Tunnellisation, vous ont trois options pour des DN :

  1. Split-dns - Les requêtes DNS qui apparient les noms de domaine configurés sur l'appliance de sécurité adaptable Cisco (ASA) passent par le tunnel, par exemple, aux serveurs DNS définis sur l'ASA, et d'autres ne font pas.

  2. Tunnel-tout-DN - seulement le trafic DNS aux serveurs DNS définis sur l'ASA est permis. Cette configuration est configurée dans la stratégie de groupe.

  3. DN standard - toutes les requêtes DNS passent par les serveurs DNS définis par l'ASA et, dans le cas d'une réponse négative, pourraient également aller aux serveurs DNS configurés sur l'adaptateur physique.

Remarque: La commande de fractionnement-tunnel-tout-dn a été mise en application la première fois dans la version 8.2(5) ASA. Avant cette version, vous pourriez seulement faire le split-dns ou les dn standard.

Dans des tous les cas, les requêtes DNS définies pour passer par le tunnel vont à tous les serveurs DNS définis sur l'ASA. En particulier, s'il n'y a aucun serveur DNS défini sur l'ASA, puis les configurations de DN sont vides pour le tunnel. Ceci signifie également cela, idéalement, si vous ne faites pas définir le split-dns, alors toutes les requêtes DNS sont envoyées au serveur DNS défini par l'ASA. Cependant, en réalité, les comportements décrits dans ce document peuvent être différents, dépendant du système d'exploitation.

Remarque: Évitez utilisant NSLookup quand vous testez la résolution de noms sur le client. Au lieu de cela, comptez sur un navigateur ou utilisez le ping. C'est parce que NSLookup ne se fonde pas sur le résolveur du système d'exploitation de DN (de SYSTÈME D'EXPLOITATION), et donc, AnyConnect ne force pas la demande de DN par l'intermédiaire d'une certaine interface. Il le permet seulement ou le rejette, selon la configuration de split-dns. Afin de forcer le résolveur de DN à juger un serveur DNS acceptable pour cette demande, il est important que l'essai de split-dns soit seulement réalisé avec les applications qui se fondent sur le résolveur indigène de DN pour la résolution de nom de domaine. Par exemple, toutes les applications excepté NSLookup, fouille, et applications semblables, qui traitent la résolution de DN seuls.

Rectifiez contre le split-dns de meilleur effort

La version 2.4 d'AnyConnect prend en charge le retour de split-dns (split-dns de meilleur effort), qui n'est pas le split-dns vrai trouvé dans le client existant d'IPSec. Si la demande apparie un domaine de split-dns, AnyConnect permet la demande d'être percé un tunnel dedans à l'ASA. Si le serveur ne peut pas résoudre le nom d'hôte, le résolveur de DN continue et envoie la même requête au serveur DNS tracé à l'interface physique. D'autre part, si la demande n'apparie pas les domaines l'uns des de split-dns, AnyConnect ne la perce pas un tunnel dedans à l'ASA. Au lieu de cela, il établit une réponse de DN de sorte que le résolveur de DN tombe de retour et envoie la requête au serveur DNS tracé à l'interface physique. C'est pourquoi cette caractéristique ne s'appelle pas le split-dns, mais retour de DN pour la Segmentation de tunnel. En d'autres termes, non seulement AnyConnect s'assure que seulement les demandes quels domaines de split-dns de cible sont percés un tunnel dedans, il se fonde également sur le comportement du résolveur de DN de SYSTÈME D'EXPLOITATION de client pour la résolution de noms d'hôte.

Ceci soulève des problèmes de sécurité dus à la fuite privée potentielle de nom de domaine. Par exemple, le client DNS indigène peut envoyer une requête pour un nom de domaine privé à un serveur DNS public, spécifiquement quand le serveur de nom DNS VPN ne pourrait pas résoudre la requête DNS.

Référez-vous à la bogue CSCtn14578, actuellement résolue sur Microsoft (MS) Windows seulement, en date de la version 3.0.4235. La solution implémente le split-dns vrai ; il questionne strictement les noms de domaine configurés qui s'assortissent et sont autorisés aux serveurs DNS VPN. On permet seulement toutes autres requêtes à d'autres serveurs DNS, comme ceux configurés sur les adaptateurs physiques.

« Percez un tunnel tous » et « percez un tunnel tous les DN »

Quand la Segmentation de tunnel est désactivée (la tunnel-toute configuration), on permet strictement le trafic DNS par l'intermédiaire du tunnel. De même, quand le tunnel toute la configuration DNS, qui envoie toutes les consultations de DN par le tunnel, est configuré dans la stratégie de groupe, avec un certain type de Segmentation de tunnel, le trafic DNS est autorisé strictement par l'intermédiaire du tunnel.

C'est compatible à travers des Plateformes, à ces mises en garde sur le MS Windows :

Quand n'importe lequel de tunnel-tout ou perce un tunnel tous les DN est configuré, AnyConnect permet le trafic DNS strictement aux serveurs DNS configurés sur la passerelle sécurisée (appliquée à l'adaptateur VPN). C'est une amélioration de la sécurité mise en application avec la véritable solution précédemment mentionnée de split-dns.

Si ceci prouve problématique dans certains scénarios (par exemple, la mise à jour de DN/demandes d'enregistrement doit être envoyée aux serveurs DNS non-VPN), le contournement en deux étapes est :

  1. Si la configuration en cours est tunnel-toute : l'enable fractionnement-excluent le Tunnellisation, n'importe quel un hôte factice fractionnement-excluent des travaux de réseau, tels qu'une adresse locale à la liaison.
  2. Assurez-vous que le tunnel tous les DN n'est pas configuré dans la stratégie de groupe.

Problème de performance de DN résolu dans la version 3.0.4325 d'AnyConnect

Cette question de Windows-particularité de MS est en grande partie de dessous répandu ces conditions :

  • Routeur domestique installé : ceci où les DN et les serveurs DHCP sont assignés la même adresse IP (AnyConnect crée une artère nécessaire au serveur DHCP) ;
  • Un grand nombre de domaines de DN sont dans la stratégie de groupe ;
  • Tunnel-toute configuration ;
  • Résolution de noms exécutée par un nom d'hôte non-qualifié, qui implique que le résolveur doit essayer un certain nombre de suffixes de DN sur tous les serveurs DNS disponibles jusqu'à ce que celui concernant le nom d'hôte questionné soit tenté.

La question est due au client DNS indigène qui tente d'envoyer des requêtes DNS par l'intermédiaire de l'adaptateur physique, dont AnyConnect bloque (donné la tunnel-toute configuration). Ceci mène à un retard de résolution de noms. De l'expérience client, ce retard est parfois significatif, particulièrement pour un grand nombre de suffixes de DN poussés par le headend, puisque le client DNS doit marcher par tous (et tous les serveurs DNS disponibles) jusqu'à ce qu'il reçoive une réaction favorable.

Ce problème est résolu dans la version 3.0.4325 (combinaison d'ID de bogue Cisco CSCtq02141 et CSCtn14578, avec l'introduction de la véritable solution précédent-mentionnée de split-dns).

Cependant, si une mise à jour ne peut pas être mise en application, puis les contournements possibles sont :

  • L'enable fractionnement-excluent le Tunnellisation pour une adresse IP factice, qui permet des demandes locales de DN de traverser l'adaptateur physique. Vous pouvez utiliser une adresse du sous-réseau linklocal 169.254.0.0/16 parce qu'il est peu probable que n'importe quel périphérique envoie le trafic à une de ces adresses IP au-dessus du VPN. Après que vous activiez le fractionnement l'excluez, souvenez-vous pour activer l'accès local au LAN sur le profil de client ou sur le client lui-même, et désactivez le tunnel tous les DN. Sur l'ASA, les modifications de configuration sont répertoriées ici :

    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


    Sur le profil de client, vous devez seulement ajouter cette ligne :

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


    Vous pouvez également activer ceci sur une base de par-client dans le GUI de client d'AnyConnect. Naviguez vers le menu préférences d'AnyConnect, et vérifiez l'option d'accès local au LAN d'enable.

  • Utilisez les noms de domaine complet (FQDN) au lieu des noms d'hôte sans réserve pour les résolutions de noms.

  • Utilisez une adresse IP différente pour le serveur DNS sur l'interface physique.

Comment chaque système d'exploitation traite-t-il des DN ?

Il y a une différence dans les différentes recherches de DN de traitement de systèmes d'exploitation de manière une fois utilisé avec la Segmentation de tunnel (sans split-dns) pour AnyConnect.

MS Windows

Sur le MS Windows, les configurations de DN sont par-interface. Ceci signifie que, si la Segmentation de tunnel est utilisée, les requêtes DNS peuvent retomber aux serveurs DNS de l'adaptateur physique si la requête manquait sur l'adaptateur de tunnel VPN. Si la Segmentation de tunnel sans split-dns est définie, alors la résolution interne et externe de DN fonctionne parce qu'elle retombe aux serveurs DNS externes.

Macintosh

Avec Macintosh (MAC), les configurations de DN sont globales. Ainsi, si la Segmentation de tunnel est utilisée, mais split-dns n'est pas utilisé, il n'est pas possible aux requêtes DNS pour aller aux serveurs DNS en dehors de du tunnel. Vous pouvez seulement résoudre intérieurement, pas extérieurement. Ceci est documenté dans les id CSCtf20226 et CSCtz86314 de bogue Cisco. Dans des les deux cas, ce contournement devrait résoudre le problème :

  • Spécifiez une adresse IP externe de serveur DNS dans le cadre de la stratégie de groupe et utilisez le FQDN pour des requêtes DNS internes.
  • Si les noms externes sont résolubles par l'intermédiaire du tunnel, les DN fendus de débronchement en retirant les noms DNS ont configuré dans la stratégie de groupe, sous avancé > Segmentation de tunnel. Ceci exige utilisant le FQDN pour des requêtes DNS internes.

Le cas de split-dns a été résolu dans AnyConnect 3,1, avec ces mises en garde :

  • Le split-dns doit être activé pour les deux protocoles IP (exige ASA v9.0 ou plus tard).


  • OU

  • Le split-dns doit être activé pour un protocole IP.

       et
      
    • (Si l'ASA a la version 9.0 ou ultérieures : protocole de contournement de client pour l'autre protocole IP, c.-à-d., aucun pool d'adresses et protocole activé de ClientBypass dans la stratégie de groupe.

    •    ou

    • Si l'ASA est plus tôt que la version 9.0 : aucun pool d'adresses configuré pour l'autre protocole IP ; ceci implique que ce autre protocole IP est IPv6.)

Remarque: AnyConnect ne change pas le fichier resolv.conf direct sur le MAC OS X, mais change plutôt des configurations de DN de X-particularité de SYSTÈME D'EXPLOITATION. L'OS X garde resolv.confup-to-date pour des raisons de compatibilité. Utilisez le scutil--les dn commandent de regarder des configurations de DN sur l'OS X.

iPhone

L'iPhone est l'opposé complet du MAC, et ce n'est pas pareil que le MS Windows. Si la Segmentation de tunnel est définie mais le split-dns n'est pas défini, alors les requêtes DNS sortent par le serveur DNS global défini. Par exemple, les entrées de domaine de split-dns sont obligatoires pour la résolution interne. Ce comportement est documenté dans l'ID de bogue Cisco CSCtq09624 et est réparé dans la plus défunte version 2.5.4038 pour le client IOS AnyConnect.

Remarque: Rendez-vous compte que des requêtes DNS d'iPhone ignorent des domaines .local, documentés dans l'ID de bogue Cisco CSCts89292. Les ingénieurs d'Apple confirment que la question est provoqué par par la fonctionnalité du SYSTÈME D'EXPLOITATION. C'est le comportement conçu, et Apple confirme là n'est aucune modification pour elle.

Informations connexes


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 116016