In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
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.
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.
******************************************
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.
******************************************
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.
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.
Das OGS-Caching funktioniert auf einer Kombination aus DNS-Domäne und den einzelnen IP-Adressen des DNS-Servers. Es funktioniert wie folgt:
Hier sind einige Fehlerszenarien, die bei Benutzern auftreten können:
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:
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.
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".
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:
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:
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
Hinweis: Die Cisco Bug-ID CSCum19065 wurde verworfen, um die TCP-Optimierungsparameter auf der ASA konfigurierbar zu machen.
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.
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:
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
C:\Documents and Settings\AllUsers\Application Data\Cisco\Cisco AnyConnect VPN
Client\preferences_global.xml
/opt/cisco/anyconnect/.anyconnect_global
Note: with older versions of the client it used to be /opt/cisco/vpn..
/opt/cisco/anyconnect/.anyconnect_global
Note: with older versions of the client it used to be /opt/cisco/vpn..
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.
Führen Sie die folgenden Schritte aus, um zu überprüfen, warum OGS ein bestimmtes Gateway ausgewählt hat:
******************************************
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
******************************************
******************************************Es ist wichtig, diese drei Werte zu beachten, da sie mit den Erfassungsergebnissen übereinstimmen müssen.
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 )
******************************************
******************************************
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.
******************************************
Ü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:
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:
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."
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
26-Oct-2013 |
Erstveröffentlichung |