セキュリティ : Cisco AnyConnect セキュア モビリティ クライアント

AnyConnect の最適なゲートウェイの選択のトラブルシューティング ガイド

2015 年 11 月 25 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 5 日) | フィードバック

概要

このドキュメントでは、最適なゲートウェイの選択(OGS)を使用して問題をトラブルシューティングする方法について説明します。 OGS は、ラウンド トリップ時間(RTT)が最小のゲートウェイを特定してそのゲートウェイに接続するための機能です。 OGS 機能を使用すれば、ユーザの介在なしでインターネット トラフィックの遅延を最小限に抑えることができます。 Cisco AnyConnect セキュア モビリティ クライアント(AnyConnect)は、OGS を使用して、接続または再接続に最適なセキュア ゲートウェイを特定して選択します。 OGS は、初回接続時または、直前の接続解除から 4 時間以上経過した後の再接続時に開始されます。 詳細については、『管理者のガイド』を参照してください。

ヒント: OGS は、最新の AnyConnect クライアントと ASA ソフトウェア バージョン 9.1(3)? 以降と最もうまく連動します。

著者:Cisco TAC エンジニア。

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 を探してください)。

: AnyConnect は、正常な応答ではなく、応答自体が重要なため、HTTP 要求を 443 に送信する必要があります。 残念ながら、プロキシ処理に対する修正では、すべての要求が HTTPS として送信されます。 「Cisco Bug ID CSCtg38672 - OGS は HTTP 要求を使って ping する必要がある」を参照してください。

: キャッシュ内にヘッドエンドが存在しない場合は、AnyConnect が最初に、認証プロキシが存在するかどうかとそれが要求を処理できるかどうかを確認するための 1 つの HTTP 要求を送信します。 サーバをプローブするために OGS ping を開始するのはこの初期要求の後だけです。

  • OGS は、ドメイン ネーム システム(DNS)のサフィックスや DNS サーバの IP アドレスなどのネットワーク情報に基づいて、ユーザ ロケーションを特定します。 RTT の結果は、このロケーションと一緒に、OGS キャッシュに保存されます。

  • OGS ロケーション エントリは 14 日間キャッシュされます。 これらの設定をユーザが構成できるようにするために、機能強化 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 交換を使って決定されます。

    : 単純な HTTP ポストを実行してから、RTT と結果を表示する HTTP ping と違って、OGS の計算はもう少し複雑です。 AnyConnect は、サーバごとに 3 つずつのプローブを送信し、送信した HTTP SYN 間の遅延とそれらのプローブごとの FIN/ACK を計算します。 その後で、最も少ない差分を使ってサーバを比較して、選択を実行します。 そのため、HTTP ping が、AnyConnect が選択するサーバの適切な指針になる場合でも、必ずしも一致しないことがあります。 この詳細については後述します。

  • 現時点で、OGS は、ユーザが一時停止から復帰したかどうかとしきい値が超過したかどうかのチェックだけを実行します。 ユーザが接続している ASA がクラッシュまたは使用不能になっている場合は、OGS が別の ASA に接続しません。 OGS は、プロファイル内のプライマリ サーバとだけ連絡を取って、最適なものを決定します。

  • OGS クライアント プロファイルがダウンロードされると、ユーザが AnyConnect クライアントを再起動したときに、他のプロファイルを選択するオプションが次のように淡色表示になります。



    ユーザ マシンに他のプロファイルが保存されている場合でも、OGS が無効になるまでそれらを選択することはできません。

OGS キャッシュ

計算が終了すると、結果が preferences_global ファイルに保存されます。 このデータがファイルに保存されないという問題が発生したことがあります。

詳細については、Cisco Bug ID CSCtj84626 を参照してください。

ロケーション判別

OGS キャッシングは、DNS ドメインと個別の DNS サーバ IP アドレスの組み合わせに対して機能します。 その動作を以下に示します。

  • ロケーション A には、locationa.com という DNS ドメインと、ip1ip2 という 2 つの DNS サーバ IP アドレスが割り当てられています。 ドメイン/IP の組み合わせごとに OGS キャッシュ エントリを指しているキャッシュ キーが作成されます。 次に、例を示します。
    • locationa.com|ip1 -> ogscache1
    • locationa.com|ip2 -> ogscache1

  • その後で、AnyConnect が物理的に異なるネットワークに接続すると、ドメイン/IP の組み合わせの同じ集合が作成され、キャッシュ リストに照らしてチェックされます。 完全に一致するものが見つかると、その OGS キャッシュ値が使用され、クライアントはロケーション A に存在すると見なされます。

障害シナリオ

ここで、発生する可能性のある障害シナリオを示します。

ゲートウェイへの接続が失われた場合

OGS が使用されている場合は、ユーザが接続されているゲートウェイへの接続が失われると、AnyConnect が、次の OGS ホストではなくバックアップ サーバ リスト内のサーバに接続します。 動作順序は次のとおりです。

  1. OGS は、プライマリ サーバとだけ連絡を取って、最適なものを決定します。
  2. 決定後の接続アルゴリズムは次のとおりです。

    1. 最適なサーバへの接続を試行する。
    2. それが失敗した場合は、最適なサーバのバックアップ サーバ リストを試す。
    3. それが失敗した場合は、選択結果の順に、OGS 選択リストに残っているサーバを試す。

: 管理者がバックアップ サーバ リストを設定するときに、最新のプロファイル エディタを使用すれば、バックアップ サーバの完全修飾ドメイン名(FQDN)を入力することはできますが、プライマリ サーバのようにユーザ グループを入力することはできません。


これを修正するために Cisco Bug ID CSCud84778 が提起されていますが、バックアップ サーバのホスト アドレス フィールドに完全な URL を入力しなければ機能しません。 https://<ip-address>/usergroup.

一時停止後の再開

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 重になっていることです。

  1. ASA は ServerHello の直後に証明書メッセージを送信しません。 クライアント ウィンドウ サイズは 64,860 バイトで、ASA からの応答全体を保持するのに十分な大きさです。

  2. クライアントは ACK ServerHello すぐに、従って ASA は ~120ms の後で ServerHello、その時点でクライアント ACK をデータ再送信します。 その後で、証明書メッセージが送信されます。 これは、クライアントが追加のデータを待っているようなものです。

この現象は、TCP slow-startTCP 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

  1. レジストリ エディタを起動します。

  2. delayed-ACK を無効にするインターフェイスの GUID を特定します。 これを実行するには、
    [HKEY_LOCAL_MACHINE] > [SOFTWARE] > [Microsoft] > [WindowsNT] > [CurrentVersion] > [NetworkCards] > [(数字)] に移動します。
    NetworkCards の下に表示された数字を確認します。 右側で、[Description] にインターフェイス(Intel(R) Wireless WiFi Link 5100AGN など)が、[ServiceName] に対応する GUID が一覧表示されるはずです。

  3. 次のレジストリ サブキーを探してクリックします。
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Interface GUID>

  4. [Edit] メニューで、[New] をポイントしてから、[DWORD Value] をクリックします。

  5. 新しい値に TcpAckFrequency という名前を付け、それに 1 の値を割り当てます。

  6. Registry Editor を終了します。

  7. この変更を有効にするために、Windows を再起動します。

: ASA 上で TCP 調整パラメータを設定可能にするために機能強化要求 CSCum19065 が提起されています。

標準的な使用例

最も一般的な使用例を紹介します。あるユーザが自宅で 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. 接続試行中のサーバ プローブのキャプチャ

  1. テスト マシン上で Wireshark を開始します。
  2. AnyConnect に対する接続試行を開始します。
  3. 接続が完了したら Wireshark キャプチャを停止します。

    ヒント: キャプチャは OGS のテストにしか使用されないため、AnyConnect がゲートウェイを選択したらすぐにキャプチャを停止することをお勧めします。 パケット キャプチャに悪影響を及ぼす可能性があるため、接続の試みは途中で切り上げることをお勧めします。

ステップ 3. OGS によって選択されたゲートウェイの確認

OGS が特定のゲートウェイを選択した理由を確認するには、次の手順を実行します。

  1. 新しい接続を開始します。
  2. AnyConnect DART を実行します。

    1. AnyConnect を起動して、[Advanced] をクリックします。
    2. [Diagnostics] をクリックします。
    3. [Next] をクリックします。
    4. [Next] をクリックします。


  3. デスクトップに新しく作成された DartBundle_XXXX_XXXX.zip ファイル内の DART 結果を確認します。

    1. [Cisco AnyConnect Secure Mobility Client] > AnyConnect.txt に移動します。

    2. この 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 プローブであるパケットと実際の接続の試みであるパケットを絞り込むことができます。

    3. AnyConnect が 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 )

      ******************************************
      この 3 つの値に注目することが重要です。これは、この値がキャプチャ結果と一致する必要があるからです。

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

      ******************************************

ステップ 4. AnyConnect によって実行された OGS 計算の検証 

RTT の計算に使用された TCP/SSL プローブのキャプチャを検査します。 HTTPS 要求が 1 回の TCP 接続を占有する時間を確認します。 プローブ要求ごとに別々の TCP 接続を使用する必要があります。 これを実現するには、Wireshark 内のキャプチャを開いて、サーバごとに次の手順を繰り返します。

  1. ip.addr フィルタを使用して、各サーバに送信されたパケットを個別のキャプチャに分離します。 これを実現するには、[Edit] に移動して、[MarkAll Displayed Packets] を選択します。 その後で、[File] > [Save As] に移動して、[Markedpackets only] オプションを選択し、[Save] をクリックします。



  2. この新しいキャプチャで、[View] > [Time Display Format] > [Date and Time of Day] に移動します。



  3. OGS プローブがステップ 3.3.2 で特定された DART ログに基づいて送信されたときに、送信されたこのキャプチャ内の最初の HTTP SYN パケットを特定します。 最初のサーバでは、最初の HTTP 要求がサーバ プローブではないことを覚えておくことが重要です。 最初の要求をサーバ プローブと誤解することによって、OGS の報告とは全く異なる値に辿り着くことがよくあります。 ここで、この問題を具体的に示します。



  4. より簡単にプローブを識別するには、次のように、最初のプローブの [HTTP SYN] を右クリックしてから、[Colorize Conversation] を選択します。



    すべてのプローブの SYN に対してこのプロセスを繰り返します。 前の図に示すように、最初の 2 つのプローブが別々の色で表示されます。 TCP カンバセーションを色分けするメリットは、プローブごとの再送信などの異常な振る舞いを簡単に見分けることができることです。

  5. 時間表示を変更するには、[View] > [Time Display Format] > [Seconds Since Epoch] に移動します。



    [Milliseconds] を選択します。これは、それが OGS が使用する精度レベルだからです。

  6. ステップ 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 will not be performed because automatic proxy detection is configured.」


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 116721