Guide de dépannage AnyConnect Optimal Gateway Selection

Introduction

Ce document décrit comment dépanner les problèmes avec la sélection de passerelle optimale (OGS). OGS est une fonctionnalité qui peut être utilisée afin de déterminer quelle passerelle a le temps de parcours aller-retour (RTT) le plus faible et de se connecter à cette passerelle. On peut utiliser la fonctionnalité OGS afin de minimiser la latence pour le trafic Internet sans intervention de l'utilisateur. Avec OGS, Cisco AnyConnect Secure Mobility Client (AnyConnect) identifie et sélectionne la passerelle sécurisée la mieux adaptée à la connexion ou à la reconnexion. L'OGS commence à la première connexion ou à la reconnexion au moins quatre heures après la déconnexion précédente. Vous trouverez plus d'informations dans le guide de l'administrateur.

Conseil : OGS fonctionne de manière optimale avec le client AnyConnect le plus récent et le logiciel ASA version 9.1(3)* ou ultérieure.

Comment OGS fonctionne -t-il ?

Une simple requête ping ICMP (Internet Control Message Protocol) ne fonctionne pas, car de nombreux pare-feu ASA (Cisco Adaptive Security Appliance) sont configurés pour bloquer les paquets ICMP afin d'empêcher la détection. Au lieu de cela, le client envoie trois requêtes HTTP/443 à chaque tête de réseau qui apparaît dans une fusion de tous les profils. Ces sondes HTTP sont appelées requêtes ping OGS dans les journaux, mais, comme expliqué précédemment, ce ne sont pas des requêtes ping ICMP. Afin de s'assurer qu'une (re)connexion ne prend pas trop de temps, OGS sélectionne la passerelle précédente par défaut si elle ne reçoit aucun résultat de requête ping OGS dans les sept secondes. (Recherchez les résultats de la requête ping OGS dans le journal.)

Remarque : AnyConnect doit envoyer une requête HTTP à 443, car la réponse elle-même est importante et non une réponse réussie. Malheureusement, le correctif pour la gestion du proxy envoie toutes les requêtes en HTTPS. Voir l'ID de bogue Cisco CSCtg38672 - OGS devrait envoyer une requête ping avec les requêtes HTTP.

Remarque : si le cache ne contient pas de têtes de réseau, AnyConnect envoie d'abord une requête HTTP afin de déterminer s'il existe un proxy d'authentification et s'il peut traiter la requête. Ce n'est qu'après cette requête initiale qu'il lance les requêtes ping OGS afin de sonder le serveur.

• OGS détermine l'emplacement de l'utilisateur en fonction des informations réseau, telles que le suffixe DNS (Domain Name System) et l'adresse IP du serveur DNS. Les résultats RTT, ainsi que cet emplacement, sont stockés dans le cache OGS.
  
  
• Les entrées d'emplacement OGS sont mises en cache pendant 14 jours. L'ID de bogue Cisco CSCtk66531 a échoué pour rendre ces paramètres configurables par l'utilisateur.
  
  
• OGS n'est pas exécuté à nouveau à partir de cet emplacement jusqu'à 14 jours après la première mise en cache de l'entrée d'emplacement. Pendant ce temps, il utilise l'entrée mise en cache et les RTT déterminés pour cet emplacement. Cela signifie que lorsqu’AnyConnect redémarre, il n’exécute plus OGS ; au lieu de cela, il utilise l’ordre optimal de la passerelle dans le cache pour cet emplacement. Dans les journaux de l'outil de génération de rapports de diagnostic AnyConnect (DART), le message suivant s'affiche :
  
  

  ******************************************
  Date : 10/04/2013
  Time : 14:00:44
  Type : Information
  Source : acvpnui
  
  Description : Function: ClientIfcBase::startAHS
  File: .\ClientIfcBase.cpp
  Line: 2785
  OGS was already performed, previous selection will be used.
  
  ******************************************

• Le RTT est déterminé par un échange TCP vers le port SSL (Secure Sockets Layer) de la passerelle à laquelle l'utilisateur tentera de se connecter comme spécifié par l'entrée d'hôte dans le profil AnyConnect.
  
  

  Remarque : contrairement à la commande HTTP-ping, qui effectue une publication HTTP simple, puis affiche le RTT et le résultat, les calculs OGS sont légèrement plus compliqués. AnyConnect envoie trois sondes pour chaque serveur et calcule le délai entre le SYN HTTP qu’il envoie et le FIN/ACK pour chacune de ces sondes. Il utilise ensuite le plus petit des deltas afin de comparer les serveurs et faire sa sélection. Ainsi, même si les requêtes ping HTTP sont une assez bonne indication du serveur choisi par AnyConnect, elles ne correspondent pas nécessairement. Le reste du document contient plus d'informations à ce sujet.

• Actuellement, OGS n'exécute les vérifications que si l'utilisateur sort d'une suspension et que le seuil a été dépassé. OGS ne se connecte pas à un ASA différent si l'ASA auquel l'utilisateur est connecté tombe en panne ou devient indisponible. OGS contacte uniquement les serveurs principaux du profil afin de déterminer le serveur optimal.
  
  
• Une fois le profil client OGS téléchargé, lorsque l’utilisateur redémarre le client AnyConnect, l’option permettant de sélectionner d’autres profils est grisée, comme illustré ci-dessous :
  
  
  
  Même si l'ordinateur de l'utilisateur a plusieurs autres profils, il ne pourra en sélectionner aucun tant qu'OGS ne sera pas désactivé.

Cache OGS

Une fois le calcul terminé, les résultats sont stockés dans le fichier preference_global. Il y a eu des problèmes avec ces données n'étant pas stockées dans le fichier avant.

Référez-vous à l'ID de bogue Cisco CSCtj84626 pour plus de détails.

Détermination De L'Emplacement

La mise en cache OGS fonctionne sur une combinaison du domaine DNS et des adresses IP des serveurs DNS individuels. Il fonctionne comme suit :

• L'emplacement A a un domaine DNS de locationa.com, et deux adresses IP de serveur DNS - ip1 et ip2. Chaque combinaison domaine/IP crée une clé de cache qui pointe vers une entrée de cache OGS. Exemple :
  • locationa.com|ip1 -> ogscache1
  • locationa.com|ip2 -> ogscache1
• Si AnyConnect se connecte alors à un réseau physiquement différent, la même accumulation de combinaisons domaine/IP est créée et vérifiée par rapport à la liste mise en cache. S'il y a des correspondances, cette valeur de cache OGS est utilisée et le client est toujours considéré comme étant à l'emplacement A.

Scénarios de défaillance

Voici quelques scénarios d'échec que les utilisateurs peuvent rencontrer :

En cas de perte de la connectivité au modem routeur

Lorsque OGS est utilisé, si la connectivité à la passerelle à laquelle les utilisateurs sont connectés est perdue, AnyConnect se connecte aux serveurs de la liste des serveurs de sauvegardeetnon à l’hôte OGS suivant. L'ordre des opérations est le suivant :

1. OGS contacte uniquement les serveurs principaux afin de déterminer le serveur optimal.
   
   
2. Une fois déterminé, l'algorithme de connexion est :
   
   1. Essayez de vous connecter au serveur optimal.
   2. En cas d'échec, essayez la liste des serveurs de sauvegarde du serveur optimal.
   3. Si cela échoue, essayez chaque serveur qui reste dans la liste de sélection OGS, trié par ses résultats de sélection.

Remarque : lorsque l'administrateur configure la liste des serveurs de sauvegarde, l'éditeur de profil actuel permet uniquement à l'administrateur d'entrer le nom de domaine complet (FQDN) pour le serveur de sauvegarde, mais pas le groupe d'utilisateurs comme c'est possible pour le serveur principal :

L'ID de bogue Cisco CSCud84778 a été classé afin de corriger ceci, mais l'URL complète doit être entrée dans le champ d'adresse d'hôte pour le serveur de sauvegarde, et cela devrait fonctionner : https://<ip-address>/usergroup.

Reprendre après une suspension

Pour qu'OGS puisse s'exécuter après une reprise, AnyConnect doit avoir établi une connexion lorsque la machine a été mise en veille. OGS après une reprise n'est effectuée qu'après le test de l'environnement réseau, qui est destiné à confirmer que la connectivité réseau est disponible. Ce test inclut un sous-test de connectivité DNS.

Cependant, si le serveur DNS abandonne les requêtes de type A avec une adresse IP dans le champ de requête, au lieu de répondre avec "name not found" (le cas le plus courant, toujours rencontré pendant les tests), alors l'ID de bogue Cisco CSCti20768 "La requête DNS de type A pour l'adresse IP doit être PTR pour éviter le délai d'attente" s'applique. 

La taille de la fenêtre TCP Delayed-ACK sélectionne une passerelle incorrecte

Lorsque des versions d'ASA antérieures à la version 9.1(3) sont utilisées, les captures sur le client indiquent un délai persistant dans la connexion SSL. Ce qui est remarqué est que le client envoie son ClientHello, puis l'ASA envoie son ServerHello. Il est normalement suivi d'un message Certificate (facultatif Certificate Request) et d'un message ServerHelloDone. L'anomalie est double :

1. L'ASA n'envoie pas immédiatement le message de certificat après ServerHello. La taille de la fenêtre du client est de 64 860 octets, ce qui est plus que suffisant pour contenir la réponse complète de l'ASA.
   
   
2. Le client n'ACK pas le ServerHello immédiatement, de sorte que l'ASA retransmet le ServerHello après ~120 ms, à ce stade le client ACK les données. Le message Certificate est ensuite envoyé. C'est presque comme si le client attendait plus de données.

Cela se produit en raison de l'interaction entre TCP slow-start et TCP delay-ACK. Avant ASA version 9.1(3), l'ASA utilise une taille de fenêtre de démarrage lent de 1, tandis que le client Windows utilise une valeur de retard d'accusé de réception de 2. Cela signifie que l'ASA n'envoie qu'un seul paquet de données jusqu'à ce qu'il obtienne un ACK, mais cela signifie également que le client n'envoie pas d'ACK avant de recevoir deux paquets de données. L'ASA expire après 120 ms et retransmet ServerHello, après quoi le client ACK les données et la connexion se poursuit. Ce comportement a été modifié par l'ID de bogue Cisco CSCug98113 afin que l'ASA utilise une taille de fenêtre de démarrage lent de 2 par défaut au lieu de 1.

Cela peut avoir un impact sur le calcul des OGS lorsque :

• Différentes passerelles exécutent différentes versions ASA.
• Les clients ont des tailles de fenêtres de réception différée différentes.

Dans de telles situations, le délai introduit par le retard-ACK pourrait être suffisant pour amener le client à sélectionner le mauvais ASA. Si cette valeur diffère entre le client et l'ASA, il peut y avoir encore des problèmes. Dans de telles situations, la solution de contournement consiste à ajuster la taille de la fenêtre Accusés de réception différés.

Fenêtres

1. Démarrez l'Éditeur du Registre.
   
   
2. Identifiez le GUID de l'interface sur laquelle vous souhaitez désactiver le retard de réponse. Pour ce faire, accédez à par :
   HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Windows NT > CurrentVersion > NetworkCards > (numéro).
   Examinez chaque numéro répertorié sous Cartes réseau. Sur le côté droit, la description doit répertorier l'interface (par exemple, Intel(R) Wireless WiFi Link 5100AGN) et le nom de service le GUID correspondant.
   
   
3. Localisez, puis cliquez sur cette sous-clé de Registre :
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<GUID d'interface>
   
   
4. Dans le menu Edition, pointez sur Nouveau, puis cliquez sur Valeur DWORD.
   
   
5. Nommez la nouvelle valeur TcpAckFrequency et attribuez-lui la valeur 1.
   
   
6. Quittez l'Éditeur du Registre.
   
   
7. Redémarrez Windows pour que cette modification prenne effet.

Remarque : le bogue Cisco ID CSCum19065 a été enregistré pour rendre les paramètres de réglage TCP configurables sur l'ASA.

Exemple d'utilisateur type

Le cas d'utilisation le plus courant est lorsque l'utilisateur à domicile exécute OGS la première fois, il enregistre les paramètres DNS et les résultats de la requête ping OGS dans le cache (par défaut, un délai d'attente de 14 jours). Lorsque l'utilisateur retourne chez lui le soir suivant, OGS détecte les mêmes paramètres DNS, les trouve dans le cache et ignore le test ping OGS. Plus tard, lorsque l'utilisateur se rend dans un hôtel ou un restaurant qui offre un service Internet, OGS détecte différents paramètres DNS, exécute les tests ping OGS, sélectionne la meilleure passerelle et enregistre les résultats dans le cache.

Le traitement est identique lorsqu'il reprend à partir d'un état suspendu ou mis en veille prolongée, si les paramètres de reprise d'OGS et d'AnyConnect le permettent.

Dépannage du système OGS

Étape 1. Effacer le cache OGS afin de forcer une réévaluation

Afin d'effacer le cache OGS et de réévaluer le RTT pour les passerelles disponibles, supprimez simplement le fichier Global AnyConnect Preferences du PC. L'emplacement du fichier varie en fonction du système d'exploitation :

• Windows Vista et Windows 7
  

  C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\preferences_global.xml 
  Note: in older client versions it used to be stored in C:\ProgramData\Cisco\Cisco
   AnyConnect VPN Client

• Windows XP
  

  C:\Documents and Settings\AllUsers\Application Data\Cisco\Cisco AnyConnect VPN
  Client\preferences_global.xml

• Mac OS X
  

  /opt/cisco/anyconnect/.anyconnect_global
  Note: with older versions of the client it used to be /opt/cisco/vpn..

• Linux
  

  /opt/cisco/anyconnect/.anyconnect_global
  Note: with older versions of the client it used to be /opt/cisco/vpn..

Étape 2. Capture des sondes du serveur pendant la tentative de connexion

1. Démarrez Wireshark sur la machine de test.
   
   
2. Lancez une tentative de connexion sur AnyConnect.
   
   
3. Arrêtez la capture Wireshark une fois la connexion terminée.

   Conseil : la capture n'étant utilisée que pour tester OGS, il est préférable d'arrêter la capture dès qu'AnyConnect sélectionne une passerelle. Il est préférable de ne pas effectuer une tentative de connexion complète, car cela peut rendre la capture de paquets incompréhensible.

Étape 3. Vérification de la passerelle sélectionnée par OGS

Afin de vérifier pourquoi OGS a sélectionné une passerelle particulière, complétez ces étapes :

1. Établir une nouvelle connexion.
   
   
2. Exécutez AnyConnect DART :
   
   1. Lancez AnyConnect, puis cliquez sur Advanced.
   2. Cliquez sur Diagnostics.
   3. Cliquez sur Next (Suivant).
   4. Cliquez sur Next (Suivant).
3. Examinez les résultats DART trouvés dans le fichier DartBundle_XXXX_XXXX.zip nouvellement créé sur le bureau.
   
   1. Accédez à Cisco AnyConnect Secure Mobility Client > AnyConnect.txt.
      
      
   2. Notez l'heure de démarrage des sondes OGS pour un serveur particulier à partir de ce journal DART :
      

      ******************************************
      
      Date : 10/04/2013
      Time : 14:21:27
      Type : Information
      Source : acvpnui
      
      Description : Function: CHeadendSelection::CSelectionThread::Run
      File: .\AHS\HeadendSelection.cpp
      Line: 928
      OGS starting thread named gw2.cisco.com
      
      ******************************************

      
      En général, ils doivent être à peu près au même moment, mais si les captures sont volumineuses, l'horodatage permet de préciser quels paquets sont les sondes HTTP et lesquels sont les tentatives de connexion réelles.
      
      
   3. Une fois qu’AnyConnect envoie trois sondes au serveur, ce message est généré avec les résultats pour chacune des sondes :
      

      ******************************************
      
      Date : 10/04/2013
      Time : 14:31:37
      Type : Information
      Source : acvpnui
      
      Description : Function: CHeadendSelection::CSelectionThread::logThreadPingResults
      File: .\AHS\HeadendSelection.cpp
      Line: 1137
      OGS ping results for gw2.cisco.com: (219 218 132 )
      
      ******************************************

      Il est important de prêter attention à ces trois valeurs, car elles doivent correspondre aux résultats de capture.
      
      
   4. Recherchez le message qui contient "*** OGS Selection Results***" afin de voir le RTT évalué, et si la dernière tentative de connexion a été le résultat d'un RTT mis en cache ou d'un nouveau calcul.
      
      Voici un exemple :

      ******************************************
      
      Date        : 10/04/2013
      Time        : 12:29:38
      Type        : Information
      Source      : vpnui
      
      Description : Function: CHeadendSelection::logPingResults
      File: .\AHS\HeadendSelection.cpp
      Line: 589
      *** OGS Selection Results ***
      OGS performed for connection attempt. Last server: 'gw2.cisco.com'
      
      Results obtained from OGS cache. No ping tests were performed.
      
      Server Address     RTT (ms)
      gw1.cisco.com     302
      gw2.cisco.com     132            <========= As seen, 132 was the lowest delay
                                       of the three probes from the previous DART log
      gw3.cisco.com     506
      gw4.cisco.com     877
      
      
      Selected 'gw2.cisco.com' as the optimal server.
      
      ******************************************

Étape 4. Valider les calculs OGS exécutés par AnyConnect 

Inspectez la capture pour les sondes TCP/SSL utilisées afin de calculer RTT. Voyez combien de temps la requête HTTPS prend sur une seule connexion TCP. Chaque requête d’exploration doit utiliser une connexion TCP différente. Pour ce faire, ouvrez la capture dans Wireshark et répétez ces étapes pour chacun des serveurs :

1. Utilisez le filtre ip.addr afin d'isoler les paquets envoyés à chacun des serveurs dans leur propre capture. Pour ce faire, accédez à Edit, et sélectionnez Mark All Displayed Packets. Accédez ensuite à File > Save As, sélectionnez l'option Marked packets only, et cliquez sur Save :
   
   
   
   
2. Dans cette nouvelle capture, naviguez à Affichage > Format d'affichage de l'heure > Date et heure du jour :
   
   
   
   
3. Identifiez le premier paquet HTTP SYN de cette capture qui a été envoyé lorsque la sonde OGS a été envoyée en fonction des journaux DART, comme indiqué à l'étape 3.3.2. Il est important de se rappeler que, pour le premier serveur, la première requête HTTP n'est pas une sonde de serveur. Il est facile de confondre la première requête pour une sonde de serveur, et d'obtenir ainsi des valeurs complètement différentes de ce que rapporte OGS. Ce problème est souligné ici :
   
   
   
   
4. Afin d'identifier plus facilement chacune des sondes, cliquez avec le bouton droit sur le SYN HTTP pour la première sonde, puis sélectionnez Colorize Conversation comme indiqué ici :
   
   
   
   Répétez cette procédure pour les SYN sur toutes les sondes. Comme le montre l'image précédente, les deux premières sondes sont représentées en différentes couleurs. L'avantage de la coloration des conversations TCP est de repérer facilement les retransmissions ou d'autres bizarreries par sonde.
   
   
5. Afin de modifier l'affichage de l'heure, naviguez à Affichage > Format d'affichage de l'heure > Secondes depuis l'époque :
   
   
   
   Sélectionnez Millisecondes, car il s'agit du niveau de précision utilisé par OGS.
   
   
6. Calculez la différence de temps entre le SYN HTTP et le FIN/ACK, comme indiqué dans le schéma de l'étape 4. Répétez cette procédure pour chacune des trois sondes et comparez les valeurs à celles indiquées dans les journaux DART à l'étape 3.3.3.

Analyse

Si, après l'analyse des captures, les valeurs RTT déterminées sont calculées et comparées aux valeurs affichées dans les journaux DART et que tout est trouvé pour correspondre, mais qu'il semble toujours que la mauvaise passerelle est sélectionnée, alors cela est dû à l'un des deux problèmes suivants :

• Il y a un problème sur la tête de réseau. Si c'est le cas, il peut y avoir trop de retransmissions d'une tête de réseau particulière, ou d'autres bizarreries de ce type dans les sondes. Une analyse plus approfondie de l'échange est nécessaire.
  
  
• Un problème est survenu avec le fournisseur d'accès Internet (FAI). Si tel est le cas, il peut y avoir une fragmentation ou des retards importants pour une tête de réseau particulière.

Q&R

Q : OGS fonctionne-t-il avec l'équilibrage de charge ?

R : Oui. OGS ne connaît que le nom du maître de cluster et l'utilise pour déterminer la tête de réseau la plus proche.

Q : OGS fonctionne-t-il avec les paramètres proxy définis dans le navigateur ?

R : OGS ne prend pas en charge les fichiers PAC (Auto Proxy ou Proxy Auto Config), mais prend en charge un serveur proxy codé en dur. En tant que tel, l'opération OGS ne se produit pas. Le message de journal approprié est : "OGS ne sera pas exécuté car la détection automatique de proxy est configurée."