هل ينقطع VPN بعد تجديد DHCP؟ قارن العناوين

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

ابدأ من العميل الذي انقطع

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

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

قارن القيم الأربع حول الحدث

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

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

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

ما يمكن للتجديد أن يغيّره وما لا يمكنه

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

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

عندما يفشل العميل في التكيّف

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

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

أعد إنتاج الحدث قبل أن تلومه

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

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