أستكشاف أخطاء المنفذ وإصلاحها عند إستخدام ترجمة عنوان المنفذ مع مكونات المظلة

المقدمة

يصف هذا وثيقة Umbrella زبون يستعمل ويجول زبون و/أو ظاهري و/أو يصادف إصدار مع إستهلاك أيسر في جدران الحماية أن يستعمل ترجمة عنوان أيسر. ويحدث ذلك على الأرجح في البيئات التي يوجد بها عدد كبير من العملاء المتجولين و/أو حركة مرور كبيرة تعمل عبر نقاط الوصول lighweight (VAs). يمكن أن تتضمن الأعراض استعلامات DNS التي تعود ببطء أو تنقطع.

الأسباب

لا يجيب العملاء المتجولون ولا ذاكرة التخزين المؤقت للأجهزة الظاهرية على استعلامات DNS. علاوة على ذلك، يرسل العملاء المتجولون طلبات DNS "Probe" متكررة لتحليل بيئة الشبكة وكفحوصات صحية.

توصيات

• تأكد من تكوين المجالات الداخلية بشكل صحيح داخل إدارة المجال على لوحة معلومات Umbrella الخاصة بك. يجب أن تحتوي على منطقة Active Directory (و/أو مناطق داخلية أخرى) لتقليل حجم الاستعلامات عالية التردد.
• راجعت بعض من ال PAT عملية إعداد على جدار الحماية:
  • يمكن أن تكون مهلة جلسة UDP الطويلة مشكلة. نوصي بشكل نموذجي بفترات انتهاء مهلة جلسة UDP التي تبلغ حوالي 15 ثانية. ومع ذلك، يرجى ملاحظة أنه إذا تم إستخدام UDP بشكل كبير من قبل التطبيقات الأخرى على الشبكة، فيمكنها الحصول على فترات زمنية أطول يجب أن تأخذها في الاعتبار.
  • على حسب جدار الحماية الخاص بك، من الممكن زيادة حجم تجمع PAT الخاص به من أجل زيادة عدد الاتصالات المتزامنة.
• إن يتلقى أنت عنوان أن أنت يستطيع كرست إلى VAs، استعملت 1:1 nat بدلا من ضرب على جدار الحماية. ملاحظة: "1:1 NAT" يشار إليه أحيانا باسم "NAT المباشر"، ولكن هذا تسمية خاطئة؛ والمصطلح الفني الصحيح هو "1:1 nat".
• راجع حدود الاتصال لكل IP. وفي كثير من الأحيان، لا يتوقع تطبيق سياسة على الجهاز المعني، بل إنها تطبق بالفعل حدا. راجع القسم التالي لمعرفة كيفية التأكيد. 

التحقق من حدود الاتصال لكل IP على ASA

أستخدم الخطوات التالية:

• قم بتكوين ASA باستخدام التقاط لمعرفة سبب إسقاط الحزم بواسطة جدار الحماية:
  

  capture asp type asp-drop all match ip any host 208.67.222.222

• ابحث عن الحزم التي يتم إسقاطها ل IP المعني. يظهر سبب حد الاتصال على هيئة سبب إسقاط: (conn-limit)
• اختبر حد اتصال المضيف باستخدام الأمر:
  

  show local-host detail | begin <IP Address of VA or roaming client>

  • هل هذا العدد ثابت عند حد معين (999) ولا يزيد أبدا؟ إذا كان الأمر كذلك، فهذا يشير إلى وجود حد للاتصال.
• تحقق من وجود نهج خدمة يطبق هذا؛ إذا وجدته، فتحقق من خريطة السياسة الخاصة به:
  

  show run service-policy, show policy-map NAME

  • إذا عثرت على "NAME" لمخطط السياسة الذي يقوم بتعيين حد الاتصال لكل مضيف على 1000 (على سبيل المثال)، يؤدي ذلك إلى إسقاط أي حزم DNS جديدة من الجهاز إلى أن يتوفر المزيد من الاتصالات. UDP عديم الحالة ولا يعيد المحاولة.
• لحل هذه المشكلة، قم بإزالة نهج الخدمة هذا (لا يوجد اسم لنهج الخدمة بالداخل). يجب أن تبدأ الاتصالات في تجاوز حد الألف (من المثال الذي ذكرناه). يحدث هذا بسرعة أكبر ل VA مقارنة بالعميل المتجول. 

توصيات أخرى

وإذا لم تساعد هذه التوصيات، فإن الحل الممكن هو:

1. أستخدم تقرير لوحة معلومات Umbrella —> Reporting —> Top Destination لتحديد مجال واحد أو أكثر يحتوي على عدد كبير من الطلبات خلال ال 24 ساعة الأخيرة.
2. في لوحة معلومات Umbrella —> Configuration —> Domain Management، أضف واحدا أو أكثر من المجالات كبيرة الحجم إلى القائمة، مع إعداد "يطبق على" إلى "كافة الأجهزة والأجهزة".
3. بعد ذلك، تتم إعادة توجيه الاستعلامات الخاصة بتلك المجالات بواسطة وحدات VA إلى DNS المحلية. من الناحية المثالية، يجب تكوين DNS المحلي لإعادة توجيهه إلى DNS Umbrella على 208.67.220.220/208.67.222.222، ولكن يمكن تكوينها لإعادة التوجيه إلى أي DNS خارجي.  
4. يعالج DNS المحلي الاستعلامات عن أي مجالات موثوق بها. 
5. بافتراض أن DNS المحلي يقبل الاستعلامات للمجالات غير المحلية، تتم إعادة توجيه الاستعلامات لتلك المجالات الأخرى إلى DNS الخارجي.

وذلك لأن DNS المحلي يمكنه تخزين نتائج DNS مؤقتا، بينما لا يقوم عملاء التجوال والأجهزة الظاهرية بالتخزين المؤقت. الرجاء ملاحظة أن إستخدام هذا الحل يؤدي إلى زيادة حركة المرور وزيادة الحمل على DNS الداخلي، لذا قم بمتابعتها بعناية للتأكد من عدم تحميلها الزائد.