أحداث خطاف OpenVPN: لماذا لا يُعد الاسم والطابع الزمني مفتاحًا

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

ابدأ بمعنى متغيرات قطع الاتصال فعليًا. وعندها فقط يصبح لاختيار المعرّف معنى.

ما يحمله خطاف قطع الاتصال حقًا

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

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

لماذا ليس الزوج البديهي فريدًا

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

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

من أين تأتي الهوية المستقرة

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

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

اجعل الإنهاء مشروطًا وقابلًا للتكرار بأمان

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

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

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

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