تغيّر عنوان IP العام وتوقف VPN عن تمرير البيانات

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

اعمل على الفحوص الأربعة بالترتيب، وتوقّف عند أول واحد يفشل.

أي عنوان تغيّر فعليًا

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

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

دع البروتوكول يتعامل مع الانتقال

تختلف البروتوكولات في طريقة تعلّمها أن طرفًا قد انتقل، والفرق مهم لمسألة ما إذا كان ينبغي لك التدخل أصلًا. يحدّث WireGuard نقطة نهاية الطرف عندما يستقبل حزمة تصادق بمفتاح ذلك الطرف، ولهذا يمكن استيعاب تغيّر العنوان دون أي إعداد. ويمتلك IKEv2 بروتوكول MOBIKE للغرض نفسه حين يدعمه الطرفان. أما التصاميم الأقدم فتتعافى بإعادة بناء النفق بدلًا من ذلك.

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

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

امسح الارتباط الخارجي القديم

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

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

أعد الاختبار بطلب جديد

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

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

إذا نجح طلب جديد ولم يستأنف القديم أبدًا، فقد أُصلح النفق ويحتاج التطبيق ببساطة إلى إعادة الاتصال.