auth-nocache مع ملف بيانات اعتماد: هل يفيد أم يضر؟

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

طريقتان للإجابة عن طلب بيانات الاعتماد

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

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

بقية هذه المقارنة تتبع هذا الانقسام: معالجة الذاكرة لنموذج، ومعالجة الملف وهوية العملية للآخر.

ما يتخلص منه auth-nocache فعليًا

مع تسجيل دخول تفاعلي، --auth-nocache يزيل النسخة المخزنة من الذاكرة بعد استخدامها. الثمن هو طلب جديد عند كل فترة إعادة تفاوض، لأن الجولة التالية لا تستطيع إعادة استخدام ما تم التخلص منه.

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

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

أين ينكسر المسار المستند إلى ملف

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

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

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

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

الحالة التي تريد الخيار فعلًا

تسجيل دخول يحمل رمزًا لمرة واحدة يريد auth-nocache لسبب مختلف. يُستهلك الرمز ذو الاستخدام الواحد عند المصادقة الأولى، لذا فنسخة مخزنة مؤقتًا عديمة الفائدة عند إعادة التفاوض التالية، وقد تُعاد قيمة قديمة حتى.

هذا سؤال عن نوع بيانات الاعتماد، لا عن مكان تخزينها. كلمة مرور ثابتة في ملف محمي لها طابع معاكس: يجب أن تكون قابلة للقراءة عند كل إعادة تفاوض، والحماية التي تحتاجها على الملف.

أبقِ هذين السببين منفصلين في تعليقات الملف الشخصي، وإلا افترض المسؤول التالي أن الخيار موجود للسبب الذي كان سيختاره.

المقارنة في قرار واحد

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

لا يجعل أي نموذج كلمة مرور مخزنة آمنة بذاته، ولا يجعل أي منهما تحذير بدء التشغيل ذا معنى.

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