غيّر مزوّد الخدمة دون إعادة ترقيم عناوين VPN للموقع

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

خطتا عناوين تتحركان بشكل مستقل

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

تغيّر المزوّد يمسّ الخطة الخارجية. وهو لا يتطلب بحد ذاته تغيير الخطة الداخلية.

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

النفق الخارجي يحمل المحادثة الداخلية

في نفق من بوابة إلى بوابة، يعنون رأس IP الخارجي البوابتين. أما الرأس الداخلي فيظل يسمّي نقاط نهاية التطبيق الفعلية. يصف RFC 7296 النفق من بوابة إلى بوابة كتوجيه عادي يوصّل الحركة عبر نقاط نهاية النفق.

لهذا يمكن لخادم الفرع أن يحتفظ بـ 10.55.8.20 بينما يتغيّر العنوان العام للبوابة. الحزمة الداخلية لا تحتوي على عنوان المزوّد إطلاقاً.

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

نقل المزوّد ما زال له قائمة تحقق

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

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

تداخل العناوين مع موقع آخر متصل مشكلة تخطيط منفصلة. تغيير المزوّد لا ينشئها، لكن الترحيل هو عادةً وقت ظهورها.

ما لا يبقى: المصدر العام والجلسات

عنوان خادم خاص مستقر ليس مصدراً عاماً مستقراً. إذا خرج التصفح مباشرة عبر المزوّد الجديد، فسترى المواقع العنوان الجديد المواجه للمزوّد.

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

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

تحقق من النقل بأربعة فحوص

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

على بوابة Linux، تغطي هذه الثلاثة منتصف تلك القائمة:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

أبقِ عناوين النقل في جرد وعناوين التطبيقات في جرد آخر. حدّث فقط المدخلات التي تحركت فعلاً. إعادة ترقيم التبعيات الداخلية لأن العنوان الخارجي للنفق تغيّر عمل يمكن تجنبه.