MRA هاتف يفشل خدمات بسبب مصدر ip ترجمة عبر NAT انعكاس (تشكيل وحيد nic مع ساكن إستاتيكي nat يمكن)

المقدمة

يصف هذا وثيقة كيف أن يتحرى خدمات هاتف إخفاق عبر MRA بسبب مصدر IP ترجمة عبر NAT انعكاس، مع Expressway-E وحيد-NIC مع ساكن إستاتيكي nat تشكيل.

المتطلبات الأساسية

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• NAT (ترجمة عنوان الشبكة)
• SIP (بروتوكول بدء جلسة عمل)
• تكوين Cisco Video Communication Server (VCS) أو Expressway الأساسي
• الوصول أثناء التنقل والوصول عن بعد (MRA) عبر Expressway أو VCS

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

ملاحظة: من خلال المستند بالكامل، تتم الإشارة إلى أجهزة Expressway على أنها Expressway-E و Expressway-C. ومع ذلك، ينطبق التكوين نفسه على Expressway لخادم إتصالات الفيديو (VCS) وأجهزة التحكم في VCS. 

معلومات أساسية

يغطي هذا المستند شريحة تم فيها نشر الوصول عن بعد والمتحرك على Expressway باستخدام عنوان NIC واحد وعنوان NAT ثابت (موضح على أنه DMZ لجدار الحماية يحتوي على 3 منافذ باستخدام واجهة شبكة محلية (LAN) أحادية Expressway-E كما هو موضح في دليل التكوين الأساسي ل Expressway). يمكن لمستخدمي MRA تسجيل الدخول بنجاح، ولكن ليس لديهم حق الوصول إلى خدمات الهاتف.

يتم تلقي رسالة سجل SIP من العميل الخارجي بواسطة Expressway-E بنجاح على المنفذ 5061.
ثم يقوم Expressway-E بإنشاء رسالة خدمة SIP باتجاه Expressway-C. ينتج عن هذا الطلب انتهاء مهلة الطلب 408.

المشكلة

فشلت الخدمات الهاتفية لأن رسالة سجل SIP لا تنتقل إلى مدير الاتصالات الموحدة من Cisco (CUCM أو مدير المكالمات). لا يمكن لكل من Expressway-E و Expressway-C تبادل الشهادات بشكل صحيح باستخدام تبادل رسائل خدمة SIP. تحصل رسائل خدمة SIP على مهلة طلب 408 فقط كإستجابة من Expressway-C. بما أن رسالة خدمة SIP غير ناجحة، فلا يقوم Expressway-E بإعادة توجيه رسالة سجل SIP إلى Expressway-C.
وهذا يرجع إلى حقيقة أن جدار الحماية بين Expressway-C و Expressway-E يعمل على توفير ترجمة IP (والمنفذ) للرسائل من Expressway-C إلى Expressway-E. وهذا يؤدي إلى توجيه رسائل خدمة SIP هذه بشكل غير صحيح إلى هذا العنوان المترجم، بدلا من عنوانه المحلي. في سيناريو ناجح، تقوم Expressway-C بمعالجة رسالة خدمة SIP نفسها. (تستخدم رسالة خدمة SIP بين Expressway-E و Expressway-C لفحص الشهادات وبالتالي لا ترى إلا في بداية إعداد منطقة عبور، أو عند التسجيل الأول عبر MRA.)

الرسم التخطيطي للشبكة

توفر الصورة التالية مثالا لمخطط الشبكة، والذي يتم إستخدامه كمرجع في هذا المستند بالكامل:

التفاصيل

من لقطات حزمة Expressway-C، يمكنك أن ترى أن Expressway-C (10.0.30.2) يتصل بنجاح بعنوان IP العام الثابت ل Expressway-E (64.100.0.10) على المنفذ 7003. (لاحظ أن منفذ المصدر هو 27901 على Expressway-C): 

في حزم التقاط من Expressway-E، يمكنك أن ترى أن الاتصال يأتي من 64.100.0.10 على المنفذ 4401 (والذي هو عنوان NAT العام الثابت الخاص به) مع الوجهة 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 المصدر والمنفذ على هذه الرسائل.
إذا قمت بإلقاء نظرة على تدفق اتصال SIP على Expressway-E، فيمكنك ملاحظة أنه يحصل على سجل SIP من جهاز عميل MRA، ثم يقوم Expressway-E بإنشاء رسالة خدمة SIP لتبادل شهاداته مع Expressway-C، ولكن ينتج عن ذلك انتهاء مهلة الطلب لعام 408.

الدليل في سجلات التشخيص

لاحظ أن رأس المسار لرسالة خدمة SIP هذه (التي يتم إرسالها من Expressway-E إلى Expressway-C) يحتوي على IP والمنفذ الخاصين بعنوان NAT (64.100.0.10:4401).
عندما تصل هذه الرسالة إلى Expressway-C، يحاول Expressway-C توجيه الرسالة بناء على رأس المسار هذا، نحو 64.100.0.10:4401. يفشل هذا لأنه غير قادر على إجراء اتصال بهذا العنوان، حيث إن هذا العنوان موجود على جانب خادم Expressway-E. حتى إذا كان Expressway-C قادرا على الاتصال بهذا العنوان، فهذا غير صحيح لأن رسالة خدمة SIP تهدف إلى إستقبال Expressway-C ومعالجتها. 

وصول رسالة خدمة SIP إلى 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 هذه فيما يتعلق بما تظهره في رأس المسار، ولكن الاتصال يفشل: 

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 يرسل مهلة طلب 408 باتجاه Expressway-E: 

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/Port المصدر على جدار الحماية، فإن خادم Expressway-E يعرض حركة مرور Expressway-C كما هي واردة من 10.0.30.2:27901 (IP والمنفذ الفعليان على Expressway-C) بدلا من 64.100.0.10:4401 (عنوان NAT). بهذه الطريقة، يحتوي رأس المسار الموجود على رسالة خدمة SIP على قيمة 10.0.30.2:27901 وعند إستلام هذه الرسالة، يقوم Expressway-C بتوجيهها إلى نفسها وإجراء بعض المعالجة عليها مما ينتج عنه 200 موافق يتم إرسالها مرة أخرى إلى Expressway-E (في حالة حدوث كل شيء على ما يرام) والتي تقوم بعد ذلك بالتوكيل من خلال رسالة سجل SIP لمتابعة عملية التسجيل.

الانتقال إلى تكوين بطاقة واجهة شبكة (NIC) مزدوجة

مع تكوين بطاقة واجهة شبكة (NIC) مزدوجة على Expressway-E، لا يلزم إجراء انعكاس بطاقة واجهة الشبكة (NAT) ويتم تجنب المشكلة. ومع ذلك، تأكد من أن جدار الحماية الداخلي بين Expressway-E و Expressway-C (إذا كان موجودا) لا يقوم بترجمة IP/port للمصدر من حركة المرور من Expressway-C إلى Expressway-E (والتي قد ينتج عنها مشاكل مماثلة).

معلومات ذات صلة

• وترد تفاصيل عمليات نشر الشبكة المدعومة ل Expressway في الملحق 4 من دليل التكوين الأساسي ل Expressway
• اتبع تفاصيل تكوين ASA لتكوين عمليات نشر شبكة Expressway المدعومة