لماذا لا يحدد ترتيب المحولات مسار VPN في مختبرك

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

ثلاثة شروط تحدد المسار

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

تلك النقطة الأخيرة هي القرار: إن لم تستطع تحديد البادئة التي تفوز لعنوان نقطة نهاية VPN نفسها، فليس لديك سياسة توجيه، بل لديك طوبولوجيا تعمل اليوم بالمصادفة.

الشرط الأول: أي بادئة تفوز

مسار إلى 10.8.0.0/24 يتغلب على المسار الافتراضي لعنوان يقع داخله، بصرف النظر عن المقاييس وبصرف النظر عن ترتيب المحولات. ولهذا يستمر عميل VPN الذي يثبت مسارًا محددًا في العمل حتى عندما يظهر محول ثانٍ بمقياس أقل: التحديد يتغلب قبل النظر في الكلفة. تحقق بالأمر ip route show على الجدول الذي تظنه قيد الاستخدام، وبالأمر ip route get 203.0.113.9 على الإجابة التي ستعطيها النواة فعلًا لوجهة محددة.

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

الشرط الثاني: ما يفعله المقياس وما لا يفعله

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

في الضيف، يطبع ip route show المقياس بجانب كل مسار، ويطبع Get-NetRoute في ويندوز InterfaceMetric إضافة إلى مقياس المسار. اقرأ كليهما، لأن الأفضلية الفعلية قد تكون مجموعًا لا حقلًا واحدًا. إن وُجد مساران افتراضيان، فهذا هو الاكتشاف: للضيف مخرجان، وأيهما يفوز دالة لأرقام يمكن لتعديل عتادي أن يغيرها.

الشرط الثالث: ما طبّقه الضيف فعلًا

الإعداد ليس هو الحالة المطبقة. أسماء الواجهات ليست مستقرة عبر تعديلات العتاد على كل منصة، وإعداد كان يطابق اسمًا قد لا ينطبق الآن على شيء.

افحص الحالة المطبقة لا المقصودة. يُظهر ip -br link الواجهات الموجودة الآن، وعلى مضيف يعمل بـ NetworkManager يُظهر nmcli connection show أي ملف تعريف مرتبط بأي جهاز. ملف تعريف فشل في الارتباط يترك الواجهة قائمة بلا عنونة، وهو ما يبدو مشكلة توجيه وهو في الحقيقة مشكلة تسمية. اللقطات المستعادة تزيد الأمر سوءًا، لأن حالة الضيف المحفوظة قد تشير إلى هويات محولات لم يعد العتاد الجديد يوفرها.

اجعل طوبولوجيا المختبر قابلة لإعادة الإنتاج

احفظ ارتباطات الشبكة الافتراضية المقصودة إلى جانب إعداد الضيف، حتى يُكتب تعيين الدور إلى المحول بدلًا من استنتاجه من موضع في قائمة.

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

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

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