تكوين هواتف VPN واستكشاف أخطائها وإصلاحها

المقدمة

يصف هذا المستند كيفية تكوين ميزة هاتف VPN الخاصة بهواتف Cisco IP ومدير الاتصالات الموحدة من Cisco واستكشاف أخطائها وإصلاحها.

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

المتطلبات

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

• برنامج Cisco Unified Communications Manager (CUCM)
• أجهزة الأمان المعدلة Cisco Adaptive Security Appliances (ASA)
• شبكة AnyConnect الخاصة الظاهرية (VPN)
• هواتف بروتوكول الإنترنت (IP) من Cisco

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

• 8861 14-0-1-0101-145
• ASAv 9.12(2)9
• CUCM 11.5.1.21900-40

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

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

تتضمن بيئة الاختبار في هذه المقالة 8861، ASAv، و CUCM 11.5.1، ولكن هناك العديد من التباينات المختلفة لهذه المنتجات التي يمكنك إستخدامها.  يجب عليك التحقق من قائمة ميزات الهاتف الموجودة على CUCM للتأكد من أن طراز هاتفك يدعم ميزة VPN.  لاستخدام قائمة ميزات الهاتف، يمكنك الوصول إلى ناشر CUCM في المستعرض لديك والانتقال إلى Cisco Unified Reporting > قائمة ميزات هاتف مدير المحتوى الموحد (CM).  قم بإنشاء تقرير جديد ثم حدد طراز هاتفك في القائمة المنسدلة.  بعد ذلك، يلزمك البحث في قسم ميزات القائمة لعميل الشبكة الخاصة الظاهرية كما هو موضح في الصورة:

التكوين

تتطلب هواتف VPN أن يكون لديك التكوين المناسب على ASA و CUCM.  يمكنك البدء بأي من المنتج أولا، ولكن هذا المستند يغطي تكوين ASA أولا.

تكوين ASA

الخطوة 1. تحقق من ترخيص ASA لدعم AnyConnect لهواتف VPN.  يمكن إستخدام الأمر show version على ASA للتحقق من تمكين AnyConnect لهاتف Cisco VPN كما هو موضح في هذا الجزء البسيط:

[output omitted]
Licensed features for this platform:
Maximum VLANs : 50
Inside Hosts : Unlimited
Failover : Active/Standby
Encryption-DES : Enabled
Encryption-3DES-AES : Enabled
Security Contexts : 0
Carrier : Enabled
AnyConnect Premium Peers : 250
AnyConnect Essentials : Disabled
Other VPN Peers : 250
Total VPN Peers : 250
AnyConnect for Mobile : Enabled
AnyConnect for Cisco VPN Phone : Enabled
Advanced Endpoint Assessment : Enabled
Shared License : Disabled
Total TLS Proxy Sessions : 500
Botnet Traffic Filter : Enabled
Cluster : Disabled

في حالة عدم تمكين هذه الميزة، يلزمك العمل مع فريق الترخيص للحصول على الترخيص المناسب.  الآن بعد أن أكدت أن ASA يدعم هواتف VPN، يمكنك بدء التكوين.

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

الخطوة 2. خلقت عنوان بركة ل VPN زبون.  هذا مماثل إلى DHCP بركة في أن عندما ip هاتف إلى ال ASA هو يستلم عنوان من هذا بركة.  البركة يستطيع كنت خلقت مع هذا أمر على ال ASA:

ip محلي بركة vpn-phone-pool 10.10.1.1-10.10.1.254 قناع 255.255.255.0

أيضا، إذا كنت تفضل قناعا مختلفا للشبكة أو الشبكة الفرعية، فيمكن تغيير ذلك أيضا.  بمجرد إنشاء التجمع، تحتاج إلى تكوين نهج مجموعة (مجموعة من المعلمات للاتصال بين هواتف ASA و IP):

نهج المجموعة vpn-phone-policy الداخلي

سمات سياسة هاتف vpn -المجموعة

     نفق-سياسة أنفاق

     vpn-tunnel-protocol ssl-client

الخطوة 3. أنت تحتاج أن يمكن AnyConnect إن لم يكن قد تم تمكينه بالفعل.  للقيام بذلك، يلزمك معرفة اسم الواجهة الخارجية.  بشكل نموذجي، يتم تسمية هذه الواجهة خارج (كما هو موضح في التعليمة البرمجية الصغيرة)، ولكنها قابلة للتكوين، لذلك تأكد من حصولك على الواجهة الصحيحة.  قم بتشغيل show ip للاطلاع على قائمة الواجهات:

sckiewer-ASAv# show ip
System IP Addresses:
Interface Name IP address Subnet mask Method
GigabitEthernet0/0 outside 172.16.1.250 255.255.255.0 CONFIG
GigabitEthernet0/1 inside 172.16.100.250 255.255.255.0 CONFIG
Current IP Addresses:
Interface Name IP address Subnet mask Method
GigabitEthernet0/0 outside 172.16.1.250 255.255.255.0 CONFIG
GigabitEthernet0/1 inside 172.16.100.250 255.255.255.0 CONFIG

في هذه البيئة، يتم تسمية الواجهة الخارجية خارج، لذلك تقوم هذه الأوامر بتمكين AnyConnect على هذه الواجهة.

WebPN
     تمكين خارج
     تمكين AnyConnect

الخطوة 4. قم بتكوين مجموعة نفق جديدة لتطبيق نهج المجموعة الذي تم إنشاؤه مسبقا على أي عملاء يتصلون على عنوان URL محدد.  لاحظ المرجع إلى أسماء تجمع عناوين IP ونهج المجموعة الذي قمت بإنشائه مسبقا في الأسطر الثالث والرابع من القصاصة.  إذا قمت بتعديل أسماء تجمع عناوين IP أو نهج المجموعة، فيلزمك إستخدام إستبدال القيم غير الصحيحة بالأسماء المعدلة:

الوصول عن بعد إلى مجموعة vpn-phone-group للنفق-group
السمات العامة ل Tunnel-Group vpn-phone-group
     address-pool vpn-phone-pool
     default-group-policy vpn-phone-policy
سمات WebVPN-مجموعة النفق
     شهادة المصادقة
     تمكين عنوان url للمجموعة https://asav.sckiewer.lab/phone

يمكنك إستخدام عنوان IP بدلا من اسم ل group-url.  وعادة ما يتم القيام بذلك إذا لم يكن للهواتف حق الوصول إلى خادم DNS الذي يمكن حل اسم المجال المؤهل بالكامل (FQDN) من ASA.  أيضا، يمكنك أن ترى أن هذا المثال يستخدم المصادقة المستندة إلى شهادة.  أنت تتلقى الخيار أن يستعمل username/كلمة صحة هوية أيضا، غير أن هناك كثير متطلب على ال ASA أن يكون خارج النطاق من هذا وثيقة.

في هذا المثال، يحتوي خادم DNS على السجل A، asav.sckiewer.lab - 172.16.1.250 ويمكنك أن ترى من إخراج show ip أنه تم تكوين 172.16.1.250 على الواجهة المسماة خارج.  إذا التكوين سيكون:

crypto ca trustPoint asa-identity-cert

     نفس التسجيل

     subject-name cn=asav.sckiewer.lab

سجل ASA-IDENTITY ل crypto ca

SSL Trust-Point asa-identity-cert خارج

بعض الأشياء التي يجب ملاحظتها:

1. وتم إنشاء نقطة ثقة جديدة تسمى ASA-IDENTITY-CERT وتم تطبيق اسم الموضوع عليها.  يؤدي ذلك إلى إستخدام الشهادة التي تم إنشاؤها من TrustPoint هذه لاسم الموضوع المحدد
2. بعد ذلك، يسمح الأمر crypto ca login asa-identity-cert' ل ASA بإنشاء شهادة موقعة ذاتيا وحفظها إلى أن trustPoint
3. وأخيرا، يقوم ASA بتقديم الشهادة في TrustPoint إلى أي جهاز يتصل بالواجهة الخارجية

الخطوة 5. قم بإنشاء نقاط الثقة اللازمة للسماح ل ASA بالثقة في شهادة هاتف IP.  أولا، تحتاج إلى تحديد ما إذا كانت هواتف بروتوكول الإنترنت الخاصة بك تستخدم الشهادة المثبتة (MIC) من الجهة المصنعة أو الشهادة المحلية المهمة (LSC).  بشكل افتراضي، تستخدم جميع الهواتف ميكروفوناتها لتأمين الاتصالات ما لم يتم تثبيت LSC عليها.  في CUCM 11.5.1 والإصدارات الأحدث، يمكنك تشغيل بحث موجود في إدارة CM الموحدة > الجهاز > الهاتف لمعرفة ما إذا تم تثبيت قوائم التحكم في الوصول إلى شبكة LSCs بينما تتطلب الإصدارات الأقدم من CUCM التحقق الفعلي من إعدادات الأمان على كل هاتف.  في CUCM 11.5.1، لاحظ أنك تحتاج إلى إضافة عامل تصفية (أو تغيير عامل التصفية الافتراضي) إلى LSC الذي تم إصداره بواسطة.  تستخدم الأجهزة ذات NA في LSC التي تم إصدارها بواسطة العمود بطاقة MIC نظرا لأنها لا تحتوي على LSC مثبت.

إذا كان هاتفك يبدو كالهاتف الذي تم إبرازه في الصورة، فأنت بحاجة إلى تحميل شهادة CAPF الخاصة بناشر CUCM إلى ASA للتحقق من صحة شهادة الهاتف للاتصال الآمن.  إذا كنت ترغب في إستخدام أجهزة بدون LSC مثبت، فأنت بحاجة إلى تحميل شهادات التصنيع من Cisco إلى ASA.  يمكن العثور على هذه الشهادات على ناشر CUCM في إدارة OS الموحدة من Cisco > الأمان > إدارة الشهادات:

ملاحظة: يمكنك أن ترى بعض هذه الشهادات في مخازن ثقة متعددة (CallManager-trust و CAPF-trust).  لا يهم أي مخزن ثقة تقوم بتنزيل الشهادات منه طالما أنك تضمن أنك قمت بتحديد تلك التي لها تلك الأسماء المحددة.

• جذر Cisco_ROOT_CA_2048 < MIC SHA-1
• Cisco_MANUFACTURING_CA < MIC SHA-1 Intermediate
• cisco_root_ca_m2 < MIC SHA-256 root
• Cisco_MANUFACTURING_CA_SHA2 < MIC SHA-256 Intermediate
• CAPF من ناشر CUCM < LSC

وفيما يتعلق بميكروفون، تستخدم طرز الهواتف الأقدم مثل السلسلتين 79xx و 99xx سلسلة الشهادات SHA-1، بينما تستخدم طرز الهواتف الأحدث مثل سلسلة 88xx سلسلة الشهادات SHA-256.  يجب تحميل سلسلة الشهادات التي يستخدمها الهاتف (الهواتف) إلى ASA.

بمجرد أن يكون لديك الشهادات المطلوبة، يمكنك إنشاء TrustPoint (نقاط) مع:

crypto ca trustPoint cert1

     الوحدة الطرفية للتسجيل

شهادة مصادقة CA1

يقوم الأمر الأول بإنشاء TrustPoint باسم cert1، ويسمح الأمر crypto ca authenticate لك بلصق الشهادة المشفرة base64 في CLI.  يمكنك تشغيل هذه الأوامر بعدد المرات التي تحتاج إليها للحصول على نقاط الثقة المناسبة على ASA، ولكن تأكد من إستخدام اسم TrustPoint جديد لكل شهادة.

الخطوة 6. الحصول على نسخة من شهادة هوية ASA بإصدار هذا الأمر:

شهادة هوية مصدر التشفير ASA-IDENTITY-CERT

يقوم هذا بتصدير شهادة الهوية ل the trustPoint المسماة asa-identity-cert.  تأكد من ضبط الاسم بحيث يطابق نقطة الثقة التي قمت بإنشائها في الخطوة 4.

وفيما يلي تكوين المختبر الكامل ل ASA:

ip local pool vpn-phone-pool 10.10.1.1-10.10.1.254 mask 255.255.255.0

group-policy vpn-phone-policy internal
group-policy vpn-phone-policy attributes
     split-tunnel-policy tunnelall
     vpn-tunnel-protocol ssl-client

webvpn
     enable outside
     anyconnect enable

tunnel-group vpn-phone-group type remote-access
tunnel-group vpn-phone-group general-attributes
     address-pool vpn-phone-pool
     default-group-policy vpn-phone-policy

tunnel-group vpn-phone-group webvpn-attributes
     authentication certificate
     group-url https://asav.sckiewer.lab/phone enable

ssl trust-point asa-identity-cert outside

عند هذه النقطة، اكتمل تكوين ASA، ويمكنك المتابعة بتكوين CUCM.  يجب أن يكون لديك نسخة من شهادة ASA التي قمت بجمعها للتو وعنوان URL الذي تم تكوينه في قسم مجموعة النفق.

تكوين CUCM

الخطوة 1. على CUCM، انتقل إلى إدارة نظام التشغيل الموحدة من Cisco > الأمان > إدارة الشهادات وقم بتحميل شهادة ASA كثقة الهاتف-vpn. 

الخطوة 2. ما إن يتم هذا، انتقل إلى cisco إدارة Unified CM > سمة متقدم > VPN > ملف تعريف VPN وأنشئ توصيف جديد.  لا يوجد صواب أو خطأ في هذا القسم، من المهم فقط فهم الغرض من كل إعداد.

1. تمكين الكشف التلقائي عن الشبكة - عند تمكين ذلك، يقوم الهاتف بإختبار اتصال خادم TFTP الخاص به عند تشغيله.  إن يستلم هو إستجابة إلى هذا عملية أزيز، هو لا يمكن VPN.  إذا لم يستلم الهاتف إستجابة إلى إختبار الاتصال هذا، فإنه يمكن VPN.  عند تمكين هذا الإعداد، لا يمكن تمكين VPN يدويا.
2. التحقق من معرف المضيف - عند تمكين ذلك، يفحص الهاتف عنوان URL لشبكة VPN من ملف التكوين الخاص به (https://asav.sckiewer.lab/phone يتم إستخدامه في هذا المستند)، ويضمن تطابق اسم المضيف أو FQDN مع الاسم الشائع (CN) أو إدخال شبكة منطقة التخزين (SAN) في الشهادة المقدمة من قبل ASA.
3. يستخدم أسلوب المصادقة - لتحديد نوع أسلوب المصادقة المستخدم للاتصال ب ASA.  في مثال التكوين من هذا المستند، يتم إستخدام المصادقة المستندة إلى الشهادة.
4. إستمرارية كلمة المرور - إذا تم تمكين ذلك، يتم تخزين كلمة مرور العميل في الهاتف حتى حدوث محاولة فشل لتسجيل الدخول، أو يقوم العميل بمسح كلمة المرور يدويا، أو يقوم بإعادة ضبط الهاتف.

الخطوة 3. بعد ذلك، انتقل إلى إدارة Cisco Unified CM > ميزات متقدمة > VPN > بوابة VPN.  تحتاج إلى التأكد من تطابق عنوان URL لبوابة VPN مع تكوين ASA، وأنك تقوم بنقل الشهادة من المربع العلوي إلى المربع السفلي كما هو موضح في الصورة:

الخطوة 4. بمجرد حفظ هذا، تحتاج إلى التنقل إلى Cisco Unified CM Administration (إدارة CM) > ميزات متقدمة > VPN > مجموعة VPN ونقل البوابة التي أنشأتها إلى المربع "بوابات VPN المحددة في مجموعة VPN هذه":

الخطوة 5. الآن أن ال VPN شكلت عملية إعداد يتلقى يكون، أنت تحتاج أن يذهب إلى cisco إدارة CM الموحدة>أداة>أداة عملية إعداد>مشترك هاتف.  هنا، أنت ينبغي نسخت التوصيف أن ك يريد VPN هاتف، عينت هو، واخترت ك VPN مجموعة و VPN ملف تخصيص بعد ذلك احفظ التشكيل جديد التوصيف:

الخطوة 6. أخيرا، يلزمك تطبيق هذا التوصيف الجديد على هاتفك، ثم إعادة ضبط الهاتف وهو على الشبكة الداخلية.  وهذا يسمح للهاتف باستلام كل هذا التكوين الجديد مثل تجزئة شهادة ASA، وعنوان URL لشبكة VPN.

ملاحظة: قبل إختبار الهاتف، يجب التأكد من أن الهواتف مكونة من خادم "بديل TFTP".  بما أن ASA لا يقدم خيار 150 إلى الهواتف، يحتاج TFTP IP إلى أن يكون شكلت على الهواتف يدويا.

الخطوة 7. اختبر هاتف الشبكة الخاصة الظاهرية (VPN) وتحقق من إمكانية إتصاله ب ASA والتسجيل بنجاح.  أنت يستطيع دققت أن النفق فوق ال ASA مع، عرض vpn-sessiondb anyConnect:

استكشاف الأخطاء وإصلاحها

البيانات المطلوب تجميعها

لاستكشاف أخطاء هاتف VPN وإصلاحها، يوصى بهذه البيانات:

• تصحيح أخطاء ASA:

  • تصحيح الأخطاء المخزن مؤقتا للتسجيل

  • تتبع أخطاء التسجيل

  • debug crypto ca transactions 255
  • debug crypto ca messages 255
  • debug crypto ca 255
  • debug webVPN 255
  • debug webVPN AnyConnect 255
• سجلات وحدة التحكم في الهاتف (أو فريق إعادة إعمار إذا كان الهاتف يدعمه - مزيد من المعلومات هنا)

ما إن يستنسخ أنت الإصدار مع ال debugs يمكن، أنت يستطيع شاهدت الإنتاج مع هذا أمر بما أن يضبط إنتاج يحتوي دائما 711001:

إظهار السجل | i 711001

المشكلات الشائعة

ملاحظة: لأغراض هذا القسم، تستخدم قصاصات السجل في هاتف 8861 لأن هذا الهاتف هو أحد أكثر سلاسل الهاتف شيوعا التي يتم نشرها كهاتف VPN.  تذكر أنه يمكن للطرز الأخرى كتابة رسائل مختلفة في السجلات.

تحديث شهادة الهوية الموقعة ذاتيا ل ASA

قبل انتهاء صلاحية شهادة هوية ASA، يلزم إنشاء شهادة جديدة ودفعها إلى الهواتف.  للقيام بذلك دون تأثير على هواتف شبكة VPN، أستخدم هذه العملية:

الخطوة 1. إنشاء نقطة ثقة جديدة لشهادة الهوية الجديدة:

crypto ca trustPoint asa-identity-cert-2

     نفس التسجيل

     subject-name cn=asav.sckiewer.lab

crypto ca login asa-identity-cert-2

الخطوة 2. عند هذه النقطة، سيكون لديك شهادة هوية جديدة ل ASA، ولكنها لا تستخدم على أي واجهة حتى الآن.  يجب تصدير هذه الشهادة الجديدة وتحميلها إلى CUCM:

crypto ca export asa-identity-cert-2 identity-certificate

الخطوة 3. بمجرد حصولك على شهادة الهوية الجديدة، قم بتحميلها إلى إحدى عقد CUCM لديك كثقة هاتف-VPN في إدارة نظام التشغيل الموحدة من Cisco > الأمان > إدارة الشهادات > تحميل.

ملاحظة: لن تكون شهادة ثقة الهاتف VPN موجودة إلا على عقدة CUCM التي تم تحميلها إليها في الأصل (لا يتم نشرها تلقائيا إلى عقد أخرى مثل بعض الشهادات).  إذا تأثر إصدار CUCM الخاص بك ب CSCuo58506، فيجب عليك تحميل شهادة ASA الجديدة إلى عقدة مختلفة.

الخطوة 4. بمجرد تحميل الشهادة الجديدة إلى أي من العقد في المجموعة، انتقل إلى إدارة CM الموحدة من Cisco > الميزات المتقدمة > VPN > بوابة VPN على ناشر CUCM

الخطوة 5. حدد البوابة المناسبة.

الخطوة 6. حدد الشهادة في المربع العلوي (هذه هي الشهادة التي قمت بتحميلها للتو) وحدد السهم لأسفل لنقلها إلى الأسفل (وهذا يسمح ل TFTP بإضافة هذه الشهادة إلى ملفات تكوين هاتف VPN الخاص بك) وحدد حفظ.

الخطوة 7. وبمجرد القيام بذلك، قم بإعادة ضبط جميع هواتف شبكة VPN.  في هذه المرحلة من العملية، لا يزال ASA يقدم الشهادة القديمة، حتى يمكن للهواتف التوصيل، ومع ذلك، فإنها تحصل على ملف تكوين جديد يحتوي على كل من الشهادة الجديدة والشهادة القديمة.

الخطوة 8. الآن يمكنك تطبيق الشهادة الجديدة على ASA.  للقيام بذلك، تحتاج إلى اسم TrustPoint الجديد واسم الواجهة الخارجية، ثم قم بتشغيل هذا الأمر باستخدام هذه المعلومات:

SSL Trust-Point asa-identity-cert-2 خارج

ملاحظة: يمكنك الانتقال إلى عنوان URL الخاص بشبكة WebVPN في المستعرض الخاص بك للتحقق من أن ASA يقدم الشهادة الجديدة.  ونظرا لأنه يجب أن يكون هذا العنوان قابلا للوصول إليه بشكل عام بالنسبة للهواتف الخارجية، يمكن لجهاز الكمبيوتر الوصول إليه كذلك.  يمكنك بعد ذلك التحقق من الشهادة التي يقدمها ASA للمستعرض لديك والتأكد من أنها الشهادة الجديدة. 

الخطوة 9. بمجرد تكوين ASA لاستخدام الشهادة الجديدة، قم بإعادة ضبط هاتف إختبار وتحقق من قدرته على الاتصال ب ASA والتسجيل.  إذا تم تسجيل الهاتف بنجاح، يمكنك بعد ذلك إعادة ضبط جميع الهواتف والتحقق من أنها قادرة على الاتصال ب ASA والتسجيل.  هذه هي العملية الموصى بها لأن الهواتف المتصلة ب ASA تظل متصلة بعد تغيير الشهادة.  إذا قمت باختبار تحديث الشهادة على هاتف واحد أولا، فإنك تقلل من مخاطر حدوث مشكلة في التكوين التي تؤثر على عدد كبير من الهواتف.  إن أول VPN هاتف يعجز أن يربط إلى ال ASA، بعد ذلك أنت يستطيع جمعت سجل من الهاتف و/أو ASA أن يتحرى بينما الآخر هاتف بقيت يربط.

الخطوة 10. بمجرد التحقق من أن الهواتف قادرة على الاتصال والتسجيل باستخدام الشهادة الجديدة، يمكن إزالة الشهادة القديمة من CUCM.

يحدد ASA شفرة المنحنى البيضاوي (EC)

تدعم ASAs تشفير المنحنى الاهليلجي (EC) اعتبارا من 9.4(x)، لذلك من الشائع رؤية هواتف VPN التي كانت تعمل سابقا تفشل بعد ترقية ASA إلى 9.4(x) أو أعلى.  يحدث هذا لأن ASA يحدد الآن تشفير EC أثناء مصافحة TLS مع طرز الهاتف الأحدث.  بشكل نموذجي، هناك شهادة RSA مرتبطة بالواجهة التي يتصل الهاتف بها نظرا لأن إصدار ASA السابق لم يدعم EC.  عند هذه النقطة، نظرا لأن ASA قام بتحديد تشفير EC، فلا يمكنه إستخدام شهادة RSA للاتصال، لذلك يقوم بإنشاء وإرسال الهاتف شهادة مؤقتة موقعة ذاتيا يقوم بإنشائها باستخدام خوارزمية EC بدلا من RSA.  ونظرا لعدم التعرف على هذه الشهادة المؤقتة بواسطة الهاتف، يفشل الاتصال.  يمكنك التحقق من ذلك في سجلات هواتف 88xx مباشرة جدا.

2101 NOT Mar 30 12:23:21.331861 (393:393) VPNC: -protocol_handler: current cipher -> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA
2102 NOT Mar 30 12:23:21.331871 (393:393) VPNC: -protocol_handler: new cipher -> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA

تظهر سجلات الهاتف أن ASA قام بتحديد تشفير EC لهذا الاتصال بما أن سطر "التشفير الجديد" يحتوي على شفرات EC التي تتسبب في فشل الاتصال.

في سيناريو تم فيه تحديد AES، سترى ما يلي:

2691 NOT Mar 30 12:18:19.016923 (907:907) VPNC: -protocol_handler: current cipher -> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA
2690 NOT Mar 30 12:18:19.016943 (907:907) VPNC: -protocol_handler: new cipher -> AES256-SHA:AES128-SHA

يمكن العثور على مزيد من المعلومات حول هذا الأمر هنا، CSCuu02848.

يتمثل الإصلاح الخاص بهذا في تعطيل شفرة EC على ASA لإصدار TLS الذي يستخدمه هاتفك.  يمكن العثور على مزيد من المعلومات حول إصدار TLS الذي يدعمه كل طراز هاتف هنا:

https://www.cisco.com/c/dam/en/us/products/collateral/collaboration-endpoints/unified-ip-phone-8800-series/white-paper-c11-739097.pdf

بمجرد معرفة إصدارات TLS ذات الصلة في بيئتك، يمكنك تشغيل هذه الأوامر على ASA لتعطيل شفرات EC لتلك الإصدارات:

ssl cipher tlsv1 custom "AES256-SHA:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES128-GCM-SHA256:AES128-SHA256:AES256-SHA" 
ssl cipher tlsv1.1 custom "AES256-SHA:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES128-GCM-SHA256:AES128-SHA256:AES256-SHA"
ssl cipher tlsv1.2 custom "AES256-SHA:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES128-GCM-SHA256:AES128-SHA256:AES256-SHA"
ssl cipher dtlsv1 custom "AES256-SHA:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES128-GCM-SHA256:AES128-SHA256:AES256-SHA"

تذكر أن هواتف IP تستخدم DTLS (تأمين طبقة نقل البيانات) بشكل افتراضي، لذلك تحتاج إلى تشغيل بيان التشفير ل DTLS وإصدار TLS ذي الصلة لهواتفك.  كما أنه من المهم فهم أن هذه التغييرات هي تغييرات عالمية على ASA، وبالتالي فإنها تمنع التفاوض حول شفرات EC بواسطة أي عميل AnyConnect آخر يستخدم إصدارات TLS هذه.

فشل اتصال DTLS

في بعض الحالات، لا يمكن لهواتف شبكات VPN إنشاء اتصال ب ASA مع DTLS.  إذا حاول الهاتف إستخدام DTLS ولكنه فشل، يستمر الهاتف في محاولة DTLS مرارا وتكرارا، بشكل غير ناجح، لأنه يعرف أن DTLS ممكنة، سترى ذلك في سجلات الهاتف 88xx:

3249 ERR Mar 29 15:22:38.949354 (385:385) VPNC: -dtls_state_cb: DTLSv0.9: write: alert: fatal:illegal parameter
3250 NOT Mar 29 15:22:38.951428 (385:385) VPNC: -vpnc_set_notify_netsd : cmd: 0x5 event: 0x40000 status: 0x0 error: 0x0 
3251 ERR Mar 29 15:22:38.951462 (385:385) VPNC: -alert_err: DTLS write alert: code 47, illegal parameter
3252 ERR Mar 29 15:22:38.951489 (385:385) VPNC: -create_dtls_connection: SSL_connect ret -1, error 1
3253 ERR Mar 29 15:22:38.951506 (385:385) VPNC: -DTLS: SSL_connect: SSL_ERROR_SSL (error 1)
3254 ERR Mar 29 15:22:38.951552 (385:385) VPNC: -DTLS: SSL_connect: error:140920C5:SSL routines:ssl3_get_server_hello:old session cipher not returned
3255 ERR Mar 29 15:22:38.951570 (385:385) VPNC: -create_dtls_connection: DTLS setup failure, cleanup
3256 WRN Mar 29 15:22:38.951591 (385:385) VPNC: -dtls_state_cb: DTLSv0.9: write: alert: warning:close notify
3257 ERR Mar 29 15:22:38.951661 (385:385) VPNC: -do_dtls_connect: create_dtls_connection failed
3258 ERR Mar 29 15:22:38.951722 (385:385) VPNC: -protocol_handler: connect: do_dtls_connect failed
3259 WRN Mar 29 15:22:38.951739 (385:385) VPNC: -protocol_handler: connect : err: SSL success DTLS fail

قد يحدث هذا بسبب نفس المشكلة المذكورة في قسم تشفير المنحنى البيضاوي (EC) الخاص بتحديد ASA، لذلك يجب التأكد من تعطيل شفرة EC ل DTLS.  بالإضافة إلى ذلك، يمكنك تعطيل DTLS بالكامل مما يفرض على هواتف VPN إستخدام TLS بدلا من ذلك.  لن يكون هذا مثاليا لأنه سيعني أن جميع حركة المرور ستستخدم بروتوكول TCP بدلا من بروتوكول UDP الذي يضيف بعض التكاليف.  ومع ذلك، في بعض السيناريوهات، يعد هذا إختبارا جيدا لأنه على الأقل يؤكد أن معظم التكوين جيد، وأن المشكلة خاصة ب DTLS.  إذا كنت ترغب في إختبار هذا، فمن الأفضل أن يتم ذلك على مستوى نهج المجموعة لأن المسؤولين يستخدمون عادة نهج مجموعة فريد لهواتف VPN، مما يتيح لنا إختبار التغيير دون التأثير على العملاء الآخرين.

سمات سياسة هاتف vpn -المجموعة
     WebPN
     AnyConnect ssl dtls none

هناك مشكلة تكوين أخرى شائعة يمكن أن تمنع اتصال DTLS ناجح وهي إذا لم يتمكن الهاتف من إنشاء اتصال TLS و DTLS بنفس التشفير.  مثال مقتطف سجل:

%%%%% TLS Ciphers Offered
3905 NOT Apr 01 20:14:22.741838 (362:362) VPNC: -protocol_handler: new cipher -> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA

%%%%% DTLS Ciphers Offered
4455 NOT Apr 01 20:14:23.405417 (362:362) VPNC: -process_connect: x-dtls-ciphersuite: AES128-SHA
4487 NOT Apr 01 20:14:23.523994 (362:362) VPNC: -create_dtls_connection: cipher list: AES128-SHA

%%%%% DTLS connection failure
4496 WRN Apr 01 20:14:53.547046 (362:474) VPNC: -vpnc_control: conn timer expired at:1585772093, to abort connect 
4497 NOT Apr 01 20:14:53.547104 (362:474) VPNC: -abort_connect: in dtls setup phase

يمكنك أن ترى شفرات TLS المقدمة في السطر الأول من القصاصة.  يتم تحديد الخيار الأكثر أمانا الذي يدعمه كلا الجانبين (لا تظهر السجلات التحديد، ومع ذلك، يمكنك إستنتاج أنه AES-256 على الأقل من قصاصة السجل).  يمكنك أيضا أن ترى أن تشفير DTLS الوحيد المقدم هو AES128.  بما أن تشفير TLS المحدد غير متاح ل DTLS، يفشل التوصيل.  يكون الإصلاح في هذا السيناريو هو التأكد من أن تكوين ASA يسمح باستخدام نفس التشفير ل TLS و DTLS.

الهاتف غير قادر على الاتصال ب ASA بعد تحديث الشهادة

من المهم جدا تحميل شهادة هوية ASA جديدة كثقة هاتف vpn على CUCM حتى تتمكن الهواتف من الحصول على التجزئة لهذه الشهادة الجديدة.  إذا لم يتم اتباع هذه العملية، بعد التحديث والمرة التالية التي يحاول فيها هاتف شبكة VPN الاتصال ب ASA، يتم تقديم الهاتف مع شهادة لا تثق بها، وبالتالي يفشل الاتصال.  قد يحدث هذا أحيانا بعد أيام أو أسابيع من تحديث شهادة ASA لأن الهواتف لا تنفصل عندما تتغير الشهادة.  ما دام ال ASA يواصل إستلام keepalives من الهاتف، ال VPN نفق يبقى فوق.  لذلك، إذا كنت قد أكدت أن شهادة ASA قد تم تحديثها، ولكن لم يتم وضع الشهادة الجديدة على CUCM أولا، فلديك خياران:

1. إذا كانت شهادة هوية ASA القديمة لا تزال صالحة، فارجع ASA مرة أخرى إلى الشهادة القديمة ثم اتبع العملية الواردة في هذا المستند لتحديث الشهادة.  يمكنك تخطي قسم إنشاء الشهادة إذا كنت قد قمت بالفعل بإنشاء شهادة جديدة.
2. إذا انتهت صلاحية شهادة هوية ASA القديمة، ستحتاج إلى تحميل شهادة ASA الجديدة إلى CUCM وإعادة الهواتف إلى الشبكة الداخلية لتلقي ملف التكوين المحدث مع تجزئة الشهادة الجديدة.

الهاتف غير قادر على حل ASA URL عبر DNS

في بعض السيناريوهات، يقوم المسؤول بتكوين عنوان URL لشبكة VPN باستخدام اسم المضيف بدلا من عنوان IP.  عند القيام بذلك، يجب أن يكون للهاتف خادم DNS حتى يتمكن من حل الاسم على عنوان IP.  في القصاصة، يمكنك أن ترى أن الهاتف يحاول حل الاسم بخادمي DNS، 192.168.1.1 و 192.168.1.2، ولكنه لا يتلقى إستجابة.  بعد 30 ثانية، يطبع الهاتف 'DnsLookupErr:'

3816 NOT Mar 3 15:38:03.819168 VPNC: -do_login: URL -> https://asav.sckiewer.lab/phone
...
3828 INF Mar 3 15:38:03.834915 dnsmasq[322]: query[A] asav.sckiewer.lab from 127.0.0.1
3829 INF Mar 3 15:38:03.835004 dnsmasq[322]: forwarded asav.sckiewer.lab to 192.168.1.1
3830 INF Mar 3 15:38:03.835030 dnsmasq[322]: forwarded asav.sckiewer.lab to 192.168.1.1
3831 INF Mar 3 15:38:17.845305 dnsmasq[322]: query[A] asav.sckiewer.lab from 127.0.0.1
3832 INF Mar 3 15:38:17.845352 dnsmasq[322]: forwarded asav.sckiewer.lab to 192.168.1.1
3833 INF Mar 3 15:38:17.845373 dnsmasq[322]: forwarded asav.sckiewer.lab to 192.168.1.2
3834 INF Mar 3 15:38:31.854834 dnsmasq[322]: query[A] asav.sckiewer.lab from 127.0.0.1
3835 INF Mar 3 15:38:31.854893 dnsmasq[322]: forwarded asav.sckiewer.lab to 192.168.1.1
3836 INF Mar 3 15:38:31.855213 dnsmasq[322]: forwarded asav.sckiewer.lab to 192.168.1.2
3837 ERR Mar 3 15:38:32.864376 VPNC: -parse_url: gethostbyname failed <asav.sckiewer.lab>
3838 NOT Mar 3 15:38:32.864435 VPNC: -vpnc_set_notify_netsd : cmd: 0x5 event: 0x40000 status: 0x0 error: 0x0 
3839 ERR Mar 3 15:38:32.864464 VPNC: -do_login: parse URL failed -> https://asav.sckiewer.lab/phone
3840 NOT Mar 3 15:38:32.864482 VPNC: -vpn_stop: de-activating vpn
3841 NOT Mar 3 15:38:32.864496 VPNC: -vpn_set_auto: auto -> auto
3842 NOT Mar 3 15:38:32.864509 VPNC: -vpn_set_active: activated -> de-activated
3843 NOT Mar 3 15:38:32.864523 VPNC: -set_login_state: LOGIN: 1 (TRYING) --> 3 (FAILED)
3844 NOT Mar 3 15:38:32.864538 VPNC: -set_login_state: VPNC : 1 (LoggingIn) --> 3 (LoginFailed)
3845 NOT Mar 3 15:38:32.864561 VPNC: -vpnc_send_notify: notify type: 1 [LoginFailed]
3846 NOT Mar 3 15:38:32.864580 VPNC: -vpnc_send_notify: notify code: 32 [DnsLookupErr]
3847 NOT Mar 3 15:38:32.864611 VPNC: -vpnc_send_notify: notify desc: [url hostname lookup err]

يشير ذلك عادة إلى أحد الأمور التالية:

1. يحتوي الهاتف على خادم DNS غير صالح
2. لم يستلم الهاتف خادم DNS عبر DHCP أو لم يتم تكوينه يدويا

in order to صححت هذا إصدار هناك إثنان خيار:

1. تحقق من التكوين على الهاتف لضمان تلقيه خادم DNS من خادم DHCP عندما يكون خارجيا و/أو تحقق من أن خادم DNS للهاتف يمكنه حل الاسم المستخدم في تكوين ASA
2. قم بتغيير عنوان URL في تكوين ASA و CUCM إلى عنوان IP حتى لا يكون DNS مطلوبا

لا يقوم الهاتف بتمكين VPN

كما تمت الإشارة إليه مسبقا في هذا المستند، يتسبب "الكشف التلقائي عن الشبكة" في إختبار اتصال الهاتف بخادم TFTP والبحث عن إستجابة.  إن يكون الهاتف على الشبكة الداخلية، بعد ذلك ال TFTP نادل يكون reachable دون VPN، لذلك عندما الهاتف يستلم إستجابة إلى ال pings، هو لا يمكن VPN.  عندما لا يكون الهاتف على الشبكة الداخلية، تفشل إختبارات الاتصال، لذلك سيقوم الهاتف بتمكين VPN والاتصال ب ASA.  تذكر أنه من المحتمل ألا يتم تكوين الشبكة المنزلية للعميل لتزويد الهاتف بخيار 150 عبر DHCP، ولا يمكن أن يوفر ASA أيضا خيار 150، لذلك فإن 'Alternate TFTP' هو متطلب لهواتف VPN.

في السجلات، قد ترغب في التحقق من بعض الأمور:

1. هل يتم إختبار اتصال الهاتف مع CUCM TFTP server؟
2. هل يتلقى الهاتف إستجابة لأدوات إختبار الاتصال؟
3. هل يقوم الهاتف بتمكين VPN بعد أن لا يستلم إستجابة إلى إختبارات الاتصال؟

من المهم عرض هذه العناصر بهذا الترتيب.  في سيناريو حيث يرن الهاتف بروتوكول IP الخطأ ويستلم إستجابة، لن يكون من المجدي تمكين تصحيح الأخطاء على ASA لأن الهاتف لن يمكن VPN.  قم بتدقيق هذه الأمور الثلاثة بهذا الترتيب بحيث يمكنك منع تحليل السجل غير الضروري.  سترى هذا في سجلات الهاتف 88xx إذا فشل إختبار الاتصال وتم تمكين VPN بعد ذلك:

5645 NOT Mar 27 11:32:34.630109 (574:769) JAVA-vpnAutoDetect: ping time out
5647 DEB Mar 27 11:32:34.630776 (710:863) JAVA-configmgr MQThread|cip.vpn.VpnStateHandler:? - VpnStateHandler: handleVPN_ENABLED_STATE()

سجلات الهاتف ولكن لا يمكن عرض محفوظات المكالمات

تحقق من تمكين TFTP البديل على الهاتف ومن تكوين IP الصحيح ل TFTP.  TFTP البديل هو متطلب لهواتف VPN لأن ASA لا يستطيع توفير خيار 150.

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

• الدعم التقني والمستندات - Cisco Systems