مسألة
يواجه مستخدمو Mac إخفاقات متقطعة عند محاولة مصادقة CLI إلى التطبيقات الداخلية أثناء الاتصال بشبكة VPN الخاصة بالعميل الآمن من Cisco. وتنتج الإخفاقات أخطاء "المضيف غير موجود" أثناء مصادقة CLI وعند إستخدام أوامر مثل curl. ومع ذلك، تحدث أوامر تحليل DNS مثل nslookup وdig بنجاح. تحدث المشكلة بشكل عشوائي ويمكن حلها مؤقتا بإعادة توصيل شبكة VPN، وبعد ذلك يعمل الاتصال لفترة قصيرة قبل حدوث المشكلة. يتم إستخدام Split-tunnel VPN، و Cisco Umbrella نشطة. لا تحدث المشكلة عند إستخدام Palo alto Global Protect شبكة خاصة ظاهرية.
- رسالة خطأ: "لم يتم العثور على المضيف" على أوامر
مصادقة CLI والتشوه. - رسالة خطأ: عميل VPN غير قادر على التحقق بنجاح من تعديلات جدول إعادة توجيه IP. إصدار حل خادم اسم المجال (DNS) أثناء توصيل الموارد الخاصة
- نجحت أوامر
nslookup وdig - اتصال متقطع بعد إعادة اتصال VPN
- تمكين الوحدة النمطية Split-Tunnel Remote Access VPN و Umbrella
- إصدار يمكن إعادة الإنشاء فقط مع Cisco Secure Client VPN على أجهزة MacOS
البيئة
- المنتج: Cisco Secure Client (CSC) مع وحدات متعددة
- النظام الأساسي: أجهزة Mac للشركات
- تكوين ملف تعريف VPN: ملف تعريف VPN للوصول عن بعد - تجاوز الوصول الآمن - وضع النفق المقسم ووضع DNS المحدد ك "DNS الافتراضي"
- تصفية DNS: تم تمكين Cisco Umbrella
- إصدارات الوحدة النمطية:
- Cloud Management v1.0.0.23
- AnyConnect VPN v5.1.13.177
- Umbrella v5.1.13.177
- DART v5.1.13.177
- Secure Firewall Posture v5.1.13.177
- وحدة رؤية الشبكة v5.1.13.177
- البيانات التشخيصية: مجموعات DART التي تم جمعها للتحليل
- تمت الملاحظة فقط على Cisco Secure Client VPN (ليس على Palo Alto GlobalProtect)
قرار
- أثناء تصحيح تكوين النفق المقسم لملف تعريف VPN (
naic.org) وجدول توجيه AnyConnect VPN على جانب العميل، تم ملاحظة هذا السلوك:- سيناريو العمل - عند إجراء
بحث NSLOOKUP للمجالات المحلية غير الأساسية في Vault، تم حل طلبات DNS التي تمت معالجتها بواسطة خوادم DNS التي تم تكوينها ضمن ملف تعريف VPN بشكل صحيح إلى 10.x عنوان. وفقا لذلك، تم تحديث جدول التوجيه باستخدام IP الذي تم حله (على سبيل المثال، 10.59.130.193) ضمن مسارات غير آمنة. - سيناريو عدم العمل - مع ذلك، عند معالجة طلبات DNS نفسها بواسطة DNS المحلي لنظام التشغيل MacOS (192.168.x.x) الذي تم تكوينه على مهايئ UNTUN4 و en0 بدلا من خوادم DNS المحددة في ملف تعريف VPN، فقد تم ملاحظة هذا السلوك بوضوح من التقاط الحزمة أثناء ملاحظة المشكلة.
- تم حل المجالات الخاصة إلى نطاق IP من 34.x.x.x، مما أدى إلى مشكلة الاتصال. ساعد التقاط Wireshark في تحديد السبب الأساسي لهذه المشكلة.
- من وجهة نظر التصميم والتكوين، باستخدام إعداد ملف تعريف VPN ذي تقسيم النفق، يوصى باستخدام DNS المقسم بدلا من الاعتماد على DNS/DNS الافتراضي للنظام المحلي.
- وبالإضافة إلى ذلك، تمت إضافة إدخال
us-east-eks-amazonaws.com لضمان توجيه حركة مرور البيانات لمجموعة EKS هذه بشكل صحيح من خلال واجهة النفق البعيد. - كما تمت مناقشة ضرورة أن تكون لواجهة RAPN الأولوية على وحدة Umbrella النمطية ويجب ألا تتعارض مع ملف
OrgInfo.json الذي يحتوي على معرف مؤسسة Umbrella. - أثناء عملية أستكشاف الأخطاء وإصلاحها، قمنا بتثبيت جديد لعميل CSC بدون وحدة Umbrella النمطية، مع هذا السيناريو لم نتمكن من رؤية المشكلة. لقد تمكنت من مراجعة الأمر من منظور Umbrella أيضا، و root domain naic.org الذي تم تكوينه في قائمة المجالات الداخلية لتخطي Umbrella مما يعني أنه تتم إعادة توجيه قرارات المجال المحلية إلى MacOS التي تم تكوينها DNS بواسطة وحدة DNS Umbrella على مستوى Kernel لواجهة الاسترجاع.
هذا محاذاة مع حل المشكلة عندما لا توجد وحدة نمطية Umbrella في موضعها. باستخدام تكوين ملف تعريف VPN المناسب بما في ذلك المجالات الصحيحة في قاعدة توجيه حركة المرور وتقسيم تكوين DNS، يجب ألا نرى المشكلة حتى مع تشغيل نموذج Umbrella.
أكد المستخدم أنه تم حل المشكلة بعد تعديل وضع DNS إلى نفق تقسيم وتحرير تكوين ملف تعريف VPN.
السبب
ملف تعريف VPN - تجاوز الوصول الآمن - من المفترض أن يتم تعيين وضع DNS على تقسيم النفق (الخيارات التي يتم رؤيتها بشكل شائع من سيناريوهات حالة إستخدام) وتضمين جميع مجالات التطبيقات الخاصة/الداخلية ضمن تكوين DNS المقسم لحل المشكلة.
المحتوى ذي الصلة
التعليقات