OpenVPN ينقطع بعد تجديد DHCP: احتفظ بمسار نقطة النهاية

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

افحص العَرَض مقابل مسارات النصف الافتراضية

مع redirect-gateway def1، يثبّت OpenVPN 0.0.0.0/1 و 128.0.0.0/1 بدلًا من استبدال المسار الافتراضي. معًا يغطي هذان المساران كامل فضاء العناوين، ويتفوقان على 0.0.0.0/0 بطول البادئة وحده. لذلك تدخل أي وجهة بلا تطابق أكثر تحديدًا إلى النفق.

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

أكّد شكل الجدول قبل لمس أي شيء آخر. ينبغي أن يسرد ip route show النصفين مع مسار مضيف لعنوان الخادم؛ وعندما يغيب مسار المضيف، يصبح لبقية التحقيق نقطة بداية واضحة.

لماذا تفوز مسارات النصف دون تغيير المقياس

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

افحص الاختيار باستخدام ip route get 203.0.113.10، مع استبداله بعنوان الخادم الحقيقي. يذكر الجواب الواجهة والقفزة التالية التي كانت النواة ستستخدمها فعلًا، وهذا أنفع من قراءة جدول والاستدلال عليه.

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

خذ ثلاث لقطات، لا لقطة واحدة

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

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

عندما تُضبط نقطة النهاية باسم لا بعنوان، حلّ الاسم في كل لقطة أيضًا. يمكن لتغيير DNS على رابط الوصول أن ينقل نقطة النهاية دون لمس أي مسار إطلاقًا.

قرر أي مكوّن يحدّث الاستثناء

في نظام dhcpcd، تعمل الخطافات من دليل الخطافات ومن خطاف الخروج، ويختلف وضع المدير في النطاق عن وضع كل واجهة. ما يفعله الخطاف يجب أن يكون عديم الأثر عند التكرار، لأن التجديدات قد تصل دفعات.

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

سجّل المالك داخل الإعداد. يحتاج من يصحح إعادة الاتصال بعدك إلى معرفة أن خطافًا، لا VPN، مسؤول عن مسار الاستثناء.

اختبر دورة الحياة، لا إعادة الاتصال فقط

أجبر تجديدًا باستخدام dhcpcd -n eth0 أو بإفلات الإيجار وتجديده، ثم افحص ip route get لنقطة النهاية مرة أخرى. افعل ذلك مرتين، لأن التشغيل الثاني يلتقط الخطافات التي تضيف مسارات مكررة. ثم أعد التشغيل، لأن الاستمرارية خاصية مختلفة عن الصحة.

النفق الذي ينجو من تجديد وإعادة تشغيل له مالك واستثناء عامل. النفق الذي ينجو من إعادة تشغيل يدوية فقط ليس له أي منهما، وسيفشل عند الحدث التالي الذي لا يمكنك جدولته.