AnyConnect Optimal Gateway - Leitfaden zur Fehlerbehebung

Einleitung

In diesem Dokument wird beschrieben, wie Sie Probleme mit Optimal Gateway Selection (OGS) beheben. OGS ist eine Funktion, die verwendet werden kann, um zu bestimmen, welches Gateway die niedrigste Round Trip Time (RTT) hat, und eine Verbindung zu diesem Gateway herzustellen. Mit der OGS-Funktion kann die Latenz für den Internetdatenverkehr ohne Benutzereingriff minimiert werden. Mit OGS identifiziert der Cisco AnyConnect Secure Mobility Client (AnyConnect) das sichere Gateway, das für eine Verbindung oder eine erneute Verbindung am besten geeignet ist, und wählt dieses aus. OGS beginnt beim ersten Anschluss oder bei einem erneuten Anschluss mindestens vier Stunden nach der vorherigen Trennung. Weitere Informationen finden Sie im Administratorhandbuch.

Tipp: OGS funktioniert am besten mit dem neuesten AnyConnect-Client und der ASA-Software Version 9.1(3)* oder höher.

Wie wirkt OGS?

Eine einfache ICMP-Ping-Anfrage (Internet Control Message Protocol) funktioniert nicht, da viele Cisco Adaptive Security Appliance (ASA)-Firewalls so konfiguriert sind, dass sie ICMP-Pakete blockieren, um eine Erkennung zu verhindern. Stattdessen sendet der Client drei HTTP/443-Anfragen an jedes Headend, das in einer Zusammenführung aller Profile erscheint. Diese HTTP-Tests werden in den Protokollen als OGS-Pings bezeichnet, sind aber, wie bereits erläutert, keine ICMP-Pings. Um sicherzustellen, dass eine (Re-)Verbindung nicht zu lange dauert, wählt OGS standardmäßig das vorherige Gateway aus, wenn es innerhalb von sieben Sekunden keine OGS-Ping-Ergebnisse empfängt. (Suchen Sie im Protokoll nach OGS-Ping-Ergebnissen.)

Hinweis: AnyConnect sollte eine HTTP-Anfrage an 443 senden, da die Antwort selbst wichtig ist und keine erfolgreiche Antwort. Leider sendet die Korrektur für die Proxy-Verarbeitung alle Anfragen als HTTPS. Siehe Cisco Bug-ID CSCtg38672 - OGS sollte Ping mit HTTP-Anfragen senden.

Hinweis: Wenn der Cache keine Headends enthält, sendet AnyConnect zunächst eine HTTP-Anfrage, um festzustellen, ob ein Authentifizierungsproxy vorhanden ist und ob die Anfrage verarbeitet werden kann. Erst nach dieser ersten Anfrage beginnt der OGS-Ping, um den Server zu testen.

• Der OGS bestimmt den Benutzerstandort anhand der Netzwerkinformationen, z. B. dem DNS-Suffix (Domain Name System) und der IP-Adresse des DNS-Servers. Die RTT-Ergebnisse werden zusammen mit diesem Speicherort im OGS-Cache gespeichert.
  
  
• Einträge des OGS-Standorts werden 14 Tage zwischengespeichert. Die Cisco Bug-ID CSCtk66531 wurde abgelegt, um diese Einstellungen vom Benutzer konfigurierbar zu machen.
  
  
• OGS wird erst 14 Tage nach dem ersten Zwischenspeichern des Standorteintrags von diesem Standort aus erneut ausgeführt. Während dieser Zeit werden der zwischengespeicherte Eintrag und die für diesen Speicherort ermittelten RTTs verwendet. Das bedeutet, dass AnyConnect beim erneuten Start kein OGS mehr ausführt, sondern stattdessen die optimale Gateway-Reihenfolge im Cache für diesen Standort verwendet. In den DART-Protokollen (Diagnostic AnyConnect Reporting Tool) wird folgende Meldung angezeigt:
  
  

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

• Der RTT-Wert wird mithilfe eines TCP-Austauschs mit dem SSL-Port (Secure Sockets Layer) des Gateways bestimmt, mit dem der Benutzer eine Verbindung herstellen möchte. Dies wird durch den Host-Eintrag im AnyConnect-Profil festgelegt.
  
  

  Hinweis: Im Gegensatz zum HTTP-Ping, der einen einfachen HTTP-Beitrag erstellt und dann den RTT und das Ergebnis anzeigt, sind OGS-Berechnungen etwas komplizierter. AnyConnect sendet drei Tests für jeden Server und berechnet die Verzögerung zwischen dem HTTP-SYN, das gesendet wird, und dem FIN/ACK-Wert für jede dieser Tests. Es verwendet dann die niedrigsten der Deltas, um die Server zu vergleichen und seine Auswahl zu treffen. Obwohl also HTTP-Pings ein ziemlich gutes Indiz dafür sind, welchen Server der AnyConnect wählen wird, stimmen sie möglicherweise nicht unbedingt überein. Weitere Informationen hierzu finden Sie im restlichen Dokument.

• Derzeit führt OGS die Prüfungen nur dann durch, wenn der Benutzer aus einem Suspend kommt und der Schwellenwert überschritten wurde. OGS stellt keine Verbindung mit einer anderen ASA her, wenn die ASA, mit der der Benutzer verbunden ist, abstürzt oder nicht verfügbar ist. OGS kontaktiert nur die primären Server im Profil, um den optimalen zu ermitteln.
  
  
• Wenn das OGS-Client-Profil heruntergeladen wurde und der Benutzer den AnyConnect-Client neu startet, wird die Option zur Auswahl anderer Profile abgeblendet, wie hier gezeigt:
  
  
  
  Selbst wenn der Benutzer mehrere andere Profile hat, kann er keines dieser Profile auswählen, bis OGS deaktiviert ist.

OGS-Cache

Nach Abschluss der Berechnung werden die Ergebnisse in der Datei preferences_global gespeichert. Es gab Probleme damit, dass diese Daten zuvor nicht in der Datei gespeichert wurden.

Weitere Informationen finden Sie unter Cisco Bug-ID CSCtj84626.

Standortbestimmung

Das OGS-Caching funktioniert auf einer Kombination aus DNS-Domäne und den einzelnen IP-Adressen des DNS-Servers. Es funktioniert wie folgt:

• Standort A hat eine DNS-Domäne von locationa.com und zwei IP-Adressen für DNS-Server - ip1 und ip2. Jede Domänen/IP-Kombination erstellt einen Cache-Schlüssel, der auf einen OGS-Cache-Eintrag verweist. Beispiele:
  • locationa.com|ip1 -> ogscache1
  • locationa.com|ip2 -> ogscache1
• Wenn AnyConnect dann eine Verbindung zu einem physisch unterschiedlichen Netzwerk herstellt, wird die gleiche Zusammenstellung von Domänen-/IP-Kombinationen erstellt und mit der zwischengespeicherten Liste abgeglichen. Wenn überhaupt Übereinstimmungen bestehen, wird dieser OGS-Cachewert verwendet, und der Client wird weiterhin als Standort A betrachtet.

Fehlerszenarien

Hier sind einige Fehlerszenarien, die bei Benutzern auftreten können:

Wenn keine Verbindung zum Gateway mehr besteht

Wenn bei Verwendung von OGS die Verbindung zum Gateway, mit dem die Benutzer verbunden sind, unterbrochen wird, stellt AnyConnect eine Verbindung zu den Servern im Sicherungsserverlisteundnicht auf den nächsten OGS-Host übertragen. Die Reihenfolge der Vorgänge ist wie folgt:

1. OGS kontaktiert nur die primären Server, um den optimalen zu ermitteln.
   
   
2. Nach der Ermittlung lautet der Verbindungsalgorithmus wie folgt:
   
   1. Versuchen Sie, eine Verbindung zum optimalen Server herzustellen.
   2. Wenn dies fehlschlägt, versuchen Sie es mit der Backup-Serverliste des optimalen Servers.
   3. Wenn dies fehlschlägt, probieren Sie jeden Server aus, der in der OGS-Auswahlliste verbleibt, sortiert nach seinen Auswahlergebnissen.

Hinweis: Wenn der Administrator die Liste der Backup-Server konfiguriert, kann der Administrator im aktuellen Profil-Editor nur den vollqualifizierten Domänennamen (FQDN) für den Backup-Server eingeben, nicht jedoch die Benutzergruppe, wie dies für den primären Server möglich ist:

Die Cisco Bug-ID CSCud84778 wurde zur Behebung dieses Problems abgelegt. Die vollständige URL muss jedoch in das Hostadressenfeld des Backup-Servers eingegeben werden und sollte funktionieren: https://<ip-address>/usergroup.

Fortsetzen nach einem Suspend

Damit OGS nach einem Lebenslauf ausgeführt werden kann, muss bei AnyConnect eine Verbindung hergestellt worden sein, als die Maschine in den Ruhemodus versetzt wurde. OGS nach einem Lebenslauf wird nur nach dem Test der Netzwerkumgebung durchgeführt, um sicherzustellen, dass die Netzwerkverbindung verfügbar ist. Dieser Test umfasst einen DNS-Verbindungsteiltest.

Wenn der DNS-Server jedoch Anforderungen des Typs A mit einer IP-Adresse im Abfragefeld verwirft, anstatt mit "name not found" zu antworten (der häufigere Fall, der immer während der Tests aufgetreten ist), wird die Cisco Bug-ID CSCti20768 "DNS query of type A for IP address, should be PTR to avoid timeout". 

TCP verzögert - ACK-Fenstergröße wählt falsches Gateway aus

Wenn ASA-Versionen vor Version 9.1(3) verwendet werden, zeigen die Erfassungen auf dem Client eine dauerhafte Verzögerung beim SSL-Handshake an. Es wird festgestellt, dass der Client Client ClientHello sendet, die ASA dann ServerHello. Darauf folgen normalerweise eine Zertifikatnachricht (optionale Zertifikatanforderung) und eine ServerHelloDone-Nachricht. Die Anomalie hat zwei Ursachen:

1. Die ASA sendet die Zertifikatsmeldung nicht sofort nach ServerHello. Die Größe des Client-Fensters beträgt 64.860 Byte, was mehr als genug ist, um die gesamte Antwort von der ASA aufzunehmen.
   
   
2. Der Client AKTIVIERT ServerHello nicht sofort, sodass die ASA ServerHello nach ~120 ms erneut sendet. Anschließend werden die Daten vom Client AKTIVIERT. Anschließend wird die Zertifikatsmeldung gesendet. Es ist fast so, als würde der Client auf weitere Daten warten.

Dies ist auf die Interaktion zwischen TCP Slow Start und TCP Delayed-ACK zurückzuführen. Vor der ASA-Version 9.1(3) verwendet die ASA-Version eine Zeitlupenfenstergröße von 1, wohingegen der Windows-Client den Delayed-ACK-Wert 2 verwendet. Das bedeutet, dass die ASA nur ein Datenpaket sendet, bis sie eine ACK erhält. Dies bedeutet aber auch, dass der Client erst eine ACK sendet, wenn er zwei Datenpakete empfängt. Nach 120 ms erfolgt die Zeitüberschreitung der ASA und die erneute Übertragung von ServerHello. Anschließend überprüft der Client die Daten und die Verbindung wird fortgesetzt. Dieses Verhalten wurde durch die Cisco Bug-ID CSCug98113 geändert, sodass die ASA standardmäßig eine langsame Startfenstergröße von 2 anstelle von 1 verwendet.

Dies kann sich auf die OGS-Berechnung auswirken, wenn:

• Auf verschiedenen Gateways werden verschiedene ASA-Versionen ausgeführt.
• Clients haben unterschiedliche verzögerte ACK-Fenstergrößen.

In solchen Situationen kann die Verzögerung, die durch das Delayed-ACK verursacht wird, ausreichen, um den Client zur Auswahl der falschen ASA zu veranlassen. Wenn sich dieser Wert zwischen Client und ASA unterscheidet, können weiterhin Probleme auftreten. In solchen Fällen besteht die Problemumgehung darin, die Größe des Fensters für verzögerte Bestätigungen anzupassen.

Windows

1. Starten Sie den Registrierungs-Editor.
   
   
2. Geben Sie die GUID der Schnittstelle an, für die Sie das Delayed-ACK deaktivieren möchten. Navigieren Sie dazu zu:
   HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > WindowsNT > CurrentVersion > NetworkCards > (Zahl).
   Schauen Sie sich die einzelnen Nummern unter NetworkCards an. Auf der rechten Seite sollte in der Beschreibung die Schnittstelle (z. B. Intel(R) Wireless WiFi Link 5100AGN) und in ServiceName die entsprechende GUID aufgeführt sein.
   
   
3. Suchen Sie den folgenden Registrierungsunterschlüssel, und klicken Sie darauf:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Schnittstellen-GUID>
   
   
4. Zeigen Sie im Menü Bearbeiten auf Neu, und klicken Sie dann auf DWORD-Wert.
   
   
5. Nennen Sie den neuen Wert TcpAckFrequency, und weisen Sie ihm den Wert 1 zu.
   
   
6. Beenden Sie den Registrierungs-Editor.
   
   
7. Starten Sie Windows neu, damit diese Änderung wirksam wird.

Hinweis: Die Cisco Bug-ID CSCum19065 wurde verworfen, um die TCP-Optimierungsparameter auf der ASA konfigurierbar zu machen.

Beispiel für einen typischen Benutzer

Der häufigste Anwendungsfall ist, dass ein Benutzer zu Hause OGS das erste Mal ausführt, die DNS-Einstellungen aufgezeichnet werden und der OGS-Ping im Cache erfolgt (standardmäßig ein 14-tägiges Timeout). Wenn der Benutzer am nächsten Abend nach Hause zurückkehrt, erkennt OGS die gleichen DNS-Einstellungen, findet sie im Cache und überspringt den OGS-Ping-Test. Später, wenn der Benutzer zu einem Hotel oder Restaurant geht, das Internet-Service anbietet, erkennt OGS verschiedene DNS-Einstellungen, führt die OGS-Ping-Tests durch, wählt das beste Gateway aus und speichert die Ergebnisse im Cache.

Die Verarbeitung ist identisch, wenn sie aus einem ausgesetzten oder Ruhezustand wieder aufgenommen wird, sofern dies die Wiederaufnahmeeinstellungen von OGS und AnyConnect zulassen.

Fehlerbehebung bei OGS

Schritt 1: Löschen des OGS-Cache, um eine Neubewertung zu erzwingen

Um den OGS-Cache zu löschen und die RTT auf verfügbare Gateways zu überprüfen, löschen Sie einfach die Datei "Global AnyConnect Preferences" vom PC. Der Speicherort der Datei hängt vom Betriebssystem ab:

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

Schritt 2: Erfassen Sie die Serversonden während des Verbindungsversuchs.

1. Starten Sie Wireshark auf dem Testcomputer.
   
   
2. Starten Sie auf AnyConnect einen Verbindungsversuch.
   
   
3. Beenden Sie die Erfassung von Wireshark, sobald die Verbindung abgeschlossen ist.

   Tipp: Da die Erfassung nur zum Testen von OGS verwendet wird, ist es am besten, die Erfassung zu stoppen, sobald AnyConnect ein Gateway auswählt. Es ist am besten, keinen kompletten Verbindungsversuch zu durchlaufen, da dies die Paketerfassung Cloud-fähig machen kann.

Schritt 3: Prüfen Sie, ob das Gateway von OGS ausgewählt wurde.

Führen Sie die folgenden Schritte aus, um zu überprüfen, warum OGS ein bestimmtes Gateway ausgewählt hat:

1. Stellen Sie eine neue Verbindung her.
   
   
2. Ausführen von AnyConnect DART:
   
   1. Starten Sie AnyConnect, und klicken Sie auf Erweitert.
   2. Klicken Sie auf Diagnose.
   3. Klicken Sie auf Next (Weiter).
   4. Klicken Sie auf Next (Weiter).
3. Überprüfen Sie die DART-Ergebnisse in der neu erstellten Datei DartBundle_XXXX_XXXX.zip auf dem Desktop.
   
   1. Navigieren Sie zu Cisco AnyConnect Secure Mobility Client > AnyConnect.txt.
      
      
   2. Beachten Sie, wie die OGS-Tests für einen bestimmten Server aus diesem DART-Protokoll gestartet wurden:
      

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

      
      Normalerweise sollten sie ungefähr zur gleichen Zeit sein, aber wenn die Aufnahmen groß sind, hilft der Zeitstempel, einzugrenzen, welche Pakete die HTTP-Tests sind und welche die tatsächlichen Verbindungsversuche sind.
      
      
   3. Sobald AnyConnect drei Tests an den Server sendet, wird diese Meldung mit den Ergebnissen für jede der Tests generiert:
      

      ******************************************
      
      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 ist wichtig, diese drei Werte zu beachten, da sie mit den Erfassungsergebnissen übereinstimmen müssen.
      
      
   4. Suchen Sie nach der Meldung, die "*** OGS Selection Results***" enthält, um die ausgewertete RTT zu sehen und ob der letzte Verbindungsversuch das Ergebnis einer zwischengespeicherten RTT oder einer neuen Berechnung war.
      
      Hier ein Beispiel:

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

Schritt 4: Validierung der von AnyConnect ausgeführten OGS-Berechnungen 

Überprüfen Sie die Erfassung auf die verwendeten TCP/SSL-Tests, um die RTT zu berechnen. Erfahren Sie, wie lange die HTTPS-Anfrage eine TCP-Verbindung übernimmt. Jede Anfrage sollte eine andere TCP-Verbindung verwenden. Öffnen Sie dazu die Erfassung in Wireshark, und wiederholen Sie diese Schritte für jeden der Server:

1. Verwenden Sie den ip.addr-Filter, um die an die einzelnen Server gesendeten Pakete in ihrer eigenen Erfassung zu isolieren. Navigieren Sie dazu zu Bearbeiten, und wählen Sie Alle angezeigten Pakete markieren aus. Navigieren Sie dann zu Datei > Speichern unter, wählen Sie die Option Nur markierte Pakete aus, und klicken Sie auf Speichern:
   
   
   
   
2. Navigieren Sie in dieser neuen Erfassung zu Ansicht > Zeitanzeigeformat > Datum und Tageszeit:
   
   
   
   
3. Identifizieren Sie das erste HTTP-SYN-Paket in dieser Erfassung, das gesendet wurde, als die OGS-Anfrage gesendet wurde, basierend auf den DART-Protokollen, wie in Schritt 3.3.2 beschrieben. Beachten Sie, dass die erste HTTP-Anforderung für den ersten Server keine Serverprobe ist. Es ist leicht, die erste Anfrage für eine Serverprobe zu verwechseln und so zu Werten zu gelangen, die sich völlig von denen unterscheiden, die OGS meldet. Dieses Problem wird hier hervorgehoben:
   
   
   
   
4. Um die einzelnen Tests einfacher zu identifizieren, klicken Sie mit der rechten Maustaste auf das HTTP SYN für die erste Abfrage, und wählen Sie dann Conversation (Konversation einfärben) wie folgt aus:
   
   
   
   Wiederholen Sie diesen Vorgang für die SYNs aller Tests. Wie im vorherigen Bild gezeigt, sind die ersten beiden Sonden in verschiedenen Farben dargestellt. Der Vorteil der Einfärbung der TCP-Konversationen besteht darin, auf einfache Weise Neuübertragungen oder andere derartige Kuriositäten pro Anfrage zu erkennen.
   
   
5. Um die Zeitanzeige zu ändern, navigieren Sie zu Ansicht > Zeitanzeigeformat > Sekunden seit Epoche:
   
   
   
   Wählen Sie Millisekunden aus, da dies der Genauigkeitsgrad ist, den OGS verwendet.
   
   
6. Berechnen Sie die Zeitdifferenz zwischen HTTP SYN und FIN/ACK, wie im Diagramm von Schritt 4 gezeigt. Wiederholen Sie diesen Vorgang für jede der drei Sonden, und vergleichen Sie die Werte mit den Werten in den DART-Protokollen in Schritt 3.3.3.

Analyse

Wenn nach der Analyse der Aufnahmen die ermittelten RTT-Werte berechnet und mit den Werten in den DART-Protokollen verglichen werden und alles als übereinstimmend erkannt wird, aber dennoch scheinbar das falsche Gateway ausgewählt wird, liegt dies an einem der folgenden beiden Probleme:

• Es liegt ein Problem am Headend vor. Wenn dies der Fall ist, kann es zu viele Neuübertragungen von einem bestimmten Headend geben, oder andere solche Kuriositäten, die in den Sonden gesehen werden. Eine genauere Analyse des Austauschs ist erforderlich.
  
  
• Es liegt ein Problem mit dem Internetdienstanbieter (ISP) vor. Ist dies der Fall, kann es zu Fragmentierung oder großen Verzögerungen bei einem bestimmten Headend kommen.

Fragen und Antworten

F: Funktioniert OGS mit Load Balancing?

A: Ja. OGS erkennt nur den Cluster-Master-Namen und verwendet diesen, um das nächste Headend zu beurteilen.

F: Funktioniert OGS mit den im Browser definierten Proxy-Einstellungen?

A: OGS unterstützt keine Auto-Proxy- oder Proxy Auto Config (PAC)-Dateien, jedoch einen fest codierten Proxy-Server. Daher tritt der OGS-Betrieb nicht auf. Die relevante Protokollmeldung lautet: "OGS wird nicht ausgeführt, da die automatische Proxy-Erkennung konfiguriert ist."