أين تنتمي حصة البيانات الشهرية لكل حساب OpenVPN

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

ثبّت الحصة على حساب، لا على نفق

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

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

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

حدّد الوحدة والاتجاه وحدود إعادة الضبط

يجب حسم أربعة تعريفات كتابةً قبل بدء أي جمع. هل تحتسب الحصة البايتات التي يرسلها العميل، أم البايتات التي يستقبلها، أم مجموعهما؟ هل الغيغابايت 10^9 بايت أم 2^30؟ في أي ساعة محلية وفي أي منطقة زمنية تنقلب الفترة؟ وما الذي يقيسه العدّاد بالضبط، مع أن الحمل الإضافي للنفق وإعادات الإرسال مشمولة بينما حجم ملف التطبيق وفاتورة المزوّد ليست كذلك؟

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

حوّل إجماليات البايتات إلى فرق واحد محتسب

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

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

rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge  = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now

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

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

اجعل النفاد يمنع القبول، لا يقتل النفق فحسب

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

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

إعادات الاتصال القائمة على الرموز تستحق اختبارًا خاصًا. يستطيع OpenVPN 2.6 التحقق من رمز جلسة داخليًا باستخدام auth-gen-token، متجاوزًا نداء المصادقة الخارجي الذي كانت وحدة التحكم لديك تستخدمه لفرض الحد. لذا فإن الرمز الذي ما زال صالحًا يثبت الهوية لا الحصة المتبقية، ويجب على كل نسخة عميل جديدة أن تستشير السجل أيضًا. وإذا فعّلت management-client-auth بدلًا من ذلك، تصبح وحدة التحكم هي المُصادِق وترث التزام تحليل حالة الجلسة ورفض الرموز المنتهية أو غير الصالحة بنفسها.

اقبل التجاوز الذي يخلقه أخذ العينات

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

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

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