Guía de Troubleshooting de AnyConnect Optimal Gateway Selection

Introducción

Este documento describe cómo resolver problemas con Optimal Gateway Selection (OGS). OGS es una función que se puede utilizar para determinar qué gateway tiene el menor tiempo de ida y vuelta (RTT) y conectarse a ese gateway. Se puede utilizar la función OGS para minimizar la latencia del tráfico de Internet sin la intervención del usuario. Con OGS, Cisco AnyConnect Secure Mobility Client (AnyConnect) identifica y selecciona qué gateway seguro es mejor para la conexión o reconexión. OGS comienza en la primera conexión o en una reconexión al menos cuatro horas después de la desconexión anterior. Encontrará más información en la guía del administrador.

Sugerencia: OGS funciona mejor con el cliente AnyConnect más reciente y el software ASA versión 9.1(3)* o posterior.

¿Cómo funciona OGS?

Una simple solicitud de ping del protocolo de mensajes de control de Internet (ICMP) no funciona porque muchos firewalls del dispositivo de seguridad adaptable de Cisco (ASA) están configurados para bloquear paquetes ICMP con el fin de evitar que se detecten. En su lugar, el cliente envía tres solicitudes HTTP/443 a cada cabecera que aparece en una combinación de todos los perfiles. Estos sondeos HTTP se conocen como pings OGS en los registros, pero, como se explicó anteriormente, no son pings ICMP. Para asegurarse de que una (re)conexión no tome demasiado tiempo, OGS selecciona el gateway anterior de forma predeterminada si no recibe ningún resultado de ping OGS en siete segundos. (Busque los resultados de ping de OGS en el registro.)

Nota: AnyConnect debe enviar una solicitud HTTP a 443, porque la respuesta en sí es importante, no una respuesta correcta. Desafortunadamente, la corrección para el manejo de proxy envía todas las solicitudes como HTTPS. Consulte Cisco bug ID CSCtg38672 - OGS debería hacer ping con solicitudes HTTP.

Nota: Si no hay cabeceras en la memoria caché, AnyConnect primero envía una solicitud HTTP para determinar si hay un proxy de autenticación y si puede manejar la solicitud. Es sólo después de esta solicitud inicial que comienza los pings OGS para sondear el servidor.

• OGS determina la ubicación del usuario en función de la información de red, como el sufijo del sistema de nombres de dominio (DNS) y la dirección IP del servidor DNS. Los resultados de RTT, junto con esta ubicación, se almacenan en la memoria caché de OGS.
  
  
• Las entradas de ubicación de OGS se almacenan en caché durante 14 días. El ID de bug de Cisco CSCtk66531 se archivó para hacer estos ajustes configurables por el usuario.
  
  
• OGS no se vuelve a ejecutar desde esta ubicación hasta 14 días después de que la entrada de la ubicación se almacene por primera vez en caché. Durante este tiempo, utiliza la entrada en caché y los RTT determinados para esa ubicación. Esto significa que cuando AnyConnect se inicia de nuevo, no vuelve a realizar OGS; en su lugar, utiliza el orden de gateway óptimo en la caché para esa ubicación. En los registros de la herramienta Diagnostic AnyConnect Reporting Tool (DART), aparece este mensaje:
  
  

  ******************************************
  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.
  
  ******************************************

• El RTT se determina mediante un intercambio TCP con el puerto Secure Sockets Layer (SSL) del gateway al que el usuario intentará conectarse según lo especificado por la entrada de host en el perfil de AnyConnect.
  
  

  Nota: A diferencia del ping HTTP, que realiza una simple publicación HTTP y luego muestra el RTT y el resultado, los cálculos de OGS son ligeramente más complicados. AnyConnect envía tres sondeos para cada servidor y calcula el retraso entre el HTTP SYN que envía y el FIN/ACK para cada uno de estos sondeos. A continuación, utiliza el menor de los deltas para comparar los servidores y realizar su selección. Por lo tanto, aunque los pings HTTP son una indicación bastante buena de qué servidor elegirá AnyConnect, es posible que no coincidan necesariamente. Hay más información al respecto en el resto del documento.

• Actualmente, OGS sólo ejecuta las comprobaciones si el usuario sale de una suspensión y se ha excedido el umbral. OGS no se conecta a un ASA diferente si el ASA al que el usuario está conectado falla o no está disponible. OGS se pone en contacto solamente con los servidores primarios en el perfil para determinar el óptimo.
  
  
• Una vez que se descarga el perfil del cliente OGS, cuando el usuario reinicia el cliente AnyConnect, la opción para seleccionar otros perfiles aparecerá atenuada como se muestra aquí:
  
  
  
  Incluso si la máquina del usuario tiene otros perfiles múltiples, no podrá seleccionar ninguno de ellos hasta que se inhabilite OGS.

Caché de OGS

Una vez finalizado el cálculo, los resultados se almacenan en el archivo preferences_global. Ha habido problemas con que estos datos no se han almacenado antes en el archivo.

Consulte Cisco bug ID CSCtj84626 para obtener más detalles.

Determinación de ubicación

El almacenamiento en caché de OGS funciona en una combinación del dominio DNS y las direcciones IP individuales del servidor DNS. Funciona de la siguiente manera:

• La ubicación A tiene un dominio DNS de locationa.com y dos direcciones IP de servidor DNS: ip1 e ip2. Cada combinación de dominio/IP crea una clave de caché que apunta a una entrada de caché de OGS. Por ejemplo:
  • locationa.com|ip1 -> ogscache1
  • locationa.com|ip2 -> ogscache1
• Si AnyConnect se conecta a una red físicamente diferente, se crea la misma acumulación de combinaciones de dominio/IP y se compara con la lista almacenada en caché. Si hay alguna coincidencia, se utiliza ese valor de caché de OGS y se sigue considerando que el cliente se encuentra en la ubicación A.

Escenarios de fallos

Estos son algunos escenarios de error que los usuarios podrían encontrar:

Cuando se pierde la conectividad con la puerta de enlace

Cuando se utiliza OGS, si se pierde la conectividad con la puerta de enlace a la que están conectados los usuarios, AnyConnect se conecta a los servidores de la lista de servidores de backupyno al siguiente host OGS. El orden de las operaciones es el siguiente:

1. OGS se pone en contacto solamente con los servidores primarios para determinar el óptimo.
   
   
2. Una vez determinado, el algoritmo de conexión es:
   
   1. Intente conectarse al servidor óptimo.
   2. Si esto falla, pruebe con la lista de servidores de respaldo óptima del servidor.
   3. Si esto falla, pruebe con cada servidor que permanezca en la lista de selección de OGS, ordenado por sus resultados de selección.

Nota: cuando el administrador configura la lista de servidores de copia de seguridad, el editor de perfiles actual sólo permite al administrador introducir el nombre de dominio completo (FQDN) para el servidor de copia de seguridad, pero no el grupo de usuarios como es posible para el servidor principal:

El ID de bug de Cisco CSCud84778 ha sido archivado para corregir esto, pero la URL completa debe ser ingresada en el campo de dirección de host para el servidor de respaldo, y debe funcionar: https://<ip-address>/usergroup.

Reanudar tras una suspensión

Para que OGS se ejecute después de una reanudación, AnyConnect debe haber tenido una conexión establecida cuando la máquina se puso en suspensión. OGS después de un curriculum vitae solo se realiza después de que se produce la prueba del entorno de red, que se supone para confirmar que la conectividad de red está disponible. Esta prueba incluye una subprueba de conectividad DNS.

Sin embargo, si el servidor DNS descarta las solicitudes de tipo A con una dirección IP en el campo de consulta, en lugar de responder con "nombre no encontrado" (el caso más común, siempre encontrado durante las pruebas), entonces el ID de bug de Cisco CSCti20768 "La consulta de DNS de tipo A para la dirección IP debe ser PTR para evitar el tiempo de espera" se aplica. 

El tamaño de la ventana TCP Delayed-ACK selecciona una gateway incorrecta

Cuando se utilizan versiones de ASA anteriores a la versión 9.1(3), las capturas en el cliente muestran un retraso persistente en el intercambio de señales SSL. Lo que se observa es que el cliente envía su ClientHello, luego ASA envía su ServerHello. Normalmente, va seguido de un mensaje de certificado (solicitud de certificado opcional) y un mensaje ServerHelloDone. La anomalía es doble:

1. El ASA no envía inmediatamente el mensaje del certificado después del ServerHello. El tamaño de la ventana del cliente es de 64.860 bytes, lo que es más que suficiente para contener la respuesta completa del ASA.
   
   
2. El cliente no ACK el ServerHello inmediatamente, por lo que ASA retransmite el ServerHello después de ~120ms, momento en el cual el cliente ACKs los datos. Luego se envía el mensaje de certificado. Es casi como si el cliente esperara más datos.

Esto sucede debido a la interacción entre TCP slow-start y TCP delay-ACK. Antes de la versión 9.1(3) de ASA, ASA utilizaba un tamaño de ventana de inicio lento de 1, mientras que el cliente de Windows utilizaba un valor de retraso de ACK de 2. Esto significa que ASA envía solamente un paquete de datos hasta que obtiene una ACK, pero también significa que el cliente no envía una ACK hasta que recibe dos paquetes de datos. El ASA agota el tiempo de espera después de 120 ms y retransmite el ServerHello, después de lo cual el cliente ACK los datos y la conexión continúa. Este comportamiento fue modificado por el ID de bug de Cisco CSCug98113 para que ASA utilice un tamaño de ventana de inicio lento de 2 de forma predeterminada en lugar de 1.

Esto puede afectar el cálculo de OGS cuando:

• Los distintos gateways ejecutan diferentes versiones de ASA.
• Los clientes tienen diferentes tamaños de ventana de retraso en la aceptación.

En tales situaciones, la demora introducida por el ACK retrasado podría ser suficiente para hacer que el cliente seleccione el ASA incorrecto. Si este valor difiere entre el cliente y el ASA, puede haber problemas. En tales situaciones, la solución alternativa es ajustar el tamaño de la ventana Confirmaciones retrasadas.

Windows:

1. Inicie el Editor del Registro.
   
   
2. Identifique el GUID de la interfaz en la que desea inhabilitar el ACK retrasado. Para ello, navegue por a:
   HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > WindowsNT > CurrentVersion > NetworkCards > (número).
   Observe cada número que aparece en Tarjetas de red. En la parte derecha, la descripción debe mostrar la interfaz (por ejemplo, Intel(R) Wireless WiFi Link 5100AGN) y el nombre de servicio debe mostrar el GUID correspondiente.
   
   
3. Busque y, a continuación, haga clic en esta subclave del Registro:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<GUID de interfaz>
   
   
4. En el menú Edición, elija Nuevo y, a continuación, haga clic en Valor DWORD.
   
   
5. Asigne al nuevo valor el nombre TcpAckFrequency y asígnele el valor 1.
   
   
6. Salga del Editor del Registro.
   
   
7. Reinicie Windows para que este cambio surta efecto.

Nota: El ID de bug Cisco CSCum19065 se ha archivado para hacer que los parámetros de ajuste TCP sean configurables en el ASA.

Ejemplo típico de usuario

El caso práctico más común es cuando un usuario en casa ejecuta OGS la primera vez, registra la configuración de DNS y los resultados de ping de OGS en la memoria caché (el valor predeterminado es un tiempo de espera de 14 días). Cuando el usuario vuelve a casa la noche siguiente, OGS detecta la misma configuración de DNS, la encuentra en la caché y omite la prueba de ping de OGS. Más tarde, cuando el usuario va a un hotel o restaurante que ofrece servicio de Internet, OGS detecta diferentes configuraciones de DNS, ejecuta las pruebas de ping de OGS, selecciona la mejor gateway y registra los resultados en la memoria caché.

El procesamiento es idéntico cuando se reanuda desde un estado suspendido o hibernado, si la configuración de reanudación de OGS y AnyConnect lo permite.

Solucionar problemas de OGS

Paso 1. Borre la Memoria Caché de OGS para Forzar una Reevaluación

Para borrar la memoria caché de OGS y volver a evaluar el RTT para las gateways disponibles, simplemente elimine el archivo de preferencias de Global AnyConnect del PC. La ubicación del archivo varía en función del sistema operativo (SO):

• Windows Vista y 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..

Paso 2. Capture las sondas del servidor durante el intento de conexión

1. Inicie Wireshark en la máquina de prueba.
   
   
2. Iniciar un intento de conexión en AnyConnect.
   
   
3. Detenga la captura de Wireshark una vez que se haya completado la conexión.

   Sugerencia: dado que la captura solo se utiliza para probar OGS, es mejor detener la captura tan pronto como AnyConnect seleccione un gateway. Es mejor no pasar por un intento de conexión completo, porque eso puede poner en la nube la captura de paquetes.

Paso 3. Verificar la Gateway Seleccionada por OGS

Para verificar por qué OGS seleccionó un gateway determinado, complete estos pasos:

1. Inicie una nueva conexión.
   
   
2. Ejecute AnyConnect DART:
   
   1. Inicie AnyConnect y haga clic en Advanced.
   2. Haga clic en Diagnóstico.
   3. Haga clic en Next (Siguiente).
   4. Haga clic en Next (Siguiente).
3. Examine los resultados de DART encontrados en el archivo DartBundle_XXXX_XXXX.zip recién creado en el escritorio.
   
   1. Vaya a Cisco AnyConnect Secure Mobility Client > AnyConnect.txt.
      
      
   2. Observe la hora a la que se iniciaron los sondeos OGS para un servidor determinado desde este registro 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
      
      ******************************************

      
      Por lo general, deben ser más o menos al mismo tiempo, pero en caso de que las capturas sean grandes, la marca de tiempo ayuda a reducir qué paquetes son los sondeos HTTP y cuáles son los intentos de conexión reales.
      
      
   3. Una vez que AnyConnect envía tres sondeos al servidor, se genera este mensaje con los resultados de cada uno de los sondeos:
      

      ******************************************
      
      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 )
      
      ******************************************

      Es importante prestar atención a estos tres valores, ya que deben coincidir con los resultados de la captura.
      
      
   4. Busque el mensaje que contiene "*** OGS Selection Results***" para ver el RTT evaluado y si el intento de conexión más reciente fue el resultado de un RTT en caché o un nuevo cálculo.
      
      Aquí tiene un ejemplo:

      ******************************************
      
      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.
      
      ******************************************

Paso 4. Validar los cálculos de OGS ejecutados por AnyConnect 

Inspeccione la captura para los sondeos TCP/SSL utilizados para calcular el RTT. Vea cuánto tiempo tarda la solicitud HTTPS en una sola conexión TCP. Cada solicitud de sondeo debe utilizar una conexión TCP diferente. Para ello, abra la captura en Wireshark y repita estos pasos para cada uno de los servidores:

1. Utilice el filtro ip.addr para aislar los paquetes enviados a cada uno de los servidores en su propia captura. Para hacer esto, navegue hasta Editar y seleccione Marcar todos los paquetes mostrados. Luego navegue hasta Archivo > Guardar como, seleccione la opción Solo paquetes marcados y haga clic en Guardar:
   
   
   
   
2. En esta nueva captura, navegue hasta Ver > Formato de visualización de hora > Fecha y hora del día:
   
   
   
   
3. Identifique el primer paquete HTTP SYN de esta captura que se envió cuando se envió la sonda OGS en función de los registros DART identificados en el paso 3.3.2. Es importante recordar que, para el primer servidor, la primera solicitud HTTP no es una sonda de servidor. Es fácil confundir la primera solicitud con una sonda de servidor y, por lo tanto, llegar a valores completamente diferentes de lo que informa OGS. Este problema se resalta aquí:
   
   
   
   
4. Para identificar más fácilmente cada uno de los sondeos, haga clic con el botón derecho en HTTP SYN para el primer sondeo y luego seleccione Colorear Conversation como se muestra aquí:
   
   
   
   Repita este proceso para los SYN en todos los sondeos. Como se muestra en la imagen anterior, los dos primeros sondeos se representan en colores diferentes. La ventaja de colorear las conversaciones TCP es detectar fácilmente las retransmisiones u otras rarezas por sonda.
   
   
5. Para cambiar la visualización de la hora, navegue hasta Ver > Formato de visualización de la hora > Segundos desde la época:
   
   
   
   Seleccione Milisegundos, porque ese es el nivel de precisión que utiliza OGS.
   
   
6. Calcule la diferencia de tiempo entre HTTP SYN y FIN/ACK, como se muestra en el diagrama del paso 4. Repita este proceso para cada uno de los tres sondeos y compare los valores con los que se muestran en los registros de DART del paso 3.3.3.

Análisis

Si después del análisis de las capturas se calculan los valores RTT determinados y se comparan con los valores vistos en los registros DART y se encuentra que todo coincide, pero aún parece que se está seleccionando el gateway incorrecto, entonces se debe a uno de dos problemas:

• Hay un problema en la cabecera. Si este es el caso, puede haber demasiadas retransmisiones de una cabecera en particular, o cualquier otra rareza como la que se ve en las sondas. Se requiere un análisis más detallado del intercambio.
  
  
• Hay un problema con el proveedor de servicios de Internet (ISP). Si este es el caso, puede haber fragmentación o grandes retrasos en una cabecera en particular.

Preguntas y respuestas

P: ¿Funciona OGS con el balanceo de carga?

R: Sí. OGS sólo conoce el nombre del maestro del clúster y lo utiliza para juzgar la cabecera más cercana.

P: ¿Funciona OGS con la configuración de proxy definida en el navegador?

R: OGS no admite los archivos de configuración automática de proxy o proxy (PAC), pero sí admite un servidor proxy codificado de forma rígida. Como tal, la operación OGS no ocurre. El mensaje de registro relevante es: "OGS no se realizará porque se ha configurado la detección automática de proxy."