Guia de solução de problemas de seleção de gateway ideal do AnyConnect

Introdução

Este documento descreve como solucionar problemas com a Seleção de Gateway Ideal (OGS). O OGS é um recurso que pode ser usado para determinar qual gateway tem o menor tempo de ida e volta (RTT) e se conectar a esse gateway. Pode-se usar o recurso OGS para minimizar a latência do tráfego da Internet sem a intervenção do usuário. Com o OGS, o Cisco AnyConnect Secure Mobility Client (AnyConnect) identifica e seleciona qual gateway seguro é melhor para conexão ou reconexão. O OGS começa na primeira conexão ou em uma reconexão pelo menos quatro horas após a desconexão anterior. Mais informações podem ser encontradas no Guia do administrador.

Dica: o OGS funciona melhor com o software AnyConnect Client e ASA versão 9.1(3)* ou posterior mais recente.

Como funciona o OGS?

Uma solicitação de ping do Internet Control Message Protocol (ICMP) simples não funciona porque muitos firewalls do Cisco Adaptive Security Appliance (ASA) estão configurados para bloquear pacotes ICMP a fim de impedir a descoberta. Em vez disso, o cliente envia três solicitações HTTP/443 para cada headend que aparece em uma mesclagem de todos os perfis. Esses testadores HTTP são chamados de pings OGS nos registros, mas, como explicado anteriormente, não são pings ICMP. Para garantir que uma (re)conexão não demore muito, o OGS seleciona o gateway anterior por padrão se não receber nenhum resultado de ping OGS em sete segundos. (Procure os resultados do ping OGS no registro.)

Observação: o AnyConnect deve enviar uma solicitação HTTP para 443, pois a própria resposta é importante, não uma resposta bem-sucedida. Infelizmente, a correção para tratamento de proxy envia todas as solicitações como HTTPS. Consulte o bug da Cisco ID CSCtg38672 - OGS deve fazer ping com solicitações HTTP.

Observação: se não houver headends no cache, o AnyConnect envia primeiro uma solicitação HTTP para determinar se há um proxy de autenticação e se ele pode lidar com a solicitação. É somente após essa solicitação inicial que ele inicia os pings OGS para investigar o servidor.

• O OGS determina o local do usuário com base nas informações da rede, como o sufixo DNS (Domain Name System) e o endereço IP do servidor DNS. Os resultados de RTT, junto com esse local, são armazenados no cache OGS.
  
  
• As entradas do local OGS são armazenadas em cache por 14 dias. A ID de bug da Cisco CSCtk66531 falhou para tornar essas configurações configuráveis pelo usuário.
  
  
• O OGS não é executado novamente a partir desse local até 14 dias após a entrada do local ser armazenada em cache pela primeira vez. Durante esse período, ele usa a entrada armazenada em cache e os RTTs determinados para esse local. Isso significa que quando o AnyConnect é iniciado novamente, ele não executa OGS novamente; em vez disso, ele usa a ordem de gateway ideal no cache para esse local. Nos registros da ferramenta de relatório do AnyConnect de diagnóstico (DART), esta mensagem é vista:
  
  

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

• O RTT é determinado com uma troca de TCP para a porta Secure Sockets Layer (SSL) do gateway ao qual o usuário tentará se conectar, conforme especificado pela entrada do host no perfil do AnyConnect.
  
  

  Observação: ao contrário do HTTP-ping, que faz uma postagem HTTP simples e exibe o RTT e o resultado, os cálculos OGS são um pouco mais complicados. O AnyConnect envia três testes para cada servidor e calcula o atraso entre o HTTP SYN que ele envia e o FIN/ACK para cada um desses testes. Em seguida, ele usa o menor dos deltas para comparar os servidores e fazer sua seleção. Assim, mesmo que os pings HTTP sejam uma indicação razoavelmente boa de qual servidor o AnyConnect escolherá, eles podem não necessariamente coincidir. Há mais informações sobre isso no restante do documento.

• Atualmente, o OGS executa as verificações apenas se o usuário sair de uma suspensão e o limite tiver sido excedido. O OGS não se conecta a um ASA diferente se o ASA ao qual o usuário está conectado falhar ou ficar indisponível. O OGS entra em contato somente com os servidores principais no perfil para determinar o ideal.
  
  
• Depois que o perfil do cliente OGS é baixado, quando o usuário reinicia o cliente AnyConnect, a opção para selecionar outros perfis ficará acinzentada, como mostrado aqui:
  
  
  
  Mesmo que a máquina do usuário tenha vários outros perfis, eles não poderão selecionar nenhum deles até que o OGS seja desativado.

Cache de OGS

Quando o cálculo estiver concluído, os resultados serão armazenados no arquivo preferences_global. Ocorreram problemas com esses dados que não estavam sendo armazenados no arquivo anteriormente.

Consulte o bug da Cisco ID CSCtj84626 para obter mais detalhes.

Determinação do local

O cache OGS funciona em uma combinação do domínio DNS e dos endereços IP do servidor DNS individual. Ele funciona da seguinte maneira:

• O local A tem um domínio DNS de locationa.com e dois endereços IP de servidor DNS - ip1 e ip2. Cada combinação de domínio/IP cria uma chave de cache que aponta para uma entrada de cache OGS. Por exemplo:
  • locationa.com|ip1 -> ogscache1
  • locationa.com|ip2 -> ogscache1
• Se o AnyConnect se conectar a uma rede fisicamente diferente, o mesmo acúmulo de combinações de domínio/IP será criado e comparado à lista em cache. Se houver alguma correspondência, esse valor de cache OGS será usado e o cliente ainda será considerado como no local A.

Cenários de falha

Aqui estão alguns cenários de falha que os usuários podem encontrar:

Quando a conectividade com o Gateway é perdida

Quando o OGS é usado, se a conectividade ao gateway ao qual os usuários estão conectados for perdida, o AnyConnect se conectará aos servidores no lista de servidores de backupenão para o próximo host OGS. A ordem das operações é a seguinte:

1. O OGS entra em contato somente com os servidores primários para determinar o ideal.
   
   
2. Uma vez determinado, o algoritmo de conexão é:
   
   1. Tente se conectar ao servidor ideal.
   2. Se isso falhar, tente a lista de servidores de backup do servidor ideal.
   3. Se isso falhar, tente cada servidor que permanecer na lista de seleção OGS, ordenada por seus resultados de seleção.

Observação: quando o administrador configura a lista de servidores de backup, o editor de perfil atual permite apenas que o administrador insira o FQDN (Fully Qualified Domain Name, Nome de domínio totalmente qualificado) para o servidor de backup, mas não o grupo de usuários conforme possível para o servidor primário:

O bug da Cisco ID CSCud84778 foi preenchido para corrigir isso, mas a URL completa deve ser inserida no campo de endereço de host para o servidor de backup e deve funcionar: https://<ip-address>/usergroup.

Continuar após uma suspensão

Para que o OGS seja executado após um currículo, o AnyConnect deve ter estabelecido uma conexão quando a máquina foi colocada em espera. O OGS após uma retomada só é executado após a ocorrência do teste de ambiente de rede, que tem como objetivo confirmar se a conectividade de rede está disponível. Este teste inclui um subteste de conectividade DNS.

No entanto, se o servidor DNS descartar solicitações do tipo A com um endereço IP no campo de consulta, em vez de responder com "nome não encontrado" (o caso mais comum, sempre encontrado durante testes), então ID de bug da Cisco CSCti20768 Aplica-se a "consulta DNS do tipo A para endereço IP, deve ser PTR para evitar o tempo limite". 

Tamanho da janela TCP Delayed-ACK seleciona gateway incorreto

Quando as versões do ASA anteriores à Versão 9.1(3) são usadas, as capturas no cliente mostram um atraso persistente no handshake SSL. O que é observado é que o cliente envia seu ClientHello, em seguida, o ASA envia seu ServerHello. Isso é normalmente seguido por uma mensagem de certificado (solicitação de certificado opcional) e uma mensagem ServerHelloDone. A anomalia é dupla:

1. O ASA não envia imediatamente a mensagem de certificado após o ServerHello. O tamanho da janela do cliente é de 64.860 bytes, o que é mais do que suficiente para conter toda a resposta do ASA.
   
   
2. O cliente não faz ACK do ServerHello imediatamente, portanto, o ASA retransmite o ServerHello após ~120ms, momento em que o cliente faz ACK dos dados. Em seguida, a mensagem do certificado é enviada. É quase como se o cliente esperasse por mais dados.

Isso acontece devido à interação entre início lento de TCP e ACK atrasado de TCP. Antes do ASA versão 9.1(3), o ASA usa um tamanho de janela de início lento de 1, enquanto o cliente Windows usa um valor de ACK atrasado de 2. Isso significa que o ASA envia apenas um pacote de dados até obter um ACK, mas também significa que o cliente não envia um ACK até receber dois pacotes de dados. O ASA expira após 120 ms e retransmite o ServerHello, após o qual o cliente confirma os dados e a conexão continua. Esse comportamento foi alterado pela ID de bug da Cisco CSCug98113 para que o ASA usasse um tamanho de janela de início lento de 2 por padrão em vez de 1.

Isso pode afetar o cálculo de OGS quando:

• Gateways diferentes executam versões diferentes do ASA.
• Os clientes têm tamanhos de janela de ACK atrasado diferentes.

Nessas situações, o atraso introduzido pelo retardo-ACK pode ser suficiente para fazer com que o cliente selecione o ASA errado. Se esse valor for diferente entre o cliente e o ASA, ainda poderá haver problemas. Nessas situações, a solução alternativa é ajustar o tamanho da janela Delayed Acknowledgements.

Windows

1. Inicie o Editor do Registro.
   
   
2. Identifique o GUID da interface na qual você deseja desativar o delay-ACK. Para fazer isso, navegue até para:
   HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > WindowsNT > CurrentVersion > NetworkCards > (número).
   Examine cada número listado em Placas de rede. No lado direito, a Descrição deve listar a Interface (por exemplo, Intel(R) Wireless WiFi Link 5100AGN) e o ServiceName deve listar o GUID correspondente.
   
   
3. Localize e clique nesta subchave do Registro:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Interface GUID>
   
   
4. No menu Editar, aponte para Novo e clique em Valor DWORD.
   
   
5. Nomeie o novo valor TcpAckFrequency e atribua a ele o valor 1.
   
   
6. Saia do Editor do Registro.
   
   
7. Reinicie o Windows para que esta alteração tenha efeito.

Observação: o bug da Cisco ID CSCum19065 foi arquivado para tornar os parâmetros de ajuste TCP configuráveis no ASA.

Exemplo de usuário típico

O caso de uso mais comum é quando um usuário em casa executa o OGS pela primeira vez, ele registra as configurações DNS e os resultados do ping do OGS no cache (o padrão é um tempo limite de 14 dias). Quando o usuário voltar para casa na noite seguinte, o OGS detectará as mesmas configurações DNS, localizará-as no cache e ignorará o teste de ping OGS. Mais tarde, quando o usuário vai a um hotel ou restaurante que oferece serviço de Internet, o OGS detecta diferentes configurações DNS, executa os testes de ping OGS, seleciona o melhor gateway e registra os resultados no cache.

O processamento é idêntico quando sai de um estado suspenso ou hibernado, se as configurações de retomada do OGS e do AnyConnect permitirem.

Solucionar problemas de OGS

Etapa 1. Limpe o cache OGS para forçar uma reavaliação

Para limpar o cache do OGS e reavaliar o RTT para gateways disponíveis, simplesmente exclua o arquivo de preferências do Global AnyConnect do PC. O local do arquivo varia de acordo com o sistema operacional (SO):

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

Etapa 2. Capturar os testes de servidor durante a tentativa de conexão

1. Inicie o Wireshark na máquina de teste.
   
   
2. Inicie uma tentativa de conexão no AnyConnect.
   
   
3. Pare a captura do Wireshark quando a conexão estiver completa.

   Dica: como a captura só é usada para testar OGS, é melhor interromper a captura assim que o AnyConnect selecionar um gateway. É melhor não passar por uma tentativa de conexão completa, pois isso pode colocar a captura de pacotes em nuvem.

Etapa 3. Verifique o gateway selecionado pelo OGS

Para verificar por que o OGS selecionou um gateway específico, siga estas etapas:

1. Inicie uma nova conexão.
   
   
2. Execute o AnyConnect DART:
   
   1. Inicie o AnyConnect e clique em Avançado.
   2. Clique em Diagnostics.
   3. Clique em Next.
   4. Clique em Next.
3. Examine os resultados do DART encontrados no arquivo recém-criado DartBundle_XXXX_XXXX.zip na área de trabalho.
   
   1. Navegue até Cisco AnyConnect Secure Mobility Client > AnyConnect.txt.
      
      
   2. Observe a hora em que as sondas OGS foram iniciadas para um servidor específico a partir deste log 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
      
      ******************************************

      
      Normalmente, eles devem estar próximos ao mesmo tempo, mas, caso as capturas sejam grandes, o carimbo de data e hora ajuda a restringir quais pacotes são as provas HTTP e quais são as tentativas de conexão reais.
      
      
   3. Quando o AnyConnect envia três testes ao servidor, esta mensagem é gerada com os resultados de cada um dos testes:
      

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

      É importante prestar atenção a esses três valores, pois eles devem corresponder aos resultados da captura.
      
      
   4. Procure a mensagem que contém "*** resultados de seleção OGS***" para ver o RTT avaliado e se a tentativa de conexão mais recente foi o resultado de um RTT armazenado em cache ou de um novo cálculo.
      
      Aqui está um exemplo:

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

Etapa 4. Validar os cálculos de OGS executados pelo AnyConnect 

Inspecione a captura dos testadores TCP/SSL usados para calcular o RTT. Veja quanto tempo a solicitação HTTPS leva sobre uma única conexão TCP. Cada solicitação de sondagem deve usar uma conexão TCP diferente. Para fazer isso, abra a captura no Wireshark e repita estas etapas para cada um dos servidores:

1. Use o filtro ip.addr para isolar os pacotes enviados para cada um dos servidores em sua própria captura. Para fazer isso, navegue até Edit e selecione Mark All Displayed Packets. Em seguida, navegue até File > Save As, selecione a opção Marked packets only e clique em Save:
   
   
   
   
2. Nesta nova captura, navegue para Exibir > Formato de exibição de hora > Data e hora do dia:
   
   
   
   
3. Identifique o primeiro pacote HTTP SYN nessa captura que foi enviado quando a prova OGS foi enviada com base nos registros do DART, conforme identificado na Etapa 3.3.2. É importante lembrar que, para o primeiro servidor, a primeira solicitação HTTP não é uma sonda de servidor. É fácil confundir a primeira solicitação de uma sonda de servidor e, assim, chegar a valores completamente diferentes do que o OGS relata. Esse problema é destacado aqui:
   
   
   
   
4. Para identificar mais facilmente cada um dos testes, clique com o botão direito do mouse no HTTP SYN para o primeiro teste e selecione Colorir conversação como mostrado aqui:
   
   
   
   Repita esse processo para os SYNs em todos os testes. Como mostrado na imagem anterior, os dois primeiros testes são representados em cores diferentes. A vantagem de colorir as conversações TCP é detectar facilmente retransmissões ou outras singularidades por sonda.
   
   
5. Para alterar a exibição da hora, navegue para Exibir > Formato de Exibição da Hora > Segundos Desde Época:
   
   
   
   Selecione Milissegundos, pois esse é o nível de precisão que o OGS usa.
   
   
6. Calcule a diferença de tempo entre o HTTP SYN e o FIN/ACK, como mostrado no diagrama da Etapa 4. Repita esse processo para cada um dos três testes e compare os valores com os mostrados nos registros do DART na Etapa 3.3.3.

Análise

Se, após a análise das capturas, os valores de RTT determinados forem calculados e comparados com os valores vistos nos registros do DART e tudo for encontrado para correspondência, mas ainda parecer que o gateway errado está sendo selecionado, isso se deve a um dos dois problemas:

• Há um problema no headend. Se esse for o caso, pode haver muitas retransmissões de um ponto inicial específico ou qualquer outra esquisitice vista nos testes. É necessária uma análise mais aprofundada do intercâmbio.
  
  
• Há um problema com o ISP (Provedor de serviços de Internet). Se esse for o caso, pode haver fragmentação ou grandes atrasos observados em um headend específico.

Perguntas e respostas

P: O OGS funciona com o balanceamento de carga?

R: Sim. O OGS está ciente apenas do nome do mestre do cluster e usa isso para julgar o headend mais próximo.

P: O OGS funciona com as configurações de proxy definidas no navegador?

R: O OGS não suporta proxy automático ou arquivos PAC (Auto Config) de proxy, mas suporta um servidor proxy codificado. Como tal, a operação OGS não ocorre. A mensagem de log relevante é: "O OGS não será executado porque a detecção automática de proxy está configurada".