تغيّر عنوان WAN وانقطع النفق: الفحوصات بالترتيب

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

سمِّ الحدث قبل أن تقرأ السجل

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

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

التجوال وإعادة الاتصال بروتوكولان مختلفان

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

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

لا يقول أي من السلوكين شيئًا عن التطبيقات في الداخل. النفق المستعاد لا يعيد جلسة TCP كان القرين يعتبرها ميتة بالفعل.

حالة لا يملكها النفق

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

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

رتّب الفحوصات من الخارج إلى الداخل

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

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

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

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

حدّد السلوك المتوقع واكتبه

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

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