نقل خادم VPN إلى عنوان IP عام جديد: ما يجب فحصه أولًا
يختلف موضع العطل بين الاستبدال في المكان والانتقال المتوازي. افحص الإعدادات وNAT والشهادات، ثم تحقق كيف يحل كل عميل الاسم.
إعادة ربط العنوان تستغرق دقيقة. الأسبوع الذي يلي هو حيث ينكسر الانتقال، ونادرًا حيث توحي بذلك لوحة المزوّد. يُشار إلى عنوان IP عام جديد في أربعة مواضع: المقبس الذي يستمع عليه البرنامج الخفي، ومرساة الثقة التي يتحقق منها العملاء، وكل قاعدة تذكر العنوان القديم، ثم سجل DNS الذي يربطها معًا. الانتقالان يبدوان متطابقين من لوحة التحكم لكنهما يتصرفان بشكل مختلف تمامًا: إعادة تعيين العنوان على الجهاز الذي تديره، أو إقامة نقطة نهاية ثانية ونقل العملاء إليها. الفحوص أدناه تضع الأعطال الرخيصة أولًا، وكل قسم يحدد الانتقال الذي ينطبق عليه.
الاستبدال في المكان والانتقال المتوازي مهمتان مختلفتان
الاستبدال في المكان يحافظ على المضيف والمفاتيح وجدول التوجيه وقائمة المستخدمين؛ يتغير العنوان فقط. هذا ما تفعله إعادة ربط عنوان IP عائم، وعند عدة مزوّدين لا يلاحظ الضيف شيئًا، لأن الترجمة تحدث أمام المنسخة. إعادة البناء أو إعادة التعيين من المزوّد أقسى: يرى الضيف التغيير، وكل ما خزّن القيمة القديمة مؤقتًا يتعلمها في اللحظة نفسها.
النقطة الطرفية المتوازية مضيف ثانٍ يؤدي العمل نفسه. ابنِها، واختبرها بملف تعريف واحد، واترك القديمة تجيب حتى تثبت الجديدة نفسها عبر مسار حقيقي. الثمن هو الحالة. بدون إدخالات أقران مشتركة وإلغاءات وتسجيل، لديك شبكتان تتصادف أنهما تشتركان في اسم.
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
اعثر على كل موضع كُتب فيه العنوان القديم
ابدأ بمسح نصي، لأن ملفات الإعداد هي النصف السهل. ابحث في إعداد البرنامج الخفي وشظايا الجدار الناري وأهداف المراقبة وأي حزمة عميل مولّدة على القرص. أدرج عنوان IPv6 إذا كنت تنشر واحدًا؛ الانتقال الذي يتبع سجل A فقط يترك عملاء الحزمة المزدوجة على المسار القديم.
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsثم امسح النواة، لأن نظامًا قيد التشغيل يحتفظ بالعنوان في مواضع لا يذكرها أي ملف. قاعدة NAT مصدرية ثابتة، وإدخال ipset، وعنوان ربط، وإدخال conntrack تعيش أطول من تعديل الإعداد الذي أزالها، وبعضها يعيش أطول من إعادة تشغيل لأنه عاد من مجموعة قواعد محفوظة. وعلى طبقة أعلى، مجموعات الأمان لدى المزوّد وأهداف موازن التحميل وفحوص المراقبة ليست على نظام ملفاتك إطلاقًا.
اكتب الجرد قبل أن تغيّر أي شيء؛ فهو يصلح أيضًا كنص لسكربت التراجع.
عملاء اسم المضيف يتعافون؛ عملاء IP الحرفي يصمتون
إذا وصل العملاء إلى الخادم باسم المضيف، فالانتقال في الأساس مشكلة DNS، ومدة TTL التي ضبطتها أمس تحدد مدى سوئه. المخزّنات المؤقتة تخزّن، ومخزّنات stub تخزّن مرة أخرى، وكثير من العملاء لا يبحثون عن الاسم إلا عند اتصال جديد، لذا يحتفظ النفق القائم بعنوان بدايته.
إذا كانت النقطة الطرفية عنوانًا حرفيًا، فلا شيء يعيد الحل ولا شيء يسجل شكوى. يخزّن WireGuard عنوان مقبس محلولًا: Endpoint = vpn.example.net:51820 يصبح IP في اللحظة التي يعمل فيها wg-quick up ويبقى ذلك IP حتى تغيّره. OpenVPN أكثر تسامحًا: يحل اسم المضيف remote وقت الاتصال، ومع resolv-retry infinite يعيد تجربة DNS عند إعادة الاتصال. وبعنوان IP حرفي، يستمر كلاهما في الاتصال بجهاز لم يعد موجودًا.
ما يضلل الناس هو الصورة المعكوسة. العميل الموجّه أصلًا إلى العنوان الجديد، بينما المستمع القديم ما زال يجيب، ينجح في كل اختبار تجريه من مكتبك. لقد خُدعت بذلك: ظهرت النقطة الطرفية الجديدة على هاتف من المحاولة الأولى، ولم يظهر عميل بملف تعريف قديم إلا عندما أُغلق المستمع القديم بعد ذلك بكثير.
الثقة لا تنتقل مع العنوان
يفصل WireGuard الهوية عن إمكانية الوصول، ما يجعل نقل العنوان شبه مجاني. يُعرَّف الأقران بالمفتاح العام، والنقطة الطرفية هي فقط حيث تذهب الحزم حاليًا؛ ويحدّث المضيف نقطة نهاية القرين من عنوان المصدر لأحدث حزمة موثّقة. القرين الخامل يحتاج مع ذلك إلى سبب للتحدث إلى المكان الجديد، ولا يتعلم العنوان إلا عندما تنتهي جلسته وتفشل محاولات المصافحة في مكان مرئي. يغطي الدليل السريع لـ WireGuard حقل نقطة النهاية.
الخوادم القائمة على TLS هي الحالة المعاكسة. الشهادة مرتبطة باسم، والعميل الذي يتصل بعنوان يقارن ما اتصل به مع الأسماء البديلة للموضوع. اتصل بـ IP بشهادة تحمل SAN خاصًا بـ DNS فقط، ويفشل التحقق: الاسم الذي استخدمه العميل ليس في الشهادة. إعادة الإصدار مع SAN خاص بـ IP تصلح ذلك الاتصال الواحد وتجعل الانتقال التالي أسوأ. إبقاء اسم مضيف في ملف التعريف وترك verify-x509-name في مكانه يحافظ على صرامة الفحص بينما يتغير العنوان تحته.
ثم افحص ما هو مرتبط به البرنامج الخفي؛ المقبس المثبّت على العنوان القديم يفشل بصمت. خادم OpenVPN الذي يبدأ بـ local 203.0.113.10 يرفض الإقلاع بمجرد اختفاء ذلك العنوان، بينما المستمع على 0.0.0.0 يتبع التغيير مجانًا. وNAT ينقسم بالطريقة نفسها: MASQUERADE يتبع أي عنوان أصبح للجهاز، بينما SNAT --to-source 203.0.113.10 الثابت يستمر في إعادة الكتابة إلى عنوان لم تعد تملكه، فيتلاشى مرور العودة. إذا جاء العنوان الجديد مع بوابة upstream مختلفة، فافحص rp_filter: تصفية المسار العكسي تُسقط مرور العودة القادم على واجهة لم تتوقعها النواة.
ترتيب الانتقال والأدلة على نجاحه
اخفض TTL قبل يوم، وأقم المستمع الجديد، وأثبته بملف تعريف تملكه وحدك. الاختبار من داخل الشبكة نفسها لا يثبت شيئًا تقريبًا، لذا استخدم هاتفًا على شبكة خلوية واختبر شيئًا يفترض أن ينقله النفق بدلًا من ping إلى النقطة الطرفية.
راقب العنوانين خلال النافذة. wg show all latest-handshakes على المضيف الجديد، أو ملف حالة OpenVPN، يخبرك كم قرينًا انتقل فعليًا. عندما تحصل النقطة الطرفية الجديدة على الأقران المتوقعين ولا يبقى في القديمة سوى المتخلفين، فأحِل المستمع القديم للتقاعد، وأزل قاعدة NAT القديمة، واحذف العنوان من جدار المزوّد الناري. إزالة المستمع القديم هي الخطوة التي تُتجاهل، وهي تسدّ الثغرة التي ما زال فيها ملف تعريف قديم يصل إلى الشبكة القديمة.
حدّد مشغّل التراجع كتابةً قبل أن تبدأ: إذا لم تحصل النقطة الطرفية الجديدة على مصافحة من عميل حقيقي واحد بعد النافذة المتفق عليها، فأعد العنوان القديم وتوقف عن توزيع ملفات التعريف. أعد تشغيل المسح بعد ذلك وتأكد من أن لا مستمع ما زال مرتبطًا بعنوان مسحوب. شيئان ينتقلان إلى النقل التالي: اسم مضيف في ملف تعريف العميل حتى يكون التغيير التالي تعديل DNS، والجرد المخزّن بجانب ملاحظات استعادة الخادم.