内容

お問い合わせ内容

Cisco Secure Access VPNを実装すると、DNS SRVレコード解決の競合が原因で、Jabberクライアントに接続の問題が発生します。この問題は、Jabberが2つのDNS SRVレコード(CUCM(_cisco-UDS)用とExpressWay(_collab-edge)用)に到達すると発生します。 CUCM SRVレコードが解決した場合、動作するかどうかに関係なく、Jabberはオンプレミスであると想定し、ExpressWayではなくCUCMへの接続を試みます。この動作は、Jabber.logにあるbEdgeServerFlag = 0を使用したJabberロギングで明らかです。さらに、ExpressWay SRVレコードは、セキュアクライアントが解決に使用するプライベートDNSサーバに送信されているため失敗し、プライベートDNSサーバはこのパブリックSRVレコードを再帰的に検出しません。

環境

- Cisco Secure Access（旧称：Cisco AnyConnect Secure Mobility Client）

- Cisco Jabber クライアント

- Cisco Unified Communications Manager（CUCM）

- モバイルおよびリモートアクセス向けCisco ExpressWay

- プライベートとパブリックの両方のDNSサーバを備えたDNSインフラストラクチャ

- スプリットトンネリング機能を使用したVPNトンネル設定

解決策

この問題は、ExpressWay接続用にクライアントを手動で設定する代わりに、VPNトンネルを介してJabberトラフィックをルーティングすることで解決されました。このアプローチにより、Jabberトラフィックが適切なDNS解決パスを使用し、クライアントがオンプレミス接続を誤って引き受ける原因となるSRVレコードの競合を回避できます。

トラブルシューティングの手順

ステップ1:Wiresharkパケットキャプチャを使用してDNS SRVレコードクエリを分析します。

Use Wireshark filter: dns.qry.type == 33

手順2:Jabberログでエッジサーバフラグステータスを確認します

Check Jabber.log for: bEdgeServerFlag = 0

手順3：両方のSRVレコードのDNS解決動作を確認します

解決の確認：

- _cisco-UDS SRVレコード(CUCM)

- collab-edge SRVレコード(ExpressWay)(_C)

ソリューションの実装

Cisco Secure Access VPN Clientを設定して、ローカル/プライベートDNSサーバ経由でDNSクエリーを解決するのではなく、トンネルにJabberトラフィックを含めます。これにより、次のことが保証されます。

- Jabberトラフィックは正しいDNS解決パスを使用する

- SRVレコードの競合を回避

- ExpressWay接続が正しく確立されている

- Jabberの全機能を維持

この解決策は、ExpressWay用にJabberクライアントを手動で設定する方法よりも推奨されます。手動で設定すると、一部の機能が失われる可能性があります。

原因

根本原因は、JabberクライアントのDNS SRVレコード解決ロジックにあります。Jabberは起動時に、_cisco-UDS（CUCM用）と_collab-edge（ExpressWay用）という2つの特定のDNS SRVレコードを照会します。 クライアントの意思決定プロセスは、CUCM SRVレコードを優先します。このレコードが正常に解決されると、Jabberは実際のCUCM接続が機能するかどうか、またはExpressWay SRVレコードも解決するかどうかに関係なく、オンプレミス環境で動作していると想定し、bEdgeServerFlag = 0を設定します。

スプリットトンネリングを使用するVPNシナリオでは、ExpressWay SRVレコード(_collab-edge)が、Secure Clientによって使用されるプライベートDNSサーバに送信されます。これは通常、パブリックDNSレコードであり、プライベートDNSサーバは外部レコードの再帰検索を実行しないため、ExpressWay SRV解決は失敗します。この複合的な問題により、Jabberはどちらのパスでも適切な接続を確立できなくなります。

関連コンテンツ

- シスコのテクニカルサポートとダウンロード