AnyConnect の最適なゲートウェイの選択のトラブルシューティング ガイド
内容
はじめに
このドキュメントでは、最適なゲートウェイの選択（OGS）に関する問題をトラブルシュートする方法について説明します。OGS は、ラウンド トリップ時間（RTT）が最小のゲートウェイを特定してそのゲートウェイに接続するための機能です。OGS 機能を使用すれば、ユーザの介在なしでインターネット トラフィックの遅延を最小限に抑えることができます。Cisco AnyConnect セキュア モビリティ クライアント（AnyConnect）は、OGS を使用して、接続または再接続に最適なセキュア ゲートウェイを特定して選択します。OGS は、初回接続時または、直前の接続解除から 4 時間以上経過した後の再接続時に開始されます。詳細については、『管理者のガイド』を参照してください。
OGS の機能
多くのCisco適応型セキュリティアプライアンス(ASA)ファイアウォールは、検出されないようにICMPパケットをブロックするように設定されているため、単純なInternet Control Message Protocol(ICMP)のping要求が機能しません。代わりに、クライアントは、すべてのプロファイルの merge に表示されるヘッドエンドごとに 3 つずつの HTTP/443 要求を送信します。これらの HTTP プローブはログ内の OGS ping と呼ばれていますが、前述したように、ICMP ping ではありません。（再）接続の時間を短縮するために、OGS は OGS ping の結果が 7 秒以内に戻ってこなかった場合に、デフォルトで前回のゲートウェイを選択します（ログで OGS ping results を探してください）。
- OGS は、ドメイン ネーム システム（DNS）のサフィックスや DNS サーバの IP アドレスなどのネットワーク情報に基づいて、ユーザ ロケーションを特定します。RTT の結果は、このロケーションと一緒に、OGS キャッシュに保存されます。
- OGS ロケーション エントリは 14 日間キャッシュされます。Cisco Bug ID CSCtk66531 は、これらの設定をユーザが設定可能にするために登録されました。
- ロケーション エントリが初めてキャッシュされてから 14 日後まで OGS がこのロケーションから再度実行されることはありません。その間は、キャッシュされたエントリとそのロケーションに対して決定された RTT が使用されます。つまり、AnyConnectは再起動してもOGSを再実行しません。代わりに、キャッシュ内のそのロケーションに最適なゲートウェイ順序を使用します。Diagnostic AnyConnect Reporting Tool（DART）ログに、次のメッセージが表示されます。
******************************************
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 は、ユーザが AnyConnect プロファイル内のホスト エントリで指定された接続を試みるゲートウェイのセキュア ソケット レイヤ（SSL）ポートに対する TCP 交換を使って決定されます。
- 現時点で、OGS は、ユーザが一時停止から復帰したかどうかとしきい値が超過したかどうかのチェックだけを実行します。ユーザが接続している ASA がクラッシュまたは使用不能になっている場合は、OGS が別の ASA に接続しません。OGS は、プロファイル内のプライマリ サーバとだけ連絡を取って、最適なものを決定します。
- OGSクライアントプロファイルをダウンロードした後、ユーザがAnyConnectクライアントを再起動すると、他のプロファイルを選択するオプションは次のようにグレー表示されます。
ユーザマシンに他のプロファイルが複数ある場合でも、OGSを無効にするまで、ユーザマシンはこれらを選択できません。
OGS キャッシュ
計算が終了すると、結果が preferences_global ファイルに保存されます。このデータがファイルに保存されないという問題が発生したことがあります。
詳細については、Cisco Bug ID CSCtj84626 を参照してください。
ロケーション判別
OGS キャッシングは、DNS ドメインと個別の DNS サーバ IP アドレスの組み合わせに対して機能します。その動作を以下に示します。
- ロケーション A には、locationa.com という DNS ドメインと、ip1 と ip2 という 2 つの DNS サーバ IP アドレスが割り当てられています。ドメイン/IP の組み合わせごとに OGS キャッシュ エントリを指しているキャッシュ キーが作成されます。例：
- locationa.com|ip1 -> ogscache1
- locationa.com|ip2 -> ogscache1
- その後で、AnyConnect が物理的に異なるネットワークに接続すると、ドメイン/IP の組み合わせの同じ集合が作成され、キャッシュ リストに照らしてチェックされます。完全に一致するものが見つかると、その OGS キャッシュ値が使用され、クライアントはロケーション A に存在すると見なされます。
障害シナリオ
ここで、発生する可能性のある障害シナリオを示します。
ゲートウェイへの接続が失われた場合
OGSが使用されている場合、ユーザが接続されているゲートウェイへの接続が失われると、AnyConnectは バックアップサーバリストとnot 次のOGSホストに転送します。動作順序は次のとおりです。
- OGS は、プライマリ サーバとだけ連絡を取って、最適なものを決定します。
- 決定後の接続アルゴリズムは次のとおりです。
- 最適なサーバへの接続を試行する。
- それが失敗した場合は、最適なサーバのバックアップサーバリストを試してください。
- それが失敗した場合は、選択結果の順に、OGS 選択リストに残っているサーバを試す。
一時停止後の再開
OGS が再開後に動作するためには、マシンがスリープ状態になった時点で、AnyConnect が接続を確立している必要があります。再開後の OGS は、ネットワーク接続が使用可能であることを確認するためのネットワーク環境テストの実施後にのみ実行されます。このテストには DNS 接続サブテストが含まれます。
ただし、DNSサーバが「name not found」で応答するのではなく、クエリーフィールドにIPアドレスを含むタイプA要求をドロップする場合（より一般的なケースで、テスト中に常に発生）、Cisco Bug ID CSCti20768 「IPアドレスのタイプAのDNSクエリーは、タイムアウトを避けるためにPTRにする必要がある」が適用されます。
TCP 遅延 ACK ウィンドウ サイズでの間違ったゲートウェイの選択
バージョン9.1(3)より前のASAバージョンを使用している場合は、クライアント上のキャプチャに、SSLハンドシェイクの永続的遅延が示されます。注目すべきは、クライアントがその ClientHello を送信してから、ASA がその ServerHello を送信することです。通常は、その後に証明書メッセージ（オプションの Certificate Request）と ServerHelloDone メッセージが続きます。異常はやり取りが 2 重になっていることです。
- ASA は ServerHello の直後に証明書メッセージを送信しません。クライアント ウィンドウ サイズは 64,860 バイトで、ASA からの応答全体を保持するのに十分な大きさです。
- クライアントはServerHelloをすぐにACKしないため、ASAは約120ミリ秒後にServerHelloを再送信し、その時点でクライアントはデータをACKします。その後で、証明書メッセージが送信されます。これは、クライアントが追加のデータを待っているようなものです。
この現象は、TCP slow-start と TCP delayed-ACK の間のやり取りが原因で発生します。ASA バージョン 9.1(3) 以前は、ASA が 1 の slow-start ウィンドウ サイズを使用するのに対して、Windows クライアントは 2 の delayed-ACK 値を使用します。これは、ASA は ACK を受信するまで 1 つのデータ パケットしか送信しないことを意味しますが、クライアントは 2 つのデータ パケットを受信するまで ACK を送信しないことも意味します。ASA は、120 ms 後にタイムアウトして ServerHello を再送信してから、クライアントがデータを ACK して接続を継続します。 この動作は、Cisco Bug ID CSCug98113 によって変更されたため、ASA はデフォルトで、1 ではなく 2 の slow start ウィンドウ サイズを使用します。
これは、次の場合に OGS の計算に影響を与える可能性があります。
- 複数のゲートウェイが複数の ASA バージョンを実行している場合。
- クライアントの delayed-ACK ウィンドウ サイズが異なる場合。
このような場合は、delayed-ACK によってもたらされた遅延によって、クライアントが間違った ASA を選択する可能性があります。 この値がクライアントと ASA で異なる場合も、問題が発生する可能性があります。このような場合の回避策は、Delayed Acknowledgements ウィンドウ サイズを調整することです。
Windows
- レジストリ エディタを起動します。
- delayed-ACK を無効にするインターフェイスの GUID を特定します。これを行うには、 次のようにします。
[HKEY_LOCAL_MACHINE] > [SOFTWARE] > [Microsoft] > [WindowsNT] > [CurrentVersion] > [NetworkCards] > [（数字）] に移動します。
NetworkCards の下に表示された数字を確認します。右側で、[Description] にインターフェイス（Intel(R) Wireless WiFi Link 5100AGN など）が、[ServiceName] に対応する GUID が一覧表示されるはずです。 - 次のレジストリ サブキーを探してクリックします。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Interface GUID> - [Edit] メニューで、[New] をポイントしてから、[DWORD Value] をクリックします。
- 新しい値に TcpAckFrequency という名前を付け、それに 1 の値を割り当てます。
- Registry Editor を終了します。
- この変更を有効にするために、Windows を再起動します。
標準的な使用例
最も一般的な使用例を紹介します。あるユーザが自宅で OGS を初めて実行したときに、OGS が DNS 設定と OGS ping 結果をキャッシュ（デフォルトで 14 日間のタイムアウトに設定されている）に記録します。そのユーザが翌日の夕方に帰宅すると、OGS は同じ DNS 設定を検索して、それをキャッシュ内で発見し、OGS ping テストをスキップします。後日、そのユーザがインターネット サービスを提供しているホテルまたはレストランに行くと、OGS は別の DNS 設定を検出して OGS ping テストを実行し、最適なゲートウェイを選択して、その結果をキャッシュに記録します。
OGS と AnyConnect の再開設定で許可されていれば、中断状態または休止状態から再開される処理は同じです。
OGS のトラブルシューティング
ステップ 1：再評価を実施するためのOGSキャッシュのクリア
OGS キャッシュをクリアして使用可能なゲートウェイの RTT を再評価するには、PC から Global AnyConnect Preferences ファイルを削除するだけです。ファイルの場所はオペレーティング システム（OS）によって異なります。
- Windows Vista と 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..
ステップ 2：接続試行中のサーバプローブのキャプチャ
- テスト マシン上で Wireshark を開始します。
- AnyConnect に対する接続試行を開始します。
- 接続が完了したら Wireshark キャプチャを停止します。
ステップ 3：OGSによって選択されたゲートウェイの確認
OGS が特定のゲートウェイを選択した理由を確認するには、次の手順を実行します。
- 新しい接続を開始します。
- AnyConnect DART を実行します。
- AnyConnect を起動して、[Advanced] をクリックします。
- [Diagnostics] をクリックします。
- [Next] をクリックします。
- [Next] をクリックします。
- デスクトップに新しく作成された DartBundle_XXXX_XXXX.zip ファイル内の DART 結果を確認します。
- [Cisco AnyConnect Secure Mobility Client] > AnyConnect.txt に移動します。
- この DART ログから、特定のサーバに対して開始された OGS プローブの時刻をメモします。
******************************************
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
******************************************
通常は同じ時間に行われますが、キャプチャが大きい場合は、タイムスタンプによって、どのパケットがHTTPプローブで、どのパケットが実際の接続試行であるかを絞り込むことができます。 - AnyConnect が 3 つのプローブをサーバに送信すると、プローブごとの結果と一緒に次のメッセージが生成されます。
******************************************
この 3 つの値に注目することが重要です。これは、この値がキャプチャ結果と一致する必要があるからです。
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 )
****************************************** - "*** OGS Selection Results***" を含むメッセージを探して、評価された RTT と、最新の接続の試みがキャッシュされた RTT なのか、新しい計算結果なのかを確認します。
ランダム データの例は次のとおりです。******************************************
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.
******************************************
- [Cisco AnyConnect Secure Mobility Client] > AnyConnect.txt に移動します。
ステップ 4：AnyConnectによって実行されたOGS計算の検証
RTT の計算に使用された TCP/SSL プローブのキャプチャを検査します。HTTPS 要求が 1 回の TCP 接続を占有する時間を確認します。プローブ要求ごとに別々の TCP 接続を使用する必要があります。これを実現するには、Wireshark 内のキャプチャを開いて、サーバごとに次の手順を繰り返します。
- ip.addr フィルタを使用して、各サーバに送信されたパケットを個別のキャプチャに分離します。これを行うには、Editに移動して、Mark All Displayed Packetsを選択します。次に、File > Save Asに移動し、Marked packets onlyオプションを選択して、Saveをクリックします。
- この新しいキャプチャで、[View] > [Time Display Format] > [Date and Time of Day] に移動します。
- OGS プローブがステップ 3.3.2 で特定された DART ログに基づいて送信されたときに、送信されたこのキャプチャ内の最初の HTTP SYN パケットを特定します。最初のサーバでは、最初の HTTP 要求がサーバ プローブではないことを覚えておくことが重要です。最初の要求をサーバ プローブと誤解することによって、OGS の報告とは全く異なる値に辿り着くことがよくあります。ここで、この問題を具体的に示します。
- より簡単にプローブを識別するには、次のように、最初のプローブの [HTTP SYN] を右クリックしてから、[Colorize Conversation] を選択します。
すべてのプローブの SYN に対してこのプロセスを繰り返します。前の図に示すように、最初の 2 つのプローブが別々の色で表示されます。TCP カンバセーションを色分けするメリットは、プローブごとの再送信などの異常な振る舞いを簡単に見分けることができることです。 - 時間表示を変更するには、[View] > [Time Display Format] > [Seconds Since Epoch] に移動します。
[Milliseconds] を選択します。これは、それが OGS が使用する精度レベルだからです。 - ステップ4の図に示すように、HTTP SYNとFIN/ACKの時間差を計算します。3つのプローブのそれぞれに対してこのプロセスを繰り返し、手順3.3.3のDARTログに表示された値と比較します。
分析
キャプチャの分析後に、決定されたRTT値が計算され、DARTログに記録された値と比較された結果、すべてが一致していることがわかった場合でも、誤ったゲートウェイが選択されているように見える場合は、次の2つの問題のいずれかが原因です。
- ヘッドエンドに問題がある場合。この場合は、特定のヘッドエンドからの再送信が多すぎたり、他にもプローブ内で似たような異常が見られたりします。より厳密なやり取りの分析が必要です。
- インターネット サービス プロバイダー（ISP）に問題がある場合。この場合は、特定のヘッドエンドでフラグメンテーションや大きな遅延が見つかることがあります。
Q&A
Q:OGSはロードバランシングで動作しますか。
A:はい。OGS は、クラスタ マスター名だけを認識して、それを最も近いヘッドエンドの判別に使用します。
Q: OGSは、ブラウザで定義されているプロキシ設定で動作しますか。
A: OGSでは、自動プロキシまたはプロキシ自動設定(PAC)ファイルはサポートされませんが、ハードコードされたプロキシサーバはサポートされます。そのため、OGS 操作は行われません。 関連するログメッセージは「自動プロキシ検出が設定されているため、OGSは実行されません」です。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
26-Oct-2013 |
初版 |
フィードバック