لماذا ينقطع نفق Azure OpenVPN كل ستين ثانية تقريبًا

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

اقرأ ذلك السطر قبل أن تمس أي مؤقت.

الأسطورة: شيء في المسار يحجب النفق

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

الإيقاع هو الدليل المفيد. المؤقتات تنتجه؛ وفقدان الحزم نادرًا ما ينتجه.

اقرأ سبب الانقطاع قبل المؤقت

OpenVPN يسمي سببه، وكل اسم يشير إلى نظام فرعي مختلف. Session invalidated: KEEPALIVE_TIMEOUT هو مؤقت ينتهي، لذا قارن قيم ping و ping-restart على الطرفين. AUTH_FAILED هو بيانات اعتماد أو حالة شهادة، ولن يساعد أي تغيير في المؤقت. خطأ TLS يعني أن الطرفين لم يصلا إلى مرحلة keepalive إطلاقًا.

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

الفترة المستقرة مؤقت. أما الفترة المنجرفة فالأرجح أنها مشكلة في المسار أو جلسة مزاحة.

مؤقتا keepalive لم يتفقا قط

الملفات الشخصية المصدَّرة من البوابة ما زالت تحمل أحيانًا أسطر keepalive أو ping-restart منسوخة من قالب خادم مجتمعي. تشغّل البوابة كشفها الخاص للقرين الميت وتفرض توقعاتها، وليس مطلوبًا أن يتطابق الجدولان. وعندما يختلفان، يعيد العميل التشغيل وفق جدول لم توافق عليه البوابة أبدًا.

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

أصغر تغيير من جانب العميل هو تحييد المؤقتات في المستوى الأعلى من الملف الشخصي، خارج كل كتلة مضمنة:

keepalive 0 0

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

قد يتحرك اسم الشهادة من تحتك

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

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

ما الذي تغيّره، وبأي ترتيب

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

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

لا يتغير إعداد البوابة إلا بعد تلك الاختبارات الأربعة.