Handleiding voor probleemoplossing voor AnyConnect Optimale Gateway

Inleiding

Dit document beschrijft hoe u problemen kunt oplossen met Optimal Gateway Selection (OGS). OGS is een functie die kan worden gebruikt om te bepalen welke gateway de laagste Ronde Reistijd (RTT) heeft en verbinding te maken met die gateway. Men kan de OGS-functie gebruiken om latentie voor internetverkeer te minimaliseren zonder tussenkomst van de gebruiker. Met OGS identificeert en selecteert Cisco AnyConnect Secure Mobility Client (AnyConnect) welke beveiligde gateway het beste is voor verbinding of opnieuw verbinding. OGS begint bij de eerste verbinding of bij een nieuwe verbinding ten minste vier uur na de vorige ontkoppeling. Meer informatie vindt u in de beheerdershandleiding.

Tip: OGS werkt het beste met de nieuwste AnyConnect-client en ASA-software, versie 9.1(3)* of hoger.

Hoe werkt OGS?

Een eenvoudig Internet Control Message Protocol (ICMP) ping-verzoek werkt niet omdat veel firewalls van Cisco adaptieve security applicatie (ASA) zijn geconfigureerd om ICMP-pakketten te blokkeren om detectie te voorkomen. In plaats daarvan stuurt de client drie HTTP/443-verzoeken naar elke head-end die in een samenvoeging van alle profielen wordt weergegeven. Deze HTTP-sondes worden in de logboeken OGS pings genoemd, maar zoals eerder uitgelegd zijn ze geen ICMP-pings. Om ervoor te zorgen dat een (her)verbinding niet te lang duurt, selecteert OGS standaard de vorige gateway als het geen OGS ping resultaten binnen zeven seconden ontvangt. (Zoek naar OGS ping resultaten in het log.)

Opmerking: AnyConnect moet een HTTP-verzoek verzenden naar 443, omdat het antwoord zelf belangrijk is en geen succesvol antwoord is. Helaas, de oplossing voor proxy behandeling verstuurt alle verzoeken als HTTPS. Zie Cisco bug-id CSC38672 - OGS moet pingen met HTTP-verzoeken.

Opmerking: Als er geen headends in het cache zijn, stuurt AnyConnect eerst een HTTP-verzoek om te bepalen of er een verificatieproxy is en of deze het verzoek kan verwerken. Pas na dit eerste verzoek begint de OGS pings om de server te testen.

• OGS bepaalt de gebruikerslocatie op basis van de netwerkinformatie, zoals het DNS-achtervoegsel (Domain Name System) en het IP-adres van de DNS-server. De RTT resultaten, samen met deze locatie, worden opgeslagen in de OGS cache.
  
  
• OGS-locatiegegevens worden gedurende 14 dagen gecachet. Cisco bug-id CSCtk66531 is gedeponeerd om deze instellingen door de gebruiker te kunnen configureren.
  
  
• OGS wordt niet opnieuw uitgevoerd vanaf deze locatie tot 14 dagen nadat de locatie-ingang voor het eerst is gecachet. Gedurende deze tijd gebruikt het de gecachede vermelding en de voor die locatie bepaalde RTT's. Dit betekent dat wanneer AnyConnect opnieuw start, het niet opnieuw OGS uitvoert; in plaats daarvan gebruikt het de optimale gateway-volgorde in het cache voor die locatie. In de DART-logbestanden (Diagnostic AnyConnect Reporting Tool) wordt dit bericht weergegeven:
  
  

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

• RTT wordt bepaald met een TCP-uitwisseling naar de Secure Sockets Layer (SSL)-poort van de gateway waarmee de gebruiker zal proberen verbinding te maken zoals gespecificeerd door de hostvermelding in het AnyConnect-profiel.
  
  

  Opmerking: In tegenstelling tot de HTTP-ping, die een eenvoudige HTTP post doet en vervolgens de RTT en het resultaat toont, zijn OGS-berekeningen iets ingewikkelder. AnyConnect verzendt drie sondes voor elke server en berekent de vertraging tussen het HTTP-SYN dat wordt verzonden en het FIN/ACK voor elk van deze sondes. Het gebruikt dan de laagste van de delta's om de servers te vergelijken en zijn selectie te maken. Dus ook al is HTTP-pings een vrij goede indicatie van welke server de AnyConnect zal kiezen, ze hoeft niet per se te corresponderen. Hierover is meer informatie te vinden in de rest van het document.

• Momenteel voert OGS de controles alleen uit als de gebruiker uit een schorsing komt en de drempel is overschreden. OGS maakt geen verbinding met een andere ASA als de ASA de gebruiker is verbonden met crashes of niet beschikbaar is. OGS neemt alleen contact op met de primaire servers in het profiel om de optimale server te bepalen.
  
  
• Nadat het OGS-clientprofiel is gedownload, wordt de optie voor het selecteren van andere profielen grijs weergegeven, wanneer de gebruiker de AnyConnect-client opnieuw start:
  
  
  
  Zelfs als de gebruikersmachine meerdere andere profielen heeft, kunnen ze geen van deze profielen selecteren totdat de OGS uitgeschakeld is.

OGS Cache

Als de berekening is afgerond, worden de resultaten opgeslagen in het preferred_global bestand. Er zijn problemen geweest omdat deze gegevens niet eerder in het bestand zijn opgeslagen.

Raadpleeg Cisco-bug-id CSCtj84626 voor meer informatie.

Bepaling van locatie

OGS caching werkt aan een combinatie van het DNS-domein en de individuele DNS-server IP-adressen. Het werkt als volgt:

• Locatie A heeft een DNS-domein van locationa.com en twee DNS server IP-adressen - ip1 en ip2. Elke domein/IP-combinatie maakt een cachesleutel die verwijst naar een OGS-cacheingang. Voorbeeld:
  • locationa.com|ip1 -> ogscache1
  • locationa.com|ip2 -> ogscache1
• Als AnyConnect vervolgens verbinding maakt met een fysiek ander netwerk, wordt dezelfde opbouw van domeinen/IP-combinaties gemaakt en gecontroleerd aan de hand van de gecachede lijst. Als er al overeenkomsten zijn, wordt die OGS-cachewaarde gebruikt en wordt de client nog steeds beschouwd als locatie A.

Faalscenario’s

Hier zijn een aantal storingsscenario's die gebruikers kunnen tegenkomen:

Wanneer de Connectiviteit met de Gateway wordt verloren

Wanneer een OGS wordt gebruikt, wordt de verbinding met de gateway waarmee de gebruikers zijn verbonden, verbroken. AnyConnect maakt dan verbinding met de servers in de back-upserverlijstenniet naar de volgende OGS-host. De volgorde van de operaties is als volgt:

1. OGS neemt alleen contact op met de primaire servers om de optimale server te bepalen.
   
   
2. Na vaststelling is het aansluitingsalgoritme:
   
   1. Probeer verbinding te maken met de optimale server.
   2. Als dat mislukt, probeer dan de back-upserverlijst van de optimale server.
   3. Als dat mislukt, probeer elke server die in de OGS-selectielijst blijft staan, geordend op basis van zijn selectieresultaten.

Opmerking: wanneer de beheerder de back-upserverlijst configureert, staat de huidige profieleditor de beheerder alleen toe om de FQDN-naam (Fully Qualified Domain Name) voor de back-upserver in te voeren, maar niet de gebruikersgroep zoals voor de primaire server mogelijk is:

Om dit te corrigeren, is Cisco bug-id CSCud84778 ingevuld, maar de volledige URL moet worden ingevoerd in het veld hostadres voor de back-upserver en moet werken: https://<ip-adres>/gebruikersgroep.

Hervatten na een onderbreking

Om een OGS na een cv te kunnen uitvoeren, moet voor AnyConnect een verbinding tot stand zijn gebracht toen de machine in slaap werd gebracht. OGS na een cv wordt alleen uitgevoerd nadat de netwerkomgevingstest heeft plaatsgevonden, die bedoeld is om te bevestigen dat netwerkconnectiviteit beschikbaar is. Deze test bevat een DNS-connectiviteitssubtest.

Als de DNS-server echter type A-verzoeken laat vallen met een IP-adres in het veld query, in plaats van te antwoorden met "name not found" (het meest voorkomende geval, altijd aangetroffen tijdens tests), dan is de Cisco-bug-id CSC20768 De "DNS vraag van type A voor IP adres, zou PTR moeten zijn om onderbreking te vermijden" is van toepassing. 

TCP Delayed-ACK venstergrootte selecteert onjuiste gateway

Wanneer ASA versies eerder dan Versie 9.1(3) worden gebruikt, vertonen de opnamen op de client een aanhoudende vertraging in de SSL-handdruk. Wat wordt opgemerkt is dat de client zijn ClientHello verstuurt, dan verstuurt de ASA zijn ServerHello. Dit wordt normaal gevolgd door een certificaatbericht (optioneel certificaatverzoek) en een ServerHellodone-bericht. De anomalie is tweevoudig:

1. ASA verstuurt niet onmiddellijk het certificaatbericht na ServerHello. De grootte van het clientvenster is 64.860 bytes. Dit is meer dan genoeg om de gehele respons van de ASA aan te houden.
   
   
2. De client kan de ServerHello niet direct terugzetten, zodat de ASA de ServerHello na ~120ms opnieuw verzendt, op welk punt de client ACK de gegevens. Het certificaatbericht wordt vervolgens verzonden. Het is bijna alsof de klant wacht op meer gegevens.

Dit gebeurt vanwege de interactie tussen TCP slow-start en TCP delayed-ACK. Voorafgaand aan ASA versie 9.1(3) gebruikt ASA een traag-start venstergrootte van 1, terwijl de Windows-client een vertraagd-ACK-waarde van 2 gebruikt. Dit betekent dat de ASA slechts één gegevenspakket verstuurt tot het een ACK krijgt, maar het betekent ook dat de client geen ACK verstuurt tot het twee gegevenspakketten ontvangt. De ASA verlaat na 120ms en brengt de ServerHello opnieuw over, waarna de client-ACK de gegevens en de verbinding vervolgt. Dit gedrag is gewijzigd door Cisco bug-id CSC98113, zodat de ASA standaard een traag startvenster van 2 gebruikt in plaats van 1.

Dit kan een invloed hebben op de berekening van de OGS wanneer:

• Verschillende gateways hebben verschillende ASA versies.
• De cliënten hebben verschillende vertraging-ACK venstergrootte.

In dergelijke situaties zou de vertraging die door de delayed-ACK wordt geïntroduceerd, kunnen volstaan om de cliënt ertoe te brengen de verkeerde ASA te selecteren. Als deze waarde tussen de klant en de ASA verschilt, kunnen er nog steeds problemen zijn. In dergelijke situaties moet de tijdelijke oplossing het vensterformaat Vertraagde meldingen aanpassen.

Windows

1. Start de Register-editor.
   
   
2. Identificeer de GUID van de interface waarop u delayed-ACK wilt onbruikbaar maken. Om dit te doen, navigeer in:
   HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > WindowsNT > Huidige versie > Netwerkkaarten > (nummer).
   Bekijk elk nummer dat onder Netwerkkaarten wordt vermeld. Aan de rechterkant moet in de Beschrijving de interface worden vermeld (bijvoorbeeld Intel(R) Wireless WiFi Link 5100AGN) en in de ServiceName moet de corresponderende GUID worden vermeld.
   
   
3. Lokaliseer en klik vervolgens op deze registersubsleutel:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Interface GUID>
   
   
4. Richt in het menu Bewerken op Nieuw en klik vervolgens op DWORD Value.
   
   
5. Geef de nieuwe waarde TcpAckFrequency een naam en ken er een waarde van 1 aan toe.
   
   
6. Registereditor sluiten.
   
   
7. Start Windows opnieuw om deze wijziging door te voeren.

Opmerking: CSCum19065 van Cisco bug ID is in het bestand opgenomen om TCP-afstemmingsparameters op de ASA configureerbaar te maken.

Typisch gebruikersvoorbeeld

Het meest voorkomende geval is wanneer een gebruiker thuis OGS de eerste keer draait, het registreert de DNS-instellingen en de OGS ping resultaten in het cache (standaard een 14-dagen time-out). Wanneer de gebruiker de volgende avond thuiskomt, detecteert OGS dezelfde DNS-instellingen, vindt het in de cache en slaat de OGS ping test over. Later, wanneer de gebruiker naar een hotel of restaurant gaat dat internetservice aanbiedt, detecteert OGS verschillende DNS-instellingen, voert de OGS ping-tests uit, selecteert de beste gateway en registreert de resultaten in het cache.

De verwerking is identiek wanneer deze wordt hervat na een onderbreking of stilstand, als de instellingen van de OGS en AnyConnect dit mogelijk maken.

OGS problemen oplossen

Stap 1. Wis de OGS Cache om een herevaluatie te dwingen

Om de OGS cache te wissen en de RTT voor beschikbare gateways opnieuw te evalueren, verwijdert u eenvoudig het Global AnyConnect Preferences-bestand van de pc. De locatie van het bestand varieert afhankelijk van het besturingssysteem:

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

Stap 2. Leg de servertests tijdens de verbindingspoging vast

1. Start Wireshark op de testmachine.
   
   
2. Start een verbindingspoging op AnyConnect.
   
   
3. Stop de Wireshark-opname zodra de verbinding is voltooid.

   Tip: aangezien de opname alleen wordt gebruikt om OGS te testen, is het het beste om de opname te stoppen zodra AnyConnect een gateway selecteert. Het is best om niet door een volledige verbindingspoging te gaan, omdat dat het pakketopname kan wolken.

Stap 3. Controleer de gateway die is geselecteerd door OGS

Voltooi de volgende stappen om na te gaan waarom OGS een bepaalde gateway heeft geselecteerd:

1. Start een nieuwe verbinding.
   
   
2. Voer AnyConnect DART uit:
   
   1. Start AnyConnect en klik op Geavanceerd.
   2. Klik op Diagnostiek.
   3. Klik op Next (Volgende).
   4. Klik op Next (Volgende).
3. Bekijk de DART resultaten in het nieuwe DartBundle_XXXX_XXXX.zip bestand op het bureaublad.
   
   1. Navigeer naar Cisco AnyConnect Secure Mobility Client > AnyConnect.txt.
      
      
   2. Noteer het tijdstip waarop de OGS-tests voor een bepaalde server zijn gestart vanuit dit DART-logbestand:
      

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

      
      Gewoonlijk zouden zij rond de zelfde tijd moeten zijn, maar in het geval dat de opnamen groot zijn, helpt de tijdzegel onderaan welke pakketten de sondes van HTTP zijn en welke degenen de daadwerkelijke verbindingspogingen zijn.
      
      
   3. Zodra AnyConnect drie sondes naar de server verzendt, wordt dit bericht gegenereerd met de resultaten voor elk van de 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 )
      
      ******************************************

      Het is belangrijk om aandacht aan deze drie waarden te besteden, omdat zij de vangstresultaten moeten aanpassen.
      
      
   4. Zoek naar het bericht dat "*** resultaten van de selectie van OGS***"bevat om de beoordeelde RTT te zien, en of de meest recente verbindingspoging het resultaat van een caching RTT of een nieuwe berekening was.
      
      Hierna volgt een voorbeeld:

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

Stap 4. De OGS-berekeningen valideren via AnyConnect 

Inspecteer de opname voor de TCP/SSL-sondes die worden gebruikt om RTT te berekenen. Zie hoe lang het HTTPS-verzoek één enkele TCP-verbinding overneemt. Elk sonde verzoek zou een verschillende verbinding van TCP moeten gebruiken. Om dit te doen, opent u de opname in Wireshark en herhaalt u deze stappen voor elk van de servers:

1. Gebruik het filter ip.addr om de pakketten te isoleren die naar elk van de servers worden verzonden in hun eigen opname. Hiertoe navigeer u om te bewerken en selecteer Alle weergegeven pakketten markeren. Navigeer vervolgens naar Bestand > Opslaan als, selecteer de optie Alleen gemarkeerde pakketten en klik op Opslaan:
   
   
   
   
2. In deze nieuwe opname navigeer je naar Beeld > Tijdweergave > Datum en tijd van dag:
   
   
   
   
3. Identificeer het eerste HTTP SYN-pakket in deze opname dat werd verzonden toen de OGS-sonde werd verzonden op basis van de DART-logs zoals geïdentificeerd in stap 3.3.2. Het is belangrijk om te onthouden dat, voor de eerste server, het eerste HTTP verzoek geen server sonde is. Het is gemakkelijk om het eerste verzoek voor een serversonde te verwarren, en zo tot waarden volledig verschillend te komen van wat OGS rapporteert. Dit probleem wordt hier benadrukt:
   
   
   
   
4. Om elk van de sondes gemakkelijker te identificeren, klik HTTP SYN voor de eerste sonde met de rechtermuisknop aan, en selecteer dan Colorize Conversation zoals hier getoond:
   
   
   
   Herhaal dit proces voor de SYN's op alle sondes. Zoals in het vorige beeld wordt getoond, worden de eerste twee sondes in verschillende kleuren afgebeeld. Het voordeel van het inkleuren van de TCP gesprekken is om gemakkelijk heruitzendingen of andere dergelijke eigenaardigheden per sonde te herkennen.
   
   
5. Als u de tijdweergave wilt wijzigen, navigeer dan naar Beeld > Tijdweergave > Seconden sinds tijdvak:
   
   
   
   Selecteer Milliseconden, omdat dat het niveau van precisie is dat OGS gebruikt.
   
   
6. Bereken het tijdsverschil tussen HTTP SYN en FIN/ACK, zoals in het diagram van Stap 4. Herhaal dit proces voor elk van de drie sondes, en vergelijk de waarden met die getoond in de DART logboeken in Stap 3.3.3.

Analyse

Als na de analyse van de opnamen de bepaalde RTT-waarden worden berekend en vergeleken met de waarden die in de DART-logboeken worden gezien en alles wordt gevonden om aan te passen, maar het nog steeds lijkt alsof de verkeerde gateway wordt geselecteerd, dan is het te wijten aan een van twee problemen:

• Er is een probleem met het kopstuk. Als dit het geval is, kan er teveel wederuitzendingen van één bepaalde uiteinde, of een andere dergelijke eigenaardigheden gezien in de sondes zijn. De uitwisseling moet nader worden geanalyseerd.
  
  
• Er is een probleem met de Internet Service Provider (ISP). Als dit het geval is, kan er fragmentatie zijn of grote vertragingen voor één bepaald uiteinde worden waargenomen.

Vraag en antwoord

V: Werkt OGS met taakverdeling?

A: Ja. OGS is alleen op de hoogte van de clustermasternaam en gebruikt die om de dichtstbijzijnde head-end te beoordelen.

V: Werkt OGS met de proxy-instellingen die in de browser zijn gedefinieerd?

A: OGS ondersteunt automatische proxy- of proxy Auto Config (PAC)-bestanden niet, maar ondersteunt wel een hardgecodeerde proxyserver. Als zodanig gebeurt er geen OGS-handeling. Het relevante logbericht is: "OGS zal niet worden uitgevoerd omdat automatische proxydetectie is geconfigureerd."