目錄

簡介

必要條件

採用元件

背景資訊

問題

網路圖表

詳細資料

診斷日誌中的證據

解決方案

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

移至雙NIC配置

相關資訊

簡介

本文檔介紹如何使用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/埠轉換（這將導致類似的問題）。

相關資訊

- Expressway基本配置指南的附錄4中詳細介紹了Expressway支援的網路部署

- 遵循ASA配置詳細資訊以配置支援的Expressway網路部署