Cisco Secure Access VPNでのJabber DNS SRVレコード解決の問題
内容
お問い合わせ内容
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はどちらのパスでも適切な接続を確立できなくなります。
関連コンテンツ
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
04-May-2026
|
初版 |
フィードバック