實施Cisco Secure Access VPN時,由於DNS SRV記錄解析衝突,Jabber客戶端遇到連線問題。當Jabber延伸至兩個DNS SRV記錄時會發生問題:一個用於CUCM(_cisco-UDS),一個用於ExpressWay(_collab-edge)。 如果CUCM SRV記錄解析,無論其是否工作,Jabber都會假定其為本地記錄,並嘗試連線到CUCM而不是ExpressWay。在Jabber.log中看到bEdgeServerFlag = 0的Jabber日誌記錄中,明視訊記憶體在此行為。此外,ExpressWay SRV記錄會失敗,因為它正被傳送到安全客戶端用於解析的專用DNS伺服器,並且專用DNS伺服器不會遞迴查詢此公共SRV記錄。
Cisco Secure Access(前身為Cisco AnyConnect Security Mobility Solution)
Cisco Jabber使用者端
思科整合通訊管理員(CUCM)
適用於移動和遠端訪問的Cisco ExpressWay
具有私有和公共DNS伺服器的DNS基礎設施
具有分割隧道功能的VPN隧道配置
此問題通過通過VPN隧道路由Jabber流量而不是嘗試手動配置客戶端的ExpressWay連線而得到解決。此方法可確保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)
配置Cisco安全訪問VPN客戶端,使其在隧道中包括Jabber流量,而不是允許其通過本地/專用DNS伺服器解析DNS查詢。這可確保:
Jabber流量使用正確的DNS解析路徑
避免SRV記錄衝突
ExpressWay連線已正確建立
維護了完整的Jabber功能
此解決方案優先於手動配置ExpressWay版Jabber客戶端,這將導致某些功能丟失。
根本原因是Jabber客戶端中的DNS SRV記錄解析邏輯。當Jabber啟動時,它將查詢兩個特定的DNS SRV記錄:_cisco-UDS(適用於CUCM)和_collab-edge(適用於ExpressWay)。 客戶端決策過程會優先處理CUCM SRV記錄 — 如果此記錄成功解析,Jabber會假定它在本地環境中運行並設定bEdgeServerFlag = 0,而不管實際的CUCM連線是否工作或者ExpressWay SRV記錄是否也解析。
在使用分割隧道的VPN方案中,ExpressWay SRV記錄(_collab-edge)會被傳送到安全客戶端使用的專用DNS伺服器。由於這通常是公共DNS記錄,並且專用DNS伺服器不會對外部記錄執行遞迴查詢,因此ExpressWay SRV解析失敗。此複合問題導致Jabber無法通過任一路徑建立正確的連線。
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
04-May-2026
|
初始版本 |