Interopérabilité entre AnyConnect et le client d’itinérance OpenDNS

Introduction

Ce document décrit quelques-unes des limitations actuelles et des solutions de contournement disponibles pour faire fonctionner ensemble AnyConnect et OpenDNS Roaming Client. Les clients Cisco s'appuient sur le client VPN AnyConnect pour assurer une communication sécurisée et chiffrée avec leurs réseaux d'entreprise. De même, le client d'itinérance OpenDNS permet aux utilisateurs d'utiliser les services DNS en toute sécurité à l'aide de serveurs publics OpenDNS. Ces deux clients ajoutent un ensemble complet de fonctionnalités de sécurité au terminal. Il est donc important qu'ils interagissent entre eux.

Conditions préalables

Connaissance pratique des clients d’itinérance AnyConnect et OpenDNS.

Connaissance de la configuration de tête de réseau ASA ou IOS/IOS-XE (tunnel-group/group-policy) pour AnyConnect VPN.

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Tête de réseau ASA ou IOS/IOS-XE
• Point d'extrémité exécutant le client VPN AnyConnect et le client d'itinérance OpenDNS

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Tête de réseau ASA version 9.4
• Windows 7
• Client AnyConnect 4.2.00096
• Client d'itinérance OpenDNS 2.0.154

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

OpenDNS développe actuellement un plug-in AnyConnect avec l’équipe Cisco AnyConnect, qui sera disponible ultérieurement. Bien qu’aucune date n’ait été définie, cette intégration permettra au client d’itinérance de fonctionner avec le client AnyConnect sans résoudre les problèmes. Cela permettra également à AnyConnect d’être un mécanisme de remise pour le client d’itinérance. 

Fonctionnalité

Gestion DNS AnyConnect

La tête de réseau VPN peut être configurée de deux manières différentes pour gérer le trafic du client AnyConnect.

1. Configuration complète du tunnel (tunnel-all) : ceci force tout le trafic du point d'extrémité à être envoyé à travers le tunnel VPN chiffré, et par conséquent le trafic ne quitte jamais la carte d'interface publique en texte clair
2. Configuration du tunnel fractionné:

a. Tunneling Split-include : le trafic destiné uniquement à des sous-réseaux ou hôtes spécifiques définis sur la tête de réseau VPN est envoyé à travers le tunnel, tout autre trafic est envoyé à l'extérieur du tunnel en texte clair

b. Tunnellisation à exclusion partagée : le trafic destiné uniquement à des sous-réseaux ou hôtes spécifiques définis sur la tête de réseau VPN est exclu du chiffrement et quitte l'interface publique en texte clair, tout autre trafic est chiffré et envoyé uniquement à travers le tunnel

Chacune de ces configurations détermine la manière dont la résolution DNS est gérée par le client AnyConnect, en fonction du système d’exploitation sur le terminal. Un changement de comportement s'est produit dans le mécanisme de gestion DNS sur AnyConnect pour Windows, dans la version 4.2 après le correctif pour CSCuf0785.

Windows 7+

Configuration de tous les tunnels (et split-tunneling avec tunnel-all DNS activé)

Antérieure à AnyConnect 4.2 :

Seules les requêtes DNS aux serveurs DNS configurés dans la stratégie de groupe (serveurs DNS de tunnel) sont autorisées. Le pilote AnyConnect répond à toutes les autres requêtes par une réponse « no such name ». Par conséquent, la résolution DNS ne peut être effectuée qu'à l'aide des serveurs DNS du tunnel.

AnyConnect 4.2 +

Les requêtes DNS vers n'importe quel serveur DNS sont autorisées, à condition qu'elles proviennent de l'adaptateur VPN et qu'elles soient envoyées via le tunnel. Toutes les autres requêtes reçoivent une réponse « no such name » et la résolution DNS ne peut être effectuée que via le tunnel VPN

Avant le correctif CSCuf07885, AC restreint les serveurs DNS cibles, mais avec le correctif pour CSCuf07885 , il restreint les cartes réseau qui peuvent lancer des requêtes DNS.

Configuration de Split-Incluse (tunnel-all DNS désactivé et no split-DNS)

Le pilote AnyConnect n'interfère pas avec le résolveur DNS natif. Par conséquent, la résolution DNS est effectuée en fonction de l'ordre des cartes réseau, et AnyConnect est toujours la carte préférée lorsque le VPN est connecté. Ainsi, une requête DNS sera d'abord envoyée via le tunnel et si elle n'est pas résolue, le résolveur tentera de la résoudre via l'interface publique. La liste d'accès split-include devra inclure le sous-réseau couvrant le ou les serveurs DNS du tunnel. À partir de AnyConnect 4.2, les routes d'hôte pour le ou les serveurs DNS de tunnel sont automatiquement ajoutées en tant que réseaux à inclusion partagée (routes sécurisées) par le client AnyConnect, et par conséquent, la liste d'accès à inclusion partagée ne nécessite plus l'ajout explicite du sous-réseau du serveur DNS de tunnel.

Configuration de l'exclusion partagée (DNS avec tous les tunnels désactivé et pas de DNS divisé)

Le pilote AnyConnect n'interfère pas avec le résolveur DNS natif. Par conséquent, la résolution DNS est effectuée en fonction de l'ordre des cartes réseau, et AnyConnect est toujours la carte préférée lorsque le VPN est connecté. Ainsi, une requête DNS sera d'abord envoyée via le tunnel et si elle n'est pas résolue, le résolveur tentera de la résoudre via l'interface publique. La liste de contrôle d'accès split-exclude ne doit pas inclure le sous-réseau couvrant le ou les serveurs DNS du tunnel. À partir de AnyConnect 4.2, les routes d'hôte pour le ou les serveurs DNS de tunnel sont automatiquement ajoutées en tant que réseaux à inclusion partagée (routes sécurisées) par le client AnyConnect, et par conséquent, cela empêchera une mauvaise configuration dans la liste d'accès à exclusion partagée.

Split-DNS (tunnel-all DNS désactivé, split-include configuré)

Pre AnyConnect 4.2

Les requêtes DNS correspondant aux domaines DNS fractionnés sont autorisées à tunneler les serveurs DNS, mais pas les autres serveurs DNS. Pour empêcher de telles requêtes DNS internes de sortir du tunnel, le pilote AnyConnect répond par « no such name » si la requête est envoyée à d'autres serveurs DNS. Ainsi, les domaines split-dns ne peuvent être résolus que via les serveurs DNS du tunnel.

Les requêtes DNS ne correspondant pas aux domaines DNS fractionnés sont autorisées vers d'autres serveurs DNS, mais pas vers les serveurs DNS de tunnel. Même dans ce cas, le pilote AnyConnect répond avec « no such name » si une requête pour des domaines non-split-dns est tentée via le tunnel. Ainsi, les domaines non split-dns peuvent uniquement être résolus via des serveurs DNS publics à l'extérieur du tunnel.

AnyConnect 4.2 +

Les requêtes DNS correspondant aux domaines DNS partagés sont autorisées vers tous les serveurs DNS, à condition qu'elles proviennent de l'adaptateur VPN. Si la requête provient de l'interface publique, le pilote AnyConnect répond par un « no such name » pour forcer le résolveur à toujours utiliser le tunnel pour la résolution de noms. Les domaines split-dns ne peuvent donc être résolus que par le biais du tunnel.

Les requêtes DNS ne correspondant pas aux domaines DNS partagés sont autorisées vers tous les serveurs DNS, à condition qu'elles proviennent de la carte physique. Si la requête provient de l'adaptateur VPN, AnyConnect répond par « no such name » pour forcer le résolveur à toujours tenter une résolution de noms via l'interface publique. Ainsi, les domaines non split-dns ne peuvent être résolus que via l'interface publique.

Mac OS X

Configuration de tous les tunnels (et split-tunneling avec tunnel-all DNS activé)

Lorsqu’AnyConnect est connecté, seuls les serveurs DNS de tunnel sont maintenus dans la configuration DNS du système. Par conséquent, les requêtes DNS ne peuvent être envoyées qu’au(x) serveur(s) DNS de tunnel.

Configuration de Split-Incluse (tunnel-all DNS désactivé et no split-DNS)

AnyConnect n’interfère pas avec le résolveur DNS natif. Les serveurs DNS du tunnel sont configurés en tant que résolveurs préférés, qui ont priorité sur les serveurs DNS publics, ce qui garantit que la demande DNS initiale pour une résolution de noms est envoyée sur le tunnel. Comme les paramètres DNS sont globaux sur Mac OS X, il n'est pas possible pour les requêtes DNS d'utiliser des serveurs DNS publics en dehors du tunnel comme documenté dans CSCtf2026 . À partir de AnyConnect 4.2, les routes d'hôte pour le ou les serveurs DNS de tunnel sont automatiquement ajoutées en tant que réseaux à inclusion partagée (routes sécurisées) par le client AnyConnect, et par conséquent, la liste d'accès à inclusion partagée ne nécessite plus l'ajout explicite du sous-réseau du serveur DNS de tunnel.

Configuration de l'exclusion partagée (DNS avec tous les tunnels désactivé et pas de DNS divisé)

AnyConnect n’interfère pas avec le résolveur DNS natif. Les serveurs DNS du tunnel sont configurés en tant que résolveurs préférés, qui ont priorité sur les serveurs DNS publics, ce qui garantit que la demande DNS initiale pour une résolution de noms est envoyée sur le tunnel. Comme les paramètres DNS sont globaux sur Mac OS X, il n'est pas possible pour les requêtes DNS d'utiliser des serveurs DNS publics en dehors du tunnel comme documenté dans CSCtf2026 . À partir de AnyConnect 4.2, les routes d'hôte pour le ou les serveurs DNS de tunnel sont automatiquement ajoutées en tant que réseaux à inclusion partagée (routes sécurisées) par le client AnyConnect, et par conséquent, la liste d'accès à inclusion partagée ne nécessite plus l'ajout explicite du sous-réseau du serveur DNS de tunnel.

Split-DNS (tunnel-all DNS désactivé, split-include configuré)

Si le service DNS partagé est activé pour les deux protocoles IP (IPv4 et IPv6) ou s'il est uniquement activé pour un protocole et qu'aucun pool d'adresses n'est configuré pour l'autre protocole :
Un vrai DNS divisé, semblable à Windows, est appliqué. La valeur True split-DNS signifie que les demandes correspondant aux domaines split-DNS sont uniquement résolues via le tunnel, elles ne sont pas transmises aux serveurs DNS en dehors du tunnel.

Si le Split-DNS est activé pour un seul protocole et qu'une adresse de client est attribuée pour l'autre protocole, seul le « DNS fallback for split-tunneling » est appliqué. Cela signifie qu'AC autorise uniquement les requêtes DNS correspondant aux domaines DNS partagés via un tunnel (les autres requêtes reçoivent une réponse d'AC avec une réponse « refusé » pour forcer le basculement vers les serveurs DNS publics), mais ne peut pas imposer que les requêtes correspondant aux domaines DNS partagés ne soient pas envoyées en clair, via l'adaptateur public.

Linux

Configuration de tous les tunnels (et split-tunneling avec tunnel-all DNS activé)

Lorsqu’AnyConnect est connecté, seuls les serveurs DNS de tunnel sont maintenus dans la configuration DNS du système. Par conséquent, les requêtes DNS ne peuvent être envoyées qu’au(x) serveur(s) DNS de tunnel.

Configuration de Split-Incluse (tunnel-all DNS désactivé et no split-DNS)

AnyConnect n’interfère pas avec le résolveur DNS natif. Les serveurs DNS du tunnel sont configurés en tant que résolveurs préférés, qui ont priorité sur les serveurs DNS publics, ce qui garantit que la demande DNS initiale pour une résolution de noms est envoyée sur le tunnel.

Configuration de l'exclusion partagée (DNS avec tous les tunnels désactivé et pas de DNS divisé)

AnyConnect n’interfère pas avec le résolveur DNS natif. Les serveurs DNS du tunnel sont configurés en tant que résolveurs préférés, qui ont priorité sur les serveurs DNS publics, ce qui garantit que la demande DNS initiale pour une résolution de noms est envoyée sur le tunnel.

Split-DNS (tunnel-all DNS désactivé, split-include configuré)

Si le split-DNS est activé, seul le « fallback DNS pour le split-tunneling » est appliqué. Cela signifie qu'AC autorise uniquement les requêtes DNS correspondant aux domaines DNS partagés via un tunnel (les autres requêtes reçoivent une réponse d'AC avec une réponse « refusé » pour forcer le basculement vers les serveurs DNS publics), mais ne peut pas imposer que les requêtes correspondant aux domaines DNS partagés ne soient pas envoyées en clair, via l'adaptateur public.

Client d'itinérance OpenDNS

Le client d’itinérance est un logiciel qui gère les services DNS sur le point d’extrémité et utilise les serveurs DNS publics OpenDNS pour sécuriser et chiffrer le trafic DNS.

Idéalement, le client doit être dans un état protégé et chiffré. Cependant, si le client ne parvient pas à établir une session TLS avec le serveur de résolution public OpenDNS (208.67.222.222), il tente d'envoyer le trafic DNS non chiffré sur le port UDP 53 à 208.67.222.222. Le client d'itinérance utilise exclusivement l'adresse IP de résolveur public 208.67.222.222 d'OpenDNS (il y en a quelques autres comme 208.67.220.220, 208.67.222.220 et 208.67.220.222). Une fois installé, le client d’itinérance définit 127.0.0.1 (localhost) comme serveur DNS local et remplace les paramètres DNS actuels par interface. Les paramètres DNS actuels sont stockés dans les fichiers resolv.conf locaux (même sous Windows) dans le dossier de configuration du client d'itinérance. OpenDNS sauvegarde même les serveurs DNS acquis via l'adaptateur AnyConnect. Par exemple, si 192.168.92.2 est le serveur DNS sur l'adaptateur public, OpenDNS crée le fichier resolv.conf à l'emplacement suivant :

C:\ProgramData\OpenDNS\ERC\Resolver1-LocalAreaConnection-resolv.conf
serveur de noms 192.168.92.2

Le client d’itinérance chiffre chaque paquet défini sur OpenDNS ; toutefois, il ne démarre pas ou n’utilise pas de tunnel de chiffrement vers 208.67.222.222. Le client d’itinérance dispose d’une fonctionnalité facultative d’application de couche IP qui ouvre une connexion IPSec à des fins non DNS pour bloquer les adresses IP. Cette option est automatiquement désactivée en présence d'une connexion AnyConnect active. Il se lie également à 127.0.0.1:53 pour recevoir des requêtes générées localement sur l'ordinateur. Lorsque le terminal doit résoudre un nom, les requêtes locales sont dirigées vers 127.0.0.1 en raison de la priorité, puis le processus dnscrypt-proxy sous-jacent du client d'itinérance les transfère aux serveurs publics OpenDNS sur le canal chiffré.

Si le flux DNS n’est pas autorisé vers 127.0.0.1:53, le client d’itinérance ne pourra pas fonctionner et les événements suivants se produiront. Si le client ne parvient pas à atteindre les serveurs DNS publics ou l'adresse liée 127.0.0.1:53, il passe à l'état fail-open et restaure les paramètres DNS sur les cartes locales. En arrière-plan, il continue à envoyer des sondes vers 208.67.222.222 et peut passer en mode actif si la connexion sécurisée est rétablie.

Limites

Après avoir examiné les fonctionnalités de haut niveau des deux clients, il est évident que le client itinérant doit avoir la capacité de modifier les paramètres DNS locaux et de se lier à 127.0.0.1:53 pour transférer des requêtes sur le canal sécurisé. Lorsque le VPN est connecté, les seules configurations où AnyConnect n'interfère pas avec le résolveur DNS natif sont le split-include et le split-exclude (avec split-tunnel-all DNS désactivé). Par conséquent, il est actuellement recommandé d'utiliser l'une de ces configurations, lorsque le client d'itinérance est également utilisé. Le client d'itinérance restera dans un état non protégé/non chiffré si la configuration tunnel-all est utilisée ou si le DNS split-tunnel-all est activé, comme illustré dans l'image.

Solution de contournement

Si l'intention est de protéger la communication entre le client d'itinérance et les serveurs OpenDNS à l'aide du tunnel VPN, alors une liste d'accès factice à exclusion fractionnée peut être utilisée sur la tête de réseau VPN. Il s'agit de la configuration la plus proche d'une configuration de tunnel complète. Si ce n'est pas le cas, le split-include peut être utilisé lorsque la liste d'accès n'inclut pas les serveurs publics OpenDNS, ou le split-exclude peut être utilisé lorsque la liste d'accès inclut les serveurs publics OpenDNS.

En outre, lors de l’utilisation du client d’itinérance, les modes DNS fractionnés ne peuvent pas être utilisés, car cela entraînera une perte de résolution DNS locale. Le DNS « split-tunnel-all » doit également rester désactivé. Cependant, il est partiellement pris en charge et doit permettre au client d’itinérance de devenir chiffré après le basculement. 

Configurations

Trafic OpenDNS du tunnel

Cet exemple utilise une adresse IP factice dans la liste de contrôle d'accès split-exclude. Avec cette configuration, toutes les communications avec 208.67.222.222 passent par le tunnel VPN, et le client d'itinérance fonctionne dans un état chiffré et protégé.

ciscoasa# sh run access-li split
access-list split standard permit host 2.2.2.2

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy excludespecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

Exclure le trafic OpenDNS du tunnel VPN

Cet exemple utilise l'adresse du résolveur OpenDNS dans la liste d'accès à exclusion fractionnée. Avec cette configuration, toutes les communications avec 208.67.222.222 s'effectuent en dehors du tunnel VPN et le client d'itinérance fonctionne dans un état chiffré et protégé.

ciscoasa# sh run access-li split
access-list split standard permit host 208.67.222.222

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy excludespecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

Cet exemple montre une configuration d'inclusion partagée pour un sous-réseau 192.168.1.0/24 interne . Avec cette configuration, le client d'itinérance continuera à fonctionner dans un état chiffré et protégé puisque le trafic vers 208.67.222.222 n'est pas envoyé via le tunnel.

ciscoasa# sh run access-li split
access-list split standard permit 192.168.1.0 255.255.255.0

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

Note: Split-tunnel-all-dns must be disabled in all of the  scenarios

Vérifier

Lorsque le VPN est connecté, le client d'itinérance doit afficher protégé et chiffré comme illustré dans cette image :