本產品的文件集力求使用無偏見用語。針對本文件集的目的,無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言,或引用第三方產品的語言,因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。
思科已使用電腦和人工技術翻譯本文件,讓全世界的使用者能夠以自己的語言理解支援內容。請注意,即使是最佳機器翻譯,也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責,並建議一律查看原始英文文件(提供連結)。
本文檔介紹如何解決客戶在部署階段面臨的最常見合作邊緣問題。
移動和遠端訪問(MRA)是用於虛擬專用無網路(VPN)Jabber功能的部署解決方案。此解決方案允許終端使用者從全球任何地方連線到內部企業資源。編寫本指南是為了使對Collaboration Edge解決方案進行故障排除的工程師能夠快速確定並解決客戶在部署階段面臨的最常見問題。
思科建議您瞭解以下主題:
本文中的資訊係根據以下軟體和硬體版本:
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
此症狀可能由一系列問題引起,其中某些問題將在此處概述。
要使Jabber客戶端能夠成功使用MRA登入,必須建立特定的合作邊緣SRV記錄並且可從外部訪問。當Jabber客戶端最初啟動時,它將進行DNS SRV查詢:
如果已啟動Jabber使用者端,但未收到_cisco-uds和_cuplogin的SRV回應,且未收到_collab-edge的回應,則它會使用此回應嘗試連線在SRV回應中列出的Expressway-E。
_collab-edge SRV記錄指向埠8443的Expressway-E的完全限定域名(FQDN)。如果_collab-edge SRV未建立,或不在外部可用,或如果它可用,但無法訪問埠8443,則Jabber客戶端無法登入。
您可以確認_collab-edge SRV記錄是否可解析,以及使用Collaboration Solutions Analyzer(CSA)中的SRV檢查器是否可以訪問TCP埠8443。
如果連線埠8443無法連線,則可能是由於安全裝置(防火牆)封鎖連線埠,或因為Exp-E中的預設閘道(GW)或靜態路由組態錯誤。
在Jabber客戶端收到_collab-edge的答案後,它會通過埠8443與具有傳輸層安全(TLS)的Expressway聯絡,嘗試從Expressway檢索證書,以設定TLS來進行Jabber客戶端和Expressway之間的通訊。
如果Expressway沒有包含Expressway FQDN或域的有效簽名證書,則此操作會失敗,並且Jabber客戶端無法登入。
如果發生此問題,請在Expressway上使用證書簽名請求(CSR)工具,該工具會自動將Expressway的FQDN作為使用者替代名稱(SAN)包括在內。
注意:MRA要求在Expressway-C和Expressway-E之間以及Expressway-E和外部終端之間進行安全通訊。
在MRA部署指南中可找到具有Expressway證書要求功能的下一個表:
Jabber使用者端成功建立與Expressway-E的安全連線後,會要求進行邊緣組態(get_edge_config)。此邊緣配置包含_cuplogin和_cisco-uds的SRV記錄。如果在邊緣配置中未返回_cisco-uds SRV記錄,則Jabber客戶端無法繼續登入。
若要解決此問題,請確保_cisco-uds SRV記錄已在內部建立,並且可由Expressway-C解析。
有關DNS SRV記錄的詳細資訊,請參閱X8.11的MRA部署指南。
如果您位於雙域中,這也是一個常見症狀。如果您在雙域中運行,並且發現Jabber客戶端未返回任何使用者資料服務(UDS),則必須確認在內部DNS中與外部域一起建立了_cisco-uds SRV記錄。
註:在Expressway版本X12.5之後,不再需要將_cisco-UDS SRV記錄新增到內部DNS。有關此增強功能的詳細資訊,請參閱通過Cisco Expressway的移動和遠端訪問部署指南(X12.5)。
如果Expressway-E網路介面控制器(NIC)配置不正確,可能會導致無法更新可擴展通訊平台(XCP)伺服器。如果Expressway-E符合以下標準,則可能會遇到此問題:
要解決此問題,請將Use Dual Network Interfaces選項更改為No。
出現此問題的原因是Expressway-E在錯誤的網路介面上偵聽XCP會話,從而導致連線失敗/超時。Expressway-E在TCP埠7400上監聽XCP會話。如果您使用 netstat
命令。
如果DNS頁面配置中的Expressway-E伺服器主機名/域與_collab-edge SRV應答中收到的不匹配,則Jabber客戶端無法與Expressway-E通訊。Jabber客戶端使用get_edge_config響應中的xmppEdgeServer/Address元素建立到Expressway-E的XMPP連線。
以下是從Expressway-E到Jabber客戶端的get_edge_config響應中xmppEdgeServer/Address的示例:
<xmppEdgeServer>
<server>
<address>examplelab-vcse1.example URL</address>
<tlsPort>5222</tlsPort>
</server>
</xmppEdgeServer>
為了避免這種情況,請確保_collab-edge SRV記錄與Expressway-E主機名/域名匹配。已為此錯誤歸檔思科錯誤ID CSCuo83458,並且已在思科錯誤ID CSCuo82526上新增部分支援。
Windows版Jabber日誌顯示以下內容:
2014-11-22 19:55:39,122 INFO [0x00002808] [very\WebexCasLookupDirectorImpl.cpp(134)]
[service-discovery] [WebexCasLookupDirectorImpl::makeCasLookupWhenNetworkIs
Available] - makeCasLookupForDomain result is 'Code: IS_WEBEX_CUSTOMER; Server:
http://URL server;
Url: http://example URL server';;;.2014-11-22
19:55:39,122 INFO [0x00002808] [overy\WebexCasLookupDirectorImpl.cpp(67)]
[service-discovery] [WebexCasLookupDirectorImpl::determineIsWebexCustomer] -
Discovered Webex Result from server. Returning server result.2014-11-22 19:55:39,122
DEBUG [0x00002808] [ery\WebexCasLookupUrlConfigImpl.cpp(102)]
[service-discovery] [WebexCasLookupUrlConfigImpl::setLastCasUrl] - setting last_cas_
lookup_url : http://example URL server2014-11-22
19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStoreManager.cpp(286)]
[ConfigStoreManager] [ConfigStoreManager::storeValue] - key : [last_cas_lookup_url]
value : [http://example URL server/cas/FederatedSSO?org=example URL]2014-11-22
19:55:39,123 DEBUG [0x00002808] [common\processing\TaskDispatcher.cpp(29)]
[TaskDispatcher] [Processing::TaskDispatcher::enqueue] - Enqueue ConfigStore::persist
Values - Queue Size: 02014-11-22 19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStore
Manager.cpp(140)]
[ConfigStoreManager] [ConfigStoreManager::getValue] - key : [last_cas_lookup_url]
skipLocal : [0] value: [http://website URL/cas/FederatedSSO?org=example URL]
success: [true] configStoreName: [LocalFileConfigStore]
登入嘗試定向到WebEx Connect。
若要獲得永久解決方案,必須聯絡WebEx才能停用該網站。
因應措施
在短期內,您可以使用這些選項之一將其從查詢中排除。
<?xml version="1.0" encoding="utf-8"?>
<config version="1.0">
<Policies>
<ServiceDiscoveryExcludedServices>WEBEX<
/ServiceDiscoveryExcludedServices>
</Policies>
</config>
msiexec.exe /i CiscoJabberSetup.msi /quiet CLEAR=1 AUTHENTICATOR=CUP EXCLUDED_SERVICES=WEBEX
註:第二個選項不適用於流動裝置。
ciscojabber://provision?ServiceDiscoveryExcludedServices=WEBEX
有關UC服務發現以及如何在Cisco Jabber 12.8本地部署中排除某些服務的詳細資訊,請參閱。
如果導航到Status > Unified Communications並看到錯誤消息, "Configured but with errors. Provisioning server: Waiting for traversal server info."
對於Unified CM註冊和IM&P服務,在Expressway-C上配置的內部DNS伺服器具有兩個Expressway-E的DNS A記錄。Expressway-E的多個DNS A記錄背後的原因可能是受影響的使用者從在Expressway-E上啟用了靜態NAT的單個NIC移動到啟用了靜態NAT的雙個NIC,反之亦然,並且忘記刪除內部DNS伺服器中適當的DNS A記錄。因此,當您在Expressway-C中使用DNS查詢實用程式並解析Expressway-E FQDN時,您會注意到兩個DNS A記錄。
解決方案
如果為Expressway-E NIC配置了靜態NAT:
ipconfig /flushdns
)。如果Expressway-E NIC配置為啟用靜態NAT的雙NIC:
ipconfig /flushdns
)。如果客戶在與Jabber客戶端相同的PC上使用Microsoft DirectAccess,則當您嘗試遠端登入時,可能會中斷MRA。DirectAccess強制將DNS查詢通過隧道傳送到內部網路,就像PC使用VPN一樣。
註:Microsoft DirectAccess不受Jabber over MRA支援。任何故障排除都是盡力而為。DirectAccess的配置由網路管理員負責。
有些客戶成功阻止了Microsoft DirectAccess名稱解析策略表中的所有DNS記錄。DirectAccess不會處理這些記錄(Jabber需要能夠通過MRA的公共DNS解析這些記錄):
從X8.8版本開始,Expressway/VCS要求為ExpE、ExpC和所有CUCM節點建立正向和反向DNS條目。
有關完整要求,請參閱移動和遠端訪問的x8.8發行說明和DNS記錄中的前提條件和軟體相關性。
如果內部DNS記錄不存在,Expressway日誌中可能會出現引用reverseDNSLookup的錯誤:
2016-07-30T13:58:11.102-06:00 hostname XCP_JABBERD[20026]: UTCTime="2016-07-30 19:58:11,102" ThreadID="139882696623872" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:409" Detail="caught exception: exception in reverseDNSLookup: reverse DNS lookup failed for address=x.x.x.x"
查詢Expressway-E IP的PTR記錄時,Expressway-C僅收到一個FQDN。如果從DNS收到錯誤的FQDN,則會在日誌中顯示此行並失敗:
2020-04-03T17:48:43.685-04:00 hostname XCP_JABBERD[10043]: UTCTime="2020-04-03 21:48:43,685" ThreadID="140028119959296" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:601" Detail="Certificate verification failed for host=xx.xx.xx.xx, additional info: Invalid Hostname"
來自Expressway-C的診斷日誌顯示 SIP/2.0 405 Method Not Allowed
消息響應Jabber客戶端傳送的註冊請求。這可能是因為連線埠5060/5061的Expressway-C和CUCM之間的目前作業階段啟始通訊協定(SIP)主幹所造成。
SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/TCP 10.10.40.108:5060;egress-zone=CollabZone;branch=z9hG4bK81e7f5f1c1
ab5450c0b406c91fcbdf181249.81ba6621f0f43eb4f9c0dc0db83fb291;proxy-call-id=da9e25aa-
80de-4523-b9bc-be31ee1328ce;rport,SIP/2.0/TLS 10.10.200.68:7001;egress-zone=Traversal
Zone;branch=z9hG4bK55fc42260aa6a2e3741919177aa84141920.a504aa862a5e99ae796914e85d35
27fe;proxy-call-id=6e43b657-d409-489c-9064-3787fc4919b8;received=10.10.200.68;rport=
7001;ingress-zone=TraversalZone,SIP/2.0/TLS
192.168.1.162:50784;branch=z9hG4bK3a04bdf3;received=172.18.105.10;rport=50784;
ingress-zone=CollaborationEdgeZone
From: <sip:5151@collabzone>;tag=cb5c78b12b4401ec236e1642-1077593a
To: <sip:5151@collabzone>;tag=981335114
Date: Mon, 19 Jan 2015 21:47:08 GMT
Call-ID: cb5c78b1-2b4401d7-26010f99-0fa7194d@192.168.1.162
Server: Cisco-CUCM10.5
CSeq: 1105 REGISTER
Warning: 399 collabzone "SIP trunk disallows REGISTER"
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
若要更正此問題,請將應用於在CUCM中配置的當前SIP中繼的SIP中繼安全配置檔案上的SIP埠和CUCM的Expressway-C鄰居區域更改為其他埠,例如5065。本影片將對此作進一步說明。以下是組態摘要:
CUCM
Expressway-C
"Unknown domain"
來自Expressway-C的診斷日誌顯示事件="Registration Rejected" Reason="Unknown domain"
Service="SIP" Src-ip="XXX.XXX.XXX" Src-port="51601" Protocol="TCP" AOR="sip:XXX.XXX.XXX.XXX"。
若要更正此問題,請檢查以下幾點:
"Idle countdown expired"
在Jabber客戶端傳送註冊消息的時間範圍內檢視Expressway-E日誌時,請查詢 Idle countdown expired
錯誤,如這裡的代碼片斷所示。
2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144"
Module="network.tcp" Level="DEBUG": Src-ip="JabberPubIP" Src-port="4211"
Dst-ip="VCS-E_IP" Dst-port="5061" Detail="TCP Connecting"
2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144"
Module="network.tcp" Level="DEBUG": Src-ip="JabberPubIP" Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Established"2015-02-02T19:46:49+01:00
collabedge tvcs: UTCTime="2015-02-02 18:46:49,606"
Module="network.tcp" Level="DEBUG": Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Closed" Reason="Idle
countdown expired"
此代碼片斷表示防火牆確實開啟了埠5061;但是,在足夠長的時間內沒有傳遞的應用層流量,因此TCP連線關閉。
如果您遇到這種情況,Expressway-E前面的防火牆很有可能會開啟SIP檢測/應用層網關(ALG)功能。若要修正此問題,您必須停用此功能。如果您不確定如何執行此操作,請參閱防火牆供應商產品文檔。
有關SIP檢測/ALG的詳細資訊,請參閱Cisco Expressway-E和Expressway-C基本配置部署指南的附錄4。
來自Expressway-E的診斷日誌在埠5061中顯示TLS協商失敗,但在埠8443中成功進行SSL握手。
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,533" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connecting"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,534" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Established"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(67)" Method="::TTSSLErrorOutput" Thread="0x7fae4ddb1700": TTSSL_continueHandshake: Failed to establish SSL connection
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Closed" Reason="Got EOF on socket"
2015-08-04T10:14:23-05:00 expe tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="No SSL error available, probably remote disconnect" Protocol="TLS" Level="1" UTCTime="2015-08-04 15:14:23,535"
Jabber日誌:
-- 2015-08-04 10:48:04.775 ERROR [ad95000] - [csf.cert.][checkIdentifiers] Verification of identity: 'URL address' failed.
-- 2015-08-04 10:48:04.777 INFO [ad95000] - [csf.cert][handlePlatformVerificationResultSynchronously] Verification result : FAILURE reason : [CN_NO_MATCH UNKNOWN]
-- 2015-08-04 10:48:05.284 WARNING [ad95000] - [csf.ecc.handyiron][ssl_state_callback] SSL alert read:fatal:handshake failure
type=eSIP, isRelevant=true, server=URL server name:5061, connectionState=eFailed, isEncrypted=true, failureReason=eTLSFailure, SSLErrorCode=336151568
type=eSIP, isRelevant=true, server=192.168.102.253:5060, connectionState=eFailed, isEncrypted=false, failureReason=eFailedToConnect, serverType=ePrimary, role=eNone
-- 2015-08-04 10:48:05.287 ERROR [ad95000] - [csf.ecc.handyiron][secSSLIsConnected] SSL_do_handshake() returned : SSL_ERROR_SSL.
來自Jabber的封包擷取顯示與Expressway E IP的SSL交涉;但傳送的憑證並非來自此伺服器:
FW已配置電話代理。
解決方案:
確認FW運行電話代理。若要檢查這一點,請輸入 show run policy-map
命令時,會顯示類似以下內容:
class sec_sip
inspect sip phone-proxy ASA-phone-proxy
禁用電話代理,以便電話服務成功連線。
以下是一些缺少和不正確的配置,這些配置可能會導致單NIC和雙NIC部署中出現此問題:
建議不要使用具有靜態NAT部署的單個NIC。以下是防止介質問題的注意事項:
issing
有關此問題的詳細資訊,請參閱Cisco Expressway-E和Expressway-C基本配置部署指南的附錄4。
此問題是由於X8.5之前的版本對Expressway的限制。思科錯誤ID CSCua72781描述了Expressway-C如何在183會話進度或180在遍歷區域中振鈴時轉發早期媒體。如果運行版本X8.1.x或X8.2.x,可以升級到版本X8.5,也可以執行此處列出的解決方法。
如果您的SIP配置檔案將183轉換為180並將其應用於傳入撥號對等體,則可以在思科統一邊界元素(CUBE)上使用解決方法。例如:
voice class sip-profiles 11
response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session Progress"
"SIP/2.0 180 Ringing"
然後,他們將在CUCM > CUBE的SIP配置檔案或CUBE本身的sip-ua配置模式下禁用180 Early Media。
disable-early-media 180
將CUCM新增到Expressway-C時,會遇到阻止新增CUCM的ASCII錯誤。
當Expressway-C將CUCM新增到其資料庫時,它會運行一系列與get和list函式相關的AXL查詢。這些示例包括getCallManager、listCallManager、listProcessNode、listProcessNodeService和getCCMVersion。運行getCallManager進程後,ExecuteSQLQuery設定將成功檢索所有CUCM Call Manager-trust或tomcat-trust。
一旦CUCM收到查詢並在查詢上執行,CUCM就會報告回其所有證書。如果其中一個證書包含非ASCII字元,則Expressway會在Web介面中生成錯誤,類似於 ascii codec can't decode byte 0xc3 in position 42487: ordinal not in range(128)
.
此問題已使用思科錯誤ID CSCuo5489跟蹤,並在X8.2版中解決。
當您在CUCM和Tomcat.pem/CallManager.pem上使用自簽名證書時,會出現此問題。此問題已透過思科錯誤ID CSCun30200解決。糾正此問題的解決方法是刪除tomcat.pem並從Expressway-C上的CUCM配置中禁用「TLS驗證」。
新增IM&P伺服器時,Expressway-C會報告「此伺服器不是IM and Presence Server」或「無法與.AXL查詢HTTP錯誤「HTTPError:500」,從而導致無法新增IM&P伺服器。
作為新增IM&P伺服器的一部分,Expressway-C使用AXL查詢在顯式目錄中查詢IM&P證書。由於思科錯誤ID CSCul05131,證書不在該儲存區中;因此您會遇到錯誤資訊。
為了使Jabber客戶端語音郵件狀態成功連線,必須在Expressway-C上的HTTP允許清單中配置Cisco Unity Connection IP地址或主機名。
要從Expressway-C完成此操作,請執行相關步驟:
X8.1和X8.2版的程式
X8.5版的過程
移動和遠端訪問解決方案僅利用UDS來解析聯絡人照片。這要求您有一台可用於儲存照片的Web伺服器。該配置本身是雙重的。
<Directory>
<DirectoryServerType>UDS</DirectoryServerType>
<PhotoUriWithToken>http://%IP/Hostname%/photo%%uid%%.jpg<
/PhotoUriWithToken>
<UdsServer>%IP%</UdsServer>
<MinimumCharacterQuery>3</MinimumCharacterQuery>
</Directory>
注意:有關UDS聯絡人照片解析的詳細資訊,請參閱Jabber聯絡人照片文檔。
此錯誤消息可能與未由客戶端裝置信任的公共CA簽名的Expressway邊緣證書,或者該域在伺服器證書中缺少作為SAN的CA有關。
要從Expressway證書接受提示中停止Jabber客戶端,必須滿足下面列出的兩個條件:
注意:如果您使用公共證書頒發機構,則很容易完成此操作,因為流動裝置包含大型證書信任儲存。
修訂 | 發佈日期 | 意見 |
---|---|---|
2.0 |
23-Feb-2023 |
重新認證 |
1.0 |
04-Feb-2015 |
初始版本 |