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

VPN、DNS クエリおよびオペレーティング・ システム/プラットフォーム バリアント

2013 年 3 月 16 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2013 年 3 月 13 日) | フィードバック


質問

概要
方法異なる OSS プラットフォーム ハンドル DNS クエリの違いとは何、およびどのように AnyConnect および分割するためにまたは完全なトンネリングのその影響ドメイン名解決か。
各オペレーティング・ システムはどのように DNS を取扱うか。
Cisco サポート コミュニティ - 特集対話
関連情報

概要

この資料は違いで AnyConnect を質問に対する回答にどのようにのドメイン名解決の異なる Operations Support Systems (OSS)ハンドル DNS クエリおよび影響与えたものです。

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

注: Cisco TAC エンジニアによって提供しまされる。

Q. 方法異なる OSS プラットフォーム ハンドル DNS クエリの違いとは何、およびどのように AnyConnect および分割するためにまたは完全なトンネリングのその影響ドメイン名解決か。

A. 使用するときトンネリングを、持っています DNS のための 3 つのオプションを分割含んで下さい:

  1. 分割DNS —適応性があるセキュリティ アプライアンス モデル(ASA)で設定されたドメイン名を一致する ASA で定義される DNS クエリはトンネル、たとえば、DNSサーバにをおよび他通過します。

  2. トンネルすべて DNS — ASA で定義される DNSサーバへの DNS トラフィックだけ許可されます。 この設定はグループ ポリシーで行われます。

  3. 標準 DNS — ASA によっておよびまた否定応答の場合には定義されるすべての DNS クエリは物理的 な アダプタで設定される DNSサーバに DNSサーバを行くかもしれません通過します。

いずれの場合も、トンネルを通過するために定義される DNS クエリは ASA で定義されるあらゆる DNSサーバに行きます。 特に ASA で定義される DNSサーバがなければそして DNS 設定はトンネルのためにブランクです。 これはまた分割DNS を定義してもらわない場合、それを、理想的に意味します ASA によって定義されるすべての DNS クエリは DNSサーバに送られます。 ただし、現実には、この資料に説明がある動作はオペレーティング・ システムの依存異なります。

最もよい努力 分割DNS vs 本当

AnyConnect リリース 2.4 はレガシー IPSecクライアントで見つけられる本当分割DNS ではない分割DNS フォールバック(最もよい努力 分割DNS)をサポートします。 要求が分割DNS ドメインと一致する場合、AnyConnect は要求が ASA にトンネル伝送されるようにします。 サーバがホスト名を変換できない場合 DNS リゾルバは物理インターフェイスにマッピング される DNSサーバに同じクエリを続け、送ります。 一方では、要求が分割DNS ドメインのうちのどれも一致する、AnyConnect は ASA にそれをトンネル伝送しません。 その代り、それは DNS リゾルバが落ち、物理インターフェイスにマッピング される DNSサーバにクエリを送るように DNS 応答を構築します。 そういうわけでこの機能は分割トンネリングのための分割DNS、DNS フォールバック呼ばれません。 すなわち、だけでなく、AnyConnect はどのターゲット 分割DNS ドメインがトンネル伝送されるか要求だけまたホスト 名前解決のためのクライアント オペレーティング システム DNS リゾルバの動作に、それ頼ること保証します。

これは潜在的な私用 ドメイン名リークによるセキュリティ上の問題を上げます。 たとえば、ネイティブ DNS クライアントは公共 DNSサーバに VPN DNS名 サーバが DNS クエリを解決できなかったときにとりわけ私用 ドメイン名のためのクエリを送ることができます。

現在 3.0.4235 現在で Windows だけで、解決される不具合 CSCtn14578 を、参照して下さい。 ソリューション実装本当分割DNS; それは厳しく一致する問い合わせ、VPN DNSサーバに許されます設定されたドメイン名を。 物理的 な アダプタで設定されるそれらのような他の DNSサーバにだけ他のクエリがすべて、割り当てられます。

「すべてを」トンネル伝送すれば「トンネル伝送して下さいすべての DNS」を

分割トンネリングが無効(トンネルすべての設定)である時、DNS トラフィックはトンネルによって厳しく許可されます。 トンネルが、種類の分割トンネリングと共に、グループ ポリシーですべての DNS 設定、トンネルによってすべての DNS ルックアップを送信 する、DNS トラフィック設定されるとき同様に、トンネルによって厳しく許されます。

これは Windows のこれらの警告にプラットフォームを渡って一貫しています、:

トンネルすべてのうちのどれかがセキュア ゲートウェイでトンネル伝送します時(VPN アダプタに加えられる)設定される DNSサーバにまたはすべての DNS を設定されます、AnyConnect 厳しく許可します DNS トラフィックを。 これは以前に述べられた本当分割DNS ソリューションと共に実装されるセキュリティ拡張です。

これが問題となる(たとえば DNS アップデート/登録要求は非 VPN DNSサーバに送信 される必要があります)ある特定の場合証明すれば、ツー ステップ回避策は次のとおりです:

  1. 現在のコンフィギュレーションがトンネルすべてなら: イネーブルはトンネリングを、あらゆる偽 1 ホスト分割除きますリンク ローカル アドレスのようなネットワーク作業を、分割除きます

  2. すべての DNS がグループ ポリシーで設定されないトンネルを確認して下さい。

AnyConnect 3.0.4325 で解決される DNS パフォーマンス上の問題

この Windows 仕様問題はこのような状況の下で大抵流行します:

  • 設定されるホーム ルータ: DNS および DHCP サーバ同じ IP アドレス(AnyConnect 割り当てられるところでこれは DHCPサーバに必要なルートを作成します)が;

  • 多数の DNS ドメインはグループ ポリシーにあります;

  • トンネルすべての設定;

  • 名前解決は意味する非修飾されたホスト名によって問い合わせられたホスト名に関連した 1 つが試みられるまでリゾルバはすべての利用可能 な DNSサーバのいくつかの DNS サフィックスを試みる必要があることを実行しました。

問題は AnyConnect がブロックする物理的 な アダプタで DNS クエリを送信するように試みるネイティブ DNS クライアントが原因です(トンネルすべての設定を与えられる)。 これは名前解決遅延の原因となります。 カスタマー エクスペリエンス向上から、この遅延は肯定応答を受け取るまで DNS クライアントがすべて必要があるのでヘッドエンドによって押される多数の DNS サフィックスのために時々重要、特にです(およびすべての利用可能 な DNSサーバを通って)歩く。

この問題はバージョン 3.0.4325 で述べられた本当分割DNS ソリューションの概要と共に(不具合 CSCtq02141 および CSCtn14578 の組み合せ)、解決されます。

ただしアップグレードが設定されますそして可能性のある回避策は次のとおりです:

  1. イネーブルは 1 偽 IP アドレスのためのトンネリングを分割除きます、物理的 な アダプタをフローするローカル DNS 要求を可能にする。 どのデバイスでも VPN 上の IP アドレスの 1 にトラフィックを送信 することはまずないので linklocal サブネット 169.254.0.0/16 からのアドレスを使用できます。 分割を有効に した後すべての DNS 除いて下さい、クライアント プロファイルまたはクライアント自体のローカルLAN アクセス、およびディセーブル トンネルをイネーブルに設定することを忘れないようにして下さい。 ASA で、コンフィギュレーション変更はここにリストされています:

    access-list acl_linklocal_169.254.1.1 standard permit host 169.254.1.1
     group-policy gp_access-14 attributes
     split-tunnel-policy excludespecified
     split-tunnel-network-list value acl_linklocal_169.254.1.1
     split-tunnel-all-dns disable
    exit
    

    クライアント プロファイルで、ただこの行を追加する必要があります:

    <LocalLanAccess UserControllable="true">true</LocalLanAccess>

    また AnyConnect クライアント GUI のクライアントごとの基礎でこれを有効に することができます。 AnyConnect プリファレンス メニューにナビゲート し、イネーブル ローカルLAN アクセス オプションをチェックして下さい。

  2. 名前解決のために不適当なホスト名の代りに完全修飾ドメイン名(FQDN)を使用して下さい。

  3. 物理インターフェイスの DNSサーバのために別の IP アドレスを使用して下さい。

Q. 各オペレーティング・ システムが DNS を取扱う仕組み

A. ハンドル DNS が AnyConnect を捜す方法異なるオペレーティング・ システムに違いがあります分割トンネリングと使用されたとき(分割DNS なしで)。

Windows

ON ウィンドウは、DNS 設定インターフェースごとです。 これはクエリが VPN トンネル アダプタで失敗した場合分割トンネリングが使用されれば、DNS クエリは物理的 なアダプタの DNSサーバに戻って下ることができることを意味します。 分割DNS のない分割トンネリングが定義される場合、内部および外部 DNS 解決は外部 DNSサーバに戻って下るのではたらきます。

MAC

MAC では、DNS 設定はグローバルです。 従って分割トンネリングが使用されればが、分割DNS、それではないです可能性のある使用されません DNS クエリがトンネルの外の DNSサーバに行くことができるように。 外部に 内部で解決ただできます。 これはバグ CSCtf20226 および CSCtz86314 で文書化されています。 いずれの場合も、この回避するは問題を解決する必要があります:

- Specify a external DNS server IP address under the group-policy and use 
   FQDN for internal DNS queries.
- If external names are resolvable via the tunnel, disable split DNS and 
   remove the DNS names configured in the group policy, under Advanced > 
   Split Tunneling. This requires the use of FQDN for internal DNS queries.

- The split-DNS case has been resolved in AnyConnect 3.1, with these caveats:

* split-DNS must be enabled for both IP protocols (requires ASA v9.0 or later);
OR
* split-DNS must be enabled for one IP protocol 
   and 
   (if ASA has v9.0 or later: client bypass protocol for the other IP protocol,
    i.e. no address pool and Client Bypass Protocol enabled in the group policy
   or 
   if ASA is earlier than v9.0: no address pool configured for the other 
   IP protocol; this implies that this other IP protocol is IPv6)
 

注: AnyConnect は MAC OSX で直接 resolv.conf ファイルを変更しませんがむしろ OSX 仕様 DNS 設定を変更します。 OSX は resolv.conf を互換性の理由で最新の状態に保ちます。 OSX の DNS 設定を検知 するのに scutil dns コマンドを使用して下さい。

iPhone

iPhone は MAC の完全な反対であり、Windows と同じではないです。 分割トンネリングが定義されればが、分割DNS が定義されなければ、定義される DNS クエリはグローバル な DNSサーバを通って出かけます。 たとえば、分割DNS Domain エントリは内部解像度のために必須です。 この動作は不具合 CSCtq09624 で文書化されています、iOS AnyConnect クライアントのための最新の 2.5.4038 バージョンで固定されます。

注: CSCts89292 で文書化されていますわかっている iPhone DNS クエリ無視 .local ドメインでであって下さい。 Apple エンジニアは問題がオペレーティング・ システムの機能性によって引き起こされていることを確認します。 これは設計されていた動作であり、Apple はそこにですそれのための変更確認しません。

Cisco サポート コミュニティ - 特集対話

Cisco サポート コミュニティでは、フォーラムに参加して情報交換することができます。現在、このドキュメントに関連するトピックについて次のような対話が行われています。


関連情報


Document ID: 116016