نقل OpenVPN من TAP إلى TUN: ترتيب ترحيل ينجح

إن استبدال dev tap بـ dev tun يغيّر ما يحمله النفق، لا مجرد طريقة تسميته. واجهة TAP تسلّم إطارات Ethernet إلى جسر، فيتصرّف العملاء كأنهم موصولون بمبدّل المكتب. واجهة TUN تحمل حزم IP، فيحتاج العملاء إلى مسارات ويحتاج الطرف الآخر إلى طريق للعودة. على العملاء وخطة العنونة ومسار العودة في الشبكة المحلية أن تنتقل كلها مع هذا التغيير.

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

اجرد ما يعتمد فعلاً على Ethernet

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

هذا الجرد هو أيضاً قائمة القبول. كل بند لا تستطيع ترحيله يصبح استثناءً موثَّقاً أو سبباً لإبقاء مقطع TAP صغير حياً لهذا الحمل وحده.

ابنِ خطة العنونة ومسار العودة

اختر بادئة للعملاء لا تتقاطع مع الشبكة المحلية أو نطاق الجسر القديم أو أي شبكة يصل إليها العميل بالفعل.dev tun، topology subnet و server 10.78.0.0 255.255.255.0، لكن هذا مقطع لا ملف تعريف عامل بحد ذاته. أبقِ حوله سياسة TLS والهوية والنقل والوصول المعتمدة، واستخدم بادئة تحققت من أنها حرة.

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

أجرِ تجربة على مستمع منفصل

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

ضمّن اختبار إعادة اتصال واختبار حركة عائدة. مصافحة تكتمل لا تقول شيئاً عن قدرة الطرف الآخر على الإجابة.

حرّك العملاء في مجموعات مع خطة تراجع

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

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

أزل الجسر بعد القبول فقط

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

يكتمل الترحيل عندما يعمل نموذج الوصول الموجَّه مع الجرد، لا عندما تختفي واجهة TAP من ناتج ip link.