توجيه فروع MPLS: ما يتعلّمه CE وممّن يتعلّمه

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

إن تتبّع حزمة واحدة عبر المسار هو أسرع طريقة لمعرفة أيّ جزء يقع على عاتق العميل وأيّ جزء ينتمي إلى الخدمة.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

أين تنتهي مهمة كل قفزة

يحتاج CE-A إلى مسار للشبكة المحلية البعيدة يشير إلى رابط المزوّد المحلي، لا إلى عنوان WAN للفرع البعيد. ثم يحمل المزوّد الحزمة عبر نواته باستخدام حالة توجيه VPN، ويسلّمها CE-B إلى الشبكة المحلية للوجهة. ولا يحتاج أي مضيف في أي مرحلة إلى فهم التسميات أو VRF أو دائرة الإنترنت في الجهة البعيدة.

الخطأ الذي يتكرر في التذاكر هو إعداد عنوان WAN للفرع B كقفزة تالية في الفرع A. كلا الفرعين اشترى الخدمة نفسها، فيبدو الأمر وكأنهما يجب أن يكونا جارين. لكنهما ليسا كذلك: القفزة التالية يجب أن تكون قابلة للوصول عبر تصميم التوجيه الذي لديك فعلًا، وطرف CE البعيد يبعد عادةً قفزات كثيرة خلف معدات لا تديرها. أما المسار الساكن المبني على هذا الافتراض فيظهر نشطًا ولا يحلّ إلى شيء، وهذا أسوأ من مسار مفقود لأنه يبدو صحيحًا في الجدول.

يفصل RFC 4364 بين تبادل المسارات بين طرف العميل وطرف المزوّد وبين توزيع المزوّد لمسارات VPN، وهذا بالضبط الحد الذي يتناوله هذا الدليل. ومهمة العميل أن يخبر طرفه بما يمكنه تسليمه وأن يقبل قابلية الوصول التي تقدّمها الخدمة في المقابل.

ما يجب أن يتفق عليه التسليم

اختر الآلية مع المزوّد لا من حوله. المسارات الساكنة أو BGP أو ترتيب بروتوكول توجيه بين CE وPE كلها خيارات مشروعة، وقد حدّد OSPF نموذجًا لـ MPLS VPN يناسب هذا التسليم. وليس أي منها سببًا لبناء تجاور OSPF بين طرفي عميل بعيدين عبر نواة مزوّد غير محدّدة، فهذا تصميم لم يوافق عليه المزوّد ولا يستطيع دعمه.

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

ثم تابع الردّ. يحتاج الفرع B إلى مسار عودة إلى الشبكة المحلية المصدر، ويحتاج المضيف في جهة الاستقبال إلى بوّابته وصلاحيات خدمته. والمسار الذي يظهر عند CE-A يثبت نصف رحلة ذهاب وعودة فقط، وهذا سبب أن اتجاهًا واحدًا من اختبار ping يبدو سليمًا بينما يفشل التطبيق.

تحقّق من التسليمتين قبل الاعتماد

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

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

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

اعرف ما لا تقدّمه الخدمة

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

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

أخيرًا، أبقِ نموذج الخدمة مكتوبًا بجانب إعداد التوجيه في الموقع. ينبغي للمهندس التالي الذي يضيف شبكة فرعية أن يقرأ أيّ البادئات تُعلَن، ومن يقبلها، وما مسار العودة المتوقّع، إذ إنّ مواصفة BGP/MPLS IP VPN هي المرجع للنموذج الذي يقوم عليه كل هذا.