الانتقال بين مزوّدي VPN: خطّط لاسم المضيف، لا لعنوان IP وحده
سجل DNS الجديد لا ينقل الجلسات القائمة. خطّط لمن يتحكّم بالاسم، ومتى يحلّه كل عميل، وكيف ستُخرج النقطة الطرفية القديمة من الخدمة.
سجل DNS لديك صحيح، والبديل سليم، ومع ذلك تقضي بعض العملاء ساعات في طلب العنوان القديم. ويفشل القليل منها فورًا أمام اسم يُحلّ ولا يستجيب أبدًا. تنبع النتيجتان من ثغرة واحدة: اسم المضيف يغيّر ما يبحث عنه العميل، لا متى يبحث عنه، ولا ما يثق به عند وصول الردّ.
العَرَض: سجل صحيح وأنفاق قديمة
الملف الذي يخزّن اسمًا ليس عميلًا يواصل حلّ ذلك الاسم. معظم العملاء يحلّونه مرة واحدة، عند تطبيق الإعدادات أو عند صعود النفق، ثم يعيدون استخدام ذلك العنوان حتى تنتهي الجلسة. ووجود TTL طويل فوق ذلك هو سبب وجوب تخطيط التحوّل حول إعادة الاتصال لا حول تعديل DNS.
لا يُعدّ أي من السلوكين عيبًا، وهذا ما يجعل العَرَض مربكًا. فالعميل يعمل على إجابة حصل عليها سابقًا، ولا شيء في جانب الخادم يبيّن أي إجابة كانت. خطّط لإعادة الاتصال داخل نافذة الصيانة وأخبر المستخدمين بما سيرونه، أو اقضِ النافذة في الردّ على التذاكر. والنتيجة المعتادة هي طابور من البلاغات المتطابقة.
من يتحكّم بالاسم، وما يتحقّق منه العميل
التحكّم في المنطقة يحدّد مدى سرعة الهجرة. أبقِ السجل لدى مسجّل تستطيع الدخول إليه، ودوّن من غيره يستطيع تغييره.
الثقة لا تتبع الاسم. فقد يتحقّق عميل قائم على TLS من هوية شهادة أو اسم مثبّت، بينما يوثّق WireGuard المفتاح العام للنظير ويتجاهل اسم المضيف كليًا. وهذا الفرق يحدّد ما إذا كان تعديل DNS كافيًا أم أن كل ملف يحتاج بصمة جديدة. ولا ينبغي لتعديل سجل أن يمنح إذنًا لنقطة طرفية لم يوافق عليها أحد.
أبقِ الوصول الإداري ووصول الاستعادة بعيدًا عن اسم العميل العام. فقدان حساب استضافة لا ينبغي أن يكلّفك أيضًا السجل الذي يعيد توجيه العملاء. خزّن مسار الاستعادة في مكان لا يعتمد على المزوّد الذي تغادره.
متى يعيد كل عميل قراءة الاسم
توقيت الحلّ خاصية لكل عميل، لذا افحص التنفيذ الذي تشحنه فعلًا قبل أن تعد بنافذة تحوّل. يحلّ wg-quick النقطة الطرفية عند صعود الواجهة ويحتفظ بذلك العنوان حتى يُعاد تشغيل النفق. وعميل OpenVPN يبحث عن الاسم عند الاتصال، أما ما إذا كان سيبحث مجددًا عند إعادة الاتصال فيعتمد على خياراته.
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
العملاء المحمولون هم المفاجأة المعتادة، لأنهم قد يحتفظون بعنوان محلول عبر النوم أو تغيّر الشبكة. لا تنشر سجلات A وAAAA إلا إذا كان البديل يستجيب على العائلتين. والعنوان الذي يستجيب على عائلة واحدة لا يثبت شيئًا عن الأخرى، وسجل AAAA الميت يضيف مهلة إلى كل محاولة. وثّق سلوك الحلّ لكل عميل تدعمه، ثم اختبره على الأجهزة التي يستخدمها الناس فعلًا.
إعادة الاتصال إجراء يقوم به المستخدم في معظم العملاء، ولا يستطيع الخادم فرضه. ضع تلك الخطوة في ملاحظة الصيانة، مع سطر عمّا سيراه المستخدم عند حدوثها.
حوّل بناءً على الأدلّة، ثم أخرج النقطة الطرفية القديمة
قبل التبديل، أثبت كل طبقة عند البديل: المستمع يستجيب، وجدار الحماية يمرّر المنفذ، والمسارات تعود في الاتجاه الصحيح، والاسم يُحلّ إلى العنوان الجديد، والهوية المعروفة تُقبل. والمستمع الذي يقبل اتصالًا ليس كمن يكمل مصافحة، لذا اختبر المصافحة لا المنفذ. أبقِ قائمة الإلغاء الحالية بجانب الإعدادات، لأن نسخة احتياطية مستعادة تعيد إنشاء قائمة النظير كما كانت وستعيد فتح وصول أغلقته سابقًا. سجّل الهوية التي اختبرت بها، لأن «هذا يعمل» ليس دليلًا يستطيع أحد تكراره.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesأثناء الانتقال، راقب محاولات الاتصال على كلتا النقطتين الطرفيتين للهوية نفسها. والعميل الذي ما زال يوثّق نفسه أمام العنوان القديم هو ملف أو إجابة مخزّنة لم تنتقل قط. أخرج النقطة الطرفية القديمة وفق خطة مؤرّخة، لأن خدمتين تقبلان هوية واحدة تتركان بابين مفتوحين.
اختبار التحوّل هو جلسة تطبيق عبر النقطة الطرفية الجديدة، لا أمر ping. وبمجرد أن تعمل تلك الجلسة ولا يسجّل الطرف القديم أي محاولات مصرّح بها خلال دورة إعادة اتصال كاملة، يكون الانتقال قد اكتمل.