ترحيل DHCP في ASA عبر VPN من موقع إلى موقع: دليل تطبيقي

يعمل الترحيل على ثلاث أرجل، ولا تعبر الوسطى منها إلا الشبكة الافتراضية الخاصة VPN. يبثّ العميل على مقطع الفرع، ويحوّل ASA ذلك البث إلى طلب أحادي الوجهة إلى خادم DHCP، ويجيب الخادم على عنوان الترحيل لا على العميل. تتبّع الأرجل بهذا الترتيب، وستنحلّ معظم حالات «الترحيل معطّل» إلى سياسة ناقصة أو سطر setroute مقروء خطأً.

الرجل الأولى: تمكين الترحيل على الواجهة المواجهة للعميل

في ASA الخاص بالفرع، الترحيل خاصية بالواجهة المواجهة للعملاء. يمكن تعريف الخادم عالميًا مع واجهته القابلة للوصول، أو تحت تلك الواجهة المواجهة للعميل كي يختار جدول التوجيه المخرج. هذان الشكلان غير قابلين للتبادل، ونسخ الشكل الخطأ هو أول موضع ينحرف فيه الدليل.

افحص الإعداد الجاري قبل أن تغيّر أي شيء: أي واجهة مفعّل عليها الترحيل، وأي شكل من أشكال الخادم موجود، وهل setroute مرتبط بواجهة العميل. إن كان ASA يشغّل أيضًا خادم DHCP لمقطع آخر، فتوقف واقرأ قائمة القيود؛ لا يمكن تمكين الخادم والترحيل معًا على الجهاز نفسه.

يضع الترحيل عنوانه المواجه للعميل في حقل عنوان البوابة. هذا العنوان هو ما سيجيب عليه الخادم، لذا يجب أن يكون قابلًا للوصول من الموقع البعيد عبر النفق، لا محليًا فقط.

الرجل الثانية: حمل حركة ASA المولّدة عبر النفق

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

تأكد من أن الحركة المهمة تغطي مصدر الترحيل في ASA وعنوان الخادم، وأن اتجاه العودة مسموح به أيضًا. في تصميم قائم على VTI يكون قرار التوجيه أبسط، لكن دعم الترحيل عبر VTI وصل في إصدار محدد؛ دليل DHCP في ASA يحدد 9.14(1)، لذا افحص الصورة قبل نسخ مثال VTI إلى جهاز أقدم.

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

الرجل الثالثة: قراءة الرد وخيار setroute

يقول RFC 2131 إن الخادم يرسل رده إلى العنوان الموجود في giaddr عندما يكون ذلك الحقل غير صفري. لذا يجب أن يوجّه مسار العودة إلى عنوان الترحيل، ويجب أن تسمح سياسة النفق باتجاه الخادم إلى الترحيل. إن عبر الطلب ولم يصل العرض أبدًا، فهنا موضع البحث.

ثم افصل بين أمرين متشابهين. الكلمة المفتاحية setroute تغيّر أو تضيف خيار الموجّه الافتراضي الذي يمنحه ASA للعميل. وهي لا تثبّت مسارًا على ASA ولا تنشئ سياسة VPN. العميل الذي يحصل على عنوان لكنه لا يصل إلى أي شيء غالبًا ما يواجه مشكلة setroute أو نطاق، لا مشكلة نفق. اختبر ذلك بعميل بلا بوابة ثابتة وراقب أي موجّه افتراضي يظهر في العرض.

اقرأ العرض من أوله إلى آخره: العنوان المعروض، والقناع، والموجّه الافتراضي، وDNS، ومدة الإيجار. ثم دع الإيجار يتجدد. الترحيل الذي يعمل مرة ويفشل عند التجديد لديه عادةً مشكلة نطاق أو إيجار أو مسار عودة أخفاها التبادل الأول.

ما أفحصه قبل أن أعلنه مُصلحًا

ابدأ من العميل والتقط البث، ثم تأكد من أن ASA رحّله بعنوانه الخاص بوصفه giaddr. في الجهة البعيدة، تأكد من أن الخادم رأى ذلك الطلب واختار نطاقًا يطابق الفرع. وبالعودة إلى الفرع، تأكد من أن العميل قبِل العرض ويستطيع الوصول إلى بوابته.

إن كانت أي رجل صامتة، فافحص السياسة أو المسار المطابق بدل إضافة عبارة ترحيل أخرى. إعداد الترحيل يكون عادةً صحيحًا بحلول وقت التصعيد؛ وسياسة النفق أو مسار العودة هي ما تغيّر.

اكتب الأرجل الثلاث في سجل التغيير: الواجهة المواجهة للعميل، وسياسة VPN التي تغطي حركة الترحيل، ومسار الخادم عائدًا إلى giaddr. هذا السجل هو ما يجعل بناء الفرع التالي مهمة قابلة للتكرار بدل جلسة تنقيح. ويخبر المهندس التالي أيضًا أي مخرجات أوامر يجمعها أولًا.