هل يمكن لرابط OpenVPN ذي المفتاح الثابت أن يخدم عدة عملاء؟

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

نظيران ومفتاح واحد ولا حالة لكل عميل: هذا الشكل هو القصة كلها لهذا النمط.

ما الغرض من نمط المفتاح الثابت

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

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

لهذا حد النظيرين بنيوي وليس إعدادًا يمكن تغييره.

لماذا لا يمثل client-to-client القطعة الناقصة

client-to-client يتحكم في ما إذا كان للعملاء المتصلين أن يتبادلوا حركة المرور عبر الخادم. وهو لا يسمح بدخول عملاء ولا يمنح هويات ولا ينشئ نمط خادم لم يُعد، وفي إعداد المفتاح الثابت لا توجد قائمة عملاء ليحكمها.

الالتباس الشائع الآخر يتعلق بمادة tls-crypt أو tls-auth. يمكن لخادم TLS أن يشارك أحد هذين المفتاحين بين جميع العملاء، لأنه يحمي قناة التحكم لا يثبت هوية كل عميل. والمفتاح المشترك لقناة التحكم في نمط TLS كائن مختلف عن مفتاح بيانات ثابت مشترك، وإن وصل كلاهما كملفات متشابهة.

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

بناء الخادم متعدد العملاء

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

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

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

ثم قرر سياسة التوجيه عن قصد. client-to-client يمكّن حركة المرور بين العملاء في مسار الخادم في فضاء المستخدم، وهو ما تريده أنظمة نشر كثيرة ولا يجوز لبعضها. وهو مفتاح سياسة لا آلية هوية، وينبغي تشغيله لأن التصميم يتطلبه لا لأن درسًا تعليميًا أدرجه.

التحقق من أن العملاء مستقلون فعلًا

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

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

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

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