由於通過NAT反射進行源IP轉換（啟用靜態NAT的單個NIC配置），MRA電話服務失敗

下載選項

PDF (496.6 KB)
在多種裝置上使用 Adobe Reader 檢視
ePub (394.5 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
Mobi (Kindle) (202.0 KB)
在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視

已更新: 2017 年 10 月 20 日

文件 ID:212347

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

本文檔介紹如何使用Expressway-E單NIC和靜態NAT配置，對由NAT反射上的源IP轉換導致的MRA電話服務故障進行故障排除。

必要條件

思科建議您瞭解以下主題：

NAT（網路位址轉譯）
SIP（作業階段啟始通訊協定）
Cisco Video Communication Server(VCS)或Expressway基本配置
使用Expressway或VCS的移動和遠端訪問(MRA)

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

注意：在整篇文檔中，Expressway裝置稱為Expressway-E和Expressway-C。但是，相同的配置適用於影片通訊伺服器(VCS)Expressway和VCS控制裝置。

背景資訊

本文檔介紹一種方案，其中移動和遠端訪問已部署在使用單個NIC和靜態NAT地址的Expressway-E上（如Expressway基本配置指南中所述，描述為使用單個Expressway-E LAN介面的3埠防火牆DMZ）。MRA使用者能夠成功登入，但無法訪問電話服務。

Expressway-E在埠5061上成功接收到來自外部客戶端的SIP REGISTER消息。
然後，Expressway-E建立一條指向Expressway-C的SIP SERVICE消息。此請求導致408請求超時。

問題

由於SIP REGISTER消息未通過Cisco Unified Communications Manager（CUCM或Call Manager），電話服務失敗。 Expressway-E和Expressway-C無法使用SIP SERVICE消息交換正確交換證書。SIP SERVICE消息只能從Expressway-C獲取響應為408請求超時。由於SIP SERVICE消息未成功，Expressway-E不會將SIP REGISTER消息轉發到Expressway-C。
其原因在於，Expressway-C和Expressway-E之間的防火牆為從Expressway-C到Expressway-E的消息執行源IP（和埠）轉換。這會導致Expressway-C將這些SIP SERVICE消息錯誤地路由到該轉換的地址，而不是其自己的本地地址。在成功的情況下，Expressway-C會處理SIP SERVICE消息本身。（Expressway-E和Expressway-C之間的SIP SERVICE消息用於檢查證書，因此只能在遍歷區域設定開始時或在通過MRA進行首次註冊時看到。）

網路圖表

下圖提供網路圖範例，此圖在本文檔中用作參考：

詳細資料

在Expressway-C資料包捕獲中，可以看到Expressway-C(10.0.30.2)成功連線到埠7003上的Expressway-E靜態NAT公共IP地址(64.100.0.10)。(注意，源埠在Expressway-C上為27901):

在Expressway-E的資料包捕獲中，您可以看到連線來自埠4401（其自身的靜態NAT公共IP地址）上的64.100.0.10，目的地為10.0.10.2且埠為7003:

以下是Expressway-C和E之間的連線透視：

Expressway-C:10.0.30.2:27901 <-> 64.100.0.10:7003
Expressway-E :64.100.0.10:4401 <-> 10.0.10.2:7003

這表示Expressway-C和Expressway-E之間的防火牆正在這些消息上執行源IP和埠轉換。
如果您檢視了Expressway-E上的SIP通訊流，您可以看到它從MRA客戶端裝置獲取SIP註冊，然後Expressway-E生成一條SIP SERVICE消息以與Expressway-C交換其證書，但這會導致408請求超時。

診斷日誌中的證據

請注意，此SIP服務消息（從Expressway-E傳送到Expressway-C）的路由報頭包含NAT地址(64.100.0.10:4401)的IP和埠。
當此消息到達Expressway-C時，Expressway-C會嘗試基於該路由報頭將消息路由到64.100.0.10:4401。由於無法連線到此地址（此地址位於Expressway-E伺服器端），因此操作失敗。即使Expressway-C能夠連線到此地址，它也是不正確的，因為SIP SERVICE消息旨在供Expressway-C接收和處理。

SIP SERVICE消息到達Expressway-C:

2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,973" Module="network.sip" Level="DEBUG":  Action="Received"  Local-ip="10.0.30.2"  Local-port="27901"  Src-ip="64.100.0.10"  Src-port="7003"  Msg-Hash="123456789123456789"
 SIPMSG:
 |SERVICE sip:serviceserver@cucm02.example.local SIP/2.0
 Via: SIP/2.0/TLS 64.100.0.10:7003;egress-zone=UCTraversal;branch=[branchID];proxy-call-id=[callid];rport
 Via: SIP/2.0/TCP 127.0.0.1:5060;branch=[branchID];received=127.0.0.1;rport=25063;ingress-zone=DefaultZone
 Call-ID: abcd12345678@127.0.0.1
 CSeq: 4616 SERVICE
 Contact: <sip:serviceproxy@cucm02.example.local>
 From: <sip:serviceproxy@cucm02.example.local>;tag=0987654321aaaa
 To: <sip:serviceserver@cucm02.example.local>
 Max-Forwards: 15
 Route: <sip:64.100.0.10:4401;transport=tls;apparent;ds;lr>
 Route: <sip:127.0.0.1:22210;transport=tcp;vcs-cate;lr>
 User-Agent: TANDBERG/4132 (X8.7.2)
 Date: Tue, 19 Apr 2016 07:09:13 GMT
 Event: service
 P-Asserted-Identity: <sip:serviceproxy@cucm02.example.local>
 X-TAATag: e90b4983919b1f7a46d38f835
 Identity: "7ioJ9gpsS5ob2TUAttNxBGYRWDbnRuf5skrkxP+B14ngRvjkIWIu7BQP5W7vW1BTVyVaGuubV5u7rPDc5anDx9u46i/8TkxxYuxkr83DEh/cYPWlwO7JvTP5nub6/EtEt6RXvwizY6Gm/MXV4eMqQJ06kA86EFxP1SsRxop0YjUs61B10JnBrtQjOicskoAuMGzNjiBKvcCAbrASGtWP015vRp9khcs3e8vmkpZH5Qtef6+gNaRWPES3MS=="
 Content-Type: multipart/mixed;boundary=boundary-6j7zrmj35ifsu3efg5ga603hnz1nbf
 Content-Length: 2555
 
 --boundary-6j7zrmj35ifsu3efg5ga603hnz1nbf
 Content-Type: application/text
 
 <?xml version="1.0" encoding="utf-8"?> <methodCall><params><username>john.smith</username><realm>expe.example.com</realm><nonce>2i78worv9unccs6vbclfi4xai78worv9unccs6vbclfi4xa4i15j</nonce><qop>auth</qop><cnonce>54f80570</cnonce><nc>00000001</nc><response>2i78worv9unccs6vbclfi4xa4i15j</response><uri>sip:cucm02.example.local</uri><method>REGISTER</method><id>12345678</id><caching-enabled>true</caching-enabled><reqtype>collab-edge</reqtype></params><methodName>DigestAuth</methodName><version>1.0</version><msgid>12345678979</msgid><sipdomain>cucm02.example.local</sipdomain></methodCall>
 
 --boundary-6j7zrmj35ifsu3efg5ga603hnz1nbf
 Content-Type: application/x-x509-ca-cert
-----BEGIN CERTIFICATE-----
hknS5nQ8NJEspxLPY0N4BvA8iL7ZasOqnqgHRlj95N8bn
OfigoKhe90kV6Y7PRbRpwFv6jGiFR8hyepr3t2BPec0aZ
ZAK3ZC92RQbDjCxy2U99L8WLlTpJQwIuTjLHicbiNCNZu
Be9xEMgewwGFVfSzW08DzlecJNXpsKqQ0ivbpLbwreXJG
SCbcse3O67yvghMDsotcK4gur11FZWOZJFa3EMlgoT3Mj
ApGvMfL9caTjY1EaLWDl5rWGGe8FpRLCizrz0wwUGg7Px
Moy6kAujtolwN9BUI0sgJ98MnBuuREJZNW7g7nJL5zywT
FXhMgy9PBUMuwjgu5KruY4caWDYtNu1kZzCtnm044lOk7
xhIOoOWWj9sNFnDQGDrgBIFBjggEihSbZr6h4Pq2ZMZ4r
i5yGpz0j7a6lg2NOKm6FXpfqVlB7zvyQsM6x0XJEImpjV
al0nHYkTLkBEmK5jVosgyOrSWpZPimc364sRxRW4ABZZX
M6XstZNGhvQNDVk1JlfCN5yRtEgEkkizeWOHJcts922wL
2rVTfUfWGXMkca8YHKj2ixkthNnHVbLG0YoUNOUDHq1xu
49F7Kcw7neuQQZ4MmEif59lnyhY7qEIQVEpGn0jgqZAX8
omNVxTewa9nTXvjxo5xvTLghYfESCqniBbtWwMhhRuR7N
eh09OvFWsuUyHJmDBYpoNZWTXEB4Fw5XwfjzZAoHzOFV6
xcE4LGYrpI4EbaZ58r8uVrfXkrNrgepFw2zMgamhwf9n5
AzEU2gh9vTUNZEAn8De5XQKAipeehO8Dpef2JTBLV5avf
nh7rfxh8BZY4xteSRox8iBnT4Na6qsDMb2gvp6gTYFFJH
RGMHIe5siI1HhARqDjen4EwrKfMOYNJWTqmx4mjDrqyme
 -----END CERTIFICATE-----
 
 
  |

2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,977" Module="developer.sip.leg" Level="INFO" CodeLocation="ppcmains/sip/sipproxy/SipProxyLeg.cpp(10047)" Method="SipProxyLeg::routeViaNettleIfNeeded" Thread="0x3150905deea6":  this="0xc76759f343ca" Type="Outbound"  routingViaNettle="false"  twoInARow="false" oneIsATraversalServerZone="false" isCall="false" isRefer="false" fromClusterPeer="false" fromNettle="false" toNettle="false" inboundZone=UC_Traversal (encryption-mode=on ice-mode=off) outboundZone=DefaultZone (encryption-mode=auto ice-mode=off) encryptionSettingsRequireNettle="true" iceSettingsRequireNettle="false" needlesslyNettling="false" routeViaNettle="false"

Expressway-C嘗試傳送此SIP SERVICE消息，使其顯示在路由報頭中，但連線失敗：

2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,979" Module="network.tcp" Level="DEBUG":  Src-ip="10.0.30.2" Src-port="27921" Dst-ip="64.100.0.10" Dst-port="4401" Detail="TCP Connecting"
2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,980" Module="network.tcp" Level="ERROR":  Src-ip="10.0.30.2" Src-port="27921" Dst-ip="64.100.0.10" Dst-port="4401" Detail="TCP Connection Failed"

在Expressway-C的資料包捕獲中，TCP SYN嘗試獲得RST響應：

結果是Expressway-C向Expressway-E傳送408請求超時：

2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,982" Module="network.sip" Level="INFO":  Action="Sent"  Local-ip="10.0.30.2"  Local-port="27901"  Dst-ip="64.100.0.10"  Dst-port="7003"   Detail="Sending Response Code=408, Method=SERVICE, CSeq=4616, To=sip:serviceserver@cucm02.example.local, Call-ID=abcd12345678@127.0.0.1, From-Tag=0987654321aaaa, To-Tag=0987654321bbbb, Msg-Hash=123456789123456789"
2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,982" Module="network.sip" Level="DEBUG":  Action="Sent"  Local-ip="10.0.30.2"  Local-port="27901"  Dst-ip="64.100.0.10"  Dst-port="7003"  Msg-Hash="123456789123456789"
 SIPMSG:
 |SIP/2.0 408 Request Timeout
 Via: SIP/2.0/TLS 64.100.0.10:7003;egress-zone=UCTraversal;branch=[branchID];proxy-call-id=[callid];received=64.100.0.10;rport=7003;ingress-zone=UCTraversal;ingress-zone-id=4
 Via: SIP/2.0/TCP 127.0.0.1:5060;branch=[branchID];received=127.0.0.1;rport=25063;ingress-zone=DefaultZone
 Call-ID: abcd12345678@127.0.0.1
 CSeq: 4616 SERVICE
 From: <sip:serviceproxy@cucm02.example.local>;tag=0987654321aaaa
 To: <sip:serviceserver@cucm02.example.local>;tag=0987654321bbbb
 Server: TANDBERG/4132 (X8.7.2)
 Warning: 399 10.0.30.2:5061 "Request Timeout"
 Content-Length: 0

解決方案

有兩種可能解決此情況的方案。

在防火牆上禁用源IP埠轉換

如果在防火牆上禁用源IP/埠轉換，則Expressway-E伺服器會將Expressway-C流量視為從10.0.30.2:27901（Expressway-C上的實際IP和埠）到達，而不是64.100.0.10:4401（NAT地址）。這樣，SIP SERVICE消息上的Route報頭包含10.0.30.2:27901值，在收到此消息時，Expressway-C會將其路由到自己並對其執行一些處理，從而將200 OK傳送回Expressway-E（如果所有操作都正常），然後，Expressway-E將通過SIP REGISTER消息代理以繼續註冊過程。

移至雙NIC配置

在Expressway-E上使用雙NIC配置時，無需執行NAT反射，從而避免了問題。但是，請確保Expressway-E和Expressway-C（如果存在）之間的內部防火牆沒有執行從Expressway-C到Expressway-E的流量的源IP/埠轉換（這將導致類似的問題）。